Re: [sidr] Route Leaks and BGP Security

[Christopher Morrow <[e-mail]>]

On Mon, Nov 21, 2011 at 11:15 PM, Terry Manderson <[e-mail]> wrote:
>
> 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.
>

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

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

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?

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"

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

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

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?

> 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 :(

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

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?

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

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

-chris

> Cheers,
> T.
>
>