- db-wg - mailman.ripe.net

Whois Release 1.117
by Edward Shryane 03 Apr '25

03 Apr '25

Dear colleagues, RIPE Database release 1.117 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Thursday 17th April. Whois release 1.117 contains the following changes : Inetnum status hierarchy : * Parent status for LIR-PARTITIONED PA cannot be ASSIGNED PA (#1669) * ASSIGNED PA Cannot have less/more specific ASSIGNED PA (#1672) * Aggregation by LIR Parent should not be allowed for Aggregation by LIR (#1673) * Do not allow LIR-PARTITIONED PA under SUB-ALLOCATED PA in (#1702) RDAP RIR Search: * RDAP Self Links Must Have the Type Set (#1685) * RDAP Validate Correct Key Before Redirect (#1689) * RDAP Fix Relation For Cross-Prefix Inetnum Range (#1693) * RDAP Bottom should check Parent does not CONTAINS search term (#1701) * RDAP Non Existing Search IP Terms in TOP and UP (#1703) * RDAP Add "-rdap" prefix to Relations And Change links (#1700) * RDAP Minimum status for Relations (#1705) NRTMv4: * NRTMv4 Correct aut-num object class name in delta file (#1692) * NRTMv4 Client Reject Deltas When Discontinuous and reinitialise (#1699) * NRTMv4 Client Reject update in case client is ahead instead of reinitialise (#1698) OAuth 2.0 (not ready for production use yet) : * Support OAuth 2.0 (#1688) The full list of changes is visible in the source repository: https://github.com/RIPE-NCC/whois/compare/66dd8671...fba36664 The release notes are on the website: https://docs.db.ripe.net/Release-Notes/#ripe-database-release-1-117 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 Release Candidate environment is a dummified copy of production from 31st March. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 0

Removing all MD5 Hashed Passwords Not Used for Authentication in the past year
by Edward Shryane 02 Apr '25

02 Apr '25

Dear colleagues, According to January's updated migration plan to remove all MD5 hashed passwords from the RIPE database in 2025 : https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/NGCRQWJPF7MT24… In Q2 2025, the RIPE NCC plans to remove all MD5 hashed passwords that have not been used for authentication in the past year, to reduce the risk of having so many MD5 hashes in the database in case of a data breach. Using 1st January 2024 as a cut-off, we found this will affect approximately 17,000 out of 62,000 maintainers. Accordingly, between this April and June, we will split these affected 17,000 maintainers into small groups and email each group separately, explaining that we plan to remove any such hash(es) from their mntner object. We will give each group at least one week's notice before updating their mntner object. We will not quote a password hash in any email to avoid exposing it, the maintainer is expected to know which password(s) are in active use. Affected maintainers will be free to create a replacement MD5 hashed password themselves. However as passwords will be removed by the end of 2025, we will encourage them to switch to an alternative authentication method instead, such as API keys. Most affected maintainers have an alternative method of authentication. However, approximately 3,000 of those do *not* have any alternative. If a maintainer is left without any authentication method, the Forgot Maintainer Password process will have to be followed to regain access to the maintainer. We plan to leave these maintainers until last. Please let us know your comments and/or questions regarding this planned change. Regards Ed Shryane RIPE NCC

2 3

RIPE NCC User Research on OAuth 2.0 Authentication
by Edward Shryane 14 Mar '25

14 Mar '25

Dear colleagues, On 16 April, the RIPE NCC will host an Open House from 13:00 to 14:00 CET to discuss and demo the new OAuth 2.0-based authentication solution for maintainers in the RIPE Database. We have developed a prototype and would like to share it with the community to gather your feedback and find out what your needs are. Please join us for this online discussion. Whether you are a database maintainer, network operator or just interested in authentication developments, your feedback will help shape the final implementation. You can sign up at: https://ripe.net/s/open-house-oauth2-authentication Regards Ed Shryane RIPE NCC

1 0

Mailupdates were not applied to the RIPE database
by Edward Shryane 13 Mar '25

13 Mar '25

Dear colleagues, Between approximately 12:34 UTC on March 11th and 08:18 UTC on March 13th, some mailupdates messages were not applied to the RIPE database. This was due to an upgrade of the database software. The current Long Term Support (LTS) release of Mariadb dropped a reference to mysql which the mailupdates script depended on. If you did not receive any acknowledgement for a mailupdates message during this time, then please re-submit the mailupdate. The DB team apologies for any inconvenience this incident may have caused. Regards Ed Shryane RIPE NCC

1 0

Whois Release 1.116
by Edward Shryane 03 Mar '25

03 Mar '25

Dear colleagues, RIPE Database release 1.116 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Monday 3rd March. Whois release 1.116 contains the following changes : * RDAP Relation Searches Endpoint (#1603) * Fixes to RDAP RIR-Search (Basic Searches) Feature (#1611) * Return Abuse-c Entity for RDAP organisation Entity Query (#1659) * Update key-cert lookup URL in update notification (#1631) * Warn if mbrs-by-ref in set object is changed (#1662) * Warn on override if set membership claim is not supported by mbrs-by-ref (#1660) * NRTMv4 use EC p256 key instead of ec25519 (#1645) * Remove old NRTMv4 Update Notification File Links (#1652) * Do not send the SOURCE in NRTMv4 relative URLs (#1654) The full list of changes is available in the source repository: https://github.com/RIPE-NCC/whois/compare/930e4aba...66dd8671?expand=1 We plan to enable API keys functionality in test envionments after this production release. The release notes are on the website: https://docs.db.ripe.net/Release-Notes/#ripe-database-release-1-116 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 Release Candidate environment is a dummified copy of production from 16th February. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

2 1

Something wrong?
by Hank Nussbacher 28 Feb '25

28 Feb '25

Hi, When attempting to update an in-addr.arpa object today, I repeatedly get: Unexpected error: please retry later Did not happen yesterday. Is it just me or everyone? Regards, Hank

2 3

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

RIPE88 Database Working Group Minutes
by Peter Hessler 21 Oct '24

21 Oct '24

Hello Database Working Group, The draft minutes from our session at RIPE88 has been published on the RIPE website, available at https://www.ripe.net/community/wg/active-wg/db/minutes/ripe-database-workin… We'd like to thank Alun from the RIPE NCC for preparing the draft. Please review the minutes, and send any necessary corrections to the working group mailing list. Peter Hessler, On behalf of the DB WG Co-Chairs

1 0

RDAP Transparency Report
by Edward Shryane 17 Oct '24

17 Oct '24

Dear colleagues, At RIPE 88, Leo Vegoda asked in the DB-WG session for a transparency report on RDAP, and in particular any functionality gaps between RDAP and Whois in the RIPE database. The Registration Data Access Protocol (RDAP) is an alternative protocol to Whois that specifies how to access Internet resource registration data. It is specifically designed to address various shortcomings in Whois. Because of these improvements in RDAP, we want to encourage its adoption. However, at least for the RIPE Database, over 90% of Whois queries are still on port 43. In 2015, the Whois output from both Regional Internet Registries (RIRs) and Domain Name Registries (DNSs) were collected and analysed, and created an object registry in RFC 7485, "Inventory and Analysis of WHOIS Registration Objects". https://www.rfc-editor.org/rfc/rfc7485 This formed the basis of the various object types supported in RDAP. There are gaps where Whois object types or attribute types are not supported by RDAP. One difficulty is that the Whois object model is different for each RIR. This makes supporting specific attributes in RDAP more difficult. For this analysis we will focus on the RIPE Database. Also specifically for the RIPE NCC service region, known differences between RDAP and the RIPE Database are listed in the Whois GitHub repository: https://github.com/RIPE-NCC/whois/blob/master/README.RDAP.md Once it is clear where the gaps are, we will work with the community to prioritise work to close the gaps between RDAP and Whois. We also plan to cooperate with the other RIRs to help standardise any changes. Let's now analyse the gaps by functional area between the RIPE Database and RDAP. The following sections document how RPSL attributes for different object types are mapped to RDAP. Attributes common to most or all object types follow at the end of the document. Internet Number Registry (INR) ------------------------------ The Internet Number Registry (INR) is a subset of the RIPE Database containing information about resources, including IPv4 and IPv6 prefixes and AS numbers. AS-BLOCK As-block objects are *not* returned by RDAP. If an in-region AS number is not found, even if the parent as-block exists, then HTTP status 404 “Not Found” is returned for that AS number. AUT-NUM +---------------------------------------+---------------------------------------+ | WHOIS | RDAP | +---------------------------------------+---------------------------------------+ | aut-num | /handle | | | /startAutnum | | | /endAutnum | +---------------------------------------+---------------------------------------+ | as-name | /name | +---------------------------------------+---------------------------------------+ | member-of | N/A (not returned) | +---------------------------------------+---------------------------------------+ | import-via | N/A | +---------------------------------------+---------------------------------------+ | import | N/A | +---------------------------------------+---------------------------------------+ | mp-import | N/A | +---------------------------------------+---------------------------------------+ | export-via | N/A | +---------------------------------------+---------------------------------------+ | export | N/A | +---------------------------------------+---------------------------------------+ | mp-export | N/A | +---------------------------------------+---------------------------------------+ | default | N/A | +---------------------------------------+---------------------------------------+ | mp-default | N/A | +---------------------------------------+---------------------------------------+ | sponsoring-org | N/A | +---------------------------------------+---------------------------------------+ | status | N/A | +---------------------------------------+---------------------------------------+ INETNUM +---------------------------------------+---------------------------------------+ | WHOIS | RDAP | +---------------------------------------+---------------------------------------+ | inetnum | /handle | | | /startAddress | | | /endAddress | | | /ipVersion ("v4") | +---------------------------------------+---------------------------------------+ | netname | /name | +---------------------------------------+---------------------------------------+ | country | /country | | | (Whois "country" is multiple but | | | single in RDAP. Only the first value | | | is returned). | +---------------------------------------+---------------------------------------+ | geofeed | /links/ | | | "rel": "geo" | | | "type": "application/geofeed+csv" | | | See draft-ietf-regext-rdap-geofeed | +---------------------------------------+---------------------------------------+ | geoloc | /vcardArray "geo" (N.B. this attribute| | | is not related to Geofeed) | +---------------------------------------+---------------------------------------+ | language | /lang | | | (Whois "language" is multiple but | | | single in RDAP). | +---------------------------------------+---------------------------------------+ | sponsoring-org | N/A (not returned) | +---------------------------------------+---------------------------------------+ | status | /type | +---------------------------------------+---------------------------------------+ | assignment-size | N/A (not returned) | +---------------------------------------+---------------------------------------+ INET6NUM +---------------------------------------+---------------------------------------+ | WHOIS | RDAP | +---------------------------------------+---------------------------------------+ | inet6num | /handle | | | /startAddress | | | /endAddress | | | /ipVersion ("v6") | +---------------------------------------+---------------------------------------+ | netname | /name | +---------------------------------------+---------------------------------------+ | country | /country | | | ("country" is multiple in Whois but | | | single in RDAP. Only the first value | | | is returned). | +---------------------------------------+---------------------------------------+ | geofeed | /links/ | | | "rel": "geo" | | | "type": "application/geofeed+csv" | | | See draft-ietf-regext-rdap-geofeed | +---------------------------------------+---------------------------------------+ | geoloc | /vcardArray "geo" (N.B. this attribute| | | is not related to Geofeed) | +---------------------------------------+---------------------------------------+ | language | /lang | | | ("language" is multiple in Whois but | | | single in RDAP. Only the first value | | | is returned). | +---------------------------------------+---------------------------------------+ | sponsoring-org | N/A (not returned) | +---------------------------------------+---------------------------------------+ | status | /type | +---------------------------------------+---------------------------------------+ | assignment-size | N/A (not returned) | +---------------------------------------+---------------------------------------+ Entity Object Types ------------------- Entities in RDAP include organisation, maintainer, person and role contact types. MNTNER +---------------------------------------+---------------------------------------+ | WHOIS | RDAP | +---------------------------------------+---------------------------------------+ | mntner | /handle | +---------------------------------------+---------------------------------------+ | upd-to | N/A (not intended as a contact | | | email address) | +---------------------------------------+---------------------------------------+ | mnt-nfy | N/A (not intended as a contact | | | email address) | +---------------------------------------+---------------------------------------+ | auth | N/A (mot returned) | +---------------------------------------+---------------------------------------+ ORGANISATION +---------------------------------------+---------------------------------------+ | WHOIS | RDAP | +---------------------------------------+---------------------------------------+ | organisation | /handle | +---------------------------------------+---------------------------------------+ | org-name | /vcardArray | | | "text": "org" | +---------------------------------------+---------------------------------------+ | org-type | N/A (not returned) | +---------------------------------------+---------------------------------------+ | address | /vcardArray | | | "adr" | +---------------------------------------+---------------------------------------+ | country | /country | | | ("country" is single in Whois and | | | single in RDAP. Only the first value | | | is returned). | +---------------------------------------+---------------------------------------+ | phone | /vcardArray | | | "tel" | | | "type": "voice" | +---------------------------------------+---------------------------------------+ | fax-no | /vcardArray | | | "tel" | | | "type": "fax" | +---------------------------------------+---------------------------------------+ | e-mail | /vcardArray | | | "email" | | | The "e-mail" value is filtered in | | | Whois but not in RDAP. | +---------------------------------------+---------------------------------------+ | geoloc | /vcardArray "geo" (N.B. this attribute| | | is not related to Geofeed) | +---------------------------------------+---------------------------------------+ | language | /lang ("language" is multiple in Whois| | | but single in RDAP. Only the first | | | value is returned). | +---------------------------------------+---------------------------------------+ | ref-nfy | N/A (not intended as a contact email | | | address) | +---------------------------------------+---------------------------------------+ ROLE +---------------------------------------+---------------------------------------+ | WHOIS | RDAP | +---------------------------------------+---------------------------------------+ | role | /vcardArray | | | "fn" | +---------------------------------------+---------------------------------------+ | address | /vcardArray | | | "adr" | +---------------------------------------+---------------------------------------+ | phone | /vcardArray | | | "tel" | | | "type": "voice" | +---------------------------------------+---------------------------------------+ | fax-no | /vcardArray | | | "tel" | | | "type": "fax" | +---------------------------------------+---------------------------------------+ | e-mail | /vcardArray | | | "email" | +---------------------------------------+---------------------------------------+ | nic-hdl | /handle | +---------------------------------------+---------------------------------------+ PERSON +---------------------------------------+---------------------------------------+ | WHOIS | RDAP | +---------------------------------------+---------------------------------------+ | person | /vcardArray | | | "fn" | +---------------------------------------+---------------------------------------+ | address | /vcardArray | | | "adr" | +---------------------------------------+---------------------------------------+ | phone | /vcardArray | | | "tel" | | | type": "voice" | +---------------------------------------+---------------------------------------+ | fax-no | /vcardArray | | | "tel" | | | "type": "fax" | +---------------------------------------+---------------------------------------+ | e-mail | /vcardArray | | | "email" | +---------------------------------------+---------------------------------------+ | nic-hdl | /handle | +---------------------------------------+---------------------------------------+ Internet Routing Registry (IRR) ------------------------------- The Internet Routing Registry (IRR) is a database of Routing policy information, including route objects and related sets. None of the IRR object types are currently returned by RDAP, including: ROUTE: IPv4 route ROUTE6: IPv6 route RTR-SET: Set of routers ROUTE-SET: Set of routes AS-SET: Set of aut-num objects FILTER-SET: Set of routes matched by its filter PEERING-SET: Set of peerings INET-RTR: Internet router Reverse Delegation ------------------ The RIPE Database contains information about the provisioning of Reverse Domain Name System (DNS) delegations, contained in the domain object type. DOMAIN +---------------------------------------+---------------------------------------+ | WHOIS | RDAP | +---------------------------------------+---------------------------------------+ | domain | /handle | | | /ldhName | +---------------------------------------+---------------------------------------+ | zone-c | /entities | | | "roles": "zone" | | | ("zone" is a non-standard entity type)| +---------------------------------------+---------------------------------------+ | nserver | /nameServers | +---------------------------------------+---------------------------------------+ | ds-rdata | secureDNS/dsData | +---------------------------------------+---------------------------------------+ Other Object Types ------------------ The RIPE Database also contains some other object types. IRT: referenced IRT objects are returned, but not directly. KEY-CERT : not returned by RDAP. Common Attributes ----------------- Some attributes appear on some or all object types in the RIPE Database and are mapped to RDAP as follows. +---------------------------------------+---------------------------------------+ | WHOIS | RDAP | +---------------------------------------+---------------------------------------+ | abuse-c | /entities/ | | | role: "technical" | | | email type "abuse" | +---------------------------------------+---------------------------------------+ | admin-c | /entities/ | | | role: "administrative" | +---------------------------------------+---------------------------------------+ | tech-c | /entities/ | | | role: "technical" | +---------------------------------------+---------------------------------------+ | descr | /remarks/description/ | +---------------------------------------+---------------------------------------+ | mnt-by | /entities/ | | mnt-lower | In RDAP the role "registrant" is used | | mnt-routes | to identify both organisations and | | mnt-domains | maintainer entities. | | mnt-irt | In RDAP only the "mnt-by" value is | | mnt-ref | returned and not the other mnt types. | +---------------------------------------+---------------------------------------+ | org | /entities/ | | | In RDAP the role "registrant" is used | | | to identify both organisations and | | | maintainer entities. | +---------------------------------------+---------------------------------------+ | notify | N/A (not returned in RDAP response) | +---------------------------------------+---------------------------------------+ | remarks | /remarks/description/ | +---------------------------------------+---------------------------------------+ | created | /eventeventAction "registration" | +---------------------------------------+---------------------------------------+ | last-modified | /events/ | | | eventAction: "last changed" | +---------------------------------------+---------------------------------------+ | source | /notices/ | | | title: "source" | | | description: ["Objects returned came | | | from source", "RIPE"] | +---------------------------------------+---------------------------------------+ RDAP Object Classes ------------------- The RIPE database RDAP implementation supports the following object classes: * entity - returns Whois person, role, organisation, mntner types * ip - returns Whois inetnum and inet6num types * autnum - returns Whois aut-num type * domain - returns Whois domain type It does not support the nameserver class, used for forward DNS names. RDAP Query Flags ---------------- Supported query flags in the RIPE Database can be found in the Database documentation: https://docs.db.ripe.net/Types-of-Queries/ RDAP supports the following query flags: * For entity queries there is “fn” which is used as a search term for person, role and organisation name. Also “handle” which is used as a search term just for organisation and nic-hdl. Both cannot be used at the same time. * For ip queries there is “name” or “handle” both are used as a search term for netname (which maps to “name” in RDAP). * For autnum queries, “name” which is used to specify the search term for as-name, and “handle” for aut-num. * For domain queries, “name” which is used as a search term for domain. Conclusion ---------- The RDAP protocol addresses various shortcomings in Whois. Support for resource types and contact types is reasonably good, but there is no support for Internet Routing Registry (IRR) object types in particular. We must work to close the remaining gaps between RDAP and Whois if we want to increase the adoption of RDAP. --- Regards Ed Shryane RIPE NCC

1 1

Re: API Key Expiry and Shared Credentials in the RIPE Database
by Cynthia Revström 10 Oct '24

10 Oct '24

I don't speak for the NCC but as I understand it they wanted a drop in replacement for MD5-PW. -Cynthia On Thu, 10 Oct 2024, 23:13 Laurent Pellegrino, < laurent.pellegrino(a)ipregistry.co> wrote: > Hi there, > > Given the focus on security and token management, was OAuth2 considered? > It’s a widely adopted standard that includes built-in mechanisms for secure > authentication and token expiration, and it supports various flows that > might align with your requirements. If it was evaluated, could you please > share any insights on why it wasn’t chosen? > > Regards, > Laurent > > On Thu, Oct 10, 2024 at 12:58 PM Cynthia Revström via db-wg < > db-wg(a)ripe.net> wrote: > >> I have to agree with Gert here. I think the intentions are good but it >> won't give the wanted result. >> >> Making it so API keys are tied to a user will cause people to create >> shared users to hold those keys. >> >> -Cynthia >> >> On Wed, 9 Oct 2024, 19:21 Gert Doering, <gert(a)space.net> wrote: >> >>> Hi, >>> >>> On Wed, Oct 09, 2024 at 02:28:26PM +0200, Felipe Silveira wrote: >>> > 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. >>> >>> I think you've been reading the wrong books on security here... this >>> design is actively discouraging use of API keys, because it breaks >>> doing proper automatization on the LIR size. >>> >>> Gert Doering >>> -- NetMaster >>> -- >>> have you enabled IPv6 on something today...? >>> >>> SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo >>> Lalla, >>> Karin Schuler, Sebastian Cler >>> Joseph-Dollinger-Bogen 14 >>> <https://www.google.com/maps/search/Joseph-Dollinger-Bogen+14?entry=gmail&so…> >>> Aufsichtsratsvors.: A. Grundner-Culemann >>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >>> ----- >>> To unsubscribe from this mailing list or change your subscription >>> options, please visit: >>> https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ >>> As we have migrated to Mailman 3, you will need to create an account >>> with the email matching your subscription before you can change your >>> settings. >>> More details at: >>> https://www.ripe.net/membership/mail/mailman-3-migration/ >> >> ----- >> To unsubscribe from this mailing list or change your subscription >> options, please visit: >> https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ >> As we have migrated to Mailman 3, you will need to create an account with >> the email matching your subscription before you can change your settings. >> More details at: >> https://www.ripe.net/membership/mail/mailman-3-migration/ > >

1 0

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

29 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)

11 23

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