Route object creation authorization
Hi, it looks like "things happened while I wasn't watching"... I've just had a run-in with the route object authorization rules as presently implemented in the RIPE database. I found the following flow chart documenting the authorization procedure: https://www.ripe.net/support/training/material/Routing-Security-Training-Cou... which is referenced from https://www.ripe.net/manage-ips-and-asns/db/support/managing-route-objects-i... The question I have is this: What is the policy reason for having a pre-existing route object play any role in authenticating the creation of a new route object, so that it in effect overrides any mnt-routes: fields of the corresponding inetnum object for the address space holder? When a customer who has his own address space and controls his own inetnum object, but lets his current ISP originate the route with the ISP's ASN as origin, but wants to move to another ISP, given the current rules, the current ISP is able to hold the customer hostage by refusing to create a new route object with a different ASN as origin. I would not have thought it was RIPE's role to raise and enforce such a barrier? I also can't quite comprehend why a route object would need the "mnt-routes" or "mnt-lower" attributes -- in an inetnum object I can understand the semantics of those, but in a route? Best regards, - Håvard
Hi, following up on my own message of earlier... I can't exactly say my questions were answered. Now, things have changed slightly, but the substance of my question / suggestion remains the same. If I've understood correctly, after the implementation of the NWI-5 (dealing with out-of-region address resources), changes were made to the rules for route object creation, so that route object creation should now in principle no longer be authorized by the originating AS, but rather by the address space holder. If that's correct, that's all fine. However, the new documentation for the route object creation authorization is at https://www.ripe.net/support/training/material/bgp-operations-and-security-t... so I have this question: * Why should an already-existing matching route be used to authorize the creation of a new route object, if the entire control over route object creation is supposed to now rest with the address space holder? In other words, why isn't the authorization in mnt-routes / mnt-lower / mnt-by in the inet(6)num object sufficient? Consider the transition scenario, and a common configuration, where an ISP is originating a route on behalf of the customer, and when the route object for the customer's address space was created, it would have been authorized by the mnt-routes of the AS object, and probably also only has the ISPs maintainer as mnt-by. Now, this route object acts as a blocker for allowing the customer to move to another ISP, and the customer is prevented from creating a new route object corresponding to the route the new ISP will originate -- the old ISP could (if so inclined) hold the customer hostage. I was told that this is mitigated by the "forced delete" functionality of the RIPE database -- it could be used by the address space holder to forcefully delete (how, exactly? Is there a "forcefully delete" function in the LIR portal? What about signed e-mail submissions -- any particular syntax?) the pre-existing route object, ref. https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab... (The documentation doesn't answer the parenthetical question above.) However, that can leave a time window where no route object is registered for the address space, and in a maximally pessimistic scenario that could create an operational problem with complete loss of connectivity... This would have been much simpler and easier to deal with if any preexisting route object did *not* play any role in the creation of a new route object. Can someone please justify why a preexisting matching route object should play any role in authorizing the creation of a new route object, especially with the previous authorization patterns of the objects involved? Best regards, - Håvard
Hi Havard Not sure I can answer all your questions but I will attempt some of them. 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. 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. cheersdenis co-chair DB-WG On Monday, 15 April 2019, 14:02:42 CEST, Havard Eidnes via routing-wg <routing-wg@ripe.net> wrote: Hi, following up on my own message of earlier... I can't exactly say my questions were answered. Now, things have changed slightly, but the substance of my question / suggestion remains the same. If I've understood correctly, after the implementation of the NWI-5 (dealing with out-of-region address resources), changes were made to the rules for route object creation, so that route object creation should now in principle no longer be authorized by the originating AS, but rather by the address space holder. If that's correct, that's all fine. However, the new documentation for the route object creation authorization is at https://www.ripe.net/support/training/material/bgp-operations-and-security-t... so I have this question: * Why should an already-existing matching route be used to authorize the creation of a new route object, if the entire control over route object creation is supposed to now rest with the address space holder? In other words, why isn't the authorization in mnt-routes / mnt-lower / mnt-by in the inet(6)num object sufficient? Consider the transition scenario, and a common configuration, where an ISP is originating a route on behalf of the customer, and when the route object for the customer's address space was created, it would have been authorized by the mnt-routes of the AS object, and probably also only has the ISPs maintainer as mnt-by. Now, this route object acts as a blocker for allowing the customer to move to another ISP, and the customer is prevented from creating a new route object corresponding to the route the new ISP will originate -- the old ISP could (if so inclined) hold the customer hostage. I was told that this is mitigated by the "forced delete" functionality of the RIPE database -- it could be used by the address space holder to forcefully delete (how, exactly? Is there a "forcefully delete" function in the LIR portal? What about signed e-mail submissions -- any particular syntax?) the pre-existing route object, ref. https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab... (The documentation doesn't answer the parenthetical question above.) However, that can leave a time window where no route object is registered for the address space, and in a maximally pessimistic scenario that could create an operational problem with complete loss of connectivity... This would have been much simpler and easier to deal with if any preexisting route object did *not* play any role in the creation of a new route object. Can someone please justify why a preexisting matching route object should play any role in authorizing the creation of a new route object, especially with the previous authorization patterns of the objects involved? Best regards, - Håvard
Hi, Denis, thanks for your follow-up.
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.
OK, so a "forced delete" is just a normal "delete" operation? Not sure then why it deserves the "forced" tag...
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.
That's normally what happens with PA address blocks. However, I still don't understand why authorization via an existing route object would be needed in that case -- all that would be needed to express the stated restriction is either mnt-lower or mnt-routes attributes in the enclosing address space object (inet{,6}num), which is typically held and maintained by the LIR. Best regards, - Håvard
Hi Havard (Sorry for not posting inline but yahoo doesn't allow for that option.) It is not quite a 'normal' delete. You are deleting an object using the authorisation from another, related, object. But not from any MNTNER on the object you are deleting. This is not possible in any other situation. Often when someone is given a sub-allocation the "mnt-by:" will be set to the LIRs MNTNER but the "mnt-lower:" may be set to the receiving organisation's MNTNER so they can make assignments. The sub-allocation could be split into two 'LIR PARTITIONED' objects, from which assignments can still be made. Then without this route creation flow, ROUTE objects could be created for the 'LIR PARTITIONED' objects. The first test would be for an exact matching INETNUM object. This would over ride any "mnt-routes:" set on the sub allocation object. cheersdenis co-chair DB-WG On Tuesday, 16 April 2019, 09:48:58 CEST, Havard Eidnes <he@uninett.no> wrote: Hi, Denis, thanks for your follow-up.
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.
OK, so a "forced delete" is just a normal "delete" operation? Not sure then why it deserves the "forced" tag...
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.
That's normally what happens with PA address blocks. However, I still don't understand why authorization via an existing route object would be needed in that case -- all that would be needed to express the stated restriction is either mnt-lower or mnt-routes attributes in the enclosing address space object (inet{,6}num), which is typically held and maintained by the LIR. Best regards, - Håvard
participants (2)
-
Havard Eidnes -
ripedenis＠yahoo.co.uk