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

Dear working group,

> On 22 Oct 2015, at 23:05, denis <ripedenis at yahoo.co.uk> wrote:
> 
> Hi guys
> 
> 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?

Cheers
Tim


> 
> cheers
> denis
> 
> On 22/10/2015 19:31, Gert Doering wrote:
>> Hi,
>> 
>> On Thu, Oct 22, 2015 at 12:55:07PM +0200, Job Snijders wrote:
>>> When the two steps above have been completed, it seems to me that the
>>> RIPE-NCC-RPSL-MNT maintainer can be deleted all together from the
>>> database, and we rely on the business rule as implemented in #1.
>> 
>> As soon as the maintainer object is gone, the business rule can go
>> as well...  you can't create anything that references a non-existing
>> maintainer.
>> 
>> Besides that nit pick, +1
>> 
>> Gert Doering
>>         -- NetMaster
>> 
>