- db-wg - mailman.ripe.net

Whois Release 1.114
by Edward Shryane 06 Sep '24

06 Sep '24

Dear colleagues, RIPE Database release 1.114 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Thursday 19th September. This release has the following main changes: * NRTMv4 Key Rotation (#1484) * HTTP DoS Filter for Update Requests (#1495) * HTTP block IP Filter (#1498) * Add Warning When Password Authentication is used in Mailupdates (#1511) The release notes are on the website: https://docs.db.ripe.net/Release-Notes/#ripe-database-release-1-114 More information on the Release Candidate environment can be found on our website: https://docs.db.ripe.net/Release-Notes/#release-candidate-environment The data in the RC environment is a dummified copy of production from 2nd September. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

6 10

Force-delete of route object not possible as aut-num resource holder
by Wessel Sandkuijl 04 Sep '24

04 Sep '24

Hi all, RIPE NCC has assigned me an ASN a couple of years ago. During some routine checks I noticed a few route objects with my ASN in it which were created long before the ASN got assigned to me. When trying to force-delete these objects I was unable to. After contacting RIPE NCC this is apparently by design, and RIPE NCC was unable to delete them either because the route objects were protected by a valid maintainer. They suggested I contact the original creator of the objects (which I couldn't, the email bounced), or contact the inetnum resource holder and ask them to (force) delete the route objects. I find it odd that as ASN resource holder I am unable to force-delete objects referencing the ASN that is assigned to me. I'm apparently not the only one. From what I've been told requests from ASN resource holders to delete route objects referencing their ASN pop up regularly in RIPE NCC support. I think this is something that can be improved. I suggest implementing the option to force-delete a route(6) object as ASN resource holder. This saves both the resource holder and RIPE NCC valuable time. Regards, Wessel

11 13

Joke as-set?
by Hank Nussbacher 23 Aug '24

23 Aug '24

Do we condone using the DB for this idiocy? I notice this as-set has since been deleted: as-set: AS200080:AS-KAT-IS-GAY descr: KAT IS ALSO VERY SHORT descr: THIS IS A JOKE AS-SET members: AS13335 members: AS16509 members: AS15169 members: AS36384 members: AS1 members: AS2 members: AS3 members: AS4 members: AS5 members: AS6 members: AS7 members: AS8 members: AS9 members: AS10 members: AS11 members: AS12 members: AS13 members: AS14 members: AS15 ... org: ORG-TA1687-RIPE tech-c: DUMY-RIPE admin-c: DUMY-RIPE mnt-by: T17HOST-MNT created: 2024-08-22T20:18:34Z last-modified: 2024-08-22T20:58:03Z source: RIPE Regards, Hank

3 2

Changes to the RIPE Database Acceptable Use Policy and Daily Limit Accounting
by Edward Shryane 07 Aug '24

07 Aug '24

Dear colleagues, We would like to share some changes to the RIPE Database Acceptable Use Policy and how we implement the daily limit. The Database team will enable these changes from this Thursday, 16 May 2024 onwards. The RIPE NCC Executive Board approved amendments to the "RIPE Database Acceptable Use Policy" (AUP) in March this year, allowing for an additional method of accounting for RIPE Database queries containing personal data. With this method, the count will be based per user, rather than per IP address, for logged-in users. This allows multiple users to share the same public IP address but be accounted for separately. Previously, an office behind a NAT, for example, would get blocked as all users shared the same query limit. This will no longer be the case, as we will count the number of queries per user based on their RIPE NCC Access (single sign-on) accounts, if they are logged in. For users who are not logged in to RIPE NCC Access accounts, the queries will be counted based on IP addresses. Additionally, we found that the daily limit configured in Whois was inconsistent with the AUP. Along with the other changes described above, we will enforce the daily query limit in Whois in line with the Acceptable Use Policy: * Number of personal data sets returned in queries from an IP address – 1,000 per 24 hours * Number of personal data sets returned in queries from a RIPE NCC Access (SSO) account – 1,000 per 24 hours Users who query for personal data above the daily limit will receive the message below explaining what has happened and what to do next: Access from your host has been temporarily denied. For more information, see: https://apps.db.ripe.net/docs/FAQ/#why-did-i-receive-an-error-201-access-de… The minutes from the March meeting of the RIPE NCC Executive Board are available at: https://www.ripe.net/about-us/executive-board/minutes/2024/174th-executive-… The resolution amending the RIPE Database Acceptable Use Policy is under section 4.6. The updated RIPE Database Acceptable Use Policy is available on our website: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… Regards, Ed Shryane RIPE NCC

8 26

Re: [ncc-services-wg] Changes to the RIPE Database Acceptable Use Policy and Daily Limit Accounting
by Daniel Suchy 07 Aug '24

07 Aug '24

Hi, On 8/7/24 9:06 AM, Andreas Härpfer wrote: > >> For example - it's easy to run VPS somewhere for a few bucks... using an API calls, perform few queries... detroy it and so on and on. This is a technique that a real attacker will use in practice. Because of course even real attacker knows that some AUP limits exist and will be really motivated to hide his activity. >> >> While case rapid address changes within single /64 on IPv6 are hypothetical and speculative. Because it will be quickly visible. Does anyone really think that the attacker wants to be caught quickly? > > Even a cheap VPS typically gets a whole /64 per host (at least in my > experience). So, the possibility to rotate through IPv6 addresses is > actually cheap, easy, and far from hypothetical. > > From that POV it makes perfect sense to me to block whole /64s and > _not_ bother with individual /128s. > But this is still not a solution for situations where the machines used for scraping personal change rapidly. The attacker with knowledge the AUP limits (which are public) will simply change source /64 with sufficient cadence just as it will change the IPv4 source. This is also a real experience with DDoS attacks that targeted the application. Addresses change so quickly and there are so many source networks that such kind of blocking is essentially ineffective. A real attacker who aims to obtain personal data from RIPE will unsurprisingly proceed similarly. - Daniel

1 0

Phone number requirement for person objects
by Cynthia Revström 06 Aug '24

06 Aug '24

Hi, In the DB-WG interim session I mentioned that there's currently a discrepancy between person objects and role objects with regards to contact information. More specifically, person objects currently require a phone number while role objects require an email address. I think we should try to bring person objects more in line with role objects by removing the phone number requirement. Ideally I would want it to be mandatory to have either a phone number or an email address in order to not lose any flexibility but I'm not sure if that is possible. During the session I asked if anyone was opposed to the idea and no one said they were so I would assume that this is relatively uncontroversial but please let me know what you think. -Cynthia

4 6

Postmortem for whois incident on 16th and 24th June
by Mahesh Aggarwal 31 Jul '24

31 Jul '24

Dear colleagues, Please find below the summary of incident for whois updates: When: Between approximately 20:00 UTC on Sunday, 16 June and 01:00 UTC on Monday 17 June, there was an intermittent interruption to the Whois Update service. On 24 June, between 08:03 and 08:21 UTC there was a subsequent incident. Why: The interruption occurred due to several unusual update messages containing many maintainers. Aside from this, there were a number of spurious update notification emails sent to uninvolved maintainers. Bounced mail messages from those maintainers were processed as updates which caused a lot more emails to be generated. Action: At the time of the incidents, we took measures to mitigate the impact to our users. On 24 June, we deployed the 1.112.1 release to production to mitigate this issue (validate max references). On 1 July, another release of whois 1.113.2 was made which improved our handling of multipart/mixed bounced and auto-submitted messages. The release notes are on the website: https://apps.db.ripe.net/docs/Release-Notes/#ripe-database-release-1-113-2 In the following weeks, we continued to monitor the whois updates and we did not observe any further instances since 24 June. We apologise to our users for the inconvenience this interruption may have caused. Regards, Mahesh

1 0

Re: First round of cleanup of Database WG NWIs
by Maria Stafyla 22 Jul '24

22 Jul '24

> > Hi Denis, > > Please find here our response to the request you are referencing: > https://mailman.ripe.net/archives/list/db-wg@ripe.net/message/43T2BW26I46NO… > > > For your convenience, here is our RIPE Labs article explaining the legal > basis for processing personal data in the RIPE Database when it refers to > an individual resource holder or their contact persons: > > > https://labs.ripe.net/author/athina/how-were-implementing-the-gdpr-legal-gr… > > Kind regards, > > Maria Stafyla > > Senior Legal Counsel > > RIPE NCC > > > On 12 Jul 2024, at 12:23, denis walker <ripedenis(a)gmail.com> wrote: > > > > Hi Nick > > > > You seemed to have mixed up many issues here including privacy, data > > verification, 2023-04, legal basis within GDPR, lawful access, etc. I > > actually agree with many of the points you make. In fact I have made > > many of these points myself over a number of years and generally they > > were all ignored by the community. > > > > You may remember I put forward a policy proposal on privacy and data > > verification a couple of years ago. The verification part was totally > > rejected by the community as it would involve some extra work by LIRs. > > The privacy part was rejected as I suggested using consent as the > > basis of processing personal data in the RIPE Database. Arguments were > > made that it is not processed on the basis of consent, which at that > > time was supported by the legal impact analysis. Then we jump forward > > to 2023-04 where the legal analysis said ALL personal data processed > > by the RIPE Database is on the basis of consent. When I asked the > > legal team to clarify that, they remained silent. So right now we have > > no clear idea on what basis any or all personal data in the RIPE > > Database is processed according to the GDPR. I did suggest the legal > > team writes a very clear statement defining the basis (or bases) on > > which personal data is processed. There was no response to that. I > > still think we need this clearly defined in a way that does not keep > > changing, depending on what policy proposal is being reviewed. > > > > BUT...none of this has anything to do with historical queries. Ed was > > very clear that PERSON and ROLE objects are NOT subject to historical > > queries and never will be. No one will be allowed to sign an NDA and > > get access to this personal data. So although I agree that all of what > > you have said does need to be addressed, it is not relevant to NWI-17. > > Nothing you have said justifies the complexity required to create a > > split level access to historical operational data. > > > > btw it looks like you have taken over my role of writing long, > > detailed emails...that few people, if any, read. > > > > cheers > > denis > > > > ======================================================== > > DISCLAIMER > > Everything I said above is my personal, professional opinion. It is > > what I believe to be honest and true to the best of my knowledge. No > > one in this industry pays me anything. I have nothing to gain or lose > > by any decision. I push for what I believe is for the good of the > > Internet, in some small way. Nothing I say is ever intended to be > > offensive or a personal attack. Even if I strongly disagree with you > > or question your motives. Politicians question each other's motives > > all the time. RIPE discussion is often as much about politics and self > > interest as it is technical. I have a style of writing that some may > > not be familiar with, others sometimes use it against me. I also have > > OCD. It makes me see the world slightly differently to others. It > > drives my mind's obsessive need for detail. I can not change the way I > > express my detailed opinions. People may choose how to interpret them. > > ======================================================== > > > > On Fri, 12 Jul 2024 at 01:26, Nick Hilliard <nick(a)foobar.org> wrote: > >> > >> Radu, > >> > >> Radu Anghel wrote on 11/07/2024 20:57: > >>> The lack of authentication / checks for creating person objects could > >>> indeed be a problem, but I wouldn't choose to remove the requirement > >>> for having addresses and phone numbers associated with globally unique > >>> numbers because of this. > >>> > >>> I can think of the following situations: > >>> > >>> 1) the object is created by a LIR because the person is a customer > >>> => the LIR is responsible for maintaining the accuracy of this data > >>> according to [1] > >>> > >>> 2) the object is created by the person > >>> => if the object is associated with any resource, a LIR is again > >>> responsible for the accuracy > >>> > >>> 3) the object is created by a third party, not the person, neither the > LIR > >>> => if the object is associated with any resource it is the LIR's > >>> responsibility, as it is their customer > >> > >> In all these cases, the RIPE NCC is co-processor of the data, and has a > >> responsibility for GDPR compliance. > >> > >>> If the person object is not associated with a resource I see no > >>> problem with the accuracy of the information. > >> > >> I understand where you're coming from on this, but the legal situation > >> is that this doesn't matter: personal data is personal data, regardless > >> of what sort of object it's associated with or whether it's associated > >> with any object at all. > >> > >> Unassociated person: objects are deleted after a period of time. This > >> isn't incidental. > >> > >>> I used the LEAs as an example because RIPENCC constantly refers them > >>> to the public information available in the database, if such even > >>> potentially wrong information did not exist how would the RIPE NCC > >>> reply to their requests? [2] > >> > >> It's totally worth pointing LEAs to data relating to ALLOCATED-PA and > >> ASSIGNED-PI because that will tell them where to serve the summons. But > >> its often pointless for ASSIGNED-PA which makes up the majority of the > >> objects (and consequently the person: objects) in the ripedb. > >> > >> It would help to clarify in the RIPE DB what data is authoritative, i.e. > >> subject to checks, and what sort of checks. > >> > >>> I did not suggest in any way that accurate registration details for > >>> number resources are legally required in the NL, they are required by > >>> the RIPE NCC contracts that comply with both GDPR and NL laws. > >>> > >>> The RIPE NCC Privacy Statement [3] informs that the database shows > >>> registration details and contact information such as names, phones, > >>> postal addresses. This is a legal basis to publish these details since > >>> you have to agree with it in order to register resources, as a person > >>> or organization. > >> > >> For ASSIGNED-PI and ALLOCATED-PA, the resource holder needs to provide > >> their details, for sure. That would constitute performance of a > >> contract. But that's not the same as publishing it to the world, > >> regardless of what it says in the T&Cs. You can't make the leap from > >> stating that just because the RIPE NCC Privacy Statement says the > >> information will be published, that this implies that "legal basis" is > >> satisfied as a basis for data processing. This is not how GDPR works. > >> > >> The difficulty here is that there is a mixture of PII and non-PII in the > >> database. There's no difficulty with non-PII. The problem is that it's > >> all mixed up together. > >> > >>> GDPR does not apply to company details, and both companies and natural > >>> persons agree with this information being published when requesting > >>> resources. So there is both consent and a legitimate interest in > >>> having this data and publishing it. [4] > >> > >> You're correct, partly, on company details. For example, role email > >> addresses or telephone main lines are not subject to GDPR. However, > >> individual contact details within a company can be. E.g. > >> Joe.Schmoe(a)example.com could be considered personally identifiable > >> information, but accounts(a)example.com definitely not. > >> > >> Consent is complicated in GDPR. Legally it must be possible to withdraw > >> consent without detriment. So if the GDPR basis for processing data is > >> "consent", and the resource holder withdraws that consent, you gotta > >> respect that and nothing can change contractually. This is something > >> that the european data protection board has started taking action on in > >> the last couple of years, and there is now case law to support this > >> position. > >> > >> The rationale behind this is that if there is pressure or coercion > >> involved, then it's not consent: it's pressure or coercion. > >> > >> Consent in GDPR gives the right for a data processor to hold information > >> about a data subject if the subject agrees. But it does _not_ give the > >> data processor the right to withdraw service if that consent is > withdrawn. > >> > >> There are arguable points in Legitimate Interest. If this is the basis > >> for publishing the data, then this is why the RIPE Community needs to > >> ensure that the policies and data management practices are assessed, > >> i.e. to ensure that if this information is published on the basis of > >> legitimate interest, then there is careful consideration of this within > >> GDPR, that the policies are compliant with GDPR and that the practice is > >> compliant with the policies. > >> > >> In other words, if the RIPE NCC / RIPE Community makes a claim that a > >> specific legal basis is used for processing data, then the justification > >> for that basis must be analysed carefully and clearly described. > >> > >>> I understand that some might not want this type of information related > >>> to them in a public database, but registering globally unique > >>> resources is not mandatory so it is a choice they have to make. There > >>> is nobody forcing people to become *-c contacts for resources, it is > >>> either their job, so the details except the name are company details, > >>> or their choice. > >> > >> See above on consent and whether personally identifiable information in > >> the context of corporate operation constitutes PII. > >> > >>> Only because the RIPE NCC validated part of the details at some point > >>> in time is not a guarantee that ALLOCATED PA is accurate either. > >> > >> You're correct that it doesn't guarantee accuracy, but the ARC is a > >> process which satisfies due diligence, i.e. it's a visible and tangible > >> demonstration that the RIPE NCC is proactive about maintaining data > >> accuracy. > >> > >>> Companies and persons (that are LIRs and have ALLOCATED PA) sometimes > >>> change addresses or phones and updating the RIPE DB might not be among > >>> the things on their to-do lists. > >>> > >>> So, for the particular case of the RIPE DB, I disagree with this > >>> principle, I think that having some potentially wrong data is much > >>> better than having an anonymous registry. There is a clear way to > >>> trace who is responsible for keeping the data accurate, and procedures > >>> to "persuade" them to fix it. > >>> > >>> It does not really matter if the contact details are found in a person > >>> or role object, but I think it is important to continue to have them. > >> > >> This is one of the issues which the DBTF has recommended to get some > >> attention. The one thing we can all agree on is that it's a difficult > area. > >> > >> Nick > >> > >> > >>> Best, > >>> > >>> Radu > >>> > >>> [1] https://www.ripe.net/publications/docs/ripe-791/ > >>> [2] https://www.ripe.net/publications/docs/ripe-819/ > >>> [3] https://www.ripe.net/about-us/legal/ripe-ncc-privacy-statement/ > >>> [4] > https://commission.europa.eu/law/law-topic/data-protection/reform/rules-bus… > >>> > >>> On Thu, Jul 11, 2024 at 8:22 PM Nick Hilliard <nick(a)foobar.org> wrote: > >>>> > >>>> Radu, > >>>> > >>>> there are a lot of things to unpick in regard to personal information > in > >>>> the RIPEDB. > >>>> > >>>> Person objects are not authenticated or checked, except inside the > scope > >>>> of RIPE ARC checks. Second and third parties can create person: > objects > >>>> for people without verification either for the email or phone number. > So > >>>> there are serious questions about the accuracy of the existing data in > >>>> the database. This alone needs a good deal of attention and where > >>>> necessary, remediation. > >>>> > >>>> As a general principle, no data is better than incorrect data. > >>>> > >>>> In regard to who uses the data, and what they use it for, LEAs are one > >>>> of many classifications of RIPE DB data consumers. The data might be > of > >>>> use to them if it's verified (e.g. ARC checks / LIR verification / PI > >>>> contractual obligations / etc), but for other stuff like unverified > >>>> person objects, or ASSIGNED-PA objects, there is no guarantee of any > >>>> form about whether the data is accurate in any way. > >>>> > >>>> In regard to your question, accurate registration details for this > data > >>>> are not a legal requirement in NL, and LEAs do not have statutory > access > >>>> to the data. That said, there's an obligation on the RIPE NCC to > ensure > >>>> that the policies and practices for accessing this data are legal and > >>>> fit for purpose. That will includes providing access to LEAs within > the > >>>> scope of GDPR in the normal course of events, or e.g. providing access > >>>> to internal data following a court order. > >>>> > >>>> When the DBTF noted that accurate registration of data and removal of > >>>> unnecessary data (= data minimisation) from the RIPE DB should be > >>>> followed up in a way that the DBWG thought was appropriate, they did > >>>> this because these are legal requirements. In this context, it would > be > >>>> unwise to drop this from the DBWG's list of outstanding tasks. > >>>> > >>>> Nick > >>>> > >>>> Radu Anghel wrote on 08/07/2024 18:36: > >>>>> I also support dropping NWI-17. > >>>>> > >>>>> Removing contact information (address/phones) from the database just > >>>>> because "it looks like PII" would get more confused LEAs contacting > >>>>> RIPE and just defeat the purpose of the DB - a way to find contact > >>>>> information for _who_registered_this_resource_. > >>>>> > >>>>> For GDPR there is the "legitimate interest" when dealing with > persons, > >>>>> while company addresses are not PII at all. > >>>>> > >>>>> Some persons found ways to keep the DB "accurate" regarding phone > >>>>> numbers, among other things, just check out a few examples > >>>>> nic-hdl: haz > >>>>> nic-hdl: fsci > >>>>> > >>>>> Radu > >>>>> > >>>>> On Sat, Jul 6, 2024 at 4:33 PM Nick Hilliard via db-wg < > db-wg(a)ripe.net> wrote: > >>>>>> > >>>>>> Denis, > >>>>>> > >>>>>> denis walker via db-wg wrote on 03/07/2024 17:33: > >>>>>>> The Task Force (TF) made the recommendation in NWI-17, but did not > >>>>>>> give any justification for it. > >>>>>> > >>>>>> the justification is included in the final DB-TF report which was > >>>>>> published as ripe-767. The recommendations in the various NWIs > should be > >>>>>> read in the context of this report. > >>>>>> > >>>>>>> The high cost and low (if any) benefit of splitting this data is > >>>>>>> completely pointless. [...] > >>>>>>> > >>>>>>> My recommendation is that we drop NWI-17. > >>>>>> > >>>>>> The DB-TF considerations behind NWI-17 related to GDPR, so this > wasn't a > >>>>>> recommendation that came out of nowhere. It would be a better idea > to do > >>>>>> something about the recommendation rather than unilaterally > dropping it. > >>>>>> > >>>>>> Since 2021, ML has become a thing. It would be interesting to see > if > >>>>>> any of the LLMs would return anything useful in response to a query > >>>>>> along the lines of "provide a list of all database objects > containing > >>>>>> information which looks like it's PII". > >>>>>> > >>>>>> Nick > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg > >>> _______________________________________________ > >>> db-wg mailing list -- db-wg(a)ripe.net > >>> To unsubscribe send an email to db-wg-leave(a)ripe.net > >>> > >> _______________________________________________ > >> db-wg mailing list -- db-wg(a)ripe.net > >> To unsubscribe send an email to db-wg-leave(a)ripe.net > > _______________________________________________ > > db-wg mailing list -- db-wg(a)ripe.net > > To unsubscribe send an email to db-wg-leave(a)ripe.net > >

1 0

First round of cleanup of Database WG NWIs
by Peter Hessler 14 Jul '24

14 Jul '24

Hello Working Group, As you all know, the Database Working Group uses a different process from other working groups, and have Numbered Work Items instead of Policy Development Process. We've had many Items on the list, and some have been there since we created the NWI process. So, the Chairs have decided that we need to go through and clean up the list so we can complete the items we wish to complete. For this round, we'd like us to review two NWIs that are similar to each other. https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items/ NWI-2 - Displaying history for database objects where available NWI-17 - Historical data We ask the working group to discuss these two Items and decide if the WG can confirm the problem statements and provide feedback if either of these Items are still a problem that should be persued. We ask for discussion on list until Friday July 5th. Peter Hessler on behalf of the Database WG Chairs

12 20

Historical Queries Statistics
by Miguel Mosquera 05 Jul '24

05 Jul '24

Good Morning all! We'd like to give you some insight into the use of historical queries. We counted all the 'list-versions' and 'show-version' queries since January this year. We categorise the queries in: resources, organisation and others. - We found an average of a total of 50k historical queries per month between January and April. The average of total queries increased in these last two months (June and May) with an average of 90k. - We found an average of 23k resources (Ipv4, IPv6, ASN) historical queries per month between January and April. The average of these historical queries increases to 42k in May and June. - We found an average of 26k organisation historical queries per month between January and April. The average of these historical queries increases to 48k in May and June. - We found an insignificant amount of other object types (<300 queries) per month. Regards Miguel Herrán RIPE NCC

1 0