- db-wg - mailman.ripe.net

Impact Analysis of Removing MD5 Hashed Passwords from the RIPE Database
by Edward Shryane 19 Sep '24

19 Sep '24

Dear colleagues, At RIPE 88 during the DB-WG session, I mentioned the need to replace MD5 hashed passwords that are used for authenticating updates in the RIPE Database. Now I’d like to present an impact analysis of doing this, what the alternatives are, and a draft migration plan. Please let me know your feedback. I plan to finalise the contents and present at RIPE 89 next month. Regards Ed Shryane RIPE NCC --- Introduction ------------ In the RIPE Database, some maintainers contain passwords which are protected using the MD5 hash algorithm. However MD5 has been found to have vulnerabilities which make it unsuitable for continued use. Accordingly the RIPE NCC plans to soon phase out the use of MD5 hashed passwords. We describe some alternatives, and a migration plan to deprecate passwords. Why Not Switch to a Stronger Hash Algorithm? -------------------------------------------- Stronger cryptographic hash algorithms exist, but we do not want to simply replace MD5 with a different hash algorithm. If a hash is compromised it would still need to be replaced, so the risks of exposure remain, regardless of the hash algorithm used. It is better to completely remove all password hashes from maintainer objects, so they are no longer part of the RIPE Database. Alternatives to Passwords ------------------------- In order to successfully migrate away from MD5 hashed passwords, we must also ensure that there are viable alternatives, in particular for non-interactive updates. What Alternatives Already Exist? -------------------------------- A number of alternative authentication methods are already available in the RIPE Database: * SSO (Single Sign-On). A user registers a RIPE NCC Access account and associates it with their maintainer. * Over 80% of maintainers already contain an SSO account for authentication. * SSO is an adequate replacement for passwords for interactive updates. * However SSO can only be used interactively (through the RIPE Database website), and not for batch (non-interactive) updates. * PGP can be used to authenticate updates using a signature. * There is no shared secret between the client and server, unlike with passwords. * However PGP can only be used in Syncupdates or Mailupdates, not with the REST API. * PGP signatures were used to authenticate 33% of all successful updates in the past year, but only 6% of all maintainers reference a PGP key, so it is not a widely used solution. * X-509 Certificates can also be used to authenticate updates * Use S/MIME to create a signed mailupdate message * Use Client Certificate authentication with the REST API. * X.509 signed updates were only used in a handful of updates in the past year. Only 29 maintainers reference an X.509 certificate. This means that alternatives to passwords for non-interactive (batch) updates are not widely used. In order to completely replace passwords there must be a usable alternative. Introducing API Keys -------------------- In addition to the existing alternatives, we also propose to introduce API keys linked to an SSO account to replace passwords, that is convenient and secure. An API key is an auto-generated string associated with a user account that can be used to authenticate updates on behalf of that user. They are already widely used across the Internet, although by different names (e.g. GitHub Tokens, Google Application Passwords, AWS does use API keys, etc.). Other RIPE NCC services already make use of API keys, for example the LIR Portal and RIPE Atlas. We are investigating how to create a new service to allow RIPE NCC Access accounts to generate API keys that can be used to authenticate updates to the RIPE Database. The advantages include: * RIPE NCC Access accounts are associated with a maintainer in the RIPE database and not any API keys, so there are no credentials that can be leaked. * API keys can be associated with a SSO account, so there is accountability to identify who authenticated an update. * We can automatically expire API keys after a certain time limit for increased security, in case they are leaked. * Users can more easily migrate away from passwords as API keys can be used in the same way. Deprecating Insecure Transport of Credentials --------------------------------------------- In addition to deprecating MD5 hashed passwords, we also plan to deprecate any insecure ways of transporting credentials, so that updates are kept secure. Using Mailupdates with password authentication can be insecure, as the mail message may be sent unencrypted, or the message may be spooled to disk during transport, so could be leaked. We found that 16% of successful Mailupdates contained a password. We will no longer allow Mailupdates using a password and only allow an X.509 or PGP signature for authentication. Using Syncupdates over plaintext HTTP with a password can be insecure. We found that 3% of total successful Syncupdates requests over HTTP used a password. Currently a warning is returned if this happens. We will no longer allow HTTP and only allow Syncupdates over HTTPS using an API key or a PGP signature for authentication. Password authentication of Whois REST API queries and updates already require HTTPS, and in the future it will be possible to authenticate using API keys, in addition to client certificate authentication. How Are Updates Performed? -------------------------- In the past 12 months (July 2023 to June 2024 inclusive), there were 4.3 million successful updates to the RIPE Database in total. +-------------+-------------------+-----------------------+ | | Number of Updates | Percentage of Updates | +-------------+-------------------+-----------------------+ | REST API | 2.4M | 56% | | Syncupdates | 1.0M | 24% | | Mailupdates | 0.88M | 20% | | TOTAL | 4.3M | (100%) | +-------------+-------------------+-----------------------+ Looking at the authentication method used for each protocol: +-------------+----------+-----+-----+ | | Password | SSO | PGP | +-------------+----------+-----+-----+ | REST API | 76% | 24% | N/A | | Syncupdates | 16% | 16% | 68% | | Mailupdates | 16% | N/A | 84% | | TOTAL | 50% | 17% | 33% | +-------------+----------+-----+-----+ Passwords were used in half of all successful updates (2.15M out of 4.3M) in the past year. How Many Maintainers Use Password Authentication? ------------------------------------------------- There are approximately 62,000 maintainers in the RIPE database. About 18,000 maintainers have MD5 hashed passwords. About 3,000 of those maintainers only have MD5 hashed passwords and no alternative authentication method. So most maintainers don’t use passwords, and most of those that do have at least one alternative. Any maintainers using passwords will soon need to migrate to an alternative. As mentioned already, 18,000 maintainers contain at least one MD5 hashed password. About half of all updates in the past year were authenticated with a password, but these were submitted by only 1,362 maintainers. There are about 3,000 maintainers that only have an MD5-PW auth: attribute. Only 872 of those maintainers made a successful update in the past year. It may seem that deprecating passwords will be a tall order. However, we found that only a minority of maintainers use them regularly. How Many Maintainers Use an Alternative Authentication Method? -------------------------------------------------------------- There are 51,000 maintainers containing at least one RIPE NCC Access account (SSO). In the past year, we found that 23,000 maintainers authenticated using SSO, by far the most of any authentication method. There are about 4,000 maintainers which reference a PGP key-cert that is not expired. One third of all updates are authenticated with a PGP signed message, but these were submitted by only 477 maintainers. There are only 29 maintainers which reference an X.509 key-cert that is not expired. There are only a handful of updates authenticated using an X.509 certificate each year. Migration Plan To Deprecate Passwords ------------------------------------- Firstly, existing maintainers do not need to wait for any migration away from MD5 hashed passwords as they can be replaced already. If you only perform updates interactively through the RIPE database website, then you can rely on SSO authentication. If you perform batch updates, you can switch to PGP signed updates or client certificate authentication. Following is an outline of how we can migrate away from passwords. We ask the DB-WG community for their feedback and suggestions, and will update the migration plan accordingly. In the coming months, we plan to first phase out any insecure ways of transporting credentials in Mailupdates and Syncupdates, namely: * Stop allowing passwords in Mailupdates. Any mailupdates requests containing only password authentication will fail with an error. Users must switch to PGP signed mailupdates or use the REST API or Syncupdates. * Stop allowing HTTP for Syncupdates. Any Syncupdates requests over HTTP will fail with a 403 Forbidden response. Users must switch to HTTPS. We will notify the DB-WG and affected maintainers in advance of any changes. Once the design is ready and approved, we will introduce API keys alongside password authentication as an alternative for non-interactive updates. Finally we will begin to deprecate passwords as follows: * Encourage maintainers using passwords to switch to an alternative * Stop allowing new passwords to be added to a maintainer * Set an expiration date for existing passwords * Remove passwords automatically from maintainers once they have expired We will plan together with the DB-WG and notify affected maintainers in advance of any changes. The details and timing are to be agreed with the DB-WG. Impact Analysis --------------- What is the impact on RIPE NCC services of removing MD5 hashed passwords in the RIPE Database? RIPE Database Queries Deprecating MD5 hashed passwords will have little impact on queries to the RIPE Database, except for authenticated queries for a MNTNER object. In that case, a password will no longer be allowed for authentication when querying for an unfiltered MNTNER object, and unfiltered MNTNER objects will no longer contain any password hashes. An existing alternative to using password authentication for authenticated queries is client certificate authentication, and in the future API keys will be provided as an additional alternative. RIPE Database Updates Passwords will no longer be allowed when using any RIPE Database update interface. For the Whois REST API, passwords will be replaced by client certificate authentication and API keys. Affected maintainers will need to migrate to an alternative. HTTPS is already required for updates. For Mailupdates, password authentication will no longer be allowed. Affected maintainers will need to migrate to signed updates or use an alternative transport. For Syncupdates, HTTP will no longer be allowed and passwords will be replaced by signed updates or API keys. Affected maintainers will also need to migrate. New Member Signup No impact to New Member Signup, as new LIRs are not asked for a password during the process. All LIR contacts are added as SSO accounts to the newly created maintainer during LIR activation. However, users can still add a password themselves to authenticate updates. LIR Portal There is no impact to interactive users of the LIR Portal, as authentication of changes in the RIPE Database (e.g. Set Default Maintainer) is done using their SSO account credentials. There is no impact to the API Keys feature in the LIR Portal, as these requests are not authenticated with a password. TEST Environment Currently in the TEST environment we depend on a “well-known” maintainer password to authenticate changes normally performed by the RIPE NCC. This will be changed to allow a user to make changes (e.g. setup test data) without a password. However we need to consider how to allow this while also keeping the authentication model consistent with the RIPE Database. RIPE Database Associate Certification When a user signs up to the RIPE Database Associate certification course, we provide them with resources and a user maintainer with a password. In future, a user will use their SSO account credentials to create and update their objects in the database. Training Courses The training materials used in RIPE NCC courses will have to change to account for API keys. Also we will encourage use of other alternatives such as signed updates and client certificate authentication. (END)

8 16

Whois Release 1.114
by Edward Shryane 19 Sep '24

19 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 12

Draft Agenda & Call for Presentations @ RIPE89 - Database Working Group
by William Sylvester 18 Sep '24

18 Sep '24

All, We are about six weeks out from the start of RIPE89 in Prague, Czechia. Our session will be after the morning coffee break @ 11:00 in the Main room on 31 October (Thursday). Please take a look at the NWIs to foster good discussion at the meeting. The NWIs are viewable at: https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items/ Below is the current draft agenda, please feel free to offer feedback as appropriate. We still have space on the agenda for presentations. If you have an interest in presenting to the working group please contact the Database Working Group Chairs at db-wg-chairs(a)ripe.net<mailto:db-wg-chairs@ripe.net>. Best regards, William, Peter, & David DB-WG Chairs A. Introduction - 15 min * Welcome * Scribe * Agenda B. Operational Update– 30 mins Edward Shryane, RIPE NCC D. NWI Review – 30 mins, WG Chairs D. [ YOUR PRESENTATION COULD BE HERE ] – 10 mins, WG Chairs Z. AOB (open discussion)

1 0

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

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 23 Jun '24

23 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

So what happened last night to the DB?
by Hank Nussbacher 17 Jun '24

17 Jun '24

3 2

Re: [db-wg] So what happened last night to the DB?
by Lutz Donnerhacke 17 Jun '24

17 Jun '24

> I have thought about doing it so, as I was also included as the > maintainers of the object. The real question is: why did blake66 made > such an object ? And how could we prevent something alike to happen > again (not an easy question -- maybe limiting the amount of mnt-by ?) Especially the DB should not process backscatter messages from MAILER-DAEMON.

1 0

Proposal to allow non-ASCII characters in "org-name:", "person:" and "role:" attributes
by Edward Shryane 28 May '24

28 May '24

Dear colleagues, Currently the RIPE database only allows a subset of ASCII characters in the "org-name:", "person:" and "role:" attributes, for a few reasons including: * These attributes are also a look-up key and the Whois protocol does not allow specifying character sets in queries. * RPSL names are ASCII according to RFC2622 * Using a normalised name makes the object easier to query * Reading a normalised name is easier to interpret However there are some drawbacks to forcing names to only use a subset of ASCII characters: * Organisations, roles and persons cannot use their actual name if it includes characters outside this subset. * Normalisation is not standard, but is an interpretation done by each maintainer, e.g. characters could be excluded or converted in different ways. Since we support the Latin-1 character set in the RIPE database, I propose we also allow non-ASCII Latin-1 characters in these attributes. Querying for a name can be done either using the latin-1 characters (proposed) or a normalised, ASCII representation (currently). The normalised version will be generated by Whois and stored in a database index for querying. The primary key will also be generated from the normalised version. Please let me know your feedback. Regards Ed Shryane RIPE NCC --- Whois attribute verbose description (copied from the help text). org-name -------- Specifies the name of the organisation that this organisation object represents in the RIPE Database. This is an ASCII-only text attribute. The restriction is because this attribute is a look-up key and the whois protocol does not allow specifying character sets in queries. The user can put the name of the organisation in non-ASCII character sets in the "descr:" attribute if required. A list of 1 to 30 words separated by white space. A word is made up of ASCII alphanumeric characters and additionally: ][)(._"*@,&:!'`+/- A word may have up to 64 characters and is not case sensitive. Each word can have any combination of the above characters with no restriction on the start or end of a word. person ------ Specifies the full name of an administrative, technical or zone contact person for other objects in the database. It should contain 2 to 10 words. A word is made up of ASCII alphanumeric characters and additionally: .`'_- The first word should begin with a letter. At least one other word should also begin with a letter. Max 64 characters can be used in each word. role ---- Specifies the full name of a role entity, e.g. RIPE DBM. A list of 1 to 30 words separated by white space. A word is made up of ASCII alphanumeric characters and additionally: ][)(._"*@,&:!'`+/- A word may have up to 64 characters and is not case sensitive. Each word can have any combination of the above characters with no restriction on the start or end of a word.

9 17

Historical data on deleted objects
by Yang Yu 27 May '24

27 May '24

Hi, According to https://apps.db.ripe.net/docs/Types-of-Queries/Historical-Queries/ , historical query doesn't return data on deleted objects. This behavior makes it difficult to distinguish whether a resource was squatted on / analyze history associated with abuse on the resource. And it is not consistent with other RIR's whowas behavior. Currently on RIPE whowas UI unallocated and deleted objects look exactly the same. https://stat.ripe.net/widget/historical-whois#w.resource=as199256 Last time the discussion came up appears to be https://www.ripe.net/ripe/mail/archives/db-wg/2013-November/004195.html Can history support for deleted objects get implemented? Thanks. Yang

3 5

Preferred names in the database
by Harry Cross 22 May '24

22 May '24

Dear all (copying this to both the Diversity list and the Database list), I hope you’re having a wonderful weekend and recovering from Rome. I’d like to begin thinking about a proposal for preferred names in the database/on resources. Some may have noticed this week (and for a bit prior), I have begun going by Harri instead of Harry. At the moment there is no correct way for me to represent this in the database, as an LIR the details have to match my legal name. I may think about going through the legal processes to change this soon (albeit in the UK this is easier than a lot of places). I know a few people hold their resources under a shell company for this purpose, (e.g I could incorporate Harri Cross Limited to hold the resources and be in the database). This applies to end users who hold PI or ASNs alongside LIRs. It would be good for us to think about a way for these preferred names (and pronouns?) to be shown in the database alongside the process for changing the name of an end user. I know the preferred way a lot of people in this situation would like this to be handled is to totally mask the legal name in the database. The NCC could still validate legal names to know who they are working with - and we will need some compromise here I suspect. A complete lack of verification is of course a bad thing. I have experienced talking to the NCC when handling end users in these situations who have legally name changed and the process seems to be incredibly hard with the lack of understanding on documentation for name changes. Responses from the Registry have included “How can we be sure that <oldName> and <newName> are not identical twins?” (Which in my mind, is rather disrespectful). I also have another name change in process that is being stonewalled by a lack of understanding of documents in different jurisdictions for this. Kind Regards, Harri Sent from Outlook for iOS<https://aka.ms/o0ukef>

3 2

RIPE 88 chair selection
by David Tatlisu 21 May '24

21 May '24

Dear colleagues, This is a brief reminder that the DB WG co-chair selection will happen at the Database Working Group session on Thursday. Please have your personal Meetecho link ready. We planned a time slot to discuss the recent changes in the chair selection process, as there has been a lot of discussion between the chairs. Kind regards, David RIPE DB WG co-chair

1 0

Whois Release 1.112
by Edward Shryane 21 May '24

21 May '24

Dear colleagues, RIPE Database release 1.112 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Thursday 16th May. The 1.112 release has the following main changes: * NWI-4: Add ALLOCATED-ASSIGNED PA inetnum status (#1432) * Set Charset Flag (#1450) * Don't allow "mnt-lower" on assignments (#1452) * Fixed Syncupdates HELP Bug (#1453) * RDAP Link Title is a String not List (#1445) * Route ROA checker (#1416) * Allow inverse query for sponsoring-org from all addresses (#1431) * Return 404 on invalid NRTMv4 notification file path (#1422) The release notes are on the website: https://rc.db.ripe.net/docs/Release-Notes/#ripe-database-release-1-112 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 30th April. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

2 5