- db-wg - mailman.ripe.net

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

IPv6 object update error
by Jure Knez 04 Jul '24

04 Jul '24

Hello! I'm trying to update an IPv6 object in RIPE databease via API and I'm getting an error: <errormessages> <errormessage severity="Error" text=""%s:" attribute not allowed for resources with "%s:" status"> <args value="mnt-lower"/> <args value="ASSIGNED"/> </errormessage> <errormessage severity="Info" text="Value %s converted to %s"> <attribute name="source" value="RIPE"/> <args value="ripe"/> <args value="RIPE"/> </errormessage> </errormessages> I started getting this error about a month ago. Regards Jure

3 4

Re: [db-wg] So what happened last night to the DB?
by Hank Nussbacher 03 Jul '24

03 Jul '24

> Dear colleagues, > > We are aware of an incident affecting Whois updates yesterday evening, which we are continuing to investigate. We will keep the DB-WG informed. > > Regards > Ed Shryane > RIPE NCC There is still ongoing activity with perhaps malicious whois updates. See attached. Regards, Hank

8 11

Whois Release 1.113
by Edward Shryane 01 Jul '24

01 Jul '24

Dear colleagues, RIPE Database release 1.113 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Monday 1st July. The 1.113 release has the following main changes: * Inetnum AGGREGATED-BY-LIR status (implements RIPE-822 policy) (#1467) * Enable Client Auth Certificate for REST API lookup (#1475) * ROA Overlapping INVALID ROA and VALID ROA fix (#1470) * Java 21 Support (#1440) The release notes are on the website: https://apps.db.ripe.net/docs/Release-Notes/#ripe-database-release-1-113 More information on the Release Candidate environment can be found on our website: https://apps.db.ripe.net/docs/Release-Notes/ The data in the RC environment is a dummified copy of production from 12th June. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

2 1

Whois Release 1.112.1
by Edward Shryane 24 Jun '24

24 Jun '24

Dear colleagues, RIPE Database release 1.112.1 has been deployed to the PRODUCTION environment just now. This is a bugfix release to help mitigate the ongoing production issue caused by many updates containing objects with an unusual amount of references. This is the only change from release 1.112. We will also apply this change to the upcoming 1.113 release (due next Monday, 1st July). We will continue to monitor for any more incidents, and will publish a full post-mortem later. Regards Ed Shryane RIPE NCC

1 0

RPSL for for foreigh IPv6 space
by Randy Bush 24 Jun '24

24 Jun '24

hi, All of RGnet's address space, mostly legacy, is in the RIPE whois, with RPKI etc. Except ... RGnet has three IPv6 /48s from NTT. Cogent filters BGP based on RPSL, and wants the RPSL for our ASs to be in the appropriate RPSL route6: objects, each with the appropriate AS. This is pretty old-fashioned and reasonable. Do we figure out how to register the route6: objects in NTT and presume Cogent will pick them up across IRR instances? Do we try some hack to violate the RIPE database's pristine authority model? Do we give up on this silly IPv6 stuff? [ just kidding, gert :) ] Surely other have been here before us. randy

3 2

RIPE Policy document updated “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region” (ripe-826)
by Angela Dall'Ara 20 Jun '24

20 Jun '24

Dear Colleagues, The RIPE policy “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region” has been updated to align with the implementation of NWI4, done in Whois release 1.112, which added the option to change the status of an IPv4 allocation object in the RIPE Database from “ALLOCATED PA” to “ALLOCATED-ASSIGNED PA” when the whole address space is assigned to the LIR infrastructure or for use by an End User with services provided by the issuing LIR. The new document is called ripe-826 and is available at: https://www.ripe.net/publications/docs/ripe-826/ Please note that also the following has been updated: 1) In the Abstract: The link to the webpage where to find information on the Address Policy WG from https://www.ripe.net/participate/ripe/wg/ap to https://www.ripe.net/community/wg/active-wg/ap/ 2) In 1.1 Scope: The link to the webpage listing the RIPE community’s policies: from https://www.ripe.net/ripe-policies to https://www.ripe.net/publications/docs/ripe-policies/ 3) In 5.3 Sub-Allocations The option to ask for a conversion of PI to PA via LIR Portal has been added. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

1 0