- db-wg - mailman.ripe.net

RIPE90 proposal to deprecate the RIPE NONAUTH Database
by Edward Shryane 22 Jul '25

22 Jul '25

Dear colleagues, At RIPE90 I presented a proposal to deprecate the RIPE-NONAUTH database: https://ripe90.ripe.net/wp-content/uploads/presentations/120-RIPE90-DB-WG-O… (slide 20) The objects in the RIPE-NONAUTH database are not authoritative, and were created anonymously with a well-known password as out-of-region data in the RIPE IRR database. We don’t know who created this data or whether it is still valid. There are very few (< 100) updates per year, which suggests the data is not being maintained. The RIPE-NONAUTH database has only reduced in size by about 10% since it was created in 2018. The existing cleanup jobs and maintainers are not deleting much data. Ruediger Volk pointed out that ARIN had only very recently introduced their NONAUTH database, so it was a very short-term temporary source, and that does not predict anything about the longstanding data that has been split out into RIPE-NONAUTH. He suggested that the RIPE NCC analyse whether something that’s supposed to go away is still being used, or else there is a pretty big danger that someone is actually depending on it. I now present some analysis of the RIPE-NONAUTH database for review. Perhaps we should not retire the RIPE-NONAUTH database completely as we don't know how it is being used, but we could take action to further reduce its size. Your feedback is appreciated. Should RIPE-NONAUTH Objects Be Returned By Default? --------------------------------------------------- The RIPE-NONAUTH database is included by default in Whois queries. This means that any matching object in the RIPE-NONAUTH database is automatically returned in the Whois query response. That includes as-set, aut-num, route and route6 object types. For example, when querying for "AS2561", the matching aut-num object in the RIPE-NONAUTH database is returned. Additionally, *related* matching objects in the RIPE-NONAUTH database will also be returned by default. For example, when querying for the IPv4 prefix "200.30.0.0/18", the related route object "200.30.0.0/18AS5511" in the RIPE-NONAUTH database is returned. We found that RIPE-NONAUTH objects are returned only in a small number of cases (about 0.006% of all queries), but there is a risk that clients will inadvertently trust non-authoritative data if the "source:" attribute is not checked. As a workaround, clients can use the "-s RIPE" flag to only query the RIPE database. Should objects in the RIPE-NONAUTH database continue to be returned by default? Near Realtime Mirroring (NRTM) ------------------------------ Approximately 20% of NRTM requests query for updates to the NONAUTH database. Should we continue to support mirroring the NONAUTH database, considering the non-authoritative nature of the data and low rate of updates? Should RIPE-NONAUTH objects with an exact match in another RIR database be deleted? ----------------------------------------------------------------------------------- Approximately 31,930 out of 45,754 route(6) objects in the RIPE-NONAUTH database have a matching route(6) object (i.e. matching origin ASN and exactly matching or less-specific prefix) in another RIR’s IRR database. Approximately 13 out of 67 as-set objects in the RIPE-NONAUTH database have an exactly matching as-set in another RIR’s database. Approximately 1,840 out of 2,073 aut-num objects in the RIPE-NONAUTH database have an exactly matching aut-num object in another RIR’s database. Should we delete RIPE-NONAUTH objects which duplicate identically named objects in an authoritative RIR’s database? Should unrouted RIPE-NONAUTH route(6) objects be deleted? --------------------------------------------------------- Approximately 33,912 out of 44,647 RIPE-NONAUTH route(6) objects appear in the global routing table (as of 12th July). Should we remove any NONAUTH route(6) objects which are not announced? Do they serve any useful purpose? Regards Ed Shryane RIPE NCC

4 6

NWI proposal: adjusting contact method requirements and adding new methods
by Leo Vegoda 22 Jul '25

22 Jul '25

Hi, A while back Cynthia, Dmitry and I looked at the possibility of adding new contact methods. Dmitry presented this at RIPE 88: https://ripe88.ripe.net/archives/video/1347/ I've tried to put this into a more complete NWI and offer it for discussion. The TLDR is: 1) Align the requirement levels for contact methods 2) Let people use new contact methods, like Signal We hope that by offering the methods people want to use, the contact data in the RIPE Database can be as useful as is possible. Kind regards, Leo ## Problem statement The requirement level for contact methods for person and role objects are inconsistent. This is both confusing and inconvenient. This is a proposal to add flexibility to the contact methods offered at the database level. It is not a proposal to change policy requirements for contact methods. This proposal is limited to admin-c and tech-c contact types. Our world offers more contact methods than were available when the currently supported methods were chosen for the RIPE Database. User acceptance of these methods differ by country and generation. Whether this proposal is accepted or not, it is good to review the rationale for these rules and have an updated rationale published. 1. Person and role objects have four contact methods. A postal address is mandatory for both. A phone is mandatory for person objects but not role objects. E-mail is mandatory for role but not person objects. 2. Postal mail is less useful than it was 20 years ago. Some countries are reducing the frequency of postal deliveries. And geographically distributed teams find postal mail less useful. 3. The telephone is becoming less useful, too. Call volumes are dropping and popular psychology publications explain why calls are less likely to be answered: - https://www.statista.com/statistics/551035/finland-call-volume-by-type-of-c… - https://www.bbc.com/news/articles/ckg8jllq283o - https://www.psychologytoday.com/intl/blog/un-numb/202405/why-gen-zers-keep-… ## Proposal We should provide contacts with more flexibility. We should also add new options that were not available when the RIPE Database's contact methods were last reviewed. The three elements below follow on from NWI-15, which is based on the RIPE Database Requirements Task Force recommendations for what should be published about resource holders. The registry needs to retain the full set of required data. The DBTF report did not mention contacts methods for the resources. 1. Align the contact method requirements between role and person objects used in admin-c and tech-c attributes. Make all contact methods optional for the public RIPE Database as long as one is chosen. There is no point publishing a contact method that will not be used. That would just waste the time of people trying to make contact. 2. Add support for new contact methods in the RIPE Database, including SIP (RFC 3969), Signal, Telegram, and WhatsApp. 3. Add support for RFC 8605 (ICANN Extensions for the Registration Data Access Protocol) and show the HTTPS intermediary and/or private URI where one is available. Making these changes will require updates to the RPSL and RDAP publication methods. The RIPE NCC should manage the specifics of the design and implementation. ## Recommendation for Impact Assessment The impact assessment provided by the RIPE NCC should note any contact method requirements specified in policy. It should also note where the policy does not specify a contact method requirement. The RIPE NCC might want to note the impact of enforcing policy requirements when more user choice is offered at the database layer.

8 11

Removing all MD5 Hashed Passwords Not Used for Authentication in the past year (updated)
by Edward Shryane 16 Jul '25

16 Jul '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… And to update my previous mail from 31st March: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/4QNPE24MIDFRSG… In Q2 2025, the RIPE NCC plans to remove all MD5 hashed passwords that have not been used for authentication since 1st January 2024, to reduce the risk of having so many MD5 hashes in the database in case of a data breach. We found this will affect approximately 17,000 out of 62,000 maintainers. We have now split these maintainers into four batches and will notify the first batch by email *tomorrow* 11th June. We will send a reminder email for this first batch in one week (18th June), and then finally remove any inactive password hashes for the first batch in two weeks (25th June). We will wait one week before starting on the next batch of maintainers, and also give each batch two weeks notice. This should be enough time to suffiently notify affected maintainers, and to complete the process by mid-July, so we can begin to notify maintainers who are *actively* using password hashes (giving them 6 months notice before support for passwords is removed by end 2025). If maintainers need more time, or if we have many support requests, then we can adjust the timeline accordingly. Please let us know your comments and/or questions regarding this planned change. Regards Ed Shryane RIPE NCC

1 1

Whois Release 1.118
by Miguel Mosquera 15 Jul '25

15 Jul '25

Dear colleagues, RIPE Database release 1.118 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Tuesday 29th July. Whois release 1.118 contains the following changes : Resources : * Add prefixlen Attribute to Inet(6)num (#1816) * LIR-PARTITIONED PA inetnum status is not valid under ALLOCATED UNSPECIFIED (#1825) * Run RIR Authoritative Resources Task Every Hour and Import Data Only When Updated (#1749) * Removing mbrs-by-ref maintainer from set causes aut-num update containing member-of to fail (#1770) RDAP RIR Search: * Implemented administrative status on RDAP lookup but not rir-search (yet) (#1778, #1730, #1722) * Remove HTTP status code from RDAP response "title" element. (#1777) ACL: * Do not apply accounting for an Authenticated Maintainer's own Objects (#1723) The full list of changes is visible in the source repository: https://github.com/RIPE-NCC/whois/compare/fba36664...505c5f7a The release notes are on the website: https://docs.db.ripe.net/Release-Notes/#ripe-database-release-1-118 More information on the Release Candidate environment can be found on our website: https://docs.db.ripe.net/Release-Notes/ The data in the Release Candidate environment is a dummified copy of production from 14th July. Please let us know if you find any issues with this release in the RC environment. Regards Miguel Herrán RIPE NCC

1 0

Status of my NWI proposal
by Leo Vegoda 13 Jul '25

13 Jul '25

Hi, Where are we with the NWI I posted a while back. It got some suggestions for amendment and they all seem sensible. Do you need something from me? Thanks, Leo

1 0

Proposal: Privacy in RIPE database objects
by Rodolfo García Peñas (kix) 26 Jun '25

26 Jun '25

Hi, I would like to make a proposal regarding the database so that privacy can be included in the objects. Among the main objectives of the database [1] are "To provide accurate registration information of these resources in order to meet a variety of operational requirements" and "Facilitating coordination between network operators (network problem resolution, outage notification etc.)", and therefore the database contains information to facilitate these actions. However, this information can be used to obtain information about individuals and entities in order to carry out unwanted actions (network recognition, phishing, etc.). To prevent network information and contact information from being obtained, objects with anonymized information are stored in the database, role objects are used instead of person objects, non-real information is used, or inetnum objects are not created. Some mailing threads related to these issues have been seen on the mailing list [2][3]. My proposal is that the database offers privacy regarding the information it contains, allowing real information to be stored while protecting LIRs and end users by providing filtered information. To this end, I propose using a system similar to "domain privacy" in DNS registries to hide desired information: - Use the option to hide sensitive information in mandatory fields. - Provide an option to maintain contact with the person responsible for the object. Example: person: Privacy protected address: Privacy protected address: Privacy protected e-mail: Privacy protected (contact link) phone: Privacy protected (contact link) remarks: For mail filtering or abuse problems contact with the abuse mailbox nic-hdl: ABCD1-RIPE mnt-by: Privacy protected (contact link) created: 2008-11-13T15:53:02Z last-modified: 2024-09-23T13:25:48Z source: RIPE One proposal is to use a Boolean model for each field (or for all fields in the object) to indicate whether the information should be "protected" or "public." Another example option would be to include levels such as "public" (publicly accessible), "LEA" (accessible by LEAs), "LIR" (accessible by other authenticated LIRs), and "private" (fully private). This information could be included by default at the user or LIR level using the LIR portal. For email or telephone communication, the platform could act as a mail intermediary or by providing anonymized email addresses, facilitating coordination between network operators/users. IMO, first, we must reach a consensus on whether this option is useful for database management, and then we can discuss implementation details. Regards, Rodolfo García (kix) PS. Thanks Jordi, Miguel for your help. [1] https://docs.db.ripe.net/What-is-the-RIPE-Database/Purpose-and-Content-of-t… [2] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/01… [3] https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/MEOS4MD7ZYLVOA… The content of this email reflects personal opinions and does not represent the views of any organization.

4 7

RIPE90 Database Working Group Minutes
by David Tatlisu 24 Jun '25

24 Jun '25

Hi Everyone, The draft minutes from our session at RIPE90 have 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 Hans from the RIPE NCC for preparing the draft. Please review the minutes, and send any necessary corrections to the working group mailing list. David Tatlisu, On behalf of the DB WG Co-Chairs

1 0

Archiving the "Action List"
by Peter Hessler 21 Jun '25

21 Jun '25

As seen on the website, the Database Working Group has an Action List, instead of an Action Movie. https://www.ripe.net/community/wg/active-wg/db/action-list/ From a basic perusal of them, this seems to be a basic tracking system of TODOs and Proposals. Notice it says "last updated 7 May 2009". I propose we simply archive this list. If anything is still relevant, please bring it up as if it were new. Peter Hessler, On behalf of the DB WG Co-Chairs

4 4

status levels
by denis walker 03 Jun '25

03 Jun '25

Colleagues Maybe I asked too many questions in one email, so I'll take it bit by bit. Is it reasonable to limit the number of levels of SUB-ALLOCATED PA to 4? That is the most we have now in the RIPE Database. Or do you have another number in mind...maybe even 1? Should there be a limit on the number of levels in a LEGACY hierarchy? Currently it is infinite. cheers denids

5 17

Publishing End-Site Prefix Lengths
by Randy Bush 26 May '25

26 May '25

i received a suggestion to mention this on the ripe wg list. similar to geofeed, it allows one to document the prefix length one is using. Publishing End-Site Prefix Lengths https://datatracker.ietf.org/doc/draft-ietf-opsawg-prefix-lengths/ This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to prefixlen comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure (RPKI) to authenticate the prefixlen data files. randy

2 2