Re: [sidr] Route Leaks and BGP Security

[Terry Manderson <[e-mail]>]

Speaking for myself on this one.

On 22/11/2011, at 12:47 PM, Christopher Morrow wrote:
> 
> ok, so if we step forward and ask for 'give me an attribute to
> indicate customer/peer/other', would we then trust that? it'd be
> (presumably) set per as-hop, is that anymore trustworthy than the
> communities supposed above?
> 
> (I'd also ask what the rules are for setting this sort of thing, but I
> don't think that matters since we can't really trust the value in it)
> 

So lets say (hypothetically) we adopt a requirement of this system to allow a relying party to parse a route and know if it is intended or not by some construction of verifiable information.

I can't, for the life of me, see a transitive attribute _in_ BGP (signed or otherwise) making a positive step in trying to secure intent of the local AS as effected by a routing domain 2+ hops away.

>> 
>> 
> 
> yup, I don't think we're going to get to the fully publicly exposed
> policy world though... are we? (we can't, I think, expect everyone to
> expose that sort of thing, never mind keep it updated)

History tells us we are (for the most part) inept at doing so, even with tools available.

But what we do know is that when policy is implemented, the results are transparent and can be seen
(ris, routeviews, et al) by anyone who cares to look.

> 
> yup... no-export/advertise were taken as 'advisory' communities that
> networks MAY heed, but certainly weren't bound to do so.
> 
> So, back to the question:
> "Given BGP as it is today, how do you know if a route is a leak or not?"
> 
> I suppose documenting: "One leak scenario is <see id name>" is a fine
> thing, does it help to actually fix the problem though? I think what I
> heard in the meeting and on the thread(s) here was: "Sure leaks are
> important, there's not a way devised so far that distinguishes a
> 'leak' route from a 'normal' route, more than 1 as-hop from the
> 'source' of the leak.
> 
> In the id/draft:
> 
>   isp1   isp2 - me
>       \     /
>        AS1
> 
> I can't tell at 'me' that the route I see is a 'leak', just that I see
> an as-path that is isp1-as1-isp2.


The bit I think that is missing is some knowledge that isp1 asserts it has valid routing through isp2, and any other potential 'true' paths. (noting AS1 is considered the 'Serleena' here)

From what I recall draft-huston-sidr-aao-profile takes a step in that direction. (insert my reluctance about tightly binding routing operations to allocation practice) in such that it only publicises the valid paths, through subsequent AAO's by by other ASNs. Thus if an AAO (in my reading) is created by isp1 with only an adjacency to isp2. It provides "me" with an ability to say that the received route with AS1 on path is invalid.

The AAO doesn't dive into local policy, and if isp1 has a private peering with AS3, then it need not put that in an AAO and thus the business dealings remain private - everything else ends up being seen in routeviews over time. So this is one way... but not the only way.

The killer problem here is that partial deployments will create path islands, where only a number of the ASN hops have created AAO objects and thus a path validity exercise will still fall into a potential leak trap until all ASNs get there. The question then could then be, "is it o.k. for the answer to route leaks to be near unusable until we have a significant deployment"

Cheers,
T.