Solving the issue of rogue ROUTE objects in the RIPE Database
Hi All I raised an idea before the last RIPE Meeting but it did not generate a lot of interest at that time. I brought it up again yesterday on the Anti Abuse WG list and it seemed to get quite a bit of support. So I will bring it back to the DB WG as it is a DB issue. I have CC'ed both AA WG and Routing WG for information. But it may be useful to keep the discussion now on the DB WG list. I don't claim this will solve all the problems of the universe, but it does satisfy an immediate goal to have all ROUTE objects in the RIPE Database created with the knowledge and approval of the related resource holders. And I believe it could be implemented in a relatively short space of time giving immediate benefits. cheers denis 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, delete the ROUTE object from the RIPE Database. We can be a bit more generous on the timing for this step and even send multiple reminder notifications to be sure. (Possible) 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. AUT-NUM copies 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.)
Hi All, On Fri, Nov 06, 2015 at 12:55:40PM +0100, denis wrote:
I don't claim this will solve all the problems of the universe, but it does satisfy an immediate goal to have all ROUTE objects in the RIPE Database created with the knowledge and approval of the related resource holders.
Already today, the RIPE database offers very strong guarantee for RIPE managed IP space. As most in this group know: you cannot, without approval of the holder of the RIPE managed IP space, create a route-object in the RIPE database. Any network operator can take advantage of this characteristic and ignore 'rogue' objects already today. A possible implementation of this strategy is called "IRR Lockdown" which I presented about last RIPE meeting. One can wonder why not many operators have implemented filtering strategies to exploit the strong guarantees, is this something operators should solve or should it be forced upon them from the database/data source perspective? Because of the seeming lack of traction in the operator community for which we do not know the exact reasons, I urge caution in radical changes on the database side. Another generic point I'd like to raise is that this proposal aims towards _enabling_ foreign route-objects to exist in the RIPE IRR database, while a lot of thought in the last 12 months has been spend on ... NOT enabling foreign objects in the RIPE IRR, or alternatively clearly mark those objects as "source: FOREIGN" or an equivalent of that. (See Nick Hilliard's proposal earlier this year). So the working groups needs to think about: A - do we want the RIPE IRR to ONLY contain route-objects covering space administrated by the RIPE NCC. OR B - do we want the end-game to be that the RIPE IRR can be host to any object from any RIR (and preferably be authenticated in some form). I feel that making a decision on the above choice will help us guide any subsequent choices. One example of action taken towards choice A is the "IRR Homing" effort that was set in motion at the last RIPE meeting. As we speak RIPE and AfriNIC are jointly working on a project to move all route-objects which cover AfriNIC space to the AfriNIC IRR and then delete them from the RIPE database at some point. Part of the proposal (which is under development) will be to reject creation of route-objects covering AfriNIC space in the RIPE IRR and guide the user with an error message to the appropiate RIR. If the AfriNIC IRR Homing is a success, I imagine that APNIC space is a likely candidate after that. In any regard, I think we are in agreement that what's currently in place with regard to route-objects covering foreign space in the RIPE IRR can be improved upon.
And I believe it could be implemented in a relatively short space of time giving immediate benefits.
RIPE NCC can comment on implementation timelines, I will not make any assumptions on their behalf. I've taken the liberty to summarize your proposed steps to improve readability of my reply. Hope you don't mind.
STEP 1: reject creation of route-objects if they cover foreign non-allocated / non-assigned space
Can the RIPE Whois software perform a programmatic check that with 100% certainty will conclude whether space is globally unassigned/non-allocated? Do all RIRs expose facilities today to do such a lookup? What about pre-RIR / legacy space? (would especially appreciate comments from RIPE NCC staff)
STEP 2: email confirmation link to admin-c/tech-c equivalent as listed in the foreign RIR database to confirm creation of the route-object in RIPE's IRR database.
Are we able to programmatically retrieve email addresses for which we have a high degree of certainty that they are the actual holders of the IP space? (again, comments from RIPE NCC staff welcome). Intuitively it would appear that RIPE NCC would have to strike a deal with the other 4 RIRs to be allowed to retrieve those email addresses, as some RIRs hide / rate-limit email addresses because of abuse/privacy concerns.
STEP 3: continiously check if the block is allocated in the foreign RIR database, if no longer, delete the route-object from RIPE's IRR db.
What if a registration moves from RIR to another RIR (transfers), or due to software issues the registration temporary appears to be not there? Permanently deleting a resource in RIPE IRR because of a transient issue might be too strong of a reaction.
STEP 4: one-off cleanup: confirm with all out-of-region objects whether the object belongs in RIPE IRR db or not, if no confirmation is received: delete the object.
I have trouble overseeing the exact ramifications in doing so. I'd personally prefer a more lenient mechanism so we are sure to not inflict far going damage in the routing system, alternative options could be to "freeze" existing objects covering foreign resources rather then delete them. The "freeze" wouldn't need to be entirely without mutability: should people want to change them or delete them, "step 2" could be invoked.
(Possible) STEP 5: confirm with admin-c/tech-c equivalent as listed in the foreign database when a 'delete' request is received.
Same comments as for "step 2" apply.
AUT-NUM copies: delete foreign autnum copies
I am all in favor of a method to get rid of duplicate autnum objects (duplicate in that they also exist in another RIR's IRR), this aligns with another concept under discussion in the db-wg community: relaxing the authorisation rules for foreign objects in such a way that the duplicate autnum is no longer required to be present in the RIPE IRR. Again I am hesitant to flat out delete existing information, and prefer a grandfathering mechanism as described in my response to "step 4". Denis, thank you bringing this to the group. Kind regards, Job
On Fri, Nov 06, 2015 at 02:14:15PM +0100, Job Snijders wrote:
Intuitively it would appear that RIPE NCC would have to strike a deal with the other 4 RIRs to be allowed to retrieve those email addresses, as some RIRs hide / rate-limit email addresses because of abuse/privacy concerns.
This wouldn't be a one-way street, presumably, it would also involve the NCC exporting such data to other RIRs. That is currently somewhat thin ice for EU-sourced data: http://curia.europa.eu/jcms/upload/docs/application/pdf/2015-10/cp150117en.p... rgds, Sascha Luck
On 06/11/2015 14:00, Sascha Luck [ml] wrote:
This wouldn't be a one-way street, presumably, it would also involve the NCC exporting such data to other RIRs. That is currently somewhat thin ice for EU-sourced data: http://curia.europa.eu/jcms/upload/docs/application/pdf/2015-10/cp150117en.p...
personal information is not exported for route: objects, therefore this does not apply:
remarks: **************************** remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: ****************************
Nick
Dear working groups, At RIPE 70 the RIPE Database Working group asked the RIPE NCC to work together with Afrinic on an implementation proposal to migrate Afrinic route(6) objects to the new Afrinic IRR as part of the IRR Homing project. We are planning to present a proposal at the Database Working Group session at RIPE 71. Initially we will focus on the clear cases where Afrinic is the RIR for both the inet(6)num and aut-num (roughly 34k object). In the meantime we are also seeking technical alignment with Afrinic and the other RIRs on how cross-RIR authorisation for route(6) objects can be improved, so that we can also put forward an implementation plan for the remaining objects (e.g. roughly 6k objects with an Afrinic inetnum and RIPE aut-num). Experience with the migration of Afrinic route objects can serve as a basis to similar migrations in the future. And while the RIPE NCC and RIPE working groups cannot set the priorities for other RIRs, they are following these developments with interest. All that said it is clear that the current situation is problematic and an intermediate solution may be desired. In general the RIPE NCC also likes the proposal for this put forward by Denis. But we have some comments, much in line with comments made by Job. We would propose the following:
STEP 1: reject creation of route-objects if they cover foreign non-allocated / non-assigned space
This should be doable. The past few years the RIRs have been working hard on cleaning up overlaps, and therefore we can now be certain which RIR is authoritative for which resources and check this programatically.
STEP 2: email confirmation link to admin-c/tech-c equivalent as listed in the foreign RIR database to confirm creation of the route-object in RIPE's IRR database.
Indeed as Job pointed out we may have to make a special arrangement with other RIRs, but we are confident that we can work with them on this.
STEP 3: continiously check if the block is allocated in the foreign RIR database, if no longer, delete the route-object from RIPE's IRR db.
We share concerns raised by Job. We believe this adds a lot of complexity to the implementation, and introduces an unacceptable risk of deleting the wrong objects. Furthermore we believe that this step is not necessary if we implement step 5 (below).
STEP 4: one-off cleanup: confirm with all out-of-region objects whether the object belongs in RIPE IRR db or not, if no confirmation is received: delete the object.
We would also echo the concerns raised by Job. And similar concerns with complexity and risk apply as with step 3. Furthermore we believe that this step is not necessary if we implement step 5 (below).
(Possible) STEP 5: confirm with admin-c/tech-c equivalent as listed in the foreign database when a 'delete' request is received.
If we implement this, step 3 and 4 are not needed. Rather than trying to determine automatically if an object is still valid - and risking getting it wrong, this leaves both the empowerment and responsibility to maintain this data with the current resource holders. We would propose that out-of-region resource holders can delete route(6) objects in the RIPE Database in a two step process: 1) try to delete the object without authorisation - We can detect that it's an out-of-region object and send a link to the holder similar to step 2 2) the holder can click the confirmation link
AUT-NUM copies: delete foreign autnum copies
From our perspective we agree that we do not technically need foreign aut-num objects if we have a different authorisation model, and it would be better if such duplicates did not exist. As for the clean-up we could: = disallow new out-of-region aut-num objects = warn (email) respective holders in the authoritative database = and delete them as a later step So, with the caveat about automated deletion of objects that we do have concerns with, we think we could implement the above as an intermediate solution. We would also like to point out that we can build on this step by step. E.g. we can start disallowing route objects for Afrinic resources and direct people to the Afrinic IRR, while still applying the above strategy for resources from other regions. It will obviously require work. Very rough initial estimates indicate it can take up to a few months. We can refine these estimates if and when we have a clear consensus on a go-ahead. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group
HI Tim Thanks for the review. I have added a few comments below. cheers denis On 11/11/2015 10:41, Tim Bruijnzeels wrote:
Dear working groups,
At RIPE 70 the RIPE Database Working group asked the RIPE NCC to work together with Afrinic on an implementation proposal to migrate Afrinic route(6) objects to the new Afrinic IRR as part of the IRR Homing project. We are planning to present a proposal at the Database Working Group session at RIPE 71.
Initially we will focus on the clear cases where Afrinic is the RIR for both the inet(6)num and aut-num (roughly 34k object). In the meantime we are also seeking technical alignment with Afrinic and the other RIRs on how cross-RIR authorisation for route(6) objects can be improved, so that we can also put forward an implementation plan for the remaining objects (e.g. roughly 6k objects with an Afrinic inetnum and RIPE aut-num).
Experience with the migration of Afrinic route objects can serve as a basis to similar migrations in the future. And while the RIPE NCC and RIPE working groups cannot set the priorities for other RIRs, they are following these developments with interest.
All that said it is clear that the current situation is problematic and an intermediate solution may be desired. In general the RIPE NCC also likes the proposal for this put forward by Denis. But we have some comments, much in line with comments made by Job. We would propose the following:
STEP 1: reject creation of route-objects if they cover foreign non-allocated / non-assigned space
This should be doable. The past few years the RIRs have been working hard on cleaning up overlaps, and therefore we can now be certain which RIR is authoritative for which resources and check this programatically.
Someone made a comment about legacy space. Is this now shown in the extended delegated stats? Can we determine if it is legacy space and who is authoritative for it? Or do we need a separate rule for legacy space ROUTE objects?
STEP 2: email confirmation link to admin-c/tech-c equivalent as listed in the foreign RIR database to confirm creation of the route-object in RIPE's IRR database.
Indeed as Job pointed out we may have to make a special arrangement with other RIRs, but we are confident that we can work with them on this.
STEP 3: continiously check if the block is allocated in the foreign RIR database, if no longer, delete the route-object from RIPE's IRR db.
We share concerns raised by Job. We believe this adds a lot of complexity to the implementation, and introduces an unacceptable risk of deleting the wrong objects. Furthermore we believe that this step is not necessary if we implement step 5 (below).
Agreed
STEP 4: one-off cleanup: confirm with all out-of-region objects whether the object belongs in RIPE IRR db or not, if no confirmation is received: delete the object.
We would also echo the concerns raised by Job. And similar concerns with complexity and risk apply as with step 3. Furthermore we believe that this step is not necessary if we implement step 5 (below).
Agreed with a caveat that as a one of action the authoritative contacts should be notified that a ROUTE object exists in the RIPE Database relating to their resource. If it was maliciously or accidentally created the authoritative registrants may not be aware of it's existence.
(Possible) STEP 5: confirm with admin-c/tech-c equivalent as listed in the foreign database when a 'delete' request is received.
If we implement this, step 3 and 4 are not needed. Rather than trying to determine automatically if an object is still valid - and risking getting it wrong, this leaves both the empowerment and responsibility to maintain this data with the current resource holders.
We would propose that out-of-region resource holders can delete route(6) objects in the RIPE Database in a two step process: 1) try to delete the object without authorisation - We can detect that it's an out-of-region object and send a link to the holder similar to step 2 2) the holder can click the confirmation link
Agreed
AUT-NUM copies: delete foreign autnum copies
From our perspective we agree that we do not technically need foreign aut-num objects if we have a different authorisation model, and it would be better if such duplicates did not exist.
As for the clean-up we could: = disallow new out-of-region aut-num objects = warn (email) respective holders in the authoritative database = and delete them as a later step
Agreed
So, with the caveat about automated deletion of objects that we do have concerns with, we think we could implement the above as an intermediate solution. We would also like to point out that we can build on this step by step. E.g. we can start disallowing route objects for Afrinic resources and direct people to the Afrinic IRR, while still applying the above strategy for resources from other regions.
From what I understood from Gert and Randy's comments it is a user's choice where to put a ROUTE object and there seem to be some reasons why they sometimes choose to put it in the RIPE Database. Is there some specific policy now that prohibits ROUTE objects in the RIPE Database for AFRINIC resources?
It will obviously require work. Very rough initial estimates indicate it can take up to a few months. We can refine these estimates if and when we have a clear consensus on a go-ahead.
Kind regards,
Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group
Hi, On Wed, Nov 11, 2015 at 02:52:36PM +0100, denis wrote: [..]
From what I understood from Gert and Randy's comments it is a user's choice where to put a ROUTE object and there seem to be some reasons why they sometimes choose to put it in the RIPE Database.
"Document everything one AS originates in a single database" is the primary motivation here (so upstreams/peers can go to a single source to build filters, and that single source must not be RADB). 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
"Document everything one AS originates in a single database" is the primary motivation here (so upstreams/peers can go to a single source to build filters, and that single source must not be RADB).
and why not? randy
Hi, On Thu, Nov 12, 2015 at 12:00:11PM +0900, Randy Bush wrote:
"Document everything one AS originates in a single database" is the primary motivation here (so upstreams/peers can go to a single source to build filters, and that single source must not be RADB).
and why not?
RADB? Because anyone can put arbitrary stuff in there and the operators seem more interested in selling maintainers (so you can protect your own objects that you have put in there, which shouldn't be there in the first place for RIPE region stuff). Now, if the RADB would only serve as aggregator for properly authenticated and sanitized objects from the 5 RIR IRRDBs, it would be useful. Right now, it is dangerous, because people building filters from it believe they are spending their efforts in a positive way. They are deluded, as anyone can circumvent these filters easily... (had this happen to a network of ours - the /22 was not announced yet, route: object entered into the RADB, announced for half an hour for spamming, merit refused to remove the rogue object because "please contact the people who put it in" even though it was perfectly clear from comparison with the mirrored RIPE objects that it was bogus). 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
Dear working groups, A small clarification.
On 11 Nov 2015, at 14:52, denis <ripedenis@yahoo.co.uk> wrote:
So, with the caveat about automated deletion of objects that we do have concerns with, we think we could implement the above as an intermediate solution. We would also like to point out that we can build on this step by step. E.g. we can start disallowing route objects for Afrinic resources and direct people to the Afrinic IRR, while still applying the above strategy for resources from other regions.
From what I understood from Gert and Randy's comments it is a user's choice where to put a ROUTE object and there seem to be some reasons why they sometimes choose to put it in the RIPE Database. Is there some specific policy now that prohibits ROUTE objects in the RIPE Database for AFRINIC resources?
No, there is no such policy. I was referring to the "Afrinic IRR Homing Project" and how it could fit this model. RIPE NCC and Afrinic were asked to work on a proposal for this. We will present it during the DB WG session at the RIPE Meeting (next week), and I believe it's best to discuss this in more detail then. But to be absolutely clear: we would only implement after working group discussion and consensus called by the chairs. The same applies obviously for other proposals and suggestions mentioned in this thread. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group
On Wed, Nov 11, 2015 at 02:52:36PM +0100, denis wrote:
From what I understood from Gert and Randy's comments it is a user's choice where to put a ROUTE object and there seem to be some reasons why they sometimes choose to put it in the RIPE Database.
Be that as it may, I am not convinced (yet) that non-RIPE objects really have a place in the RIPE db. Given that today there _are_ non-RIPE objects in the RIPE db, we need to find a way to deal with those. All of us hate rogue objects and want to nail down security in such a way that the RIPE db no longer is a 'free for all to exploit' database. An example of a functional IRR does not allow foreign objects: APNIC. I've not heard of that policy leading to any issues. Randy has asserted in the past that some parties (IXPs?) require people to exclusively register in the RIPE database, but I have not found data supporting that idea so far. Even if there is an IXP who operates a route-server for which filters are build exclusively using RIPE's IRR database, that is a local choice made by that IXP to not look at other databases. I won't take a single IXP's decision to not look any further as a strong incentive to put the whole world's IRR in the RIPE database. Gert indicated that it might be beneficial for a single ASN to register all their routes (including non-RIPE space) in a single database. Gert's remark is a single datapoint, it is my personal opinion that there is no operational issue if networks spread their route-object registrations over multiple databases (e.g. APNIC space in APNIC IRR, RIPE space in RIPE IRR, etc). The benefit of pushing users to the most authoritve database is that 3 out of 5 RIRs can offer strong guarantees about the validity of a route-object if it covers space managed by that respective RIR. RIPE cannot offer the same strong guarantees as APNIC & AfriNIC can in their own IRR. Why would we not encourage the community to exploit those guarantees, and direct users to create those 'foreign' route-objects in the more authoritive IRR?
Is there some specific policy now that prohibits ROUTE objects in the RIPE Database for AFRINIC resources?
"IRR Homing" was influenced by two ideas: Nick Hilliard's "why don't we change the 'source: RIPE' line to something like 'source: RIPE-NONAUTH' for objects covering non-RIPE space" and the observation that there are 30.000 route-objects covering AfriNIC space in a database which _does_not_ offer guarantees on their validity, while at the same time there is a perfect IRR which _does_ offer those guarantees: AfriNIC's own IRR. At the time I thought it safer to first migrate AfriNIC's objects and then consider changing the "source:" attribute for non-authoritive objects. So, no such policy exists, but the IRR Homing proposal (which is in the making) will include the suggestion that creation of route-objects covering AfriNIC space at some point is no longer allowed, and instead people are referred to the AfriNIC IRR. As Tim mentioned, this is a proposal and the DB-WG will be tasked with reviewing the plan. Kind regards, Job
Hi Job, Tim On 12/11/2015 16:57, Job Snijders wrote:
On Wed, Nov 11, 2015 at 02:52:36PM +0100, denis wrote:
From what I understood from Gert and Randy's comments it is a user's choice where to put a ROUTE object and there seem to be some reasons why they sometimes choose to put it in the RIPE Database.
Be that as it may, I am not convinced (yet) that non-RIPE objects really have a place in the RIPE db. Given that today there _are_ non-RIPE objects in the RIPE db, we need to find a way to deal with those. All of us hate rogue objects and want to nail down security in such a way that the RIPE db no longer is a 'free for all to exploit' database. An example of a functional IRR does not allow foreign objects: APNIC. I've not heard of that policy leading to any issues.
Just another thought on these rogue ROUTE objects. If a ROUTE object has been created maliciously for out of region address space and the authoritative address space holder asks the RIPE NCC to delete the ROUTE object, is there any policy or defined procedure existing now that gives the RIPE NCC the authority to delete it immediately? Or is this one of those 'case by case' situations where there needs to be proof of wrong doing before the RIPE NCC can delete it? Perhaps the RIPE NCC can explain how these situations are currently handled? cheers denis
Hi Tim,
STEP 3: continiously check if the block is allocated in the foreign RIR database, if no longer, delete the route-object from RIPE's IRR db.
We share concerns raised by Job. We believe this adds a lot of complexity to the implementation, and introduces an unacceptable risk of deleting the wrong objects. Furthermore we believe that this step is not necessary if we implement step 5 (below).
So what happens to route objects referring to de-registered stuff in other databases? If nobody cleans it up manually we keep objects with dangling pointers in our database? I understand that automatically deleting them would be risky as e.g. an unexpected change in a remote database might cause us to think the object has been deleted there etc. Maybe a nice idea if all RIRs publish a timestamped list of de-registered/reclaimed resources in a common format? :) Anyway: maybe something to look into to prevent garbage from accumulating in our own database.
It will obviously require work. Very rough initial estimates indicate it can take up to a few months. We can refine these estimates if and when we have a clear consensus on a go-ahead.
Thanks, always good to get an estimate from the authoritative source ;) Cheers! Sander
Hi Sander On 11/11/2015 18:34, Sander Steffann wrote:
Hi Tim,
STEP 3: continiously check if the block is allocated in the foreign RIR database, if no longer, delete the route-object from RIPE's IRR db.
We share concerns raised by Job. We believe this adds a lot of complexity to the implementation, and introduces an unacceptable risk of deleting the wrong objects. Furthermore we believe that this step is not necessary if we implement step 5 (below).
So what happens to route objects referring to de-registered stuff in other databases? If nobody cleans it up manually we keep objects with dangling pointers in our database? I understand that automatically deleting them would be risky as e.g. an unexpected change in a remote database might cause us to think the object has been deleted there etc. Maybe a nice idea if all RIRs publish a timestamped list of de-registered/reclaimed resources in a common format? :) Anyway: maybe something to look into to prevent garbage from accumulating in our own database.
I think the main issue is when a resource is reclaimed and re-issued. If the previous registrant does not clean up the ROUTE object in the RIPE Database and the new registrant does not know it is there, it could dangle for a long time. Your suggestion of a reclaimed list would work but requires agreement from all 5 RIRs to be effective. That could take some time. Another simple option (which may not be 100% effective) is to do a daily check on the related resource objects. If they have been deleted and don't reappear within x days, delete the ROUTE object. If they do reappear notify the contacts that the ROUTE object exists. It may be a different resource holder. Again existing software can be reused for this. We don't have to invent anything from scratch. There is a system to check for unreferenced PERSON objects that runs every day. If an object has not been referenced for 90 days it is deleted. cheers denis
It will obviously require work. Very rough initial estimates indicate it can take up to a few months. We can refine these estimates if and when we have a clear consensus on a go-ahead.
Thanks, always good to get an estimate from the authoritative source ;)
Cheers! Sander
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.
most other rir irr instances are unused. radb is used. i think there is an altdb which is used. randy
On Sat, Nov 07, 2015 at 06:49:07AM +0900, Randy Bush wrote:
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.
most other rir irr instances are unused. radb is used. i think there is an altdb which is used.
The following RIR IRR's are in use today: RIPE, APNIC, AfriNIC, ARIN. Three out of four apply a mechanism which ensures a high level of certainty that the route-objects covering the respective RIR's managed space are authenticated in a proper way. ARIN does not validate against their RIR database at this moment. LACNIC has no IRR. I do not agree with "most rir irr instances are unused".
The following RIR IRR's are in use today: RIPE, APNIC, AfriNIC, ARIN.
most operators in X do not register routes in irrX for all X except RIPE
I do not agree with "most rir irr instances are unused".
cool. maybe you could back your disagreement up with measurement. randy
On Sat, Nov 07, 2015 at 07:46:47AM +0900, Randy Bush wrote:
The following RIR IRR's are in use today: RIPE, APNIC, AfriNIC, ARIN.
most operators in X do not register routes in irrX for all X except RIPE
Sorry, I don't understand what you are saying here.
I do not agree with "most rir irr instances are unused".
cool. maybe you could back your disagreement up with measurement.
Anybody who generate filters using the IRRd query protocol with a client like peval, bgpq3 or something in-house; pointed at whois.radb.net or rr.ntt.net, indirectly use those RIR IRRs. I know my employer uses the rr.ntt.net instance on a daily basis. I cannot measure whether other people's queries against rr.ntt.net result in prefix filters being deployed somewhere. Here are some measurements from August 2015 comparing what objects are in IRR and which of those objects were 'confirmed' in BGP DFZ. DB | IRR objects | Corresponding BGP announcements (match pfx + origin) --------+-------------+-------------+-- ratio JPIRR | 8889 | 6478 | .728 BBOI | 1330 | 766 | .575 RIPE | 286294 | 139263 | .486 <-- RIR Afrinic | 496 | 237 | .477 <-- RIR TC | 3090 | 1411 | .456 ALTDB | 13440 | 5169 | .384 APNIC | 97955 | 30219 | .308 <-- RIR ARIN | 26872 | 8256 | .307 <-- RIR GT | 2474 | 745 | .301 LEVEL3 | 89812 | 23198 | .258 RADB | 769328 | 145845 | .189 SAVVIS | 103362 | 19064 | .184 NTTCOM | 238914 | 43832 | .183 RGNET | 314 | 45 | .143 BELL | 29545 | 656 | .022 -------------------------------------------- I only looked for exact matches in the DFZ (table taken from NLNOG RING LG with ~ 50 feeds). I did not check what the ratio is like when taking more-specific announcements for registered prefixes into consideration. Kind regards, Job
The following RIR IRR's are in use today: RIPE, APNIC, AfriNIC, ARIN. most operators in X do not register routes in irrX for all X except RIPE Sorry, I don't understand what you are saying here.
most folk in non-ripe regions do not use their rir's irr instance.
I know my employer uses the rr.ntt.net instance on a daily basis.
yes, i built that and heas has done cool stuff. does your employer register in ARIN or APNIC irr? < light goes on? > randy
Hi Randy, On Sat, Nov 07, 2015 at 08:34:46AM +0900, Randy Bush wrote:
The following RIR IRR's are in use today: RIPE, APNIC, AfriNIC, ARIN. most operators in X do not register routes in irrX for all X except RIPE Sorry, I don't understand what you are saying here.
most folk in non-ripe regions do not use their rir's irr instance.
I guess we look different at the data, APNIC's IRR seems rather populair to me, AfriNIC has good quality data. The total of 177.975 (non-RIPE: 38.712) exact matches between registered in IRR & observed in BGP is a significant amount to me, this is not even counting more specifics. Given the high irr/bgp ratio of RIPE and APNIC (taking into account the sizes), and the IRR Homing project under way for AfriNIC (30k pfx) and remaining APNIC covered route-objects in RIPE IRR, I conclude the approach for RIR authenticated IRR data is successful. My question from earlier in the thread still stands: should RIPE IRR attempt to be a global IRR and do its best to authenticate data itself (as per Denis' proposal), or should RIPE IRR continue to work to transfer objects to the appropiate RIR's IRR and let their respective communities work with those RIRs to authenticate the data (if needed)?
I know my employer uses the rr.ntt.net instance on a daily basis.
yes, i built that and heas has done cool stuff. does your employer register in ARIN or APNIC irr? < light goes on? >
We encourage anyone to register their routes in the appropiate IRR, especially when that IRR offers strong guarantees about the authenticity of the route-object. I'll take your ad-hominem-employer argument about the data-production side as an action item to assess if improvement is warranted. :-) However, the discussion at hand seems to me to be about the data consumption side, I feel that you raised the implicit question "Are RIR's IRR relevant?" to which my answer is YES. Kind regards, Job
I know my employer uses the rr.ntt.net instance on a daily basis. yes, i built that and heas has done cool stuff. does your employer register in ARIN or APNIC irr? < light goes on?> We encourage anyone to register their routes in the appropiate IRR, especially when that IRR offers strong guarantees about the authenticity of the route-object.
does ntt register its own routes in the irrs of APNIC, ARIN, etc? that is a binary question.
I'll take your ad-hominem-employer argument
exuse me! you brought up your employer, not i. and you have not answered my question.
However, the discussion at hand seems to me to be about the data consumption side, I feel that you raised the implicit question "Are RIR's IRR relevant?" to which my answer is YES.
unfortunately, the answer for many operators is NO. they voted with their feet. you can say what they SHOULD do. my family has a lot of jokes about how the world should be. randy
On Sat, Nov 07, 2015 at 09:22:53AM +0900, Randy Bush wrote:
I know my employer uses the rr.ntt.net instance on a daily basis. yes, i built that and heas has done cool stuff. does your employer register in ARIN or APNIC irr? < light goes on?> We encourage anyone to register their routes in the appropiate IRR, especially when that IRR offers strong guarantees about the authenticity of the route-object.
does ntt register its own routes in the irrs of APNIC, ARIN, etc? that is a binary question.
I believe most prefixes are registered in NTTCOM, but I cannot speak for the myriad of subsidiaries. I believe NTT (like Level3, Savvis, etc) are in a rather rare position having their own IRR, as such maybe not the best material to compare with the other 54281 ASNs out there.
I'll take your ad-hominem-employer argument
exuse me! you brought up your employer, not i. and you have not answered my question.
You asked about whether I could back up my assertion with measurements and I offered one datapoint specific to the data consumption side and many more on the data production side.
However, the discussion at hand seems to me to be about the data consumption side, I feel that you raised the implicit question "Are RIR's IRR relevant?" to which my answer is YES.
unfortunately, the answer for many operators is NO. they voted with their feet. you can say what they SHOULD do. my family has a lot of jokes about how the world should be.
I don't know why you say this. Does "many operators expressed opinion with their feet" mean that thus "many other operators" should not produce or consume IRR data? Is "many" even relevant in an internet topology that has a noticable cluster as core with tons of stub-edges, in essence being anything but a full mesh? Even if few operators consume IRR data and filter accordingly, depending on their size, it can not only protect their customers and themselves, but large portions of the global system. I ran some calculations just now, comparing public data available to me: should all the RIR's IRR databases cease to exist tomorrow, I estimate that _at_least_ 65,000 customer prefixes would no longer be accepted by NTT's filters (the real number ikely is higher as I did not take into account more-specific pfx/origin covered by registered supernet). I consider these high numbers. Please approach me off-list should you have any further NTT specific questions. (Not only Randy, I'd be happily to elaborate to anyone on how filters are generated and with which parameters!) Randy, your assertation that RIR's IRR are not relevant has been noted. I ask that we continue the discussion about Denis' proposal, under the assumption that RIR's IRRs are relevant. Kind regards, Job
I believe most prefixes are registered in NTTCOM
so you too voted with yout feet
unfortunately, the answer for many operators is NO. they voted with their feet. you can say what they SHOULD do. my family has a lot of jokes about how the world should be. I don't know why you say this.
i suggest you measure the number of prefix allocations in the arin region which are in the arin irr.
Does "many operators expressed opinion with their feet" mean that thus "many other operators" should not produce or consume IRR data?
no. i meant they did not choose to register in the irr of the rir from which they got the space. ripe region is unusual in a very positive way. do not induce to other regions.
Please approach me off-list should you have any further NTT specific questions.
i have better sources :)
Randy, your assertation that RIR's IRR are not relevant has been noted.
but that was not my assertion. my point is that, in other regions, a large portion of the space allocated by the rir is not registered in the irr provided by the rir. the ripe region is an outlier. and in a good way. we should not induce to other regions without measurement and can not tell operators there how to run or register their networks. randy
On Nov 07, Randy Bush <randy@psg.com> wrote:
However, the discussion at hand seems to me to be about the data consumption side, I feel that you raised the implicit question "Are RIR's IRR relevant?" to which my answer is YES. unfortunately, the answer for many operators is NO. they voted with their feet. you can say what they SHOULD do. my family has a lot of jokes about how the world should be. So apparently this depends on local customs: in my area it is quite common for regional operators to use the RIPE IRR as a single stop solution for their prefix-lists generation needs, so it is very useful to be able to register there as well the few prefixes of customers with non-RIPE assignments.
For a practical example see: whois -r -T route -i origin AS12637 It shows a prefix from a non-RIPE network, and if it were not possible to register it there I would have had to contact each one of my peer who build their filters from the RIPE IRR and ask them to add it manually.
the ripe region is an outlier. and in a good way. we should not induce to other regions without measurement and can not tell operators there how to run or register their networks. This is not the goal: the point is that (some) RIPE operators want to register in the RIPE IRR the prefixes of their own foreign customers who come to Europe with ARIN networks.
-- ciao, Marco
Hi, On Sat, Nov 07, 2015 at 01:15:37AM +0100, Job Snijders wrote:
My question from earlier in the thread still stands: should RIPE IRR attempt to be a global IRR and do its best to authenticate data itself (as per Denis' proposal), or should RIPE IRR continue to work to transfer objects to the appropiate RIR's IRR and let their respective communities work with those RIRs to authenticate the data (if needed)?
The way the question is phrased imlies some bias :-) No, the RIPE IRR should not attempt to be a global IRR. *But* there is benefit for network that exclusively operates in the RIPE region to tell its peers and upstreams "my prefixes are registered in the RIPE DB!", even if they have the oddball prefix or customer that is from a foreign RIR. So, *short term*, I'd like to see support in the RIPE DB for registering out-of-region prefixes (and I think Denis' proposal has merits, technical details to be fine tuned by the NCC). We have a data integrity problem right now, and this needs to be solved short term without losing functionality. *Long term*, we need something better, for world wide route registration and authentication. If we can solve the short-term issue quickly, we can build something good, in the time scales it takes if 5 RIRs are involved, one of them having too many lawyers and being not really trusted by its own members. Gert Doering -- network operator -- 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
On 06/11/2015 11:55, denis wrote:
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.
this could and probably should be made smarter. I'd be generally happy with the idea of formally asking the RIPE NCC to kindly deal with obviously abusive behaviour in a way that seems most appropriate to them. E.g. stuff like detection + rate limiting of object creation, credibility scores for mntners, checks for out of hours creation of route: objects, i.e. at 18:05 CET on friday evenings and so forth. Richard Clayton provides some really good quality analysis of at least some of the things going on here:
https://www.lightbluetouchpaper.org/2015/10/02/badness-in-the-ripe-database/
https://www.lightbluetouchpaper.org/2015/11/02/ongoing-badness-in-the-ripe-d...
Nick
participants (10)
-
denis -
Gert Doering -
Job Snijders -
Job Snijders -
md＠Linux.IT -
Nick Hilliard -
Randy Bush -
Sander Steffann -
Sascha Luck [ml] -
Tim Bruijnzeels