Re: [sidr] Route Leaks and BGP Security

[Christopher Morrow <[e-mail]>]

On Tue, Nov 22, 2011 at 12:52 AM, Terry Manderson <[e-mail]> wrote:
>
> 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.

ok

>>
>> 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.
>

right, if the attribute isn't signed (or maybe it flat doesn't exist
without signage?) then ... we are where we are today.
Once you cross out of signage, you are lost (under the bgpsec rules as
written at least).

>>      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"
>

yup... well is that for RPSL/Policy-foo? or just for registration in general?
For instance, ALT-DB blows as a source for as701 data... RADB has some
for AS701...
Neither has RPSL-Policy-Foo for AS701 :( ('accepts all routes from
<list-o-customer-asns> && sends-all-routes to
<everyone-except-SFP-peers>')

I got the impression that the culture in ripe-region essentially was
that: "Everyone autogens filters from RIPE-IRR, so ... get that right
or your internet is very small."

>
>>> 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.
>

Could be, I do know that Randy's had some study time to show that even
though people say: "Transit free" they aren't always as free as they'd
like everyone to think. This wasn't (as I recall) observable from
routeviews/ris data though :(

Also, just using ris/routeviews as a starting point I was thinking:
"Could you watch history and build a list of common adjacencies, or
adjacencies you never expect to see?" I couldn't get to a reliable
enough answer though :( (I didn't do any math though... or in-depth
research, I fell back on 'well cyclops/et-al can't seem to be reliable
100% of the time, so...')

It's fair to say that SOME transit routing relationships show up in
RV/RIS, but not all do, and the vantage points are not 'all tier-1 and
down', they are often 'tier-77 networks view of the world!' (with
paths selected such that their Level3 transit is hidden for 'most' of
the intertubes, is that because they only bought 3356-customer routes?
or??

it's messy :(

> 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)
>

sure, the really weird relationships are ... weird. Also, very hard to
quantify :(
just dealing with the 'normal' cases seems to be weird though :(

>>
>> 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.
>

err, then a corrected ascii-art is:

  isp1 --- isp2 - me
      \     /
       as1

apologies for the mistake previously :(

-chris

>>>
>>>
>>> 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.
>
>