[db-wg] Proposal to limit the use of the RIPE-NCC-RPSL-MNT on mnt-by
- Previous message (by thread): [db-wg] Proposal to limit the use of the RIPE-NCC-RPSL-MNT on mnt-by
- Next message (by thread): [db-wg] Proposal to limit the use of the RIPE-NCC-RPSL-MNT on mnt-by
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Job Snijders
job at instituut.net
Fri Oct 23 11:23:01 CEST 2015
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
- Previous message (by thread): [db-wg] Proposal to limit the use of the RIPE-NCC-RPSL-MNT on mnt-by
- Next message (by thread): [db-wg] Proposal to limit the use of the RIPE-NCC-RPSL-MNT on mnt-by
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]