<html><head></head><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_ym19_1_1539162147241_105812"><span>Hi Job</span></div><div id="yui_3_16_0_ym19_1_1539162147241_105812"><span id="yui_3_16_0_ym19_1_1539162147241_106126"><br id="yui_3_16_0_ym19_1_1539162147241_106125"></span></div><div id="yui_3_16_0_ym19_1_1539162147241_105812"><span id="yui_3_16_0_ym19_1_1539162147241_105885">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.</span></div><div id="yui_3_16_0_ym19_1_1539162147241_105812"><span><br></span></div><div id="yui_3_16_0_ym19_1_1539162147241_105812"><span id="yui_3_16_0_ym19_1_1539162147241_106117">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?</span></div><div id="yui_3_16_0_ym19_1_1539162147241_105812"><span><br></span></div><div id="yui_3_16_0_ym19_1_1539162147241_105812"><span>cheers</span></div><div id="yui_3_16_0_ym19_1_1539162147241_105812"><span>denis</span></div><div id="yui_3_16_0_ym19_1_1539162147241_105812" dir="ltr"><span>co-chair DB-WG</span></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1539162147241_105871"><br><br></div><div class="yahoo_quoted" id="yui_3_16_0_ym19_1_1539162147241_105914" style="display: block;"> <div style="font-family: Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1539162147241_105913"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1539162147241_105912"> <div dir="ltr" id="yui_3_16_0_ym19_1_1539162147241_105911"> <font size="2" face="Arial" id="yui_3_16_0_ym19_1_1539162147241_106251"> <hr size="1" id="yui_3_16_0_ym19_1_1539162147241_106250"> <b><span style="font-weight:bold;">From:</span></b> Job Snijders via db-wg <db-wg@ripe.net><br> <b><span style="font-weight: bold;">To:</span></b> Nick Hilliard <nick@foobar.org> <br><b><span style="font-weight: bold;">Cc:</span></b> Marco Schmidt <mschmidt@ripe.net>; db-wg@ripe.net<br> <b><span style="font-weight: bold;">Sent:</span></b> Sunday, 14 October 2018, 8:49<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [db-wg] RIPE Policy Proposal 2018-06 Aims to Delete Conflicting Non-authorative IRR Objects<br> </font> </div> <div class="y_msg_container"><br>Dear Nick,<br clear="none"><br clear="none">On Sat, Oct 13, 2018 at 10:38:12PM +0100, Nick Hilliard via db-wg wrote:<br clear="none">> Marco Schmidt via db-wg wrote on 11/10/2018 14:18:<br clear="none">> > We just published the RIPE Policy proposal, 2018-06, "RIPE NCC IRR<br clear="none">> > Database Non-Authoritative Route Object Clean-up", to the Routing<br clear="none">> > Working Group mailing list.<br clear="none">> > <br clear="none">> > The goal of the proposal is to delete an non-authoritative object<br clear="none">> > stored in the RIPE IRR, if it conflicts with an RPKI ROA.<br clear="none">> <br clear="none">> There are some corner cases where this could cause permanent and<br clear="none">> unwarranted pain.<br clear="none">> <br clear="none">> 1. what's the procedure for backing out the deletion if the ROA holder<br clear="none">> in the other RIR makes a mistake and, for example, forgets to create a<br clear="none">> roa for a specific ASN and then they find their RIPE-NONAUTH route<br clear="none">> object deleted by accident.<br clear="none"><br clear="none">When an operator makes a mistake, they've made a mistake. The same<br clear="none">already applies today when the operator changes the ASN in the<br clear="none">route/route6 object to the wrong origin ASN. The proposal does not have<br clear="none">a 'back out' procedure; once a route/route6 object in RIPE-NONAUTH<br clear="none">becomes in conflict with a RPKI ROA it should no longer exist.<br clear="none"><br clear="none">A different way of looking at things: What the policy proposal in a<br clear="none">nutshell does is apply the RFC 6811 BGP origin validation process to IRR<br clear="none">data. You could view the IRR data as if they are BGP announcements in<br clear="none">context of 6811.<br clear="none"><br clear="none">Example: An IRR route object in RIPE-NONAUTH states that for prefix<br clear="none">206.48.168.0/22 a possible origin is AS4663 - but a set of PKI ROAs<br clear="none">exists:<br clear="none"><br clear="none"> 206.48.0.0/16 AS5511 maxlength 24<br clear="none"> 206.48.0.0/16 AS6505 maxlength 24<br clear="none"> 206.48.0.0/16 AS51964 maxlength 24<br clear="none"><br clear="none">Obviously "206.48.168.0/22 AS4663" conflicts with the above set of ROAs<br clear="none">and would be marked with origin validation state 'invalid'.<br clear="none"><br clear="none">This means that any network applying RPKI based BGP Origin Validation<br clear="none">will reject the BGP announcement "206.48.168.0/22 AS4663", even though<br clear="none">someone documented in the RIPE-NONAUTH IRR that that announcement<br clear="none">perhaps could exist. The RIPE-NONAUTH IRR route object describes a state<br clear="none">of the network that is to be discarded anyway - so deletion is warranted<br clear="none">as it closes holes in prefix-list based filters in networks not doing<br clear="none">OV.<br clear="none"><br clear="none">Also note that in the above scenario the owner of the ARIN-managed<br clear="none">206.48.0.0/16 prefix never was consulted or consented to the creation of<br clear="none">the 206.48.168.0/22 route-object in the RIPE IRR. Leaving such objects<br clear="none">laying around is a disservice to the global community - when there is<br clear="none">clear and unambigious data that shows the IRR route object describes a<br clear="none">route announcement that is to be rejected anyway.<br clear="none"><br clear="none">> 2. what happens when someone is busy creating ROAs in, for example,<br clear="none">> Magastan and the RIPE NCC runs a deletion process mid-way through that<br clear="none">> process<br clear="none"><br clear="none">When someone needs to create multiple ROAs, but only publishes one - it<br clear="none">is an operator error. When one misconfigures things... they are<br clear="none">misconfigured, no big deal. This is why for example the RIPE RPKI portal<br clear="none">allows you to queue up RPKI ROA modifications and publish the batch in<br clear="none">one go. By the way, What is "magastan" and what does it have to do with<br clear="none">the topic at hand?<br clear="none"><br clear="none">To me "quality data" means that the routing information was created with<br clear="none">the explicit consent of the owner of the resource - this is something<br clear="none">the RPKI offers us. If the owner chooses to publish incorrect routing<br clear="none">information (for example: wrong origin ASN) that is entirely up to them.<br clear="none"><br clear="none">> 3. the above situations are complicated by RFC6382.<br clear="none"><br clear="none">Why? Section 6 of RFC 6382 explicitly states:<br clear="none"><br clear="none"> "Additionally, this technique sets the stage to employ RPKI-enabled<br clear="none"> machinery and more secure and explicit routing policies, which all<br clear="none"> network operators should be considering."<br clear="none"><br clear="none">What is your concern, how does RFC 6832 change anything? Perhaps you can<br clear="none">provide us with a tangible example scenario?<div class="yqt6135661626" id="yqtfd78944"><br clear="none"><br clear="none">> It might be a good idea to send some warnings to the holders of the<br clear="none">> route/route6 objects before nuking their objects + build in a timeout<br clear="none">> period.</div><br clear="none"><br clear="none">"their objects"?! We can not assume that the owner of a resource ever<br clear="none">asked for the objects in the first place. There are objects in the<br clear="none">RIPE-NONAUTH IRR that cover NTT Communications' resources where we've<br clear="none">never consented to their creation - since we are not the maintainer and<br clear="none">perhaps dont even have any relation with the creator of such objects, we<br clear="none">have no recourse to delete such objects. When we create RPKI ROAs<br clear="none">covering such route objects it is a clear public statement about which<br clear="none">ASNs are authorised to originate those prefixes. Any IRR information<br clear="none">that is in conflict with such information should be considered rogue and<br clear="none">a risk to our business.<br clear="none"><br clear="none">It'll take time before we see a great many networks deploy BGP Origin<br clear="none">Validation based on RPKI data, so an incremental beneficial step forward<br clear="none">is to apply the same origin validation procedure to unvalidated IRR<br clear="none">data, this closes loopholes. To me keaving the rogue IRR objects in<br clear="none">place and telling the industry to just deploy Origin Validation to<br clear="none">mitigate the effects of RIPE-NONAUTH objects would be unreasonable.<br clear="none"><br clear="none">RIPE-NONAUTH is a pile of garbage, we need to offer folks an easy way to<br clear="none">delete the portions of it affecting their resources (knownig that these<br clear="none">resource owners probably never have been aware those route/route6<br clear="none">objects existed in the first place!).<br clear="none"><br clear="none">Kind regards,<br clear="none"><br clear="none">Job<div class="yqt6135661626" id="yqtfd52399"><br clear="none"><br clear="none"></div><br><br></div> </div> </div> </div></div></body></html>