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

Dear Tim, Working Group,

[ exec summary: I'd like to see a round of +1's if you agree with the
proposal and my small addition at the end. ]

On Wed, Oct 21, 2015 at 04:32:26PM +0200, Tim Bruijnzeels wrote:
> There is an open action point on us regarding the use of the
> RIPE-NCC-RPSL-MNT maintainer:
> https://www.ripe.net/ripe/mail/archives/db-wg/2015-May/004626.html
> 
> > I'd like to ask RIPE NCC to provide the group with an implementation
> > plan and a timeline on how to prevent the RIPE-NCC-RPSL-MNT mntner from
> > being used to authenticate updates to an object after the object has
> > been created. We also ask that the RIPE NCC look into cleaning up
> > existing references to RIPE-NCC-RPSL-MNT and tell us their plan.
> 
> Note that there is an ongoing an important parallel discussion about
> the authorisation of out-of-region IRR objects in general. But this is
> specifically about the use of 'RIPE-NCC-RPSL-MNT' on "mnt-by:". As
> long as we do have RIPE-NCC-RPSL-MNT, there are things we can improve
> and we want to propose the following to working group:
> 
> 1) implement a business rule to prevent that this maintainer is used as 'mnt-by'
> 
> Submitting an object that includes 'mnt-by: RIPE-NCC-RPSL-MNT' would
> result in a hard error, with a message like: "The RIPE-NCC-RPSL-MNT is
> used to authorise the creation of out-of-region aut-num and route(6)
> objects, but may not be used as 'mnt-by'"
> 
> This is fairly trivial to implement, provided of course that the
> working group agrees to this.
> 
> 2) remove the maintainer from existing objects
> 
> There are roughly 2000 objects that are maintained by
> 'RIPE-NCC-RPSL-MNT' only, and about 10000 objects that are maintained
> by 'RIPE-NCC-RPSL-MNT' and at least one other maintainer.
> 
> In the first case we propose to lock the object, i.e. set 'mnt-by:
> RIPE-NCC-LOCKED-MNT', and send out a custom notification to any
> contacts on the object explaining that the object has been locked to
> prevent a hijack of the object, and that ripe-dbm at ripe.net can be
> contacted to unlock the object.
> 
> In the second case we propose to leave the remaining maintainer and
> send out a custom notification informing contacts on the object that
> the "RIPE-NCC-RPSL-MNT" has been removed to prevent a hijack of the
> object, and listing which maintainer(s) remain.
> 
> Technically this is not difficult either, but it can result in a lot
> of questions. Therefore we prefer to do this in batches to make sure
> that we can process possible follow up requests to ripe-dbm at ripe.net
> properly. For reference we used a similar approach when dealing with
> locking the old MD5 passwords earlier this year. Provided that the
> working group agrees with this, we expect this can be done in the
> space of a few weeks after the business rule is implemented.

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.

I am happy to hear none of the two steps are "technically difficult".

+1 from me

Kind regards,

Job