- db-wg - mailman.ripe.net

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