restrict usage of RIPE-NCC-RPSL-MNT
Dear working group, The RIPE databse provides a mntner object which can be used to create route objects for IP ranges which are not allocated or assigned through the RIPE NCC. http://www.ripe.net/data-tools/db/faq/faq-db/how-to-create-a-route-object-wh... I did some digging to understand how the RIPE-NCC-RPSL-MNT mntner object is used in practise. You can fetch the dataset through this command: $ whois -h whois.ripe.net -- '-K -i mnt-by RIPE-NCC-RPSL-MNT' Usage exceeded my expectations: (object type: occurances) route: 12195 route6: 77 And much to my suprise I found that there are all kinds of objects which reference RIPE-NCC-RPSL-MNT with an "mnt-by:" attribute: aut-num: 341 mntner: 51 as-set: 37 person: 40 route-set: 33 organisation: 5 rtr-set: 1 inet-rtr: 1 key-cert: 1 Would it be an idea to prevent objects from being updated/created when they carry a "mnt-by: RIPE-NCC-RPSL-MNT" attribute? Secondly, should RIPE NCC proactively remove all "mnt-by: RIPE-NCC-RPSL-MNT" references from the database? Kind regards, Job
On Fri, Nov 14, 2014 at 12:33:05PM +0100, Job Snijders wrote:
Dear working group,
The RIPE databse provides a mntner object which can be used to create route objects for IP ranges which are not allocated or assigned through the RIPE NCC.
http://www.ripe.net/data-tools/db/faq/faq-db/how-to-create-a-route-object-wh...
I did some digging to understand how the RIPE-NCC-RPSL-MNT mntner object is used in practise. You can fetch the dataset through this command:
$ whois -h whois.ripe.net -- '-K -i mnt-by RIPE-NCC-RPSL-MNT'
Usage exceeded my expectations:
(object type: occurances)
route: 12195 route6: 77
And much to my suprise I found that there are all kinds of objects which reference RIPE-NCC-RPSL-MNT with an "mnt-by:" attribute:
aut-num: 341 mntner: 51 as-set: 37 person: 40 route-set: 33 organisation: 5 rtr-set: 1 inet-rtr: 1 key-cert: 1
Would it be an idea to prevent objects from being updated/created when they carry a "mnt-by: RIPE-NCC-RPSL-MNT" attribute?
Secondly, should RIPE NCC proactively remove all "mnt-by: RIPE-NCC-RPSL-MNT" references from the database?
Note: Once this AFRINIC effort [1] is well underway or finished, the amount of route objects should be greatly reduced. [1]: https://www.mail-archive.com/announce@afrinic.net/msg00847.html
On Fri, Nov 14, 2014 at 12:33:05PM +0100, Job Snijders wrote: Dear Job and All
I did some digging to understand how the RIPE-NCC-RPSL-MNT mntner object is used in practise. You can fetch the dataset through this command:
$ whois -h whois.ripe.net -- '-K -i mnt-by RIPE-NCC-RPSL-MNT'
Usage exceeded my expectations:
(object type: occurances)
route: 12195
I have noticed also that TOP10 ASes cover 80% of those routes. Moreover, most of them are longer prefixes from the same bigger network (like /16 divided to 256 /24 with the same data in the route object).
route6: 77
And much to my suprise I found that there are all kinds of objects which reference RIPE-NCC-RPSL-MNT with an "mnt-by:" attribute:
aut-num: 341 mntner: 51 as-set: 37 person: 40 route-set: 33 organisation: 5 rtr-set: 1 inet-rtr: 1 key-cert: 1
Would it be an idea to prevent objects from being updated/created when they carry a "mnt-by: RIPE-NCC-RPSL-MNT" attribute?
What about delete?
Secondly, should RIPE NCC proactively remove all "mnt-by: RIPE-NCC-RPSL-MNT" references from the database?
+1 Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On Fri, Nov 14, 2014 at 11:00:03PM +0100, Piotr Strzyzewski wrote:
Would it be an idea to prevent objects from being updated/created when they carry a "mnt-by: RIPE-NCC-RPSL-MNT" attribute?
What about delete?
We cannot delete these objects, that would wipe out a large portion of routing information regarding Africa. That is not acceptable. I solely mean to reject the update/creation of an object if it contains this line: mnt-by: RIPE-NCC-RPSL-MNT Because the above line is a security risk for the object, everybody knows the password for RIPE-NCC-RPSL-MNT.
Secondly, should RIPE NCC proactively remove all "mnt-by: RIPE-NCC-RPSL-MNT" references from the database?
+1
On Fri, Nov 14, 2014 at 11:12:44PM +0100, Job Snijders wrote:
On Fri, Nov 14, 2014 at 11:00:03PM +0100, Piotr Strzyzewski wrote:
Would it be an idea to prevent objects from being updated/created when they carry a "mnt-by: RIPE-NCC-RPSL-MNT" attribute?
What about delete?
We cannot delete these objects, that would wipe out a large portion of routing information regarding Africa. That is not acceptable. I solely mean to reject the update/creation of an object if it contains this line:
mnt-by: RIPE-NCC-RPSL-MNT
Because the above line is a security risk for the object, everybody knows the password for RIPE-NCC-RPSL-MNT.
I have been misunderstood. What about extending the protection to covers also the inability of deletion? Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
I would say it depends on the [future] AfriNIC procedure. I mean if the objects will be transferred not all at once but gradually there may be a situation when some objects still have to be kept in RIPE DB, and other (transferred ones) should live in AFRINIC DB. Obviously transferred objects are subject to future change, so they will have to be synchronized or removed from RIPE DB. In this scenario the object immunity can cause needless trouble. Isn't it reasonable just to change the maintainer to the another one, with the unknown password? 2014-11-15 1:16 GMT+03:00 Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl>:
On Fri, Nov 14, 2014 at 11:12:44PM +0100, Job Snijders wrote:
On Fri, Nov 14, 2014 at 11:00:03PM +0100, Piotr Strzyzewski wrote:
Would it be an idea to prevent objects from being updated/created when they carry a "mnt-by: RIPE-NCC-RPSL-MNT" attribute?
What about delete?
We cannot delete these objects, that would wipe out a large portion of routing information regarding Africa. That is not acceptable. I solely mean to reject the update/creation of an object if it contains this line:
mnt-by: RIPE-NCC-RPSL-MNT
Because the above line is a security risk for the object, everybody knows the password for RIPE-NCC-RPSL-MNT.
I have been misunderstood. What about extending the protection to covers also the inability of deletion?
Piotr
-- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
-- Alex Semenyaka
On Sat, Nov 15, 2014 at 10:33:12PM +0400, Alex Semenyaka wrote:
I would say it depends on the [future] AfriNIC procedure. I mean if the objects will be transferred not all at once but gradually there may be a situation when some objects still have to be kept in RIPE DB, and other (transferred ones) should live in AFRINIC DB. Obviously transferred objects are subject to future change, so they will have to be synchronized or removed from RIPE DB. In this scenario the object immunity can cause needless trouble.
Isn't it reasonable just to change the maintainer to the another one, with the unknown password?
RIPE NCC can work with affected parties which _only_ have "mnt-by: RIPE-NCC-RPSL-MNT" on a route object to get them to add another maintainer object. For all objects where there are multiple "mnt-by" lines, we just need to delete the "mnt-by: RIPE-NCC-RPSL-MNT" line and the object will be better secured. Kind regards, Job
On Fri, Nov 14, 2014 at 11:16:21PM +0100, Piotr Strzyzewski wrote:
On Fri, Nov 14, 2014 at 11:12:44PM +0100, Job Snijders wrote:
On Fri, Nov 14, 2014 at 11:00:03PM +0100, Piotr Strzyzewski wrote:
Would it be an idea to prevent objects from being updated/created when they carry a "mnt-by: RIPE-NCC-RPSL-MNT" attribute?
What about delete?
We cannot delete these objects, that would wipe out a large portion of routing information regarding Africa. That is not acceptable. I solely mean to reject the update/creation of an object if it contains this line:
mnt-by: RIPE-NCC-RPSL-MNT
Because the above line is a security risk for the object, everybody knows the password for RIPE-NCC-RPSL-MNT.
I have been misunderstood. What about extending the protection to covers also the inability of deletion?
You mean that mntner 'RIPE-NCC-RPSL-MNT' cannot delete objects? That sounds good as well. Kind regards, Job
participants (3)
-
Alex Semenyaka -
Job Snijders -
Piotr Strzyzewski