- db-wg - mailman.ripe.net

NWI-10 "Definition of Country" is Complete
by Edward Shryane 02 Dec '22

02 Dec '22

Dear Colleagues, The RIPE NCC has now completed the implementation of phase 3 of NWI-10: "Definition of Country". This work included: * Recording the legal address for all End User organisations with Provider Independent resource(s); * Populating the legal address country code into end user organisation objects in the RIPE database; * Updating the country code in the Extended Delegated Stats for all the Provider Independent resources an end user holds to the legal address country code. * Internal software changes to synchronise changes of legal address country code to the RIPE database and Extended Delegated Stats. More information about NWI-10 is available here: https://labs.ripe.net/author/stefania_fokaeos/our-plan-to-update-country-co… Regards Ed Shryane RIPE NCC

1 0

proposal: disallow creation of new non-hierarchically named AS-SET objects
by Job Snijders 01 Dec '22

01 Dec '22

Dear DB-WG, Speaking in individual capacity. In RFC 2622 section 5 specifies the naming convention for AS-SET objects. https://www.rfc-editor.org/rfc/rfc2622#section-5.1 There basically are two styles: * "short" (example: AS-SNIJDERS) * "hierarchical" (example: AS15562:AS-SNIJDERS) Problem statement ================= In recent weeks a number of hypergiant cloud providers have faced the thorny effects of adversarial AS-SET object naming collisions between IRR databases. An example of this phenomenon is the existence of AS-AMAZON in both RADB and RIPE. According to https://www.peeringdb.com/net/1418 the RADB copy of the object is the the correct one and populated with a number of members entries. The RIPE one is empty, and not under control of Amazon. The existence of the AS-AMAZON object in the RIPE database might cause some operators to inadvertently apply empty prefix-filters to EBGP sessions which in turn causes various problems. It seems Amazon has no recourse to get the AS-AMAZON object removed from the RIPE database; because the existence of that object in the RIPE database does not violate any policies (as far as I know). But perhaps, going forward, this community can do a little bit more to help prevent similar situations from happening to others. Solution proposal ================= I think the solution is to - GOING FORWARD - disallow creation of new AS-SET objects which follow the 'short' naming style. The advantage of hierarchical naming is that the existing authorization rules as applied by the RIPE Whois Server database engine do a decent job of protecting/separating namespaces. 'Grandfathering' existing short-named objects ensures that implementation of this solution proposal causes minimal (if any) disruption to existing workflows. The RIPE database engine blocking creation of short-named AS-SETs might help nudge the industry towards making hierarchical naming the norm. Related work ============ Related work throughout the registry industry: IRRd version 4 forces new AS-SET objects to be structured hierarchically: https://github.com/irrdnet/irrd/issues/408 Kind regards, Job

21 50

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

Issue with authorization in hierarchical as-sets
by Cynthia Revström 21 Nov '22

21 Nov '22

Hi DB-WG, While looking into the discussion about requiring hierarchical as-sets I wanted to see if all current hierarchical as-sets were authorized by the ASN holders and I found two separate issues (in my opinion). I could find at least two cases of hierarchical as-sets that were likely created before RIPE and RIPE-NONAUTH split. They are using APNIC ASNs and there are aut-num objects for both of them in RIPE-NONAUTH, but the as-sets are still in RIPE. I am not sure of the scope of this issue or if others consider it an issue, but it seems like that should possibly get cleaned up, or at least get checked out. I only tried to check if there were any occurrences of this, not trying to find a complete list, so I just checked for any 32-bit APNIC ASNs in the db dump using grep. For those who want to look at it, the grep command I used was: grep '^as\-set:\s*[Aa][Ss][1][3-6][0-9][0-9][0-9][0-9]' ripe.db.as-set There is also another issue related to authorization when it comes to hierarchical as-sets. While authorization by a maintainer listed as mnt-by on the aut-num object is required to create an as-set, that maintainer can then later be removed and there is no force-delete option like there is for inet(6)num delegations. I think that a force-delete option should be implemented so any maintainer with mnt-by on the relevant aut-num can delete an as-set. I think that it would also be helpful to introduce a "associated as-set objects" list to the DB web UI, just like there is for associated route objects currently. Something that could be an issue is the cleanup, what happens with an hierarchical as-set when the relevant ASN is de-registered? Maybe someone on the DB team could clarify? -Cynthia

2 1

2022-01 Policy Proposal Withdrawn (Personal Data in the RIPE Database)
by Angela Dall'Ara 17 Nov '22

17 Nov '22

Dear colleagues, The policy proposal 2022-01, "Personal Data in the RIPE Database” has been withdrawn. The goal of this proposal was to allow the publication of verified Personal Data in the RIPE Database only when justified by its purpose. The proposal is archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive… Reason for withdrawal: The proposer felt that the scope of this proposal was too wide and decided to withdraw the proposal. Raised concerns like the potential consequences of the consent based publication of personal data and the efficacy of their verification might be addressed in future discrete proposals. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

1 0

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

Re: [db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects
by William Weber 16 Nov '22

16 Nov '22

> Limiting database updates to only accounts associated with LIR sounds reasonable. I cannot support this unless it is limited to AS-SET and similar; i for example hand out IPv6 prefixes to endusers and that would be impossible if they are unable to create MNT/Person/ORGs. I support this in general for AS-SET which makes no sense to have access to unless you have an ASN, but the startup maintainer process should stay the same. Same for ORGs - to request ASNs the enduser needs an ORG and i as LIR should not have to create that or even have MNT-BY on it. — William Sent from my iPhone > On 16.11.2022, at 12:00, db-wg-request(a)ripe.net wrote: > > Send db-wg mailing list submissions to > db-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.ripe.net/mailman/listinfo/db-wg > or, via email, send a message with subject or body 'help' to > db-wg-request(a)ripe.net > > You can reach the person managing the list at > db-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of db-wg digest..." > > > Today's Topics: > > 1. Re: proposal: disallow creation of new non-hierarchically > named AS-SET objects (Pierfrancesco Caci) > 2. Re: proposal: disallow creation of new non-hierarchically > named AS-SET objects (Yang Yu) > 3. Re: proposal: disallow creation of new non-hierarchically > named AS-SET objects (Teun Vink) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 16 Nov 2022 10:48:18 +0100 > From: Pierfrancesco Caci <pcaci(a)pccwglobal.com> > To: Job Snijders via db-wg <db-wg(a)ripe.net> > Subject: Re: [db-wg] proposal: disallow creation of new > non-hierarchically named AS-SET objects > Message-ID: <20221116104818.25bba55e(a)lavoro.tippete.net> > Content-Type: text/plain; charset=US-ASCII > > Hi > Speaking as be.ccafrique and uk.pccwg-uk I support Job's proposal. > > Pf > >> On Mon, 14 Nov 2022 17:41:16 +0000 >> Job Snijders via db-wg <db-wg(a)ripe.net> wrote: >> >> CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe. >> >> Dear DB-WG, >> >> Speaking in individual capacity. >> >> In RFC 2622 section 5 specifies the naming convention for AS-SET >> objects. https://www.rfc-editor.org/rfc/rfc2622#section-5.1 >> There basically are two styles: >> >> * "short" (example: AS-SNIJDERS) >> * "hierarchical" (example: AS15562:AS-SNIJDERS) >> >> Problem statement >> ================= >> In recent weeks a number of hypergiant cloud providers have faced the >> thorny effects of adversarial AS-SET object naming collisions between >> IRR databases. >> >> An example of this phenomenon is the existence of AS-AMAZON in both RADB >> and RIPE. According to https://www.peeringdb.com/net/1418 the RADB copy >> of the object is the the correct one and populated with a number of >> members entries. The RIPE one is empty, and not under control of Amazon. >> >> The existence of the AS-AMAZON object in the RIPE database might cause >> some operators to inadvertently apply empty prefix-filters to EBGP >> sessions which in turn causes various problems. >> >> It seems Amazon has no recourse to get the AS-AMAZON object removed from >> the RIPE database; because the existence of that object in the RIPE >> database does not violate any policies (as far as I know). But perhaps, >> going forward, this community can do a little bit more to help prevent >> similar situations from happening to others. >> >> Solution proposal >> ================= >> I think the solution is to - GOING FORWARD - disallow creation of new >> AS-SET objects which follow the 'short' naming style. >> >> The advantage of hierarchical naming is that the existing authorization >> rules as applied by the RIPE Whois Server database engine do a decent >> job of protecting/separating namespaces. 'Grandfathering' existing >> short-named objects ensures that implementation of this solution >> proposal causes minimal (if any) disruption to existing workflows. >> >> The RIPE database engine blocking creation of short-named AS-SETs might >> help nudge the industry towards making hierarchical naming the norm. >> >> Related work >> ============ >> Related work throughout the registry industry: IRRd version 4 forces new >> AS-SET objects to be structured hierarchically: >> https://github.com/irrdnet/irrd/issues/408 >> >> Kind regards, >> >> Job >> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg >> > > > -- > Pierfrancesco Caci <pcaci(a)pccwglobal.com> > VP Network & Security Architecture - AS3491 Peering Coordinator > Tel.: +39 0287 049 871 > www.pccwglobal.com > > This message (and any attachments) may contain information that is > confidential, proprietary, privileged or otherwise protected by law. > The message is intended solely for the named addressee (or a person > responsible for delivering it to the addressee). If you are not the > intended recipient of this message, you are not authorized to read, > print, retain, copy or disseminate this message or any part of it. If > you have received this message in error, please destroy the message or > delete it from your system immediately and notify the sender. PCCW > Global cannot guarantee that this e-mail is secure, error-free and/or > virus-free as e-mail messages could be intercepted, altered, corrupted, > lost, delayed or become incomplete and/or infected by viruses in the > course of their transmission. PCCW Global and the sender therefore do > not accept liability for any loss or damage arising from any errors or > omissions in the contents of this e-mail. > > > > > ------------------------------ > > Message: 2 > Date: Wed, 16 Nov 2022 04:06:57 -0600 > From: Yang Yu <yang.yu.list(a)gmail.com> > To: denis walker <ripedenis(a)gmail.com> > Cc: Job Snijders <job(a)sobornost.net>, db-wg(a)ripe.net > Subject: Re: [db-wg] proposal: disallow creation of new > non-hierarchically named AS-SET objects > Message-ID: > <CAFwKRnR1U7X99nXsE_pqk982Hf4BXOZ9RoV+Aa7Y4C-Zyu=4fA(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > I support this proposal. > >> It seems Amazon has no recourse to get the AS-AMAZON object removed from >> the RIPE database; because the existence of that object in the RIPE >> database does not violate any policies (as far as I know). > > Also ran into this issue and would like to see policy support to > handle this kind of abuse. > >> On Mon, Nov 14, 2022 at 3:08 PM denis walker via db-wg <db-wg(a)ripe.net> wrote: >> Interesting timing. I was about to make the same suggestion but for a >> different reason...accountability. Currently ANYONE can create a set >> object in the RIPE Database. You can be completely anonymous, not a >> member or LIR, hold no resources. All you need to do is create a ROLE, >> MNTNER and set object. > > Anyone with an email can make a RIPE account and start creating > objects in RIPE database. In other registries there are usually some > safeguards on user / mntner object creation. Limiting database updates > to only accounts associated with LIR sounds reasonable. > > > Yang > > > > ------------------------------ > > Message: 3 > Date: Wed, 16 Nov 2022 11:19:17 +0100 > From: "Teun Vink" <teun(a)bit.nl> > To: "Job Snijders" <job(a)sobornost.net> > Cc: db-wg(a)ripe.net > Subject: Re: [db-wg] proposal: disallow creation of new > non-hierarchically named AS-SET objects > Message-ID: <A2DF4E9C-3BA7-415C-8C0A-FDBE11BF9736(a)bit.nl> > Content-Type: text/plain > > Hi all, > > On 14 Nov 2022, at 18:41, Job Snijders via db-wg wrote: > [...] >> Solution proposal >> ================= >> I think the solution is to - GOING FORWARD - disallow creation of new >> AS-SET objects which follow the 'short' naming style. >> > > I support this proposal. > > Kind regards, > -- > Teun Vink > BIT | teun(a)bit.nl | +31 318 648 688 > KvK: 09090351 | GPG: 0xFC8B25D6 | RIPE: TEUN-RIPE > > > > ------------------------------ > > Subject: Digest Footer > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg > > > ------------------------------ > > End of db-wg Digest, Vol 135, Issue 8 > *************************************

1 0

RIPE 85 session
by denis walker 08 Nov '22

08 Nov '22

Colleagues I would like to apologise for missing the DB-WG session at RIPE 85. I was taken ill the night before with severe gastric problems, which I have only recently recovered from. Now I am still recovering from covid also. I would like to thank my co-chair William for stepping in at the last minute to run the whole show. I have some comments to make on each presentation, but don't expect much from me this week. I will start to get my head round these issues again next week. cheers denis co-chair DB-Wg

1 0

Support for "::" notation in the "members" field
by James Bensley 04 Nov '22

04 Nov '22

Dear Working Group, I want to discuss a format change to the "members" field of the AS-SET and Route-Set objects in the RIPE DB. I do not know what the process is for this so please guide me if this is the wrong place to raise this. Specifically, I want to discuss adding supported for the "::" source notation in the "members" field of an AS-SET or Route-Set. Currently my AS-SET might look like the following when the tree is fully expanded: as-set: AS4200000011:AS-EXAMPLE-11 -> members: AS4200000011 -> members: AS4200000012:AS-EXAMPLE-12 - -> members: AS4200000012 - -> members: AS4200000021 -> members: AS4200000013:AS-EXAMPLE-13 - -> members: AS4200000013 - -> members: AS4200000022:AS-EXAMPLE-22 - - -> members: AS4200000031 When a peer or upstream is building the prefix lists towards me (AS4200000011), they need to generate a prefix list for my entire AS tree/route set tree. The problem is that historically objects with the same name have been registered in different IRR databases. This causes a problem because it's not clear which IRR DB should be used to pull the prefix list for a given ASN. For example, AS-GOOGLE current exists in RIPE and APNIC IRR DBs, but the AS-SET in both DBs is empty: $whois -h whois.ripe.net AS-GOOGLE | grep -E "as-set|members" as-set: AS-GOOGLE $whois -h whois.apnic.net AS-GOOGLE | grep -E "as-set|members" as-set: AS-GOOGLE As per Google's peeringdb page, the correct data source for their AS-SET is RADB: https://www.peeringdb.com/net/433 $whois -h whois.radb.net AS-GOOGLE | grep -E "as-set|members" as-set: AS-GOOGLE members: AS11344 members: AS13949 members: AS15169 ... The above query to RADB produces the correct information. Historically people have registered objects with the same AS-SET or Route-Set name, in different IRR DBs, both by accident and maliciously, and this practice continues today. It is very difficult to get these issues resolved in a timely manner and the result on daily operations is that we can't establish a new peering session with a customer/peer/upstream or update our prefix list facing an existing customer/peer/upstream because we can't generate the prefix towards them. We need to be able to signal which IRR DB is authoritative for an AS-SET or Route-Set object. For this reason I ask, what it would take to allow the use of the "::" indicator in the "members" field of an AS-SET and Route-Set so that in my own AS-SET I can specify the correct source for the direct members (my customers), and in their AS-SET's they can specify the correct source for each of their customers, and so on all the way down the tree, so that I end up with my AS-SET tree looking like the following when fully expanded: -> members: RIPE::AS4200000011 -> members: RADB::AS4200000012:AS-EXAMPLE-12 - -> members: RIPE::AS4200000012 - -> members: ARIN::AS4200000021 -> members: ARIN::AS4200000013:AS-EXAMPLE-13 - -> members: APNIC::AS4200000013 - -> members: ARIN::AS4200000022:AS-EXAMPLE-22 - - -> members: RADB::AS4200000031 Kind regards, James Bensley (he/him) Network Team Inter.link GmbH Boxhagener Str. 80, 10245 Berlin, Germany Email: hello(a)inter.link, Phone: +49-030-577123821 Registry: Local court Charlottenburg, HRB 138876 Managing directors: Marc Korthaus, Theo Voss

2 2

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