Solving the issue of rogue ROUTE objects in the RIPE Database
HI all I am going to have one last go at solving this problem. I challenge anyone/everyone to tell me why this is such a stupid idea, technically impossible to do, won't solve any of the issues partially or fully. Then I can shut up about it and go away. If you can't condemn the idea then support it. Lets fix this issue once and for all, stop this endless discussion about rogue ROUTE objects and get on with life. So here is my 4 step proposal that I believe could be implemented within a month. If we implemented this you can be sure that all ROUTE objects in the RIPE Database were created with the knowledge and approval of the related resource holders. I believe that is the desired goal. STEP 1 Any ROUTE object submitted for creation in the RIPE Database involving an out of region resource (address space and/or ASN) where that out of region resource does not exist in the authoritative RIR database (has not been allocated or assigned), reject the creation. The RIPE NCC mirrors the operational data from all the other 4 RIRs. These mirrors are updated daily as well as the RIRs daily stats. It is easy to determine if a resource is registered in the authoritative database. STEP 2 For those ROUTE objects from STEP 1 where the out of region resource does exist, hold the object creation as pending. The mechanism for doing this already exists in the RIPE Database software as it is used for multiple authentications. Lookup the out of region resource(s) in the authoritative database(s) and find the contacts for that resource. Send a notification to those contacts informing them of the pending ROUTE object creation in the RIPE Database. The notification mechanism already exists in the RIPE Database software. If they don't approve, do nothing and the creation request will time out after a week and the object will not be created. If they do approve, respond in some way (many technical options for doing this that the RIPE NCC can choose from). If appropriate approval(s) are received within a week, create the ROUTE object. STEP 3 On a daily basis, for each ROUTE object in the RIPE Database that relates to an out of region resource, check for the continued existence of that resource in the appropriate RIR database. If it no longer exists, delete the ROUTE object from the RIPE Database. STEP 4 This is a one off cleanup of existing ROUTE objects. For all ROUTE objects currently in the RIPE Database that relate to an out of region, existing resource, send the appropriate notifications. For any that no response is received within a week, delete the ROUTE object from the RIPE Database. cheers denis
Hi, On Thu, Nov 05, 2015 at 07:40:58PM +0000, ripedenis@yahoo.co.uk wrote:
So here is my 4 step proposal that I believe could be implemented within a month. If we implemented this you can be sure that all ROUTE objects in the RIPE Database were created with the knowledge and approval of the related resource holders. I believe that is the desired goal.
This sounds like a workable and fairly low-effort approach to me which would bring lots of direct benefits. So +1, full support. (I do see some resistance in the form "but, but, what about the other databases?" - yes, we need to clean up cross-registry and all that, but cleaning up our own backyard right away without having to wait for the global solution is GOOD)
STEP 4
This is a one off cleanup of existing ROUTE objects. For all ROUTE objects currently in the RIPE Database that relate to an out of region, existing resource, send the appropriate notifications. For any that no response is received within a week, delete the ROUTE object from the RIPE Database.
I'm a bit more careful about that one, though - in principle, yes, but "one week" is a bit harsh here, so I'd go for multiple reminders and a longer time. This is a different case than "I have just added this object and it is now showing up (with an appropriate message by the DB robot), so let's just check my mail until the reminder appears!". (NB: did you intentionally not copy db-wg?) 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 Gert Thanks for the quick response and support. On 05/11/2015 20:56, Gert Doering wrote:
Hi,
On Thu, Nov 05, 2015 at 07:40:58PM +0000, ripedenis@yahoo.co.uk wrote:
So here is my 4 step proposal that I believe could be implemented within a month. If we implemented this you can be sure that all ROUTE objects in the RIPE Database were created with the knowledge and approval of the related resource holders. I believe that is the desired goal.
This sounds like a workable and fairly low-effort approach to me which would bring lots of direct benefits. So +1, full support.
(I do see some resistance in the form "but, but, what about the other databases?" - yes, we need to clean up cross-registry and all that, but cleaning up our own backyard right away without having to wait for the global solution is GOOD)
I agree a full implementation of cross registry auth with all 4 other RIRs would be great....but how far has that gone in the last 6 months since the last RIPE Meeting?
STEP 4
This is a one off cleanup of existing ROUTE objects. For all ROUTE objects currently in the RIPE Database that relate to an out of region, existing resource, send the appropriate notifications. For any that no response is received within a week, delete the ROUTE object from the RIPE Database.
I'm a bit more careful about that one, though - in principle, yes, but "one week" is a bit harsh here, so I'd go for multiple reminders and a longer time. This is a different case than "I have just added this object and it is now showing up (with an appropriate message by the DB robot), so let's just check my mail until the reminder appears!".
Agreed.
(NB: did you intentionally not copy db-wg?)
I put this idea on the table before the last RIPE Meeting. I even wrote a RIPE Labs article on it. I wasn't there but tried to get it input to the BOFF on the issue. But I was pretty much ignored. So I thought this time I will target the people who make the most complaints about the consequences of the problem. If these guys like the idea then maybe the DB WG will pick it up :) cheers denis
Gert Doering -- NetMaster
That might not get as much traction but a cross registry one time cleanup of such route objects should be attempted to be coordinated, I guess? --srs
On 06-Nov-2015, at 1:36 AM, denis <ripedenis@yahoo.co.uk> wrote:
I agree a full implementation of cross registry auth with all 4 other RIRs would be great....but how far has that gone in the last 6 months since the last RIPE Meeting?
On Thu, Nov 05, 2015 at 08:56:42PM +0100, Gert Doering wrote: Hi
On Thu, Nov 05, 2015 at 07:40:58PM +0000, ripedenis@yahoo.co.uk wrote:
STEP 4
This is a one off cleanup of existing ROUTE objects. For all ROUTE objects currently in the RIPE Database that relate to an out of region, existing resource, send the appropriate notifications. For any that no response is received within a week, delete the ROUTE object from the RIPE Database.
I'm a bit more careful about that one, though - in principle, yes, but "one week" is a bit harsh here, so I'd go for multiple reminders and a longer time. This is a different case than "I have just added this object and it is now showing up (with an appropriate message by the DB robot), so let's just check my mail until the reminder appears!".
+1 on that.
(NB: did you intentionally not copy db-wg?)
What about routing-wg? Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Den 2015-11-05 kl. 20:40, skrev ripedenis@yahoo.co.uk:
HI all
I am going to have one last go at solving this problem. I challenge anyone/everyone to tell me why this is such a stupid idea, technically impossible to do, won't solve any of the issues partially or fully. Then I can shut up about it and go away. If you can't condemn the idea then support it. Lets fix this issue once and for all, stop this endless discussion about rogue ROUTE objects and get on with life.
So here is my 4 step proposal that I believe could be implemented within a month. If we implemented this you can be sure that all ROUTE objects in the RIPE Database were created with the knowledge and approval of the related resource holders. I believe that is the desired goal.
Hi Denis, I don't see any immediate pitfalls in your 4-step. The only small, very small, thing is step 3 and it can be abused. But only for <24h. So I think your proposal makes sense. +1 for it. rgrds, /bengan
STEP 1
Any ROUTE object submitted for creation in the RIPE Database involving an out of region resource (address space and/or ASN) where that out of region resource does not exist in the authoritative RIR database (has not been allocated or assigned), reject the creation.
The RIPE NCC mirrors the operational data from all the other 4 RIRs. These mirrors are updated daily as well as the RIRs daily stats. It is easy to determine if a resource is registered in the authoritative database.
STEP 2
For those ROUTE objects from STEP 1 where the out of region resource does exist, hold the object creation as pending. The mechanism for doing this already exists in the RIPE Database software as it is used for multiple authentications.
Lookup the out of region resource(s) in the authoritative database(s) and find the contacts for that resource. Send a notification to those contacts informing them of the pending ROUTE object creation in the RIPE Database. The notification mechanism already exists in the RIPE Database software. If they don't approve, do nothing and the creation request will time out after a week and the object will not be created. If they do approve, respond in some way (many technical options for doing this that the RIPE NCC can choose from). If appropriate approval(s) are received within a week, create the ROUTE object.
STEP 3
On a daily basis, for each ROUTE object in the RIPE Database that relates to an out of region resource, check for the continued existence of that resource in the appropriate RIR database. If it no longer exists, delete the ROUTE object from the RIPE Database.
STEP 4
This is a one off cleanup of existing ROUTE objects. For all ROUTE objects currently in the RIPE Database that relate to an out of region, existing resource, send the appropriate notifications. For any that no response is received within a week, delete the ROUTE object from the RIPE Database.
cheers denis
-- Bengt Gördén Resilans AB
+1 here - though for step 3 it might be an idea to check just how many such objects are there and with what frequency they pop up. Some of these funny announcements can be short lived indeed - only lasting a few hours. --srs
On 06-Nov-2015, at 1:29 AM, Bengt Gördén <bengan@resilans.se> wrote:
I don't see any immediate pitfalls in your 4-step. The only small, very small, thing is step 3 and it can be abused. But only for <24h
Hi, On Fri, Nov 06, 2015 at 06:01:53AM +0530, Suresh Ramasubramanian wrote:
+1 here - though for step 3 it might be an idea to check just how many such objects are there and with what frequency they pop up.
Some of these funny announcements can be short lived indeed - only lasting a few hours.
Step 3 will only be relevant if another RIR withdraws address space (so a route: object that has been properly validated before now points to no-longer-valid address space), which I see as a somewhat infrequent event. Of course there is the issue of cleanup of "dangling" objects when the address space changes hands (properly documented, and all that) - but that's not much different from "people forget to remove stale route: objects after a transfer" in just a single registry. 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 Gert On 06/11/2015 10:00, Gert Doering wrote:
Hi,
On Fri, Nov 06, 2015 at 06:01:53AM +0530, Suresh Ramasubramanian wrote:
+1 here - though for step 3 it might be an idea to check just how many such objects are there and with what frequency they pop up.
Some of these funny announcements can be short lived indeed - only lasting a few hours.
Step 3 will only be relevant if another RIR withdraws address space (so a route: object that has been properly validated before now points to no-longer-valid address space), which I see as a somewhat infrequent event.
Of course there is the issue of cleanup of "dangling" objects when the address space changes hands (properly documented, and all that) - but that's not much different from "people forget to remove stale route: objects after a transfer" in just a single registry.
We could add a STEP 5: If a delete request is sent to the RIPE Database for a ROUTE object related to out of region address space without the proper authorisation, send a notification to the contacts for the authoritative address space holder. If an appropriate response is received back, delete the ROUTE object. This would simulate the reclaim functionality for RIPE address space holders. Another byproduct of implementing this is that we no longer need to hold copies of AUT-NUM objects in the RIPE Database. The out of region ASN auth requirement is satisfied by the appropriate response to the notification. So all 'foreign' AUT-NUM objects could be immediately deleted. (Or after allowing time for these ASN holders to make sure their routing policy is actually up to date in the authoritative AUT-NUM object.) cheers denis
Gert Doering -- NetMaster
Hi, I like the idea. I would have preffered a cross registry/RIR solution but as you said, it has been many months (I actually raised the issue 2 RIPE meetings ago - in London) but nothing visible has been done to fix this problem. +1 from me. cheers, elvis Excuse the briefness of this mail, it was sent from a mobile device. On Nov 5, 2015, at 11:47, "ripedenis@yahoo.co.uk" <ripedenis@yahoo.co.uk> wrote: HI all I am going to have one last go at solving this problem. I challenge anyone/everyone to tell me why this is such a stupid idea, technically impossible to do, won't solve any of the issues partially or fully. Then I can shut up about it and go away. If you can't condemn the idea then support it. Lets fix this issue once and for all, stop this endless discussion about rogue ROUTE objects and get on with life. So here is my 4 step proposal that I believe could be implemented within a month. If we implemented this you can be sure that all ROUTE objects in the RIPE Database were created with the knowledge and approval of the related resource holders. I believe that is the desired goal. STEP 1 Any ROUTE object submitted for creation in the RIPE Database involving an out of region resource (address space and/or ASN) where that out of region resource does not exist in the authoritative RIR database (has not been allocated or assigned), reject the creation. The RIPE NCC mirrors the operational data from all the other 4 RIRs. These mirrors are updated daily as well as the RIRs daily stats. It is easy to determine if a resource is registered in the authoritative database. STEP 2 For those ROUTE objects from STEP 1 where the out of region resource does exist, hold the object creation as pending. The mechanism for doing this already exists in the RIPE Database software as it is used for multiple authentications. Lookup the out of region resource(s) in the authoritative database(s) and find the contacts for that resource. Send a notification to those contacts informing them of the pending ROUTE object creation in the RIPE Database. The notification mechanism already exists in the RIPE Database software. If they don't approve, do nothing and the creation request will time out after a week and the object will not be created. If they do approve, respond in some way (many technical options for doing this that the RIPE NCC can choose from). If appropriate approval(s) are received within a week, create the ROUTE object. STEP 3 On a daily basis, for each ROUTE object in the RIPE Database that relates to an out of region resource, check for the continued existence of that resource in the appropriate RIR database. If it no longer exists, delete the ROUTE object from the RIPE Database. STEP 4 This is a one off cleanup of existing ROUTE objects. For all ROUTE objects currently in the RIPE Database that relate to an out of region, existing resource, send the appropriate notifications. For any that no response is received within a week, delete the ROUTE object from the RIPE Database. cheers denis
Hi Elvis,
I like the idea. I would have preffered a cross registry/RIR solution but as you said, it has been many months (I actually raised the issue 2 RIPE meetings ago - in London) but nothing visible has been done to fix this problem.
+1 from me.
I raised similar kind of issue in APNIC meeting as well. So lets see how it works out in RIPE :) -- Best Wishes, Aftab A. Siddiqui
On Thu, Nov 05, 2015 at 07:40:58PM +0000, ripedenis@yahoo.co.uk wrote:
STEP 2
For those ROUTE objects from STEP 1 where the out of region resource does exist, hold the object creation as pending. The mechanism for doing this already exists in the RIPE Database software as it is used for multiple authentications.
Lookup the out of region resource(s) in the authoritative database(s) and find the contacts for that resource. Send a notification to those contacts informing them of the pending ROUTE object creation in the RIPE Database. The notification mechanism already exists in the RIPE Database software. If they don't approve, do nothing and the creation request will time out after a week and the object will not be created. If they do approve, respond in some way (many technical options for doing this that the RIPE NCC can choose from). If appropriate approval(s) are received within a week, create the ROUTE object.
The issue I see is that it is even harder to verify out-of-region resource holders than RIPE NCC ones. (Please don't even mention letterheaded faxes, this is 2015 not 1995). If you can assume that, just as in the RIPE region, the majority of those resource holders are honest, this is workable. Overall a good idea even if it goes against simplicity.
STEP 3
On a daily basis, for each ROUTE object in the RIPE Database that relates to an out of region resource, check for the continued existence of that resource in the appropriate RIR database. If it no longer exists, delete the ROUTE object from the RIPE Database.
rgds, Sascha Luck
Denis, On 05/11/2015 19:40, ripedenis@yahoo.co.uk wrote:
HI all
I am going to have one last go at solving this problem. I challenge anyone/everyone to tell me why this is such a stupid idea, technically impossible to do, won't solve any of the issues partially or fully. Then I can shut up about it and go away. If you can't condemn the idea then support it. Lets fix this issue once and for all, stop this endless discussion about rogue ROUTE objects and get on with life.
So here is my 4 step proposal that I believe could be implemented within a month. If we implemented this you can be sure that all ROUTE objects in the RIPE Database were created with the knowledge and approval of the related resource holders. I believe that is the desired goal.
Thanks for this. I think I would agree with Gert's comments about Step 4 and the timings, but that's implementation detail to a certain extent. It and other timings would be something to discuss with the NCC. The big, procedural, question to get this moved along is whether this is AA-WG or DB-WG. To be clear, I'm very happy to work with you on it either way. I'm going to have a quick chat with the DB-WG chairs and we can crank up the PDP as soon as possible, if that's ok with you? Brian
Hi Brian On 06/11/2015 11:29, Brian Nisbet wrote:
Denis, On 05/11/2015 19:40, ripedenis@yahoo.co.uk wrote:
HI all
I am going to have one last go at solving this problem. I challenge anyone/everyone to tell me why this is such a stupid idea, technically impossible to do, won't solve any of the issues partially or fully. Then I can shut up about it and go away. If you can't condemn the idea then support it. Lets fix this issue once and for all, stop this endless discussion about rogue ROUTE objects and get on with life.
So here is my 4 step proposal that I believe could be implemented within a month. If we implemented this you can be sure that all ROUTE objects in the RIPE Database were created with the knowledge and approval of the related resource holders. I believe that is the desired goal.
Thanks for this. I think I would agree with Gert's comments about Step 4 and the timings, but that's implementation detail to a certain extent. It and other timings would be something to discuss with the NCC.
The big, procedural, question to get this moved along is whether this is AA-WG or DB-WG. To be clear, I'm very happy to work with you on it either way. I'm going to have a quick chat with the DB-WG chairs and we can crank up the PDP as soon as possible, if that's ok with you?
That sounds like a great idea :) cheers denis
Brian
Denis, On 06/11/2015 11:01, denis wrote:
Hi Brian
On 06/11/2015 11:29, Brian Nisbet wrote:
Denis, On 05/11/2015 19:40, ripedenis@yahoo.co.uk wrote:
HI all
I am going to have one last go at solving this problem. I challenge anyone/everyone to tell me why this is such a stupid idea, technically impossible to do, won't solve any of the issues partially or fully. Then I can shut up about it and go away. If you can't condemn the idea then support it. Lets fix this issue once and for all, stop this endless discussion about rogue ROUTE objects and get on with life.
So here is my 4 step proposal that I believe could be implemented within a month. If we implemented this you can be sure that all ROUTE objects in the RIPE Database were created with the knowledge and approval of the related resource holders. I believe that is the desired goal.
Thanks for this. I think I would agree with Gert's comments about Step 4 and the timings, but that's implementation detail to a certain extent. It and other timings would be something to discuss with the NCC.
The big, procedural, question to get this moved along is whether this is AA-WG or DB-WG. To be clear, I'm very happy to work with you on it either way. I'm going to have a quick chat with the DB-WG chairs and we can crank up the PDP as soon as possible, if that's ok with you?
That sounds like a great idea :)
DB wish to take this, which is sensible because it's a DB proposal. So do you want to sent a mail to the list and/or chairs and kick this off there? Copying AA-WG would be useful on the discussion, I think. Brian
participants (10)
-
Aftab Siddiqui -
Bengt Gördén -
Brian Nisbet -
denis -
Elvis Daniel Velea -
Gert Doering -
Piotr Strzyzewski -
ripedenis＠yahoo.co.uk
-
Sascha Luck [ml] -
Suresh Ramasubramanian