Re: [sidr] BGPSEC Threat Model ID

[Eric Osterweil <[e-mail]>]

On Nov 4, 2011, at 8:59 PM, Randy Bush wrote:

>> Point being that in cases like this (or really all route leak cases)
>> the only thing that stops this is filtering routes between bgp peers.
>> (transits, customers, SFP peers) There isn't anything in the protocol
>> itself (which is Stephen's, Russ's, Randy's comment through out) that
>> tells you/me/them that 12989 should not be permitted to announce this
>> route. (looking at available data, it seems that they SHOULD, perhaps
>> not with this ASPath, but...)
> 
> we can not know intent.
> 
> to take it to one extreme, did the pakistani operator mean to 'leak'
> youtube's prefix or not?

So, in the spirit of not forking the thread too many more times than necessary, I'll try to speak to both of these comments here.  Sorry, if this misses some of context from the snipped text, lemme know if there was important context I missed and I'll backup to that).

I think the distinction between a leak and something more intentional s a matter of policy.  Knowing the policy associated with the adjacencies that an AS is leaking over would allow leaked announcements to be identified, right (or am I in the weeds on this)?  If so, then one could use policy to filter announcements that violate that.  If an intentional leak (i.e. path hijack) were launched, one could use the policy statements that authorized the leak as evidence of intent, or at least a hammer to hit someone over the head with.

As for Pakistan, iirc that was an origin hijack.  In this case, the origin authenticity was the issue, and that problem should be solved through resource certification.

Eric