On Fri, Oct 23, 2015 at 10:51:25AM +0200, Tim Bruijnzeels wrote:
On 22 Oct 2015, at 23:05, denis <ripedenis@yahoo.co.uk> wrote:
Maybe I have missed something here. But I thought Tim was very clear that his proposal is to prevent the use of this MNTNER in a "mnt-by" attribute. He also said clearly it has nothing to do with the parallel discussion on hierarchical authorisation for out of region ROUTE objects.
The current proposal just prevents the use of this maintainer on mnt-by, but it is still used to authorise the creation of the objects. This is easy to implement and just enforces current best practice without fundamentally changing the authorisation model.
Therefore we propose to do this as a quick first step, and then continue with the discussion below.
So unless there is a plan to change the authorisation process to 'pass by default' hierarchical authorisation for any out of region address space or ASNs then this MNTNER is not going to be deleted any time soon.
With the proposed changes we would still be using it to authorise object creation, and it would be referenced on mnt-routes for out-of-region inet(6)num objects and mnt-lower on out-of-region as-sets. The business rule would just prevent using it on mnt-by.
But we can take this further, as some people have suggested. Allow me to add some thoughts to this ongoing discussion.
We know which resources are in-region, so we do not need to rely on placeholder objects and mnt-lower/mnt-routes for this. Instead we could have a business rule to allow authorisation for the out-of-region prefix or AS to be implicit. Anyone would be able to create these objects, much like today, but without the need for the maintainer or password.
As an added benefit this would eliminate the need for explicit out-of-region aut-num objects to authorise route(6) objects. The rule can be based on the origin attribute, it wouldn't insist that the aut-num exists. Having out-of-region aut-num objects authorise route(6) objects does not seem to add much security if anyone can create them in the first place. And having aut-num objects that are different from the object in the authoritative RIR database can cause issues. In addition, for out of region resources there is no need to create a dummy inetnum, so why would there be a need for a dummy aut-num?
I am confident there are quite some networks (that started out in a non-RIPE region) that would _love_ to see an implementation like this. Many of those operators describe it as 'dirty' that they are forced to register a place-holder autnum object in the RIPE database to be able to register the proper route-objects for their RIPE managed space. And to that point, there also are quite some networks that just gave up on the concept of registering fake autnum + proper route-objects in RIPE and resorted to just register their RIPE address space in a commodity IRR such as NTTCOM or RADB. I consider this a bad practise, as we (as community) loose the strong assurances that the RIPE db offers for those prefixes. Kind regards, Job