RIPE Policy Proposal 2018-06 Aims to Delete Conflicting Non-authorative IRR Objects
Dear colleagues, We just published the RIPE Policy proposal, 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up", to the Routing Working Group mailing list. The goal of the proposal is to delete an non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA. As the RIPE IRR is part of the RIPE Database, we want to notify the Database Working Group. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2018-06 We encourage you to review this proposal and send your comments to <routing-wg@ripe.net> before 9 November 2018. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
Marco Schmidt via db-wg wrote on 11/10/2018 14:18:
We just published the RIPE Policy proposal, 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up", to the Routing Working Group mailing list.
The goal of the proposal is to delete an non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA.
There are some corner cases where this could cause permanent and unwarranted pain. 1. what's the procedure for backing out the deletion if the ROA holder in the other RIR makes a mistake and, for example, forgets to create a roa for a specific ASN and then they find their RIPE-NONAUTH route object deleted by accident. 2. what happens when someone is busy creating ROAs in, for example, Magastan and the RIPE NCC runs a deletion process mid-way through that process 3. the above situations are complicated by RFC6382. It might be a good idea to send some warnings to the holders of the route/route6 objects before nuking their objects + build in a timeout period. Nick
Dear Nick, On Sat, Oct 13, 2018 at 10:38:12PM +0100, Nick Hilliard via db-wg wrote:
Marco Schmidt via db-wg wrote on 11/10/2018 14:18:
We just published the RIPE Policy proposal, 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up", to the Routing Working Group mailing list.
The goal of the proposal is to delete an non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA.
There are some corner cases where this could cause permanent and unwarranted pain.
1. what's the procedure for backing out the deletion if the ROA holder in the other RIR makes a mistake and, for example, forgets to create a roa for a specific ASN and then they find their RIPE-NONAUTH route object deleted by accident.
When an operator makes a mistake, they've made a mistake. The same already applies today when the operator changes the ASN in the route/route6 object to the wrong origin ASN. The proposal does not have a 'back out' procedure; once a route/route6 object in RIPE-NONAUTH becomes in conflict with a RPKI ROA it should no longer exist. A different way of looking at things: What the policy proposal in a nutshell does is apply the RFC 6811 BGP origin validation process to IRR data. You could view the IRR data as if they are BGP announcements in context of 6811. Example: An IRR route object in RIPE-NONAUTH states that for prefix 206.48.168.0/22 a possible origin is AS4663 - but a set of PKI ROAs exists: 206.48.0.0/16 AS5511 maxlength 24 206.48.0.0/16 AS6505 maxlength 24 206.48.0.0/16 AS51964 maxlength 24 Obviously "206.48.168.0/22 AS4663" conflicts with the above set of ROAs and would be marked with origin validation state 'invalid'. This means that any network applying RPKI based BGP Origin Validation will reject the BGP announcement "206.48.168.0/22 AS4663", even though someone documented in the RIPE-NONAUTH IRR that that announcement perhaps could exist. The RIPE-NONAUTH IRR route object describes a state of the network that is to be discarded anyway - so deletion is warranted as it closes holes in prefix-list based filters in networks not doing OV. Also note that in the above scenario the owner of the ARIN-managed 206.48.0.0/16 prefix never was consulted or consented to the creation of the 206.48.168.0/22 route-object in the RIPE IRR. Leaving such objects laying around is a disservice to the global community - when there is clear and unambigious data that shows the IRR route object describes a route announcement that is to be rejected anyway.
2. what happens when someone is busy creating ROAs in, for example, Magastan and the RIPE NCC runs a deletion process mid-way through that process
When someone needs to create multiple ROAs, but only publishes one - it is an operator error. When one misconfigures things... they are misconfigured, no big deal. This is why for example the RIPE RPKI portal allows you to queue up RPKI ROA modifications and publish the batch in one go. By the way, What is "magastan" and what does it have to do with the topic at hand? To me "quality data" means that the routing information was created with the explicit consent of the owner of the resource - this is something the RPKI offers us. If the owner chooses to publish incorrect routing information (for example: wrong origin ASN) that is entirely up to them.
3. the above situations are complicated by RFC6382.
Why? Section 6 of RFC 6382 explicitly states: "Additionally, this technique sets the stage to employ RPKI-enabled machinery and more secure and explicit routing policies, which all network operators should be considering." What is your concern, how does RFC 6832 change anything? Perhaps you can provide us with a tangible example scenario?
It might be a good idea to send some warnings to the holders of the route/route6 objects before nuking their objects + build in a timeout period.
"their objects"?! We can not assume that the owner of a resource ever asked for the objects in the first place. There are objects in the RIPE-NONAUTH IRR that cover NTT Communications' resources where we've never consented to their creation - since we are not the maintainer and perhaps dont even have any relation with the creator of such objects, we have no recourse to delete such objects. When we create RPKI ROAs covering such route objects it is a clear public statement about which ASNs are authorised to originate those prefixes. Any IRR information that is in conflict with such information should be considered rogue and a risk to our business. It'll take time before we see a great many networks deploy BGP Origin Validation based on RPKI data, so an incremental beneficial step forward is to apply the same origin validation procedure to unvalidated IRR data, this closes loopholes. To me keaving the rogue IRR objects in place and telling the industry to just deploy Origin Validation to mitigate the effects of RIPE-NONAUTH objects would be unreasonable. RIPE-NONAUTH is a pile of garbage, we need to offer folks an easy way to delete the portions of it affecting their resources (knownig that these resource owners probably never have been aware those route/route6 objects existed in the first place!). Kind regards, Job
Job Snijders wrote on 14/10/2018 07:48:
When an operator makes a mistake, they've made a mistake.
When someone needs to create multiple ROAs, but only publishes one - it is an operator error. When one misconfigures things... they are misconfigured, no big deal.
operator error happens all the time. In most cases, it's reversible and life goes on. As it stands, the proposal allows some types of operator error to cause irreversible changes to their exterior routing policy, with no notification or grace period. It may be that those changes are for the better, but there will also be cases where it's for the worse. The RIPE-NONAUTH data set contains garbage, but it also contains plenty of accurate objects. If this proposal does not provide a mechanism to notify holders of conflicting route/route6 objects and provide a reasonable grace period for sorting conflicts, then the proposal is harmful and should not proceed. Nick
On Sun, Oct 14, 2018 at 11:32:44AM +0100, Nick Hilliard wrote:
Job Snijders wrote on 14/10/2018 07:48:
When an operator makes a mistake, they've made a mistake.
When someone needs to create multiple ROAs, but only publishes one - it is an operator error. When one misconfigures things... they are misconfigured, no big deal.
operator error happens all the time. In most cases, it's reversible and life goes on.
Operators are free to create route/route6 objects in the appropriate validating IRR database.
As it stands, the proposal allows some types of operator error to cause irreversible changes to their exterior routing policy, with no notification or grace period. It may be that those changes are for the better, but there will also be cases where it's for the worse. The RIPE-NONAUTH data set contains garbage, but it also contains plenty of accurate objects.
Using RPKI data to purge RIPE-NONAUTH cleans up garbage. Are you suggesting that the RIPE-NONAUTH objects are more accurate than the RPKI ROAs (which semantically have a higher precedence)? We have *NO* idea who created the objects in the RIPE-NONAUTH database, we have no idea whether this was done with the consent of the resource owner. We *DO* know that any RPKI ROAs created through the 5 RIRs are created with the fully consent of the owner, why shouldn't that take precedent?
If this proposal does not provide a mechanism to notify holders of conflicting route/route6 objects and provide a reasonable grace period for sorting conflicts, then the proposal is harmful and should not proceed.
I disagree - the current situation is harmful. Leaving things as-is is damaging. Kind regards, Job
Hi, On Sun, 14 Oct 2018, Nick Hilliard via db-wg wrote:
Job Snijders wrote on 14/10/2018 07:48:
When an operator makes a mistake, they've made a mistake.
When someone needs to create multiple ROAs, but only publishes one - it is an operator error. When one misconfigures things... they are misconfigured, no big deal.
operator error happens all the time. In most cases, it's reversible and life goes on.
As it stands, the proposal allows some types of operator error to cause irreversible changes to their exterior routing policy, with no notification or grace period. It may be that those changes are for the better, but there will also be cases where it's for the worse. The RIPE-NONAUTH data set contains garbage, but it also contains plenty of accurate objects.
Do you care to ellaborate...? Those "accurate objects" absolutely need to be there?
If this proposal does not provide a mechanism to notify holders of conflicting route/route6 objects and provide a reasonable grace period for sorting conflicts, then the proposal is harmful and should not proceed.
The notifications should be issued towards ASN holders? When the route/route6 objects were changed, there was no notification? I don't agree notifications are mandatory in this case, hence i do support the proposal. ps: I only think this needs some rephrasing -- "Due to the way authorisation (or lack of authorisation) is currently set up, there is room for abuse in the RIPE Database, by creating out-of-region inetnums and out-of-region ASN.s without the consent of the resource holder." As of today, after NWI-5 implementation, these new objects shouldn't be possible. :-) Cheers, Carlos
Nick
once a route/route6 object in RIPE-NONAUTH becomes in conflict with a RPKI ROA it should no longer exist.
and once a route/route6 object in the ripe irr instance comes in conflict with a roa published anywhere in the rpki, it should no longer exist? randy
Hi, On Sun, Oct 14, 2018 at 12:34 PM Randy Bush via db-wg <db-wg@ripe.net> wrote:
once a route/route6 object in RIPE-NONAUTH becomes in conflict with a RPKI ROA it should no longer exist.
and once a route/route6 object in the ripe irr instance comes in conflict with a roa published anywhere in the rpki, it should no longer exist?
This policy proposal concerns exclusively the RIPE-NONAUTH IRR database. If you feel strongly about the information in the "RIPE" IRR source feel free to make a new proposal. (Side note: I believe RIPE NCC staff is working on streamlining the user experience & process to help users ensure there are no conflicts. Since all route/route6 objects in the "RIPE" IRR database are created with the full consent of the owner of the resource I find conflict resolution less concerning.) There are ~ 70,000 objects in the RIPE-NONAUTH database, many of which that have been created without the consent of the resource owner, and the resource owners are left with no method to clean them up. Many of these objects are pre-date resource transfer events. Resource owners are free to not create RPKI ROAs if they don't want to use this mechanism - and they are also free to recreate objects in more suitable (validating) databases. NTT has skin in this game, we'd love to get rid of rogue route objects covering our IP space, and do so with an industry wide procedure that can be applied in other databases too. Kind regards, Job
Job Snijders via db-wg wrote on 14/10/2018 11:40:
This policy proposal concerns exclusively the RIPE-NONAUTH IRR database. If you feel strongly about the information in the "RIPE" IRR source feel free to make a new proposal.
There's no need for a new proposal: a notification mechanism and a grace period can be built into either the proposal or else the operating procedure. Some of these old route objects have been there for many years. Another couple of weeks isn't going to cause a huge amount of harm. Nick
On Sun, Oct 14, 2018 at 10:27:28PM +0100, Nick Hilliard wrote:
There's no need for a new proposal: a notification mechanism and a grace period can be built into either the proposal or else the operating procedure.
Some of these old route objects have been there for many years. Another couple of weeks isn't going to cause a huge amount of harm.
I'm hesitant to add such things because we don't have such a notification & grace period in BGP Origin Validation process when processing BGP route announcements either. Those are real time and a such a good control feedback loop. I think it'll significantly complicate the effects of the policy proposal by introducing back-out/undelete/grace-period elements. Regarding the notification process itself, it may be tricky to programmatically find the appropiate contacts to send the notification. The route/route6 object's "notify:" attribute (when present) is perhaps not entirely suitable in this context - since that mail address may not point to the resource holder but rather to a previous owner, an adversary or simply the wrong people. If it is acceptable to the community that a percentage of notifications won't arrive at all, or go to the entirely wrong people - I'm willing to entertain the possibility of amending the proposal to add one-off notifications when an object is deleted. But I do think it'll lead to more confusion, rather than be useful. Kind regards, Job
On 15 Oct 2018, at 11:31, Job Snijders <job@instituut.net> wrote:
I'm hesitant to add such things because we don't have such a notification & grace period in BGP Origin Validation process when processing BGP route announcements either.
You don’t need one there. If there’s a problem with those you can back out the configuration and life will proceed as before. The difference between the examples you’re giving and this proposal is that - as it stands - this proposal will automatic activate a mechanism with no backout, no grace period and no warning. Nick
On Mon, Oct 15, 2018 at 12:52 Nick Hilliard <nick@foobar.org> wrote:
On 15 Oct 2018, at 11:31, Job Snijders <job@instituut.net> wrote:
I'm hesitant to add such things because we don't have such a notification & grace period in BGP Origin Validation process when processing BGP route announcements either.
You don’t need one there. If there’s a problem with those you can back out the configuration and life will proceed as before. The difference between the examples you’re giving and this proposal is that - as it stands - this proposal will automatic activate a mechanism with no backout, no grace period and no warning.
If we deconstruct RIPE-NONAUTH’s current state of affairs we already are facing a irreversible concept: if one deletes an object in RIPE-NONAUTH, it can never be restored. I’ve made it clear what I think should be done - I think the current proposal resolves contention between the owner of the route object and the owner of the resource not being the same entity. But you disagree, so I propose two things: 1) I’ll produce some data on what will happen to the contents of the RIPE-NONAUTH database if Origin Validation is applied. 2) let’s sit down face to face at RIPE 77 to see if we can find a compromise or at least better understand each other’s concerns. Kind regards, Job
On 15 Oct 2018, at 13:00, Job Snijders <job@instituut.net> wrote:
If we deconstruct RIPE-NONAUTH’s current state of affairs we already are facing a irreversible concept: if one deletes an object in RIPE-NONAUTH, it can never be restored.
If someone deletes their nonauth route/route6, they’re making an explicit request for deletion. It may be wrong and they may have made a mistake but the outcome will happen as the result of an explicit, password authorised instruction to the IRRDB to take a specific action. This proposal suggests deleting these objects on the basis of implicit requests via a third party without any feedback mechanism to either the creator of the roa or the holder of the route object and where the person creating the roa may not even be aware of the consequences of their actions. This violates the principle of least astonishment. Nick
Dear Nick, On Mon, Oct 15, 2018 at 02:21:00PM +0200, Nick Hilliard wrote:
On 15 Oct 2018, at 13:00, Job Snijders <job@instituut.net> wrote:
If we deconstruct RIPE-NONAUTH’s current state of affairs we already are facing a irreversible concept: if one deletes an object in RIPE-NONAUTH, it can never be restored.
If someone deletes their nonauth route/route6, they’re making an explicit request for deletion. It may be wrong and they may have made a mistake but the outcome will happen as the result of an explicit, password authorised instruction to the IRRDB to take a specific action.
We can't operate under the assumption that the route object holder and the resource holder are the same and that these objects are harmless.
This proposal suggests deleting these objects on the basis of implicit requests via a third party without any feedback mechanism to either the creator of the roa or the holder of the route object and where the person creating the roa may not even be aware of the consequences of their actions. This violates the principle of least astonishment.
It is not implicit - the semantical meaning of RPKI ROAs in relation to IRR or BGP make for a perfectly valid use of RPKI data to clean up piles of garbage. I repeat: there are route objects in the RIPE-NONAUTH database which cover resources belonging to NTT - and NTT has *NO* way to delete these objects. Being concerned about violating the principle of least astonishment meanwhile our resources are put at unnecessary risk strikes me as a odd approach to risk management. These objects have been created without NTT's consent and without informing us. NTT is informing the world what the authorised origin ASNs are for these resources through RPKI - so that networks deploying RPKI based BGP Origin Validation will reject announcements that align with the information stated in the RIPE-NONAUTH IRR rather than with the ROAs. If we can do origin validation in BGP based on RPKI - we can certainly do origin validation for IRR data based on RPKI. It makes no sense to protect adversarial, rogue or stale objects - why protect them? The flow chart should be simple: - Want to create RPKI ROAs? Make sure you don't misconfigure them or face the consequences. - Want to get rid of stale or fraudulent route objects? Create RPKI ROAs The owners of route objects in RIPE-NONAUTH don't get a say in any of this - they don't own the resource. But, if they *do* own the resource, they can simply create the appropriate route objects in the appropriate RIR IRR database. Kind regards, Job
Hi Job Just a couple of points. First is a technical issue with your proposal. In your Rationale you mention ¨creating out of region inetnums¨. It wasn't possible to create such objects. Only out of region aut-nums and route(6)s. You talk about cleaning up garbage in the RIPE-NONAUTH IRR. The principle of cleaning up garbage is always good. But doesn't this still leave a lot of potential garbage in all the commercial IRRs where ROUTE objects can still be created without authorisation by, consent from and knowledge of the address space holder? So should we also be promoting the RIRs authoritative IRRs over commercial IRRs so that ROUTE objects can all be created with proper authorisation? cheersdenisco-chair DB-WG From: Job Snijders via db-wg <db-wg@ripe.net> To: Nick Hilliard <nick@foobar.org> Cc: Marco Schmidt <mschmidt@ripe.net>; db-wg@ripe.net Sent: Sunday, 14 October 2018, 8:49 Subject: Re: [db-wg] RIPE Policy Proposal 2018-06 Aims to Delete Conflicting Non-authorative IRR Objects Dear Nick, On Sat, Oct 13, 2018 at 10:38:12PM +0100, Nick Hilliard via db-wg wrote:
Marco Schmidt via db-wg wrote on 11/10/2018 14:18:
We just published the RIPE Policy proposal, 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up", to the Routing Working Group mailing list.
The goal of the proposal is to delete an non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA.
There are some corner cases where this could cause permanent and unwarranted pain.
1. what's the procedure for backing out the deletion if the ROA holder in the other RIR makes a mistake and, for example, forgets to create a roa for a specific ASN and then they find their RIPE-NONAUTH route object deleted by accident.
When an operator makes a mistake, they've made a mistake. The same already applies today when the operator changes the ASN in the route/route6 object to the wrong origin ASN. The proposal does not have a 'back out' procedure; once a route/route6 object in RIPE-NONAUTH becomes in conflict with a RPKI ROA it should no longer exist. A different way of looking at things: What the policy proposal in a nutshell does is apply the RFC 6811 BGP origin validation process to IRR data. You could view the IRR data as if they are BGP announcements in context of 6811. Example: An IRR route object in RIPE-NONAUTH states that for prefix 206.48.168.0/22 a possible origin is AS4663 - but a set of PKI ROAs exists: 206.48.0.0/16 AS5511 maxlength 24 206.48.0.0/16 AS6505 maxlength 24 206.48.0.0/16 AS51964 maxlength 24 Obviously "206.48.168.0/22 AS4663" conflicts with the above set of ROAs and would be marked with origin validation state 'invalid'. This means that any network applying RPKI based BGP Origin Validation will reject the BGP announcement "206.48.168.0/22 AS4663", even though someone documented in the RIPE-NONAUTH IRR that that announcement perhaps could exist. The RIPE-NONAUTH IRR route object describes a state of the network that is to be discarded anyway - so deletion is warranted as it closes holes in prefix-list based filters in networks not doing OV. Also note that in the above scenario the owner of the ARIN-managed 206.48.0.0/16 prefix never was consulted or consented to the creation of the 206.48.168.0/22 route-object in the RIPE IRR. Leaving such objects laying around is a disservice to the global community - when there is clear and unambigious data that shows the IRR route object describes a route announcement that is to be rejected anyway.
2. what happens when someone is busy creating ROAs in, for example, Magastan and the RIPE NCC runs a deletion process mid-way through that process
When someone needs to create multiple ROAs, but only publishes one - it is an operator error. When one misconfigures things... they are misconfigured, no big deal. This is why for example the RIPE RPKI portal allows you to queue up RPKI ROA modifications and publish the batch in one go. By the way, What is "magastan" and what does it have to do with the topic at hand? To me "quality data" means that the routing information was created with the explicit consent of the owner of the resource - this is something the RPKI offers us. If the owner chooses to publish incorrect routing information (for example: wrong origin ASN) that is entirely up to them.
3. the above situations are complicated by RFC6382.
Why? Section 6 of RFC 6382 explicitly states: "Additionally, this technique sets the stage to employ RPKI-enabled machinery and more secure and explicit routing policies, which all network operators should be considering." What is your concern, how does RFC 6832 change anything? Perhaps you can provide us with a tangible example scenario?
It might be a good idea to send some warnings to the holders of the route/route6 objects before nuking their objects + build in a timeout period.
"their objects"?! We can not assume that the owner of a resource ever asked for the objects in the first place. There are objects in the RIPE-NONAUTH IRR that cover NTT Communications' resources where we've never consented to their creation - since we are not the maintainer and perhaps dont even have any relation with the creator of such objects, we have no recourse to delete such objects. When we create RPKI ROAs covering such route objects it is a clear public statement about which ASNs are authorised to originate those prefixes. Any IRR information that is in conflict with such information should be considered rogue and a risk to our business. It'll take time before we see a great many networks deploy BGP Origin Validation based on RPKI data, so an incremental beneficial step forward is to apply the same origin validation procedure to unvalidated IRR data, this closes loopholes. To me keaving the rogue IRR objects in place and telling the industry to just deploy Origin Validation to mitigate the effects of RIPE-NONAUTH objects would be unreasonable. RIPE-NONAUTH is a pile of garbage, we need to offer folks an easy way to delete the portions of it affecting their resources (knownig that these resource owners probably never have been aware those route/route6 objects existed in the first place!). Kind regards, Job
Den 16-10-2018 kl. 03:56 skrev denis walker via db-wg:
(...) So should we also be promoting the RIRs authoritative IRRs over commercial IRRs so that ROUTE objects can all be created with proper authorisation?
In my mind. It makes sense if commercial IRRs were never born. And databases of route(6) objects was hosted by the RIRs. Which would then validate any attempts for creating route(6) objects is actually done by an authorised entity. But then ... history ... :sigh: -Christoffer
Hi, Where can we express our support for this RIPE Policy proposal? We think it is a great idea and gets rid of commercial IIRs where you can register just about anything which is or is not yours... Robert Heuvel atom86 (AS8455) Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
participants (8)
-
Carlos Friaças -
Christoffer Hansen (Lists) -
denis walker -
Job Snijders -
Marco Schmidt -
Nick Hilliard -
Randy Bush -
Robert Heuvel