Sorry I forgot to include routing-wg on my reply... ----- Forwarded Message ----- From: denis walker via db-wg <db-wg@ripe.net> To: Job Snijders <job@instituut.net>; Nick Hilliard <nick@foobar.org> Cc: Marco Schmidt <mschmidt@ripe.net>; "db-wg@ripe.net" <db-wg@ripe.net> Sent: Tuesday, 16 October 2018, 3:57 Subject: Re: [db-wg] RIPE Policy Proposal 2018-06 Aims to Delete Conflicting Non-authorative IRR Objects Hi Job Just a couple of points. First is a technical issue with your proposal. In your Rationale you mention ¨creating out of region inetnums¨. It wasn't possible to create such objects. Only out of region aut-nums and route(6)s. You talk about cleaning up garbage in the RIPE-NONAUTH IRR. The principle of cleaning up garbage is always good. But doesn't this still leave a lot of potential garbage in all the commercial IRRs where ROUTE objects can still be created without authorisation by, consent from and knowledge of the address space holder? So should we also be promoting the RIRs authoritative IRRs over commercial IRRs so that ROUTE objects can all be created with proper authorisation? cheersdenisco-chair DB-WG From: Job Snijders via db-wg <db-wg@ripe.net> To: Nick Hilliard <nick@foobar.org> Cc: Marco Schmidt <mschmidt@ripe.net>; db-wg@ripe.net Sent: Sunday, 14 October 2018, 8:49 Subject: Re: [db-wg] RIPE Policy Proposal 2018-06 Aims to Delete Conflicting Non-authorative IRR Objects Dear Nick, On Sat, Oct 13, 2018 at 10:38:12PM +0100, Nick Hilliard via db-wg wrote:

Marco Schmidt via db-wg wrote on 11/10/2018 14:18:

...

We just published the RIPE Policy proposal, 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up", to the Routing Working Group mailing list.

The goal of the proposal is to delete an non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA.

There are some corner cases where this could cause permanent and unwarranted pain.

1. what's the procedure for backing out the deletion if the ROA holder in the other RIR makes a mistake and, for example, forgets to create a roa for a specific ASN and then they find their RIPE-NONAUTH route object deleted by accident.

When an operator makes a mistake, they've made a mistake. The same already applies today when the operator changes the ASN in the route/route6 object to the wrong origin ASN. The proposal does not have a 'back out' procedure; once a route/route6 object in RIPE-NONAUTH becomes in conflict with a RPKI ROA it should no longer exist. A different way of looking at things: What the policy proposal in a nutshell does is apply the RFC 6811 BGP origin validation process to IRR data. You could view the IRR data as if they are BGP announcements in context of 6811. Example: An IRR route object in RIPE-NONAUTH states that for prefix 206.48.168.0/22 a possible origin is AS4663 - but a set of PKI ROAs exists:     206.48.0.0/16 AS5511 maxlength 24     206.48.0.0/16 AS6505 maxlength 24     206.48.0.0/16 AS51964 maxlength 24 Obviously "206.48.168.0/22 AS4663" conflicts with the above set of ROAs and would be marked with origin validation state 'invalid'. This means that any network applying RPKI based BGP Origin Validation will reject the BGP announcement "206.48.168.0/22 AS4663", even though someone documented in the RIPE-NONAUTH IRR that that announcement perhaps could exist. The RIPE-NONAUTH IRR route object describes a state of the network that is to be discarded anyway - so deletion is warranted as it closes holes in prefix-list based filters in networks not doing OV. Also note that in the above scenario the owner of the ARIN-managed 206.48.0.0/16 prefix never was consulted or consented to the creation of the 206.48.168.0/22 route-object in the RIPE IRR. Leaving such objects laying around is a disservice to the global community - when there is clear and unambigious data that shows the IRR route object describes a route announcement that is to be rejected anyway.

2. what happens when someone is busy creating ROAs in, for example, Magastan and the RIPE NCC runs a deletion process mid-way through that process

When someone needs to create multiple ROAs, but only publishes one - it is an operator error. When one misconfigures things... they are misconfigured, no big deal. This is why for example the RIPE RPKI portal allows you to queue up RPKI ROA modifications and publish the batch in one go. By the way, What is "magastan" and what does it have to do with the topic at hand? To me "quality data" means that the routing information was created with the explicit consent of the owner of the resource - this is something the RPKI offers us. If the owner chooses to publish incorrect routing information (for example: wrong origin ASN) that is entirely up to them.

3. the above situations are complicated by RFC6382.

Why? Section 6 of RFC 6382 explicitly states:     "Additionally, this technique sets the stage to employ RPKI-enabled     machinery and more secure and explicit routing policies, which all     network operators should be considering." What is your concern, how does RFC 6832 change anything? Perhaps you can provide us with a tangible example scenario?

It might be a good idea to send some warnings to the holders of the route/route6 objects before nuking their objects + build in a timeout period.

"their objects"?! We can not assume that the owner of a resource ever asked for the objects in the first place. There are objects in the RIPE-NONAUTH IRR that cover NTT Communications' resources where we've never consented to their creation - since we are not the maintainer and perhaps dont even have any relation with the creator of such objects, we have no recourse to delete such objects. When we create RPKI ROAs covering such route objects it is a clear public statement about which ASNs are authorised to originate those prefixes. Any IRR information that is in conflict with such information should be considered rogue and a risk to our business. It'll take time before we see a great many networks deploy BGP Origin Validation based on RPKI data, so an incremental beneficial step forward is to apply the same origin validation procedure to unvalidated IRR data, this closes loopholes. To me keaving the rogue IRR objects in place and telling the industry to just deploy Origin Validation to mitigate the effects of RIPE-NONAUTH objects would be unreasonable. RIPE-NONAUTH is a pile of garbage, we need to offer folks an easy way to delete the portions of it affecting their resources (knownig that these resource owners probably never have been aware those route/route6 objects existed in the first place!). Kind regards, Job