Proposal to limit the use of the RIPE-NCC-RPSL-MNT on mnt-by
Dear working group, 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. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group
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
On Thu, Oct 22, 2015 at 12:55:07PM +0200, Job Snijders wrote: Dear Job, WG Members
[ 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. ]
[cut]
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
+1 Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
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 -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
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. 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. 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
Dear working group,
On 22 Oct 2015, at 23:05, denis <ripedenis@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
On Fri, Oct 23, 2015 at 10:51:25AM +0200, Tim Bruijnzeels wrote:
On 22 Oct 2015, at 23:05, denis <ripedenis@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
On 22 Oct 2015, at 23:05, denis <ripedenis@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
+1 (despite the wg chairs having told us to vote otherwise)
then continue with the discussion below.
sigh randy
All, On Fri, 23 Oct 2015 19:51:47 +0900 Randy Bush <randy@psg.com> wrote:
On 22 Oct 2015, at 23:05, denis <ripedenis@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
+1 (despite the wg chairs having told us to vote otherwise)
I agree. Lets do the two mnt-by changes proposed, then worry about out-of-region authentication separately.
then continue with the discussion below.
sigh
It doesn't have to be a *long* discussion. :) Certainly some things are completely non-controversial (not requiring authentication from AS number holders), right? Cheers, -- Shane
On 21/10/2015 15:32, Tim Bruijnzeels wrote:
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.
sounds good (i.e. +1). Could you send 3M/1M/1W notifications of the removal and the consequences of the object being locked? Locking has operational implications and a bunch of people got hit with problems due to the mntner md5 locking issue a couple of months ago. Nick
Nick, On Thu, 22 Oct 2015 18:02:23 +0100 Nick Hilliard <nick@inex.ie> wrote:
On 21/10/2015 15:32, Tim Bruijnzeels wrote:
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.
sounds good (i.e. +1). Could you send 3M/1M/1W notifications of the removal and the consequences of the object being locked? Locking has operational implications and a bunch of people got hit with problems due to the mntner md5 locking issue a couple of months ago.
I suppose that's fine, but to be honest experience has shown that people either fix their information very quickly after notification, or wait until the very last minute, or only discover that they were supposed to do something much later. Based on this I'm kind of in favor of short(ish) migration periods - why have a long period in the middle when nothing much happens? Also, a longer period for something vaguely security related seems like a bad idea (although I think I was involved with perpetrating this problem more than a decade ago, so presumably the urgency is not very high). :) Cheers, -- Shane
On 23/10/2015 12:53, Shane Kerr wrote:
I suppose that's fine, but to be honest experience has shown that people either fix their information very quickly after notification, or wait until the very last minute, or only discover that they were supposed to do something much later.
Based on this I'm kind of in favor of short(ish) migration periods - why have a long period in the middle when nothing much happens?
because: people on holidays, change management, extended breaks during december, general business, people being, etc. In the worst case, this is 4 reminder emails, which removes almost all possibility for people to complain about adequate notice for something which might matter to them. Is this such a bad thing? Nick
Dear Tim, DB-WG Members It seems that support was shown for this proposal and no strong objections were raised during the discussion. Tim, would you be so kind and prepare the schedule for implementing this proposal? Kind regards, Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Dear working group,
On 19 Jan 2016, at 15:47, Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> wrote:
Dear Tim, DB-WG Members
It seems that support was shown for this proposal and no strong objections were raised during the discussion.
Tim, would you be so kind and prepare the schedule for implementing this proposal?
Of course. Tentatively I would say that we can work on this in February, but I can give a more detailed schedule by the beginning of next week. Kind regards, Tim Bruijnzeels
Kind regards, Piotr
-- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Dear working group, After discussing this with the working group chairs it was decided that we should implement the following: = RIPE NCC should send a warning email to contacts we can find for objects that use the RIPE-NCC-RPSL-MNT = RIPE NCC will implement a business rule to prevent the future use of RIPE-NCC-RPSL-MNT on mnt-by = RIPE NCC will remove RIPE-NCC-RPSL-MNT from objects, locking them if no other maintainers are present We plan to deploy release 1.86 for this to the Release Candidate environment on Wednesday 2 March. We aim to send warning emails on Monday 7 March. Provided no issues are found we plan to deploy the business rule to production, and remove the RIPE-NCC-RPSL-MNT from mnt-by on objects on Monday 21 March. We will inform the working group again when we do each step. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group
On 19 Jan 2016, at 16:23, Tim Bruijnzeels <tim@ripe.net> wrote:
Dear working group,
On 19 Jan 2016, at 15:47, Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> wrote:
Dear Tim, DB-WG Members
It seems that support was shown for this proposal and no strong objections were raised during the discussion.
Tim, would you be so kind and prepare the schedule for implementing this proposal?
Of course.
Tentatively I would say that we can work on this in February, but I can give a more detailed schedule by the beginning of next week.
Kind regards,
Tim Bruijnzeels
Kind regards, Piotr
-- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
participants (9)
-
denis -
Gert Doering -
Job Snijders -
Job Snijders -
Nick Hilliard -
Piotr Strzyzewski -
Randy Bush -
Shane Kerr -
Tim Bruijnzeels