Re: [sidr] Route Leaks and BGP Security

[Terry Manderson <[e-mail]>]

On 22/11/2011, at 3:13 PM, Christopher Morrow wrote:

> 
> 'if it is intended' ... means:
>  a) "is intended to be seen at the vantage point it was observed at"
> (3 as-hops away)
>  b) "with the as-path it shows up with" (isp1 - as1 - isp2 - me)
>  c) something else?
> 
> it's not clear what you meant, I'll assume b though...
> 

to be specific, "it was intended to be seen at the vantage point it was observed at, and in the form presented".

So something showing up 3 hops away might be fine provided the 3 hops are intended to be isp1 - as1 - isp2.

> 
> err, this didn't parse for me :(
> You mean you don't see the possibility of adding a transitive
> attribute to BGP, which some AS adds to a path (and signs into the
> announcement, so it has to be kept along the path) and is replicated
> with each as-hop?
> 

yes. (and sorry for being terse)


> Something like:
>  isp1      -      as1      -      isp2     -   me
>   out:is-cust  in:is-transit out:is-transit in:is-cust  out:is-cust
> in:is-transit
> 
> So, isp1 signs toward as1 "is-customer"
>      as1 signs from isp1 "is-transit"
> 
>      as1 signs to isp2 "is-transit"
>      isp2 signs from as1 "is-customer"
> 

the problem is that as1 can validly say "i don't do BGPSEC, but i'm still a valid on path actor" and you have to trust that at face value even though as1 is maleficent. You need isp1 to say that isp1 & as1 have a valid transit arrangement.

>      isp2 signs to me "is-customer"
>      me signs from isp2 "is-transit"
> 
> Given that you'd have to configure (I suspect) each peering as
> 'peering' or 'transit' or 'customer' ...I don't see this flying
> either. :( I also don't see how to compute this on the local-router
> level either, given the information in the session, without an
> operator having to designate "this is a X" :(
> 

right.

>> 
>> History tells us we are (for the most part) inept at doing so, even with tools available.
> 
> I had thought that RIPE had this licked in their region, no? they have
> policy-foo encoded in RPSL-stuff in the DB no? Is that NOT working for
> the cases in region?
> 

Probably they are the closest it gets, but a line from the ENISA paper sticks with me:

"Unfortunately, the quality of the IRRs varies, which makes it difficult to rely on them"


>> 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.
>> 
> 
> sure... but the data isn't exactly always 'accurate' there, and it's
> not accessible to the 'user' (router in the field) really, and I think
> the data includes lots of helter-skelter cruft that's not very helpful
> for this case :(

I was simply using it to demonstrate that since transit routing relationships end up in the RIS and routeviews as observable artefacts (cruft included), advertising who you have a transit relationship in something like the AAO isn't making any huge declarations of "I peer with company X" that can't be found by other investigations.

Although in hindsight the AAO might not be fine grained enough. In some cases an autonomous system may want to optionally list a set of prefixes that are subject to a transit/peer relationship with an adjacent AS.. (and of course, in some cases not)

> 
> oh, I think danny's draft has a link between isp1/isp2 :(
> you probably meant here: "ISP1 and ISP2 directly connect, the path via
> AS1 is invalid/improper/a-leak" right?

That was my understanding.

>> 
>> 
>> 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"
>> 
> 
> note sure, is that time also when we'd have full
> resource-certification and the tools mostly available to just filter
> people reliably/properly/everywhere? ('everywhere' for some value of
> all-customers-of-all-isps, and maybe including
> settlement-free-interconnects as well?)
> 

That I don't know - crystal ball cracked when I tried to beat this year's NHL results out of it.

T.