October 2022 - db-wg - mailman.ripe.net

Using the RIPE Database for IPAM
by denis walker 04 Oct '23

04 Oct '23

Colleagues Do you use the RIPE Database as your IPAM solution? If so, read on.... The RIPE NCC has done a brief review of the recommendations made by the DB Task Force (DBTF). You can find it here: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/initial-analys… There is one point in the summary that I disagree with: One recommendation can be implemented immediately by the RIPE NCC: - 3. Using the RIPE Database as an IPAM solution The recommendation from the DBTF was: "The task force recommends limiting and discouraging the use of the RIPE Database as an enterprise IPAM solution." This has not yet been discussed by the community and there is no consensus on this recommendation. So the RIPE NCC should not be doing anything to implement this recommendation. There are a number of points relating to this. The first BoF held by the DBTF had 46 participants. They had some polls about IPAM: Where do you hold your canonical IP address assignment details? (13 answers) Internal database or IPAM system (5 - 38%) RIPE Database (5 - 38%) Internal database for detailed assignments and RIPE database for allocations (3 - 23%) What should we do about the IPAM use of the RIPE Database? (12 answers) We should discourage it (3-25%) We should tolerate it but provide restrictions and best practices (5-42%) We should promote it and facilitate it (4-33%) During the BoF some comments were also made on this: Shane's comment "IPAM seems to be an important thing" Nathalie said about 50% of people attending training courses over a number of years said they use the RIPE DB for IPAM. Also trainees said open source IPAM solutions often pull data out of the RIPE DB but have no functionality to push data to the RIPE DB. During the presentation by the DBTF in the DB-WG session at RIPE 83 Shane said (on IPAM): "if you had very light requirements for IPAM then maybe it is OK, but it's not really what it's for" "unable to find out if this [response] was based on misunderstanding of the question" "we think there are probably good ways to go forward with that, for example making hooks so that external IPAM solutions can hook into it...that makes sense, there are certainly many commercial vendors that make IPAM products who would be happy to use hooks, there are many ways that third parties could use this but probably not a requirement" So it looks like there are very mixed views on the use of the RIPE Database for IPAM. Some people also expressed surprise that so many people use the database for IPAM. It is clear that we don't actually understand who, how and why people use the database for IPAM. We need a better understanding of the how and why and the number of users doing this before we can make any decision about discouraging or encouraging this use of the database. Even to consider if IPAM should be defined as a purpose of the database. As we are talking about it, maybe now is the time to start this discussion. If you use the RIPE Database as your IPAM solution maybe you can offer some more details. cheers denis co-chair DB-WG

5 5

NWI-14 Authenticating References to Objects
by denis walker 19 Jun '23

19 Jun '23

Colleagues The chairs propose creating NWI-14 for expanding the optional use of the "mnt-ref:" attribute to protect objects from accidental or intentional mis-representation of responsibility. See slide 14 of this presentation for the problem definition: https://ripe78.ripe.net/presentations/129-RIPE78-Operational-Update.pdf We ask the RIPE NCC to add NWI-14 to the list. cheers denis co-chair DB-WG

3 4

NWI-10 Populating End User Organisation Country Attribute
by Edward Shryane 01 Dec '22

01 Dec '22

Dear colleagues, As I mentioned in the Operational Update during the DB-WG session at RIPE85 last week (slide 16): https://ripe85.ripe.net/wp-content/uploads/presentations/111-DB-WG-Operatio… *today* the DB team will populate the "country:" attribute in approximately 20K organisation objects in the RIPE database. This will be done for end user organisations with resources allocated or assigned by the RIPE NCC, with the country code value where the resource holder is legally based. We are continuing work internally on the remaining end user organisations without a country code, and software changes for synchronisation during resource requests. Regards Ed Shryane RIPE NCC

5 9

Recognisition of Kosovo and adding of LIR signup options with Kosovo as well as XK in inet(6)num
by William Weber 17 Nov '22

17 Nov '22

Hi, As the Netherlands recognise the Republic of Kosovo as sovereign nation (see 1), and the EU does as well (see 2) there should be a way to include the proposed 2 letter country code (XK, see 3) as option for inet(6)num objects. The EU and other multinational organisation (IMF, SWIFT etc., see 4) use this code already since independence in 2008, and it is the currently reserved ccTLD for Kosovo as well. Kosovo also has a unique phone number prefix assigned (+383) by the ITU (see 5). It makes no sense that EU and AP is available (which are not countries, AP is not even in ISO-3166-2), but XK is not. I am aware the the X* series of codes is reserved and not permanently assigned, however UN Security Council resolution 1244/99 (see 6) mandates the use binding to all UN members. Please let me know how to bring in a draft resolution to adopt the ability to use Kosovo as legitimate country option in RIPE database objects, as well as the LIR sign up. It is the ONLY country that is recognised by both the Netherlands and the EU that cannot be used to sign up as a LIR and my client - a Telecoms company in Pristina that wants to stay anonymous at this time to avoid issues with Serbia - feels their right is violated by having to use either Serbia or Albania as billing location, and sees uncertainty in applicable laws and taxation with this. Thank you, William Weber (LIR Portal user: william(a)william.si, multiple LIRs managed) 1: https://web.archive.org/web/20080430070042/http://www.minbuza.nl/en/news/ne… Kosovo.html 2: https://ec.europa.eu/neighbourhood-enlargement/countries/detailed-country-i… 3: https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#User-assigned_code_elements 4: https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Glossary… 5: https://www.itu.int/dms_pub/itu-t/oth/02/02/T02020000FD0001PDFE.pdf 6: https://www.nato.int/kosovo/docu/u990610a.htm

13 22

Privacy proposal, concerns
by Frank Breedijk 27 Oct '22

27 Oct '22

Dear all, I’m new to this mailing list, but joined because I’m concerned about this policy proposal: https://www.ripe.net/participate/policies/proposals/2022-01 <https://www.ripe.net/participate/policies/proposals/2022-01> I am a volunteer for DIVD, the Dutch Institute for Vulnerability Disclosure. We are a non profit organisation that aims to make the digital world safer by reporting vulnerabilities we find in digital systems to the people who can fix them. For this we heavily reply on whois and the underlying database like RIPE NCC’s DB. (For more information see https://www.divd.nl <https://www.divd.nl/> and https://csirt.divd.nl <https://csirt.divd.nl/>) We are very concerned about the impact this proposal may have on us and on RIPE NCC. The basis of the proposal is good. Let’s stop collecting and publishing PII in RIPE DB, especially where it doesn’t serve the purpose of the DB. But RIP NCC is setting itself up for a lot of trouble by going to “permission” as the GDPR ground for processing instead of “legitimate interests pursued by the controller” Especially this line in the proposal can be explained as such: “All organisations holding resources allocated or assigned by the RIPE NCC, or documented in the RIPE Database, must sign a declaration that they have read and understood this policy and that either all the data for their organisation and resources contained in the RIPE Database is fully compliant with this policy or they are working towards full compliance.” With this statement in the policy it is quite possible that RIPE NCC at some point will have to choose between two evils: a) Either revoking all resources of those parties that did not sign a declaration b) Removing all PII of those parties from the database. What would the impact be? I analyzed 7476 IP addresses that popped up in a certain case using ripeSTAT and whois (see attachment) 458 Afrinic 1052 APNIC 1277 ARIN 190 LACNIC 4090 RIPE 409 no RIR in ripeSTAT abuse finder API I marked all email addresses that were not clearly a “function”/group/department mailbox as personal. If we could not report to email addresses that were personal we would not be able to report abuse to 929 out of 7476 ip addresses. (~12%) 201 of these IP addresses belong to the rir RIPE. (of the 4090 marked as belonging to RIPE, about 5%) 180 of these come from the ripeSTAT API, so they come from a CONTACT record, not a PERSON record. In only 21 cases I had to resort to whois to get a PERSON record. Conclusion: A small but significant portion of “abuse” addresses are “personal” Most of these are in CONTACT records not PERSON records. Besides these email addresses, RIPE NCC will have to do the work to be GDPR compliant for other PII anyway. IP addresses are considered PII in The Netherlands, a work/group phone number/email can still be PII, e.g. in the case where the company is a single person company or the company name can be traced back to a natural person, so going this route creates a lot of work and doesn’t actually reduce the compliance load on RIPE NCC. Regards, Frank Breedijk +31643822637

3 5

2022-01 Review Phase (Personal Data in the RIPE Database)
by Angela Dall'Ara 20 Oct '22

20 Oct '22

Dear colleagues, Policy proposal 2022-01, "Personal Data in the RIPE Database", is now in the Review Phase. The goal of this proposal is to allow the publication of verified Personal Data in the RIPE Database only when they are justified by its purpose. The proposal has been updated to version 3.0 after the last round of discussion. This version differs from version 2.0 as follows: - it is not explicitly proscribed to enter the name of a person in role objects - the verification of fax numbers is not required The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion. You can find the proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2022-01 https://www.ripe.net/participate/policies/proposals/2022-01#impact-analysis And the draft documents at: https://www.ripe.net/participate/policies/proposals/2022-01/draft As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to <db-wg(a)ripe.net> before 4 November 2022. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

5 6

Agenda RIPE85 - Database Working Group
by William Sylvester 10 Oct '22

10 Oct '22

Below is the agenda for the Database Working Group for RIPE85. If you would like to present, have questions, comments, or requested changes please let the chairs know. Best regards, William & Denis DB-WG Chairs A. Introduction - 10 min * Welcome * Scribe * Jabber * Chairs & Succession Planning * Agenda B. NWI Update – 20 mins Denis Walker, Co-Chair DB-WG C. Operational Update– 20 mins Edward Shryane, RIPE NCC D. Geofeed Discussion – 10 mins Denis Walker, Co-Chair DB-WG E. Proposal 2022-01 – 10 mins Denis Walker, Co-Chair DB-WG Z. AOB (open discussion)

2 1

RIPE Database Service Criticality Questionnaire
by denis walker 10 Oct '22

10 Oct '22

Colleagues [Apologies to Job for copying your email from the Routing WG but you explained it well :) ] The RIPE NCC has asked the Database WG Chairs to facilitate a working group conversation on framing the RIPE Database service subcomponents in terms of criticality. At the bottom of this email is a form that focuses on three components: confidentiality, integrity and availability. Each component is split into three questions (a, b, and c), a total of 9 questions are being put forward to the working group. We envisage this process to be a public consultation: WG participants can submit (free-form) responses, and also chime in by replying to each other's responses; hopefully bringing us to a degree of consensus in the coming weeks. We believe this is a unique opportunity to help the RIPE NCC! The goal is to help the RIPE NCC develop a deeper understanding of how the moving parts fit together, which in turn helps decide where and how to invest resources. >>> Your feedback is much appreciated! <<< cheers, denis, William DB WG co-chairs ----------------------- FORM STARTS HERE ----------------------- Service Criticality Form - RIPE Database Introduction ------------ This form is used to gather input from the community on the service criticality of the RIPE database. The framework is detailed in https://labs.ripe.net/author/razvano/service-criticality-framework/ The service criticality has three components: * Confidentiality What is the highest possible impact of a data confidentiality -related incident (data leak)? * Integrity What is the highest possible impact of a data integrity -related incident (hacking)? * Availability What is the highest possible impact of a service availability -related incident (outage)? All our services are designed with at least 99% availability, so please consider outages of up to 22 hours. Service Purpose --------------- The RIPE Database is the public internet registry for the RIPE NCC region, comprised of: * Internet Number Registry * Internet Routing Registry * Reverse Delegations The critical parts of the service are: * Query (Port 43, REST API, NRTM, Web Application) * FTP dumps (whole database and split files) The non-critical part of the service is: * Update (REST API, Mailupdates, Syncupdates) Service Criticality ------------------- Please review the following three areas. (1) Global Routing Incident Severity * Low (No / negligible impact) * Medium (One or a few ASes are unavailable) * High (Many ASes in a region are unavailable) * Very High (Global Internet routing disruptions) Please rate the incident severity (Low to Very High) in the following three areas. Please explain why. (a) Confidentiality (Impact level of incidents such as data leaks) (b) Integrity (Impact level of incidents such as hack attempts) (c) Availability (Impact level of service outage incidents, up to 22 hours per quarter) (2) IP addresses and AS Numbers Incident Severity * Low (No / negligible impact) * Medium (Local disruptions (registration information not being available for some entities)) * High (Regional disruptions (registration information not being available for the RIPE NCC region)) * Very High (Global disruptions (lack of registration information for all AS Numbers and IP addresses)) Please rate the incident severity (Low to Very High) in the following three areas. Please explain why. (a) Confidentiality (Impact level of incidents such as data leaks) (b) Integrity (Impact level of incidents such as hack attempts) (c) Availability (Impact level of service outage incidents, up to 22 hours per quarter) (3) Global DNS Incident Severity * Low (No / negligible impact) * Medium (Local disruptions) * High (Regional disruptions) * Very High (Global disruptions) Please rate the incident severity (Low to Very High) in the following three areas. Please explain why. (a) Confidentiality (Impact level of incidents such as data leaks) (b) Integrity (Impact level of incidents such as hack attempts) (c) Availability (Impact level of service outage incidents, up to 22 hours per quarter)

2 2

Whois Release 1.104
by Edward Shryane 10 Oct '22

10 Oct '22

Dear Colleagues, RIPE Database release 1.104 has been deployed to the Release Candidate environment. We plan to deploy to production on Monday 10th October. This release includes the following main changes: * Allow Grouping (-G) flag in Whois Search API (#1077) * cidr0 notation for rdap response (#1068) * Remove whois tags (#1059) * Added text/plain to Search and REST APIs (#1054) * Add comment not NOOP (#1052) * Do not allow comments in managed attributes (#1045) * Use documentation prefix 192.0.2.0/24 (#1044) * Organisation country: is modifiable for end-user orgs without RIPE NCC resources (#1041) * Do not return deleted versions (#1015) * Redirect empty requests to syncupdates help (#1011) The release notes are on the website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… More information on the Release Candidate environment can be found on our website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candid… Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1