<html><head></head><body><div class="ydp8474df95yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div></div>
<div>Hi Havard</div><div><br></div><div>Not sure I can answer all your questions but I will attempt some of them.</div><div><br></div><div>Firstly the 'forced delete' has nothing to do with the LIR portal. It is also indifferent to the authentication option you use (signed email, password, SSO). If you are the holder of an allocation or PI assignment then you can delete a ROUTE object for your resource or any more specific range using the MNTNER authentication on the resource object.</div><div><br></div><div>Why is authorisation still needed from a ROUTE object? I don't know much about how you guys structure your routing, but purely from the Database rules I can suggest this possible scenario (although it may not apply in practise). Suppose an LIR makes a sub-allocation to another organisation, but the LIR routes the whole of their allocation including the sub-allocation. The organisation holding the sub-allocation cannot choose to route their sub-allocation without the consent of the LIR as to create such a ROUTE object would need to be authorised by the LIR's ROUTE object covering the whole allocation.</div><div><br></div><div>cheers</div><div>denis</div><div><br></div><div>co-chair DB-WG</div><div><br></div>
</div><div id="ydp7b28d6a5yahoo_quoted_6212182343" class="ydp7b28d6a5yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Monday, 15 April 2019, 14:02:42 CEST, Havard Eidnes via routing-wg <routing-wg@ripe.net> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div dir="ltr">Hi,<br clear="none"><br clear="none">following up on my own message of earlier...<br clear="none"><br clear="none">I can't exactly say my questions were answered.<br clear="none"><br clear="none">Now, things have changed slightly, but the substance of my<br clear="none">question / suggestion remains the same.<br clear="none"><br clear="none">If I've understood correctly, after the implementation of the<br clear="none">NWI-5 (dealing with out-of-region address resources), changes<br clear="none">were made to the rules for route object creation, so that route<br clear="none">object creation should now in principle no longer be authorized<br clear="none">by the originating AS, but rather by the address space holder.<br clear="none">If that's correct, that's all fine.<br clear="none"><br clear="none">However, the new documentation for the route object creation<br clear="none">authorization is at<br clear="none"><br clear="none"> <a shape="rect" href="https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/route-object-creation-flowchart.pdf" rel="nofollow" target="_blank">https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/route-object-creation-flowchart.pdf</a><br clear="none"><br clear="none">so I have this question:<br clear="none"><br clear="none"> * Why should an already-existing matching route be used to<br clear="none"> authorize the creation of a new route object, if the entire<br clear="none"> control over route object creation is supposed to now rest<br clear="none"> with the address space holder? In other words, why isn't the<br clear="none"> authorization in mnt-routes / mnt-lower / mnt-by in the<br clear="none"> inet(6)num object sufficient?<br clear="none"><br clear="none">Consider the transition scenario, and a common configuration,<br clear="none">where an ISP is originating a route on behalf of the customer,<br clear="none">and when the route object for the customer's address space was<br clear="none">created, it would have been authorized by the mnt-routes of the<br clear="none">AS object, and probably also only has the ISPs maintainer as<br clear="none">mnt-by.<br clear="none"><br clear="none">Now, this route object acts as a blocker for allowing the<br clear="none">customer to move to another ISP, and the customer is prevented<br clear="none">from creating a new route object corresponding to the route the<br clear="none">new ISP will originate -- the old ISP could (if so inclined) hold<br clear="none">the customer hostage.<br clear="none"><br clear="none">I was told that this is mitigated by the "forced delete"<br clear="none">functionality of the RIPE database -- it could be used by the<br clear="none">address space holder to forcefully delete (how, exactly? Is<br clear="none">there a "forcefully delete" function in the LIR portal? What<br clear="none">about signed e-mail submissions -- any particular syntax?) the<br clear="none">pre-existing route object, ref.<br clear="none"><br clear="none"> <a shape="rect" href="https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/10-authorisation/10-13-force-delete-functionality" rel="nofollow" target="_blank">https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/10-authorisation/10-13-force-delete-functionality</a><br clear="none"><br clear="none">(The documentation doesn't answer the parenthetical question<br clear="none">above.)<br clear="none"><br clear="none">However, that can leave a time window where no route object is<br clear="none">registered for the address space, and in a maximally pessimistic<br clear="none">scenario that could create an operational problem with complete<br clear="none">loss of connectivity...<br clear="none"><br clear="none">This would have been much simpler and easier to deal with if any<br clear="none">preexisting route object did *not* play any role in the creation<br clear="none">of a new route object.<br clear="none"><br clear="none">Can someone please justify why a preexisting matching route<br clear="none">object should play any role in authorizing the creation of a new<br clear="none">route object, especially with the previous authorization patterns<br clear="none">of the objects involved?<div class="ydp7b28d6a5yqt8155032545" id="ydp7b28d6a5yqtfd25592"><br clear="none"><br clear="none">Best regards,<br clear="none"><br clear="none">- Håvard<br clear="none"></div></div></div>
</div>
</div></body></html>