- db-wg - mailman.ripe.net

Agenda RIPE88 - Database Working Group [REVISED]
by William Sylvester 17 May '24

17 May '24

All, Here is the revised agenda for the Database Working Group for RIPE88. If you would like to present, have questions, comments, or requested changes please let the chairs know. Best regards, William, Denis, & David DB-WG Chairs A. Introduction - 15 min * Welcome * Scribe * Agenda B. Operational Update– 20 mins Edward Shryane, RIPE NCC C. Adding Contact Methods in Whois & RDAP – 15 mins, Cynthia Revström, Dmitry Kohmanyuk, Leo Vegoda C. NWI Review – 15 mins, WG Chairs D. WG Discussion – 25 mins, WG Chairs Z. AOB (open discussion)

1 0

Update to RIPE Database Terms & Conditions
by denis walker 17 May '24

17 May '24

Colleagues In the Impact Analysis (IA) for 2023-04, the RIPE NCC legal team expressed rules for entering personal data into the RIPE Database that are quite different to our previous understanding. This legal IA was relied on heavily by the proposers of 2023-04 and constantly referred to by them during the policy discussions. Based on the discussions and the IA, the chairs of the AP-WG have now approved the proposal 2023-04. We MUST now update the RIPE Database Terms and Conditions to reflect this new understanding on personal data. In the IA the legal team said this: "Inserting any personal data in the RIPE Database must be in compliance with the RIPE Database Terms and Conditions, even when it relates to the contact details of the member’s own contact person(s). In particular, before anyone updates the RIPE Database with personal data, they must obtain the contact person’s informed and expressed consent and ensure this data is kept accurate and up-to-date." Article 6.3 of the RIPE Database Terms and Conditions currently says: "The Maintainer who enters personal data into the RIPE Database has a responsibility to inform the individual to whom the data pertains and to obtain their explicit consent for the entry in the public RIPE Database if required by law." This article does not accurately reflect the statement in the IA by the legal team. The text "if required by law." must be removed. This suggests that some personal data may not need the 'contact person’s informed and expressed consent'. The IA makes it clear that all personal data entered into the RIPE Database must have the 'contact person’s informed and expressed consent'. There are no exceptions or caveats to this consent. Also the responsibility must not be restricted to the 'Maintainer'. ANYONE has the capability to enter personal data into the RIPE Database. This personal data can then be referenced by a Maintainer of resource data. I would suggest Article 6.3 says something like this: "Anyone who updates the RIPE Database with personal data must obtain the contact person’s informed and expressed consent to enter their personal details into a global, freely accessible, public database. This consent cannot be subject to any conditions. If the consent is withdrawn, the personal data must be removed from the RIPE Database in a reasonable time frame. The personal data must be kept accurate and up-to-date. The right to use some Internet resources requires a consenting contact. If no such contact person is available, the right to use some Internet resources may be revoked." This is a clear and honest statement that fully reflects the IA understanding of the use of personal data in the RIPE Database. I would like to ask the RIPE NCC legal team to make arrangements for this update to the Terms and Conditions. cheers denis co-chair DB-WG ======================================================== 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. ========================================================

2 5

Unintended consequences of 2023-04
by denis walker 15 May '24

15 May '24

Colleagues The proposers of 2023-04 assured the community that their motivation was purely to provide aggregation, an optional, minor, inconsequential feature that did not change anything else. So if their minds were focused purely on aggregation, as they have told us and we must accept that without question, then it is reasonable to expect that they put a lot of effort into getting all the details and implications of aggregation correct. Unfortunately they seem to have missed quite a lot of details and consequences. Nothing much was said throughout the whole discussion, nor in the policy proposal itself, about where AGGREGATED-BY-LIR fits in relation to other status values. Nothing was said about the semantics of the RIPE Database. So, as it has not been explicitly stated what types of address space can be created more specific to an aggregation, we can have partitions, sub-allocations and assignments. The assignments can either be directly under the aggregation or from any of the multiple, same level or hierarchical levels of sub-allocations. There can be quite a complex structure of address space more specific to an aggregation, but you may never know because none of it needs to be documented in the RIPE Database. The boundaries of aggregations have not been defined. So they can overlap the boundaries of assignments that do not have objects in the database. If objects are created in the database, the software will not allow any overlapping objects to be created. Objects must be fully contained within the boundaries of a less specific object. But now that objects do not need to be created and they are not of a fixed size, you can do whatever you want. This can be by mistake or intentional. So resource holders can now delete all assignments from an allocation and create two equal sized aggregation objects. If the boundaries of the aggregations overlap the existing assignments it doesn't matter as long as you delete the assignment objects first. Nothing prohibits the creation of sub-allocations within an aggregation. The definition simply says "This address space has been assigned...". It does not state that the assignment must be only one level more specific to the aggregation. So you can create as complex a structure as you wish with multiple sub-allocations in a hierarchy and multiple sub-allocations on the same level within the hierarchy, as long as it ends with an assignment. Then you have satisfied the condition that "This address space has been assigned". You think that is bad...it gets worse... Previously it was not permitted to sub-assign. So you could not create an assignment more specific to an existing assignment. Now this is permitted. The policy says: "The creation of an inetnum object with a status of "ASSIGNED PA" or "ASSIGNED PI" is only possible if there is no less specific or more specific inetnum object with an "ASSIGNED" status." How many times have I said "words matter"!!! And still no one listens. This rule relates to 'objects' in the RIPE Database. It does NOT refer to 'assignments'. Previously it meant the same as an assignment could only exist if there was an assignment 'object' in the database. Now we do not need to create assignment objects in the database. Now you can create hierarchies of multiple assignments as deep as you like, provided no more than one of those assignments is represented in the database by an assignment object. Now some will say that we all 'know what it means' and people will respect the 'spirit' of the policy. IPv4 runout proved that 'spirit' and 'intent' are meaningless. All that matters is what is actually written in the policy and how those words can be literally interpreted. Before runout, the 'intent' was to keep the last bits of IPv4 for new entrants into the industry who intended to provide LIR services and needed that little bit of IPv4 for their infrastructure. That intent was never written into the policy, so it was heavily ignored by everyone. Existing members, financial investors and the RIPE NCC. It turned into a land grab for free address space for profit. So the only thing that matters is the actual words in the policy. Sub-assignment to any level is now permitted. You think that is bad...it gets even worse... We can now have duplicate and overlapping assignments to multiple End Users. There is no requirement for resource holders to have state of the art IPAM systems. A notebook on an office desk is perfectly valid. The same address block could be assigned to multiple End Users. Or two address blocks with an overlap. This could be accidental or intentional. Previously, you had to create the assignment objects in the database for an assignment to be valid. The database software prevented duplicate or overlapping assignments. Now you don't need to create these objects so there is no final check to prevent mistakes or deliberate intent. I don't know much about how internet technical operations work, so I am just going to put some thoughts here. People with more knowledge than I have can consider these scenarios to see if it is a problem. Suppose overlapping assignments are given to two End Users. Suppose they each only use the first few addresses of their respective assignments. Then only one is using the overlapping addresses. Can the LIR know for sure which End User is actually using those overlapping addresses? If not, then if some criminal activity occurs with those addresses, who committed the crime? We have also created a situation now where people with criminal intent can construct hierarchies of data that would hide the End User for a long period of time. Based on a comment by Europol that a court order can take months to get the information, we are looking at possibly delaying the identification of an End User by a couple of years. I won't describe how this can be done here. I don't want to give an instruction manual to criminals. I will explain it to Europol when I see them at RIPE 88. Looking at different parts of the address policy, there are other concerns now. (Yes I know this is the DB-WG and some people will use this to deflect attention away from the message by attacking the messenger. A frequently used tactic. But as I said over there, on the other list, not everything fits perfectly within the bounds of one WG. There is considerable overlap between Database and Address Policy.) 3.0 Goals of the Internet Registry System Because of the issue of duplicate and overlapping assignments mentioned above, two of the 4 goals of the Internet Registry System can no longer be guaranteed. 3.1 Uniqueness: this can no longer be maintained if it is possible to assign the same addresses to multiple End Users. 3.4 Registration: the public registry no longer contains sufficient detail to ensure uniqueness. 4.0 Registration Requirements The level of detail in the RIPE Database is no longer sufficient to ensure uniqueness. "Only allocations and assignments registered in the RIPE Database are considered valid." It is no longer possible to validate assignments that are aggregated. So this requirement no longer has any meaning. 6.3 Validity of an Assignment "An assignment is valid as long as the original criteria on which it was based remain valid and it is properly registered in the RIPE Database." Again because of the lack of detail about assignments within an aggregation is is not possible to determine if an assignment is valid. Although with or without aggregation, I am not sure what this 'validity' means in the real world. Was it to show if an IP address is actually assigned to an End User or maybe it is unused address space that has been hijacked? I have no idea how the 'original criteria' for an assignment is documented in the RIPE Database registry or any changes to that original criteria. Is this another example or registration rules that we have lost the meaning of? You can fix all this wording if you want, but in the end it makes no difference. Previously the policy said all resource holders MUST document assignments in the database. Some chose not to do that, even though it was mandatory. It seems the community has accepted that some resource holders refused to comply with mandatory policy. The RIPE NCC had no power to enforce the policy, other than the nuclear option of closure. One of the arguments for 2023-04 was that if we dilute the registration requirements, maybe a few more resource holders will choose to comply with the policy. If you make new rules about aggregation, some will choose to ignore them. Before we could see who chose to ignore the registration of assignments. Now we will have no idea who is ignoring any new rules. It's all hidden inside the aggregations. The proposers frequently referred to IPv6 and kept telling us how wonderful everything was 'over there'. So I had a look and not everything is rosy in the IPv6 garden. Let's look at some numbers. There are 16,144 /29 allocation objects. 11,246 of them have no more specific objects (i.e. nothing underneath the /29). That is about 70% of all the allocated IPv6 is either not in use or nothing has been registered about usage. If it is not in use, that is a huge stockpile of unused IPv6 address space. Why is it out there at all if no one is using it? If a lot of it is in use, even if it is only one assignment for the LIRs infrastructure, then it is a huge rejection of the registration policy to register nothing in the RIPE Database. So which one is it? A massive stockpile of unused address space or large scale refusal to register anything? There are only 4,898 /29 allocations that have any more specifics. Of these, 370 of them have 2 /30's with status (ALLOCATED-BY-LIR or AGGREGATED-BY-LIR) with *nothing* more specific below the /30's. That is about 7.6% of the registered in use IPv6 that tells us nothing about End Users. Of the 370 objects, 88 of them have two sub-allocations (ALLOCATED-BY-LIR) with no more specifics. So they don't even register any aggregations. I checked a number of these sub-allocation objects randomly and not one of them even had a mnt-lower. So the sub-allocation holder can't even create any aggregations or assignments. I also found a batch of them allocated to the same resource holder where both the /30 objects have been deleted in the last couple of weeks since these numbers were generated. The proposers of 2023-04 claimed IPv6 to be a beacon of perfection and used that to argue that nothing will go wrong with adding aggregation to IPv4. From my brief look at IPv6 all I see is a lot of very dodgy looking data with little information. I suspect that will become the reality for IPv4... So this optional, minor, inconsequential feature seems to have changed quite a lot. Is it worth all this for aggregation? I suspect many people will consider it worth it to make assignments optional. cheers denis co-chair DB-WG ======================================================== 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. ========================================================

2 1

Agenda RIPE88 - Database Working Group
by William Sylvester 15 May '24

15 May '24

All, Here is the proposed agenda for the Database Working Group for RIPE88. If you would like to present, have questions, comments, or requested changes please let the chairs know. Best regards, William, Denis, & David DB-WG Chairs A. Introduction - 15 min * Welcome * Scribe * Agenda B. Operational Update– 25 mins Edward Shryane, RIPE NCC C. NWI Review – 15 mins, WG Chairs D. WG Discussion – 25 mins, WG Chairs Z. AOB (open discussion)

1 0

Re: [db-wg] Complying with Mail Provider Requirements When Sending Mail from Whois
by Lutz Donnerhacke 13 May '24

13 May '24

* Denis Walker wrote: > But looking through lots of email notifications about changes that you > already know about, because you did them, and maybe in the middle is a > notification of an attempted security breach that failed on > authentication (that you may miss), doesn't that also eat up brain > cycles? Please do not assume that LIR activities are single handed everywhere. Several LIRs do have an automation (i.e. netbox) to update the RIPE DB. Others might have multiple independent people working with RIPE on their own behalf. So notifications, especially the notify: attribute are currently in use. > So how about a compromise. A full audit trail of all details of all > changes to all your data available by default to designated people > through your portal account. Plus a daily email summarising all the > changes also sent to people whose email addresses are set up in the > portal account. So still no notif email addresses needed all across > the database. This could even be done per maintainer. How about using the notify: attribute for notifications?

7 8

Re: [db-wg] Call for Volunteers for RIPE Database Working Group Co-Chair
by Randy Bush 07 May '24

07 May '24

> Peter Hessler volunteered for the working group co-chair position. cool beans! thanks peter. randy

1 0

Proceeding with NWI-4
by David Tatlisu 02 May '24

02 May '24

Hi everyone, Following recent discussions the working group chairs have determined the new "status" option for NWI-4 garnered the most support. The working group chairs would like to ask the NCC to proceed with the implementation. Your feedback and engagement have been invaluable throughout this process, and we appreciate your continued involvement as we move forward with NWI-4. Kind regards, Denis, William, and David

2 1

Overly specific inet6num objects by Hetzner
by Semisol 27 Apr '24

27 Apr '24

Hetzner apparently creates an `inet6num` object per dedicated server allocation (enough to get my IP blocked for 1 day trying to query them all), and it took several seconds to execute the query. > whois -r -- "-i mnt-by HOS-GUN -T inet6num" (warning: this will get your IP blocked) Some questions: 1. Is there any policy about "too specific" objects? 2. Is there any plans to restrict how many objects a single query can get at once?

2 1

Re: [db-wg] Call for Volunteers for RIPE Database Working Group Co-Chair
by David Tatlisu 24 Apr '24

24 Apr '24

Dear colleagues, Peter Hessler volunteered for the working group co-chair position. He wrote: I've been active for the last few years as a member, and I would like to contribute more by helping to guide the working group. I did not receive any other emails from volunteers. Please keep in mind that the official selection will take place during the DB WG session at RIPE 88. Furthermore, I would like to thank Peter in my personal capacity for volunteering and for his many contributions to the working group. Kind regards, David RIPE DB WG co-chair

2 1

creating a second route object
by Aleksi Suhonen 16 Apr '24

16 Apr '24

Hi, When migrating a route from one ASN to another, the best practice is to create a second route(6) object for it with the new origin. The creation of the new object is dependent on the "mnt-routes:" field of the enclosing inetnum(6) object. Am I correct thus far? Because I'm running into an issue. When trying to create a new route object using the LIR portal, I'm getting an error that the route is not authenticated by the maintainer of _the other_ route object. Am I missing something obvious, or have I found a bug/regression? BR, -- Aleksi Suhonen () ascii ribbon campaign /\ support plain text e-mail

6 7

Whois Inverse Query by "sponsoring-org:" Attribute
by Edward Shryane 08 Apr '24

08 Apr '24

Dear colleagues, Currently, Whois query does not support the "sponsoring-org:" attribute in an inverse query, i.e. to find all resources sponsored by an organisation. The "sponsoring-org:' attribute was added to the RIPE database in these policies, but there's no mention of support for inverse queries: 2012-08: https://www.ripe.net/membership/policies/proposals/2012-08/ 2014-06: https://www.ripe.net/membership/policies/proposals/2014-06/ If there is no objection, I propose for consistency to also add "sponsoring-org:" to the list of inverse query attributes. Regards Ed Shryane RIPE NCC

18 19

email's disappeared from RDAP output
by Ben Cartwright-Cox 05 Apr '24

05 Apr '24

Hi everybody, I was just re-running some tests internally within bgp.tools and I've noticed that the RDAP responses from RIPE no longer include the email address of the person object. For example I used to (and expected) to get the email address in the object for https://rdap.db.ripe.net/entity/BC6775-RIPE, but it seems to have been removed from the output at some point. That does not appear to be a way to log in to authenticate trustworthiness of RDAP responses, is there any other way to get this information? I can see this information on the RIPE website ( https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=BC6775-RIPE&type=… ) but I do not want to scrape that, and this information is incredibly useful for helping users onboard ( with a trustworthy email address ) to services like bgp.tools. Is this an intended change? Have I done something silly? All of the above ;) ? By looking at the release info I can see it was added in November (#1333) Thanks Ben

7 18

Call for Volunteers for RIPE Database Working Group Co-Chair
by David Tatlisu 29 Mar '24

29 Mar '24

********************************************************************************** Please DO NOT reply to this message if you wish to propose a volunteer. ********************************************************************************** Dear colleagues, We would like to invite you to volunteer for the role of the co-chair of the RIPE Database working group. We will have two seats to fill at RIPE 88. Anyone can volunteer for this role. You can also nominate others. Please send a mail to db-wg-volunteers(a)tatlisu.eu before 22 April. Please DO NOT send your name directly to the DB WG mailing list. Please include your motivation and any ideas you might have for the future of the RIPE Database WG. I will then publish the list of volunteers to this mailing list no later than 24 April. Any statements of support on the mailing list are welcome. However, the selection will take place during the DB WG session at RIPE 88. You can find a job description for RIPE WG Chairs here: https://www.ripe.net/publications/docs/wgchair-job-description You can find an e-learning course about the role and responsibilities of RIPE Working Chairs here: https://academy.ripe.net/enrol/index.php?id=16 Please feel free to contact me directly if you have any questions about the role or the process. Kind regards, David RIPE DB WG co-chair

4 5

Whois Release 1.111
by Edward Shryane 28 Mar '24

28 Mar '24

Dear colleagues, RIPE Database release 1.111 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Thursday 28th March. The 1.111 release has the following main changes: * Don't send email to undeliverable addresses (#1404) * Add email unsubscribe support This release is *combined* with the 1.110 release, which we had planned to deploy in March. However as we have an upcoming deadline in April to comply with email anti-spam requirements, we decided to combine the releases. We will explain those changes separately. The 1.110 release has the following main changes: * Implemented RDAP Extension for Geofeed Data (draft-ietf-regext-rdap-geofeed-01) (#1366) * Improve RDAP documentation (#1373, #1388) * Implement RDAP RIR Search - Basic Search Features (#1379) * Enable e-mail in RDAP entity responses (in top level vcard) (#1384) * Add geofeed as a link to conform with v1 draft (#1374) * Separate secure connector for Client Certificate authentication (#1390) * Use clientip flag as remote address from trusted source (#1391) * Redirect HTTP(S) requests to whois.ripe.net to the DB web application query page (#1396) * Elasticsearch refreshed after update/create (#1367) * Document inet6num assignment-size maximum prefix (#1375) * Daily limit is configurable (#1401) The release notes are on the website: https://rc.db.ripe.net/docs/Release-Notes/#ripe-database-release-1-111 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 19th February. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

Complying with Mail Provider Requirements When Sending Mail from Whois
by Edward Shryane 19 Mar '24

19 Mar '24

Dear colleagues, As part of the Whois 1.111 release planned for 28th March, we will make changes to comply with new requirements for bulk email senders from two of the large email providers, namely Google [1][2] and Yahoo [3][4]. The RIPE NCC are reviewing these requirements across all our services. Please refer to the RIPE Labs article published today [5]. We send a lot of mail from Whois, on average 30,000 messages a day (comprised mostly of update acknowledgements and notifications) which qualifies us as a bulk sender. We want to comply with these requirements as we depend on email for notifications but also to listen to our users wishes. There are nearly 900,000 email addresses in the RIPE Database. 65,000 are hosted by Google and 5,000 by Yahoo, so these addresses are directly affected by these requirements. In this release, we will implement mail bounce detection (i.e. an outgoing message has permanently failed delivery) and also unsubscription (i.e. one-click unsubscribe from a mail client). Once an address is undeliverable or unsubscribed, we will not send further Whois update acknowledgements or notifications to that address. However we will continue to send targeted notifications where required by RIPE policy (e.g. abuse-c validation, RIPE-NONAUTH route object cleanup etc.). Notification attributes in the RIPE Database (i.e. irt-nfy, mnt-nfy, notify, ref-nfy, upd-to) will be affected, as we will no longer send update notifications to an unsubscribed or undeliverable address. In update acknowledgements we will warn if any address is undeliverable or unsubscribed. Once unsubscribed, if you want to re-subscribe, for now you will need to contact RIPE NCC support [6]. The changes can already be tested in our Release Candidate environment [7]. We welcome feedback from the community. Regards Ed Shryane RIPE NCC --- References 1. Google announcement: https://blog.google/products/gmail/gmail-security-authentication-spam-prote… 2. Google email sender guidelines: https://support.google.com/a/answer/81126?hl=en 3. Yahoo announcement: https://blog.postmaster.yahooinc.com/post/730172167494483968/more-secure-le… 4. Yahoo sender best practices: https://senders.yahooinc.com/best-practices/ 5. Enhancing Email Delivery at the RIPE NCC: https://labs.ripe.net/author/fergalc/enhancing-email-delivery-at-the-ripe-n… 6. Contacting the RIPE NCC https://www.ripe.net/support/contact/ 7. Release candidate environment https://apps.db.ripe.net/docs/Release-Notes/#release-candidate-environment

3 4

Re: [db-wg] Complying with Mail Provider Requirements When Sending Mail from Whois
by Lutz Donnerhacke 15 Mar '24

15 Mar '24

> In this release, we will implement mail bounce detection (i.e. an outgoing > message has permanently failed delivery) and also unsubscription (i.e. one- > click unsubscribe from a mail client). Once an address is undeliverable or > unsubscribed, we will not send further Whois update acknowledgements or > notifications to that address. However we will continue to send targeted > notifications where required by RIPE policy (e.g. abuse-c validation, RIPE- > NONAUTH route object cleanup etc.). Thank you for your ongoing work and please forgive my ignorance on this subject. IIUC, all addresses, which are unavailable for the sending RIPE MTA once, will be blocked until manual interference. The cause of this error might be located in the RIPE MTA, the RIPE uplink, a global network routing issue, a peering issue, our uplink, our local MTA, or even a DNS(sec) issue. In consequence we will not receive any notifications anymore unless we try to update the very object in question and read the warning box the RIPE-DB update web form. Hence we can't rely on the email notifications anymore?

2 1

NWI-4: Preferred Solution Definition
by Edward Shryane 14 Feb '24

14 Feb '24

Dear colleagues, During the interim meeting on 17th January: https://www.ripe.net/community/wg/active-wg/db/interim-sessions/interim-ses… The two proposed solutions to NWI-4 were discussed, namely, either add a new combined "status:" value "ALLOCATED-ASSIGNED PA": https://www.ripe.net/ripe/mail/archives/db-wg/2022-December/007722.html Or combine the prefix and status tuple as a primary key: https://www.ripe.net/ripe/mail/archives/db-wg/2023-September/007913.html I proposed to go ahead with the new combined "status:" solution as it has fewer drawbacks and appears to be the preferred option from the community, pending the co-chairs to declare consensus on the solution. Please let me know if you have any comments or concerns. Regards Ed Shryane RIPE NCC

1 0

DB WG interim session January 2024
by David Tatlisu 06 Feb '24

06 Feb '24

Hi, Picking up from RIPE87, the first interim working group session for the Database Working Group is planned for 17 January 2024, 15:00–16:00 UTC. The following topics are on the agenda right now: * Discussing the two possible solutions for NWI4 (multivalued status:) * Discussing the use of UTF-8 in the RIPE database * Following the recent breach, feedback on how authentication could be improved * Leo Vegoda and Dmitry Kohmanyuk would like to talk about alternative modes of contact in the RIPE database * Any other business Kind regards, Denis, William, and David https://ripe.zoom.us/j/99068479472 Alternatively, dial by your location • +1 253 205 0468 US • +1 253 215 8782 US (Tacoma) • +1 301 715 8592 US (Washington DC) • +1 305 224 1968 US • +1 309 205 3325 US • +1 312 626 6799 US (Chicago) • +1 346 248 7799 US (Houston) • +1 360 209 5623 US • +1 386 347 5053 US • +1 507 473 4847 US • +1 564 217 2000 US • +1 646 558 8656 US (New York) • +1 646 931 3860 US • +1 669 444 9171 US • +1 669 900 9128 US (San Jose) • +1 689 278 1000 US • +1 719 359 4580 US Meeting ID: 990 6847 9472 Find your local number: https://ripe.zoom.us/u/adsp2SzA80

5 6

geolocation purpose
by Maria Stafyla 24 Jan '24

24 Jan '24

Hello all, As you may have seen in the minutes from the RIPE NCC Executive Board's most recent meeting (on 6 October 2023), the Executive Board approved the amendments to the RIPE Database Terms and Conditions. The RIPE Database Working Group had reached consensus that the provision of geolocation information should be included in the list of purposes of the RIPE Database. Accordingly, the approved amendments to the RIPE Database Terms and Conditions include this new purpose and replace the pronouns 'he/she' with the gender-neutral singular 'they'. You can access the RIPE NCC Executive Board Meeting minutes at: https://www.ripe.net/about-us/executive-board/minutes/2023/minutes-168th-ex… And the updated RIPE Database Terms and Conditions are available at: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms In the next whois release, we will remove the prefix size validation rules, which we had to implement to restrict unnecessary processing of personal data when geolocation was not yet a defined purpose of the RIPE Database. If you have any questions, please let us know. Kind regards, Maria Stafyla Senior Legal Counsel RIPE NCC

2 1

Re: [db-wg] [ncc-services-wg] Enforce 2FA for RIPE NCC Access account
by Daniel Suchy 04 Jan '24

04 Jan '24

Hi, Denis is right, the problem isn't only RIPE access and I aggre DB needs to be redesigned in terms of security - we're talking not only about LIR portal and RPKI dashboard, which caused issue with Orange. If you break objects in DB in similar manner (as-sets, route objects), you'll cause similar outage - just because many upstreams and IXP use these data to build their prefix filters. Maybe the destruction will not be so fast... For some methods (restAPI) you need password linked to maintainer object. And all passwords here are still stored in MD5! Yes, this is year 2023. There's no other option [1]... All this is one big ticking bomb... I don't want to guess what could happen if the internal in case of internal RIPE database leak. Just because we're still storing some passwords in prehistoric way. It's not only about LIR accounts, risks are also hidden in maintainer objects, which can be used outside LIR portal. And it's out of reach of one working group. Trivialization of risks is highway to hell. And there're more things, which needs better protection - not only RPKI ROAs. - Daniel [1] https://apps.db.ripe.net/docs/Authorisation/Authorisation-Model/#solving-au… On 1/4/24 21:24, Jim Reid wrote: > IMO, no. Your question is a bit like asking what colour the new carpets should be while the house is on fire. :-) > > The first priorities should be to plug the security issue(s), secure the exposed LIR accounts and do an audit/impact analysis. Discussions about next steps can wait until these have been done. Those next steps may well include a redesign of the RIPE database. Though I think other things would need attention before that: revising the RIPE Access requirements, introducing 2FA, assessing the report about the latest breach, etc. > > It seems premature to debate changes to the database when it’s not yet clear what needs to be done. That may well be clear to you Denis. But perhaps your thoughts will need a reassessment in light of this security breach. > >

1 0

Warning: This Syncupdates request used insecure HTTP
by Peter Hessler 27 Dec '23

27 Dec '23

I was doing some object updates / creation on https://apps.db.ripe.net/db-web-ui/syncupdates and I got this warning while doing so: ***Warning: This Syncupdates request used insecure HTTP, which may be removed in a future release. Please switch to HTTPS. I'm using https to apps.db.ripe.net, so I assume it is the backend that is in http mode. Can this be updated before insecure http mode is removed? Thanks! -- Nothing is illegal if one hundred businessmen decide to do it. -- Andrew Young

2 1

RIPE Database Quarterly Planning Q1 2024
by Edward Shryane 20 Dec '23

20 Dec '23

Dear colleagues, The next quarterly plans for the RIPE Database are now available on our website: https://www.ripe.net/manage-ips-and-asns/db/quarterly-planning In this quarter, we will continue with our day-to-day operations and work on the implementation of the RDAP 'RIR Search' feature. By sharing these plans with you, we want to inform you of the ongoing developments on the RIPE Database and get your feedback on other work items you would like us to focus on. If you have comments or questions around this, we hope you'll let us know on the list or you can always contact the DB team directly at ripe-dbm(a)ripe.net . Regards, Ed Shryane RIPE NCC

1 0

Whois 1.109.1 Release
by Edward Shryane 20 Dec '23

20 Dec '23

Dear colleagues, Following the Whois 1.109 release on Monday, we found a regression affecting all RDAP queries for an organisation entity containing a "country:" attribute. We have now deployed a Whois 1.109.1 release which fixes this regression to the Release Candidate environment for testing. We plan to deploy to production on Wednesday 20th December. The data in the RC environment is a dummified copy of production from 16th November. The release is tagged on GitHub: https://github.com/RIPE-NCC/whois/releases/tag/acc20f73 More information on the Release Candidate environment can be found on our website: https://apps.db.ripe.net/docs/Release-Notes/ Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

Re: [db-wg] Proposal to allow non-ASCII characters in "org-name:", "person:" and "role:" attributes
by Ángel González Berdasco 18 Dec '23

18 Dec '23

It's nice to see you here, Marco. I don't think it will be possible to change the default without potentially causing problems for clients not expecting that. Adding that -C option to the server seems appropriate, and unless you expect that at one point there will be no clients not providing that, you will face the issue that if the default changes from iso-8859-1 to utf-8, old clients will be wrong, as you can't get every client to be updated at the same time. The most similar situation would be if you had a predefined epoch at which both server and clients would change the encoding. But it still requires all clients to have been updated, and the date having been agreed far in advance (and not posponed later!). A situation that could help would be if the server marked the encoding so that the client could recognise the output is no longer iso-8859-1, but utf-8, such as including a BOM (although it may be preferable to include that inside a comment rather than at the beginning, I see benefits both ways), and thus old-but-not-ancient clients could autodetect the switch. Most likely, the server default will not change, though. Best regards -------- Original message -------- From: Marco d'Itri via db-wg <db-wg(a)ripe.net> Date: 12/18/23 00:44 (GMT+01:00) To: Piotr Strzyzewski <piotr(a)internetsailor.net> Cc: db-wg <db-wg(a)ripe.net> Subject: Re: [db-wg] Proposal to allow non-ASCII characters in "org-name:", "person:" and "role:" attributes On Dec 03, Piotr Strzyzewski via db-wg <db-wg(a)ripe.net> wrote: > As the UTF-8 topic was briefly discussed during DB-WG session at RIPE87 > in Rome, I would like to propose moving forward with it. If that means a > topic for first (?) interim meeting, let it be. Let me know please if > this works for you. Thanks in advance. In Rome I talked a bit with Edward about this. Background: I am the author of the whois client used by all Linux distributions. I fully agree that switching to UTF-8 is desirable, but we cannot just change the encoding of port 43 without major side effects. Since version 5.5.4 (december 2019), the client assumes that the output of whois.ripe.net is Latin 1 and then transcodes it to the system encoding. Receiving unexpected UTF-8 would cause mojibake. My suggestion is to add a new query "command line" option to specify the desired encoding (limiting it to either ISO-8859-1 or UTF-8), as supported by other whois servers. -C is the most common choice, but maybe it would be better to use --charset to not waste a single letter option. See https://github.com/rfc1036/whois/blob/next/servers_charset_list . In a few years then it will be much easier to switch the default from Latin 1 to UTF-8. -- ciao, Marco

1 0

Whois Release 1.109
by Edward Shryane 04 Dec '23

04 Dec '23

Dear colleagues, RIPE Database release 1.109 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Monday 4th December. The data in the RC environment is a dummified copy of production from 16th November. This release has the following main changes: * RDAP redaction (#1317) * Removed organisation "e-mail" from RDAP to match Whois and added to redaction list (#1333) * Removed geofeed prefix validation (#1326) * Added HTTPS Support to Whois Backend (#1329) * Support HTTP Basic authentication (#1342) * Support HTTPS Client Certificate Authentication (#1343) * Initialize NRTMv4 from command-line (JMX) (#1310) * Use parallel stream to generate NRTMv4 snapshots more quickly (#1309) * Include AS-SET in RIPE-NONAUTH dump (#1352) The release notes are on the website: https://apps.db.ripe.net/docs/Release-Notes/#ripe-database-release-1-109 More information on the Release Candidate environment can be found on our website: https://apps.db.ripe.net/docs/Release-Notes/ Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1