[db-wg] Proposal to limit the use of the RIPE-NCC-RPSL-MNT on mnt-by

On Fri, Oct 23, 2015 at 10:51:25AM +0200, Tim Bruijnzeels wrote:
> > On 22 Oct 2015, at 23:05, denis <ripedenis at 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