September 2018 - db-wg - mailman.ripe.net

remove bogon prefixes in the RIPE IRR NON-AUTH DB?
by Job Snijders 09 Oct '18

09 Oct '18

Dear WG, I'd like to raise the issue of bogon prefixes in the RIPE IRR, and ask RIPE NCC to remove all "bogon" route object registrations from the "RIPE-NONAUTH" IRR database. Today I was made aware of this example: $ whois -h whois.ripe.net -- "-Troute6 2001:db8::/32" | egrep -v "%|^$" route6: 2001:db8::/32 origin: AS25375 descr: AS25375 mnt-by: ch-stafag-1-mnt mnt-by: LEUNET-SECURITY-MNT created: 2018-08-25T15:27:50Z last-modified: 2018-08-25T15:27:50Z source: RIPE I'd consider the following prefixes, and any more-specifics of these to be bogons prefixes: 0.0.0.0/8 # RFC 1122 'this' network 10.0.0.0/8 # RFC 1918 private space 100.64.0.0/10 # RFC 6598 Carrier grade nat space 127.0.0.0/8 # RFC 1122 localhost 169.254.0.0/16 # RFC 3927 link local 172.16.0.0/12 # RFC 1918 private space 192.0.2.0/24 # RFC 5737 TEST-NET-1 192.168.0.0/16 # RFC 1918 private space 198.18.0.0/15 # RFC 2544 benchmarking 198.51.100.0/24 # RFC 5737 TEST-NET-2 203.0.113.0/24 # RFC 5737 TEST-NET-3 224.0.0.0/4 # Multicast 240.0.0.0/4 # Reserved ::/8 # RFC 4291 IPv4-compatible, loopback, et al 0100::/64 # RFC 6666 Discard-Only 2001:2::/48 # RFC 5180 BMWG 2001:10::/28 # RFC 4843 ORCHID 2001:db8::/32 # RFC 3849 documentation 3ffe::/16 # RFC 3701 old 6bone fc00::/7 # RFC 4193 unique local unicast fe80::/10 # RFC 4291 link local unicast fec0::/10 # RFC 3879 old site local unicast ff00::/8 # RFC 4291 multicast Any route/route6 objects covered by the above prefixes should be deleted from the database, and the software should be extended in such a way that nobody can register new route/route6 objects covered by the above list. Kind regards, Job

8 10

PERSON objects in the RIPE Database
by denis walker 07 Oct '18

07 Oct '18

Colleagues, I will start with a blunt question, then give some arguments for my concern. In May the RIPE NCC told me there are more than 2 million PERSON objects in the RIPE Database. That is almost 25% of the objects in the database. Who are these people and why do we hold so much personal data? At RIPE 76 the RIPE NCC legal team gave a presentation on GDPR and the RIPE Database. The basis of that presentation seemed to be that Article 3 of the RIPE Database Terms and Conditions defined one of the purposes of the database as: Facilitating coordination between network operators (network problem resolution, outage notification etc.) It was argued that this justifies the inclusion of personal data in the RIPE Database so that these people can be contacted in the event of network operational issues, even by people who have no business relationship with these contacts. But this Article makes no mention of 'personal' contact information. It was also mentioned that some personal data is included for policy reasons. The IPv4 Address Allocation and Assignment Policy makes a couple of references to contact data. In 4.0 Registration Requirements it says: All assignments and allocations must be registered in the RIPE Database....Registration data (range, contact information, status etc.) must be correct at all times This clearly associates contact information with the necessary registration. But this does not specify that it has to be 'personal' contact information. In 6.2 Network Infrastructure and End User Networks it says: When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users. This clearly has the intent of avoiding the need to enter 'personal' data as contact information. In the IPv6 Address Allocation and Assignment Policy it is even more vague saying in 3.3 Registration: Internet address space must be registered in a registry database accessible to appropriate members of the Internet community. This is necessary to ensure the uniqueness of each Internet address and to provide reference information for Internet troubleshooting at all levels, ranging from all RIRs and IRs to End Users. The goal of registration should be applied within the context of reasonable privacy considerations and applicable laws. 'Reference' information and concerns about privacy again clearly indicate that the intent is to avoid using 'personal' data for the contacts. This does raise a number of questions: -Should I believe that we really do have more than 2 million individual people in this region who can seriously address technical or administrative questions on Internet resources or network operational issues? -Why is it considered necessary for contacts to be identifiable people rather than roles? -Abuse-c was intentionally designed to reference a ROLE object, which no longer needs to have any referenced PERSON objects, to avoid the need to enter personal data, why can't technical matters be addressed in the same way? The purpose in the Terms and Conditions may define a reason for holding contact information, but it doesn't justify this level of personal data being held in the database. Perhaps it's time to review what is meant by 'contact information'. What is really needed to satisfy this purpose? For example, why do we need an address for a technical contact who may need to be contacted in the event of an operational issue? No one is going to go to that address or post a letter. As always your thoughts and opinions are welcome... cheers denis co-chair DB WG

4 7

Re: [db-wg] WG Chair Selection - Call for Discussion
by William Sylvester 05 Oct '18

05 Oct '18

WG Members, Congratulations to everyone on the success of NWI-5! With the deployment behind us and everyone back from holiday in August we are moving to the next step in our chair selection process. This email opens the two (2) weeks of chair selection discussion. All members of the community are encourage to make a discussion and express their approval or otherwise of the presented candidates. The candidates are as follows and have either made their interest known on this mailing list, or directly to the chair(s). I encourage each candidate to reiterate their qualifications to the mailing list. Piotr Strzyzewski Sean Stuart As members of this working group please discuss your approval or otherwise of each candidate. Best regards, Denis & William DB-WG Chairs

4 3

RIPE Policy Proposal 2018-05 Aims to Publish Legal Address Information
by Marco Schmidt 27 Sep '18

27 Sep '18

Dear colleagues, We just published the RIPE Policy proposal, 2018-05, "Publication of Legal Address of Internet Number Resource Holder", to the RIPE NCC Services Group mailing list. The goal of the proposal is for the RIPE NCC to publish the validated legal address information of holders of Internet number resources. As the publishing of such data likely will happen in the RIPE Database, we want to notify the Database Working Group. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2018-05 We encourage you to review this proposal and send your comments to <ncc-services-wg(a)ripe.net> before 26 October 2018. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

Re: [db-wg] Draft Agenda RIPE77 - Database Working Group
by William Sylvester 25 Sep '18

25 Sep '18

Dear Working Group Members, Below is the DRAFT agenda for the Database Working Group for RIPE77. If you would like to present please submit your content as soon as possible to the chairs. If you have any questions, comments, or requested changes please let the chairs know. Best regards, William & Denis DB-WG Chairs A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database – 45 mins Edward Shryane, RIPE NCC C. Discussion: PERSON objects in the RIPE Database – 15 mins Denis Walker D. NWI - Open Proposals – 15 mins Z. AOB (open discussion)

1 0

PERSON objects in the RIPE Database
by Alexander Stranzky 21 Sep '18

21 Sep '18

On 20/09/2018 15:04, denis walker via db-wg wrote: > Colleagues, > > I will start with a blunt question, then give some arguments for my > concern. In May the RIPE NCC told me there are?more than 2 million > PERSON objects in the RIPE Database. That is almost 25% of the objects > in the database. Who are these people and why do we hold so much > personal data? Hello, I suspect that many of these objects are old (pre-API) and/or duplicates. Before RIPE had a REST API (and I can't tell how many ISPs still use emails to create their resources) automatically fetching, linking, and updating a RIPE object was a pain (as is the current situation with APNIC) and likely involved someone to create the email personally. Hence going the easy route--making new entries every time. Regards, Alexander Stranzky -- velia.net Internetdienste GmbH * Hessen-Homburg-Platz 1 * 63452 Hanau Geschäftsführer: Franz G. Köhler, Arek Akilli * AG Hanau * HRB 7588 Tel: +49 6181 1898119 * http://www.velia.net

5 7

Re: [db-wg] PERSON objects in the RIPE Database
by Cynthia Revström 20 Sep '18

20 Sep '18

Hi, I am not sure how the best way to do this but maybe check the database for person handles with identical name, address, phone number and such things. Also maybe if we could take a look at the amount of person handles that are not used at all in any other object, and potentially delete them. Kind regards, Cynthia Revström On 2018-09-20 14:57, Alexander Stranzky via db-wg wrote: > On 20/09/2018 15:04, denis walker via db-wg wrote: >> Colleagues, >> >> I will start with a blunt question, then give some arguments for my >> concern. In May the RIPE NCC told me there are?more than 2 million >> PERSON objects in the RIPE Database. That is almost 25% of the objects >> in the database. Who are these people and why do we hold so much >> personal data? > Hello, > > I suspect that many of these objects are old (pre-API) and/or > duplicates. Before RIPE had a REST API (and I can't tell how many ISPs > still use emails to create their resources) automatically fetching, > linking, and updating a RIPE object was a pain (as is the current > situation with APNIC) and likely involved someone to create the email > personally. Hence going the easy route--making new entries every time. > > Regards, > Alexander Stranzky >

2 1

Whois release 1.92.6 deployed to Production
by Edward Shryane 20 Sep '18

20 Sep '18

Dear Working Group, we have deployed a bug-fix release 1.92.6 to production that fixes a bug when updating an object with a lowercase source value (e.g. "source: ripe"). The release notes have been updated: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… Regards Ed Shryane RIPE NCC

1 0

avoiding RIPE IRR vs. RPKI ROA mismatches/inconsistencies
by nusenu 13 Sep '18

13 Sep '18

Dear DB Working Group, when looking into RPKI and RIPE IRR coverage I stumbled on prefixes that are covered by a RIPE route object and a RPKI ROA, which is great, but there are cases where these records make conflicting statements about the origin of a prefix. example: 185.46.20.0/22 origin according to ROA: AS199785 origin according to route object: AS61952 origin according to RIS: AS61952 (matches route object) Note: this is just an example to better illustrate the issue. (I didn't do a comprehensive analysis to be able to tell how often this is the case but for a sample of ~1900 prefixes I found 3 such occurrences.) Since route objects and ROAs are created by the prefix holders this is possible (human mistake). Are there any measures in place to prevent or at least warn about the inconsistency when the IP holder creates/updates route objects and ROAs that would result in inconsistencies? What do you think about an UI feature that says something like: "You are about to change/create the route object for prefix ... would you also like to update the existing ROA to match the route object and help avoid inconsistencies?" [ ] yes [ ] no, I know what I'm doing, I'll fix the mismatch manually similarly for updating/creating ROAs. Should there even be a 'No' option? Should the question even be exposed to the user or should records simply be synced automatically once one of either is changed by the IP holder? and simply showing an info like: "We took care of updating your ROA/route object to keep in sync." In case there are well established best practices for an ASN change of a prefix these best practices should be incorporated (i.e. delete the route object and ROA, change the actual announcement in BGP, create new route and ROAs that match the announcement) kind regards, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

2 3

Whois release 1.92.5 deployed to Production
by Edward Shryane 11 Sep '18

11 Sep '18

Dear Working Group, after deploying the NWI-5 changes last week, we found an issue preventing out of region transfers (the top-level placeholder template still referenced the RPSL maintainer). We have now deployed a bug-fix release 1.92.5 to production that fixes this issue. Regards Ed Shryane RIPE NCC

1 0