[routing-wg] Route object creation authorization

 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 at 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-training-course/route-object-creation-flowchart.pdf

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-database-documentation/10-authorisation/10-13-force-delete-functionality

(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
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/routing-wg/attachments/20190415/399a20c4/attachment.html>