Database Working Group RIPE 77

Wednesday, 18 October 2018, 14:00-15:30
WG Co-Chairs: William Sylvester, Denis Walker
Scribe: Fergal Cunningham
Status: Draft

A. Introduction 

William Sylvester, working group co-chair, opened the session, asking for any other items to put on the agenda. No items were suggested.

B. Operational Update RIPE Database - Edward Shryane, the RIPE NCC

Ed Shryane gave the operational update from the RIPE NCC.

The presentation is available at:
https://ripe77.ripe.net/presentations/130-RIPE77-DB-Operational-Update.pdf

George Michaelson, APNIC, thanked the RIPE NCC for its work in completing the NWI-5 project on out-of-region objects in the RIPE Database. He commented on the specific reference to “reserved” space in Ed’s presentation, saying it means different things to different people, and Ed confirmed that this was the IETF version of “reserved”.

George also asked if there would need to be protection added in relation to 32-bit AS that has not been released into use but that people can potentially expose in BGP. Ed said the property is configurable so they will be able to make adjustments if problems are encountered in the future.

George added that APNIC had not contacted non-auth holders in their service region as they felt this was something for the RIPE NCC to do. He saw this as a communications issue that might need to be discussed further between the two RIRs.

Martin Levy, Cloudflare, asked if there was coordination between the RIPE NCC and AFRINIC that would see proactive removal of non-auth objects that have been put somewhere useful. Ed said they already saw duplicate routes in the AFRINIC and RIPE NCC databases so this is something that could be looked at, and there is also a numbered work item to look at removing AFRINIC routes from the RIPE non-auth Database.

Ruediger Volk, Deutsche Telekom, said the RIPE NCC should make sure to add updates to its service status pages during any database transitions and that the status itself should specify that something unusual is happening. He also asked about the RIPE Database no longer being able to validate RFC882 addresses – he wanted to know if the software was available to validate that a syntax was an RFC address. Ed said his slides showed the results of a check on this validation and asked if the working group thought the RIPE NCC should proceed along these lines or would it cause more problems. Ruediger asked that correct syntax be enforced as soon as possible and Ed said this would help with abuse-c validation and also parsing database objects.

Alan Barrett, AFRINIC, noted that they check AS validity differently – they do daily looks at the other four RIRs and therefore it can take time to catch up. Ruediger commented that responsibility for maintaining the dataset Alan talks about is not completely transparent and he noted differences between that dataset and the relevant IANA allocations dataset. Ed agreed to look into this after receiving details from Ruediger.

C. 2018-06 RIPE-NONAUTH Improvement Project - Erik Bais, A2B Internet,  and Martin Levy, Cloudflare

Erik Bais from A2B Internet and Martin Levy from Cloudflare presented slides prepared by Job Snijders, NTT, about the RIPE Policy Proposal in the Routing Working Group on the clean-up of the RIPE-NONAUTH dataset. The presentation is available at:
https://ripe77.ripe.net/presentations/138-RIPE77_dbwgroutingwg_2018_06_RPKI_IRR_Cleanup_Snijders.pdf

Nick Hilliard, INEX, said there is a need to have a general clean-up of the IRRDB and have some people sit with RIPE NCC people and figure out what is legitimate and what’s not and what can be cleaned up. Erik agreed with the general point but advised against postponing smaller clean-ups while waiting for a bigger project. Martin added that this work would build on the previous work to segregate non-auth routes.

Nick said there was also a procedural gap in that address holders with out-of-region objects in the RIPE IRR were unable to remove those objects. Martin said this was true for other databases and Nick acknowledged this but said we had to focus on the RIPE Database.

Erik asked Nick if signed ROAs would work for having authority to get rid of non-auth objects and said it mostly would work but there are likely to be corner cases where it would not work. Nick added that intra-company communications were important for this proposal to work and he added that he felt the proposal was a little bit dangerous in its hardline approach.

Elvis Velea, V4Escrow, asked how the proposal would work if a ROA was created for a /24 but there was a /16 route object in the non-auth, would the RIPE NCC have to delete the whole /16 block. Martin said the /16 would be untouched in this case as the scope of the ROA would only extend to the /24.

Elvis had a follow-up question about route objects created in both the RIPE and AFRINIC databases and whether the old one should be deleted when the new one is created. Martin said this was something for another proposal as the proposal in question just dealt with ROAs and the idea that their assertation should more authoritative value than IRR data. Erik added that AFRINIC was looking at ways to add ROAs that matched route objects in its IRR.

Gert Döring, RIPE Database user, said people are using data for business reasons and if you take it away they will be upset. Gert said a twist on the proposal could also be to allow anyone with a ROA to click a button that says they want to clean up all their certified space in the RIPE Database.

Ruediger Volk, Deutsche Telekom, regretted use of foul language during previous discussions on this matter. He said the time spent on this proposal could be better spent identifying dubious records and allowing RPKI users to assert they want to clean up data. He added that tampering with the data in an abstract manner with doing proper analysis first would be a mistake.

John Curran, ARIN, asked the proposers if they considered introducing a delay mechanism before deleting data to cater for cases where invalid announcements are the result of a typo – he suggested a 72-hour delay before deletion of RIPE-NONAUTH objects. Martin said that would be considered for version 2 of the proposal.

D. Country Code Use in RIPE DB and Extended Delegated Statistics and the RIPE Database

Ingrid Wijte, RIPE NCC, talked about country code use in the RIPE Database. The presentation is available at:
https://ripe77.ripe.net/presentations/73-CC-extdelstats-database-IW.pdf

There were no questions.

E. Discussion: PERSON objects in the RIPE Database

Working Group Chair Denis Walker opened a discussion on removing PERSON objects from the RIPE Database. His discussion slides are available at:
https://ripe77.ripe.net/presentations/63-PERSONobjects.pdf

Elvis Velea, V4ESCROW, said that he was assigned address space by his provider many years ago and his personal details were added to the RIPE Database by that provider without his consent. He suggested this type of data should be deleted and Denis asked if PERSON objects were needed at all.

Ruediger Volk, Deutsche Telekom, said he had concerns when people obsessively tried to remove data. He said the GDPR rules should cater for cases like Elvis’s and he would prefer to see good practice documentation on registration.

Hans Petter Holen, RIPE Chair, said it was amazing that these many PERSON objects existed, and he thanked Denis for bringing it to the working group’s attention. He said this was an LIR issue rather than a RIPE NCC issue and 17,000 LIRs should hold an evaluation and clean this up.  

Andreas Polyrakis, GRNET, outlined possible cases where the PERSON object might be useful to have but he agreed that removing it would be a step in the right direction.

Peter Koch, DENIC, said this was similar to the experience in the domain industry and he said that because data was in a PERSON object it was not necessarily non-compliant with GDPR. He suggested contacting the top five PERSON object creators to find out why they have these objects and for what purpose.

Kenji Shioda, Nebula Online, asked about the issue of the RIPE NCC owning the hardware that the personal data is stored on and said this could be non-compliant with GDPR. Denis said you could not assume that people were unaware that their data was in the RIPE Database.

Hans Petter clarified that the RIPE NCC in this case is the data processor, the LIR is the data controller, and this is specified under the contractual relationship. He said the RIPE NCC knows this is in the service contract, so the risk really lies with the LIR.

Elvis said work should start to move everyone towards using ROLE objects. Denis agreed with this and said discussion should move to the mailing list.

William concluded the session by thanking presenters, attendees and the RIPE NCC for scribe and chat support.