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@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@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