- db-wg - mailman.ripe.net

Whois Release 1.115.1
by Edward Shryane 03 Feb '25

03 Feb '25

Dear colleagues, We have just deployed Whois release 1.115.1 to production. This release contains a single change since release 1.115 last week. We fixed an issue where the mntner details were not parsed properly when authenticating an API key, even though the API key was valid. We did not wait for the usual 2 week testing period in the RC environment because this issue was sometimes causing updates using API key authentication to fail. There was no other impact to application security, and no other changes were included. Thanks to the community member who reported this issue. Regards Ed Shryane RIPE NCC

1 0

Using API Keys in the RIPE Database
by Edward Shryane 31 Jan '25

31 Jan '25

Dear colleagues, We have now enabled API keys for authenticating updates in the RIPE database. We have written a RIPE Labs article including a video on how to use this feature: https://labs.ripe.net/author/ed_shryane/using-api-keys-in-the-ripe-database/ Please let me know if you have any comments. Regards Ed Shryane RIPE NCC

2 2

Chicken and egg in regards to inverse
by Hank Nussbacher 30 Jan '25

30 Jan '25

We have a customer with an inverse object (in-addr.arpa) whereby the 3 nameservers listed are long extinct and need to be replaced. So the customer went to Cloudflare and paid to use their 2 nameservers (specifically harley.ns.cloudflare.com and teagan.ns.cloudflare.com). Yet, when I go to RIPE to update their inverse record I get many standard errors that the nameservers do not exist yet to serve this inverse domain. The customer tried to create the zone in cloudflare, but CF asks them to change the DNS in the RIPE object, but to change the RIPE object they need first to have an active DNS zone…. So what is one to do in such a case? Thanks, Hank

3 3

Updated Migration Plan to Remove MD5 Hashed Passwords from the RIPE Database
by Edward Shryane 30 Jan '25

30 Jan '25

Dear colleagues, You will find below an updated draft of the migration plan to remove MD5 hashed passwords from the RIPE Database in 2025. The original migration plan was announced last September to the DB-WG and at RIPE 89 in October: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/FTOPBPOGWIQFQP… Thank you all for your valuable feedback, which we have taken into consideration, and in summary we now plan to deploy support for OAuth 2.0 in mid-2025, and we will delay the phase-out of MD5 hashed passwords completely to the end of 2025. The updated migration plan is as follows: * 30 January: Introduced support for API keys in the RIPE Database. * Q2 2025: Remove all MD5 hashed passwords that have not been used for authentication in the past year. This new step reduces the risk of having so many MD5 hashes in the database in case of a data breach, while minimising inconvenience for maintainers that are actively using passwords. This step will affect about 14,000 maintainers which have an alternative method of authentication (out of 62,000 total maintainers), and about 2,000 maintainers with no alternative method of authentication other than passwords. We will communicate this in advance to the DB-WG and to affected maintainers, and encourage them to switch to an alternative authentication method. * Q3 2025: Introduce support for OAuth 2.0 authentication, which will provide automation, including key rollover. * Q3 2025: Communicate to the DB-WG and affected maintainers that we plan to remove support for MD5 hashed passwords before the end of 2025. * Q3 2025: Select batches of maintainers to migrate away from passwords. * Warn that we will remove their MD5 hashed passwords in one month * Assist anyone who asks for help to switch to an alternative * Remove MD5 hashed passwords in batches * Q4 2025: Remove support for MD5 hashed passwords altogether. After that, any maintainers without an alternative authentication method must follow the “Forgot Maintainer Password” process, or contact the RIPE Database support directly. Please let us know if you have any comments on the details and timing. Regards Ed Shryane RIPE NCC

1 0

Whois Release 1.115
by Edward Shryane 30 Jan '25

30 Jan '25

Dear colleagues, RIPE Database release 1.115 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Thursday 30th January. The 1.115 release has the following main changes: * API key authentication for queries and updates * Use relative path in NRTMv4 update notification file * Add JWS Support To Fix Race Condition in NRTMv4 * NRTMv4 client implementation * Add MNTNER to RDAP Entities Search * Import ARIN and LACNIC IRR database dumps into mirror * Syncupdates will return an error in future if used over HTTP * Mailupdates will return an error in future if a password is used * Include password authentication type in Whois Update notifications * Extend Maximum Length of an Email Address * Allow blocking by source address on Port 43 Queries * Generate mail Message-ID including angle brackets. * Change Database Schema from Latin-1 to UTF-8 The full list of changes is available in the source repository: https://github.com/RIPE-NCC/whois/compare/15434524...930e4aba?expand=1 Please note that because API key functionality in RIPE NCC Access is not available yet, it will not be enabled in the Release Candidate environment for now. The release notes are on the website: https://docs.db.ripe.net/Release-Notes/#ripe-database-release-1-115 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 13th January. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

Identifying IX space in the database
by Ben Cartwright-Cox 23 Jan '25

23 Jan '25

Hey everybody! I was wondering if it was possible to tell if an inetnum or inet6num was assigned for the purpose of an internet exchange. Looking at the inetnum objects for 185.1.0.0/16 (that seems to now be depleted) it does not seem there is anything different between a IX allocation and a regular allocation, in either the delegate file or the actual DB. Anyone know any better? Ben

3 2

ALLOCATED-ASSIGNED PA with another org than the LIR's org itself ?
by Clement Cavadore 16 Dec '24

16 Dec '24

Dear all, I am trying to make my first ALLOCATED-ASSIGNED PA block for one of my end user. It seems that I cannot change the org: line, as it's also the same inetnum than my own LIR. Is there any way to be able to associate another org object to the whole inetnum, without loosing the link with the parent LIR of that block ? Thanks in advance for your help ! Kind regards, Clément Cavadore

4 4

sub-allocation
by denis walker 31 Oct '24

31 Oct '24

Colleagues During the discussion in the DB-WG session this morning there was a question about sub-allocations. It was asked if it could be possible to identify when resources have been sub-allocated. Hans Petter said it would be possible to give some indication of this. Well, sorry, but NO. Thanks to 2023-04 it is no longer possible to identify sub-allocations. I believe most people were so focused on making assignments optional, no one gave any thought to the consequences of making the simple technical change of adding the status value 'aggregated-by-lir'. As I pointed out in an email some months ago, this has broken the database in many ways. An LIR with an allocation can now simply split that allocation in half and create two objects with status 'aggregated-by-lir'. The boundary between the two aggregations does not even need to match the boundaries of any more specific ranges. There are NO rules about using this status. Absolutely nothing else more specific to these aggregations needs to be documented in the RIPE Database, in any public domain or notified to the RIPE NCC. The LIR may make a sub-allocation of, say, a /24 below one of these aggregations. Or maybe below both of them, crossing the boundary. You will never know what they have done. That sub-allocation holder may sub-allocate again. They can even sub-allocate the whole sub-allocation. Because you do not need to create objects in the database, there is no reason why the whole range cannot be sub-allocated. There are no rules!!! The same block can be sub-allocated 100 times in a long chain of downstream customers. There are no rules!!! Even if there were rules, they would not be enforceable as no one can 'see' what is being done with these addresses. Finally the whole block could be assigned to an End User. This has serious consequences to rights enforcers and law enforcement trying to find that End User. They will never be found. As things stand, because none of the details of this chain of downstream customers is public information, court orders will be needed to identify each layer. In practice this means 100 sequential court orders, each one identifying the next link in the chain. This could zig zag across multiple countries, multiple legal jurisdictions, in multiple languages.The LIR does not know who the End User is. They only know who they sub-allocated to. Only the last link in the sub-allocation chain knows who the End User is. This situation was created by 2023-04 and a lack of attention to detail. We cannot allow this situation to continue. I would suggest we create/amend a policy so that when an LIR is served a court order to identify the (End) User of an IP address, the obligation is on the LIR to internally follow any such chain of sub-allocations, whether it is 1 or 100, to identify the End User. 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. ========================================================

3 8

API Key Expiry and Shared Credentials in the RIPE Database
by Felipe Silveira 26 Oct '24

26 Oct '24

Dear all, Thank you for your feedback during the recent DB-WG discussion on API key authentication for updates in the RIPE Database. After discussions and careful consideration of the points raised, we have come to the following decisions. Firstly, we will only support the use of API keys created and used by an individual RIPE NCC Access account. When multiple people share the same login credentials, it creates security risks, leaving the system open to potential abuse. For instance, a former employee with access to shared credentials could still access sensitive data after leaving the company. Additionally, it becomes impossible to track who made specific changes in the system, leading to a lack of accountability and an incomplete audit trail, making it difficult to investigate incidents or ensure compliance. Based on these risks, we have chosen not to offer a design that allows API key sharing for better security and traceability. We will help an LIR manage how API keys are used. The LIR Portal will list who has used API keys with the default maintainer in the LIR Portal. We will also display a warning in the LIR Portal when removing or changing a user’s role when they have API keys. Secondly, we will implement mandatory API key expiration dates. We will allow the user to choose the expiry date when creating a new key, but expiry cannot be more than one year. We will notify the RIPE NCC Access user in advance by email and on our web interface(s), if any of their API keys are due to expire soon. Our top priority is the security of everyone’s data. While I understand these decisions will require members to make changes to their scripts, it's essential that we remain compliant and follow best practices here. Kind regards, Felipe Victolla Silveira Chief Technology Officer RIPE NCC

6 9

Re: Agenda @ RIPE89 - Database Working Group
by William Sylvester 25 Oct '24

25 Oct '24

All, We are to start 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 agenda, please feel free to offer feedback as appropriate. 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– 20 mins Edward Shryane, RIPE NCC C. dead-ends and car parks – 25 mins, Lee Kent, beIN D. MD5 and UTF-8– 15 mins Edward Shryane, RIPE E. NWI Review – 10 mins, WG Chairs Z. AOB (open discussion)

1 0