Re: Level 3's IRR Database
Based on this draft the recommended preference order is:
1) Validation ok 2) not found 3) Validation nok
Suppose an operator would use local-pref to achieve this. This intention (preferring validated routes) will break, when there's a more specific announcement that doesn't validate. For example the youtube incident would not have been stopped by doing this.
i do not understand your logic. let's try to show the case 666.42.0.0/16 has a roa for as 777 666.42.1.0/24 has a roa for as 888 an announcement comes for 666.42.1.0/24 originating from as 999. are you implying that it should be marked valid? i sure don't want it to. an announcement for 666.42.0.0/16 from as 777 would still be valid. so i am not sure what your point is. please clarify with a concrete example. randy
On 1/31/2011 1:18 AM, Randy Bush wrote:
Based on this draft the recommended preference order is:
1) Validation ok 2) not found 3) Validation nok
Suppose an operator would use local-pref to achieve this. This intention (preferring validated routes) will break, when there's a more specific announcement that doesn't validate. For example the youtube incident would not have been stopped by doing this. i do not understand your logic.
let's try to show the case
666.42.0.0/16 has a roa for as 777 666.42.1.0/24 has a roa for as 888
an announcement comes for 666.42.1.0/24 originating from as 999. are you implying that it should be marked valid? i sure don't want it to.
an announcement for 666.42.0.0/16 from as 777 would still be valid.
Andree was saying, 666.42.0.0/16 has a roa for as 777 you start receiving 666.42.0.0/24 and 666.42.1.0/24, both unsigned. Changing preference isn't enough to stop routing, as it's a more specific route and automatically wins if it gets into the table. Jack
666.42.0.0/16 has a roa for as 777
you start receiving
666.42.0.0/24 and 666.42.1.0/24, both unsigned. Changing preference isn't enough to stop routing, as it's a more specific route and automatically wins if it gets into the table.
nope when there is no roa for the arriving prefix, a roa for the covering prefix is used. see draft-pmohapat-sidr-pfx-validate-07.txt. randy
when there is no roa for the arriving prefix, a roa for the covering prefix is used. see draft-pmohapat-sidr-pfx-validate-07.txt.
which, btw, is why draft-ietf-sidr-rpki-origin-ops-04.txt warns Before issuing a ROA for a block, an operator MUST ensure that any sub-allocations from that block which are announced by others (e.g. customers) have ROAs in play. Otherwise, issuing a ROA for the super-block will cause the announcements of sub-allocations with no ROAs to be Invalid. randy
On 1/31/2011 7:59 AM, Randy Bush wrote:
when there is no roa for the arriving prefix, a roa for the covering prefix is used. see draft-pmohapat-sidr-pfx-validate-07.txt.
Ahh, very good. I think that was the only concern. Presumably that would invalidate the route and it would be discarded vs deprefed. Jack
when there is no roa for the arriving prefix, a roa for the covering prefix is used. see draft-pmohapat-sidr-pfx-validate-07.txt. Ahh, very good. I think that was the only concern. Presumably that would invalidate the route and it would be discarded vs deprefed.
well, i am not sure you want to discard it. this is where the op has to make a decision. in a world of partial deployment and ops and customers still learning how to deal with this stuff, should it be discarded? again from draft-ietf-sidr-rpki-origin-ops-04.txt Local policy using relative preference is suggested to manage the uncertainty associated with a system in flux, applying local policy to eliminate the threat of unroutability of prefixes due to ill- advised certification policies and/or incorrect certification data. E.g. until the community feels comfortable relying on RPKI data, routing on Invalid origin validity, though at a low preference, will likely be prevalent for a long time. but you configure your routers as you think best. randy
On 1/31/2011 8:35 AM, Randy Bush wrote:
when there is no roa for the arriving prefix, a roa for the covering prefix is used. see draft-pmohapat-sidr-pfx-validate-07.txt. Ahh, very good. I think that was the only concern. Presumably that would invalidate the route and it would be discarded vs deprefed.
well, i am not sure you want to discard it. this is where the op has to make a decision. in a world of partial deployment and ops and customers still learning how to deal with this stuff, should it be discarded?
I agree and definitely understand the turnup viewpoint. However, RPKI is useless if we don't discard invalid routes which are more specific than valid covering routes. local pref doesn't override prefix length decisions. Hijacks will continue to occur unless we issue discards... at some point. Jack
well, i am not sure you want to discard it. this is where the op has to make a decision. in a world of partial deployment and ops and customers still learning how to deal with this stuff, should it be discarded?
I agree and definitely understand the turnup viewpoint. However, RPKI is useless if we don't discard invalid routes which are more specific than valid covering routes. local pref doesn't override prefix length decisions. Hijacks will continue to occur unless we issue discards... at some point.
i think that is how i would run my network. but those concerned about *any* change, might prefer being vulnerable to the youtube accident. we all have choices. randy
Hi Randy, .-- My secret spy satellite informs me that at 11-01-30 11:18 PM Randy Bush wrote:
so i am not sure what your point is. please clarify with a concrete example.
Adjusting a route's degree of preference in the selection algorithm based on its validation state only works if it's exactly the same prefix. Jack already sort of explained what I meant, but here's an example Assume that youtube's prefix had a roa like this Origin ASN: AS36561 Prefixes: 208.65.152.0/22 Now AS17557 start to announce a more specific: 208.65.153.0/24. Validators would classify this as Invalid (2). If we would only use local-prefs, routers would still choose to send it to AS17557 (Pakistan Telecom) as it's a more specific. So in cases where the invalid announcement is a more specific, the only way to prevent 'hijacks' is to actually drop these 'invalid' announcement from day one. I understand this is by design, but I can imagine some operators will be reluctant to actually drop routes when they start testing RPKI deployments in their networks. Cheers, Andree
On Mon, Jan 31, 2011 at 6:17 PM, Andree Toonk <andree+nanog@toonk.nl> wrote:
Now AS17557 start to announce a more specific: 208.65.153.0/24. Validators would classify this as Invalid (2).
Would it be classified as invalid or unknown? Or are both possible depending on whether 208.65.153.0/24 is signed? Do these two cases differ in this particular case? Dongting
On 1/31/2011 12:40 PM, Dongting Yu wrote:
Would it be classified as invalid or unknown? Or are both possible depending on whether 208.65.153.0/24 is signed? Do these two cases differ in this particular case?
Based on the draft it is invalid, as the shorter covering prefix is signed, so the longer prefix will inherit that signing but not be valid. Jack
On 31 Jan 2011, at 19:40, Dongting Yu wrote:
On Mon, Jan 31, 2011 at 6:17 PM, Andree Toonk <andree+nanog@toonk.nl> wrote:
Now AS17557 start to announce a more specific: 208.65.153.0/24. Validators would classify this as Invalid (2).
Would it be classified as invalid or unknown? Or are both possible depending on whether 208.65.153.0/24 is signed? Do these two cases differ in this particular case?
No, it would classify as invalid because as Randy said earlier in the thread: Before issuing a ROA for a block, an operator MUST ensure that any sub-allocations from that block which are announced by others (e.g. customers) have ROAs in play. Otherwise, issuing a ROA for the super-block will cause the announcements of sub-allocations with no ROAs to be Invalid. In a ROA you can specify a maximum length, authorising the AS to deaggregate the prefix to the point you specify. If no max length is specified, the AS is only allowed to announce the prefix as indicated. So if the ROA for AS36561 with prefix 208.65.152.0/22 was created with no 'max length' specified, the /24 that AS17557 announces would be invalid because it's the wrong prefix length *and* because it's the wrong origin AS. If a max length of /24 was specified in the ROA, it would be invalid only because of the latter. There could be another ROA for 208.65.153.0/24 specifically, but obviously not for AS17557, so again invalid because of the wrong origin AS. Pakistan Telecom also can't create a valid ROA, because they are not the holder of the address space. -Alex
I think the issue is not between valid vs invalid, but that using route-maps and local preference a "more specific not valid" route would be used over another "less specific valid" because of the routing decision process, right? Perhaps this would help? http://www.ietf.org/mail-archive/web/sidr/current/msg02117.html So, it is my understanding that yes, with local pref the Google vs Pakistan Telecom wouldn't have been avoided, however Google would "only need" to generate more specific routes to beat the unauthorised announce and "fix" the issue. Right? .as On 31 Jan 2011, at 14:20, Alex Band wrote:
On 31 Jan 2011, at 19:40, Dongting Yu wrote:
On Mon, Jan 31, 2011 at 6:17 PM, Andree Toonk <andree+nanog@toonk.nl> wrote:
Now AS17557 start to announce a more specific: 208.65.153.0/24. Validators would classify this as Invalid (2).
Would it be classified as invalid or unknown? Or are both possible depending on whether 208.65.153.0/24 is signed? Do these two cases differ in this particular case?
No, it would classify as invalid because as Randy said earlier in the thread:
Before issuing a ROA for a block, an operator MUST ensure that any sub-allocations from that block which are announced by others (e.g. customers) have ROAs in play. Otherwise, issuing a ROA for the super-block will cause the announcements of sub-allocations with no ROAs to be Invalid.
In a ROA you can specify a maximum length, authorising the AS to deaggregate the prefix to the point you specify. If no max length is specified, the AS is only allowed to announce the prefix as indicated.
So if the ROA for AS36561 with prefix 208.65.152.0/22 was created with no 'max length' specified, the /24 that AS17557 announces would be invalid because it's the wrong prefix length *and* because it's the wrong origin AS. If a max length of /24 was specified in the ROA, it would be invalid only because of the latter.
There could be another ROA for 208.65.153.0/24 specifically, but obviously not for AS17557, so again invalid because of the wrong origin AS. Pakistan Telecom also can't create a valid ROA, because they are not the holder of the address space.
-Alex
I think the issue is not between valid vs invalid, but that using route-maps and local preference a "more specific not valid" route would be used over another "less specific valid" because of the routing decision process, right?
in a word, no please read draft-pmohapat-sidr-pfx-validate randy
Now AS17557 start to announce a more specific: 208.65.153.0/24. Validators would classify this as Invalid (2). Would it be classified as invalid or unknown?
invalid
Or are both possible
no. the result is a single value
depending on whether 208.65.153.0/24 is signed?
<pedant=on> roas, which are signed by resource certificates, bind a prefix to a set of ASs. sorry to wax pedantic. but this stuff can get crufty, and getting the nouns and verbs correct will help us navigate. randy
On Mon, Jan 31, 2011 at 1:17 PM, Andree Toonk <andree+nanog@toonk.nl> wrote:
Hi Randy,
.-- My secret spy satellite informs me that at 11-01-30 11:18 PM Randy Bush wrote:
so i am not sure what your point is. please clarify with a concrete example.
Adjusting a route's degree of preference in the selection algorithm based on its validation state only works if it's exactly the same prefix.
Jack already sort of explained what I meant, but here's an example
Assume that youtube's prefix had a roa like this Origin ASN: AS36561 Prefixes: 208.65.152.0/22
Now AS17557 start to announce a more specific: 208.65.153.0/24. Validators would classify this as Invalid (2). If we would only use local-prefs, routers would still choose to send it to AS17557 (Pakistan Telecom) as it's a more specific.
So in cases where the invalid announcement is a more specific, the only way to prevent 'hijacks' is to actually drop these 'invalid' announcement from day one.
I understand this is by design, but I can imagine some operators will be reluctant to actually drop routes when they start testing RPKI deployments in their networks.
yes, but what is the way forward?
On Jan 31, 2011, at 3:11 PM, Christopher Morrow wrote:
I understand this is by design, but I can imagine some operators will be reluctant to actually drop routes when they start testing RPKI deployments in their networks.
yes, but what is the way forward?
RPKI in my IPv6? :) Someone is going to be the first person to jump into this sea. It continues to be something that I am interested in. If you look at the risk to your $dayjob, at minimum you should be looking at RPKI for your infrastructure IP space, similar to how you might obtain a certificate for your corporate website. I applaud vendors of hardware and IP services that have managed to do BCP-38 type packet filtering. It cleans up the mess others have to see. This is the same thing IMHO. We need to keep the routing infrastructure secure. This doesn't mean you have to secure your network. But I can decide that if you buy into the same security model as described via SIDR/RPKI you may obtain better preference in my network. - Jared
.-- My secret spy satellite informs me that at 11-01-31 12:11 PM Christopher Morrow wrote:
I understand this is by design, but I can imagine some operators will be reluctant to actually drop routes when they start testing RPKI deployments in their networks.
yes, but what is the way forward?
Not sure, that was my original question: Are there any suggestions or recommendations for how to handle these cases?
On Mon, Jan 31, 2011 at 3:55 PM, Andree Toonk <andree+nanog@toonk.nl> wrote:
.-- My secret spy satellite informs me that at 11-01-31 12:11 PM Christopher Morrow wrote:
yes, but what is the way forward?
Not sure, that was my original question: Are there any suggestions or recommendations for how to handle these cases?
So... I think we should keep in mind that rPKI provides some in-protocol (and on-router) certificate checking bits (this is over simplified, on purpose). Those things allow you to validate routing data as you see it on the device, and take some policy steps to react to that decision. The other thing that rPKI gets us to is the ability to create and maintain prefix-list (or equivalent) data for routers in an automatedand verifiable manner. You could validate the prefixes your customers/peers claim to have with some cryptographic assurance... that data is tied to the allocation hierarchy, and it's kept updated by the allocation chain (IANA->RIR->NIR->LIR->EndUser). So, maybe the answer is folks will be able to better/quicker/more-accurately maintain bgp filters and drop this sort of problem in Adj-Rib-In ? -Chris
Jack already sort of explained what I meant, but here's an example
Assume that youtube's prefix had a roa like this Origin ASN: AS36561 Prefixes: 208.65.152.0/22
Now AS17557 start to announce a more specific: 208.65.153.0/24. Validators would classify this as Invalid (2). If we would only use local-prefs, routers would still choose to send it to AS17557 (Pakistan Telecom) as it's a more specific.
So in cases where the invalid announcement is a more specific, the only way to prevent 'hijacks' is to actually drop these 'invalid' announcement from day one.
yes. and your point is? we all run our routers according to our views of what policy we want. some folk will want to drop that, i encourage them to, and have done my best to see that they have the capability to do so. i am in that camp. others fear rir and black helicopter control of their routing. they may not want to drop the 'bad' announcement. i tried to document how they might do so. we all have choices. the point of the design is to empower the operator to make those choices, and to do so in a simple and consistent fashion. randy
On 1/31/2011 3:06 PM, Randy Bush wrote:
some folk will want to drop that, i encourage them to, and have done my best to see that they have the capability to do so. i am in that camp.
I definitely recommend it as BCP.
others fear rir and black helicopter control of their routing. they may not want to drop the 'bad' announcement. i tried to document how they might do so.
I think this is fine. It will fix a few minor problems (the problem network will have to be the same length or shorter to be ignored by pref), while keeping RPKI from solving the worst of them. The best of both worlds, IMHO, is to allow all routes were are not specifically contrary to a valid route. ie, if RIR/government makes a route invalid, it will still work, unless there is an equal size or shorter route which is valid (ie, the government not only has to invalidate your route, but they also have to advertise your route or a covering route with a valid ROA). Jack
others fear rir and black helicopter control of their routing. they may not want to drop the 'bad' announcement. i tried to document how they might do so.
I think this is fine. It will fix a few minor problems (the problem network will have to be the same length or shorter to be ignored by pref), while keeping RPKI from solving the worst of them.
my routing security half agrees. i have another half which fears that we have not completely connected the dots between the egyptian net shut off of their nets and the media interests who own the us government shutting off domain names without a court order. randy
On 1/31/2011 3:45 PM, Randy Bush wrote:
i have another half which fears that we have not completely connected the dots between the egyptian net shut off of their nets and the media interests who own the us government shutting off domain names without a court order.
I agree, which is why I had the alternative mechanism. It allows for the best of both worlds, and if an RIR or government want to revoke an roa AND advertise the route themselves with a valid roa, they could easily have just advertised more specific routes to override the valid route. Jack
participants (8)
-
Alex Band -
Andree Toonk -
Arturo Servin -
Christopher Morrow -
Dongting Yu -
Jack Bates -
Jared Mauch -
Randy Bush