Re: [sidr] Route Leaks and BGP Security

[Christopher Morrow <[e-mail]>]

On Mon, Nov 21, 2011 at 6:08 PM, Shane Amante <[e-mail]> wrote:
> Hi Chris,

howdy!

> On Nov 20, 2011, at 10:35 PM, Christopher Morrow wrote:
>> On Wed, Nov 16, 2011 at 11:23 PM, Danny McPherson <[e-mail]> wrote:
>>>
>>> Team,
>>> I've updated this draft based on some feedback received already.  Given
>>> the discussion at the WG session, and the list discussion as of late, I'd like
>>> to ask that it become a WG item and used to inform the BGP Threat Model
>>> document -- particularly with regards to what's an acceptable residual risk and
>>> what is not.  Once that's comprehensive it can be used to inform secure routing
>>> requirements documents in the working group, and then we can begin assessing
>>> the feasibility of reducing various risks.
>>
>> "The authors believe the capability to prevent leaks should be a
>> first-order engineering objective in any secure routing architecture."
>>
>> So, in the simple scenario laid out, the customer is filtered by the
>> isp's, no? and the filter data is built with something like:  take irr
>> data, meld with rpki data, create filter-lists.
>>
>> The rpki data gives the isps an ability to filter the customer
>> announcements, which would stop the leaks. Is the thing you really
>> want to outline in a draft the process to link the
>> resource-certification data with the existing IRR data and create
>> better prefix/as-path filters?
>
> As the -01 draft states:
> ---snip---
>  Discussion of out of band methods to mitigate this attack are beyond
>  the scope of this document, as it's objective is to inform routing
>  protocol design choices currently being considered within the IETF's
>  SIDR Working Group.
> ---snip---
>

yea, that's cheating :)

>
>> I think one item that was asked for on the list (or perhaps in the
>> meeting) was: How can you know a route you see is a leak?
>>
>> Taken another way, in the case of your example:
>>
>> victim - isp2 - attacker - isp1
>>
>> how is the victim to know that this path isn't proper?
>> what in the update says that?
>
> That's the point.  :-)  At present, nothing being "secured" in the UPDATE, (specifically AS_PATH wrt BGPSec), will tell you that the UPDATE was sent through a legitimate control-plane path vs. an illegitimate control-plane path.
>

agreed.

> In today's networks, the means to control the propagation of a particular BGP route are through configuration of 'policy' locally on routers, (ASBR's/PE's), that look for a combination of /one or more/ _BGP_attributes_ in the BGP route itself to limit its propagation.  As one specific example, an operator of an AS typically configures their ingress ASBR's to assign a specific standard BGP community that says something like:
> - this is a customer route;
> - this is a peer route
> (I would note that these BGP standard communities are 'local' to and only have meaning within the operator of their particular AS.  An operator should NOT or would NOT "trust" third-parties, e.g.: their customers or peers, to set and send these communities to them for lots of obvious reasons).
>

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)

> When a BGP route travels to that operator's egress ASBR's, the egress ASBR then has a locally configured policy that looks for the locally significant BGP community string that says: "this is a customer route", in which case the route is sent out of both peer & customer eBGP sessions.  OTOH, if the eBGP policy at the egress ASBR determines, based on the locally significant BGP community string assigned to a BGP route, "this is a peer route", the action in that locally configured policy at peer eBGP sessions is to drop (not announce outbound) that particular UPDATE; whereas, the action at customer eBGP sessions is to announce that UPDATE outbound.
>
> Locally significant BGP communities + locally configured policy are just one method that could be used, but likely the most widely used.  Depending on the size of one's network other BGP Attributes + locally configured policy may be used.
>
>
>> is there other data that could be used (outside of bgp) to tell the
>> victim that the path is improper?
>
> IMHO, and as I think Russ has pointed out, BGP was only (?) designed to express reachability, not to carry or forward _policy_.  At present, nothing in the BGP protocol disseminates _policy_[1].  Instead, policy to control propagation of BGP routing information is only known to routers via out-of-band configuration (through CLI or NETCONF), either manually or through automated methods.
>

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)

> -shane
>
> [1] The only minor exception I can think of to this is the well-known NO_EXPORT or NO_ADVERTISE BGP communities.  However, those have an extremely limited scope -- specifically, both communities are only exchanged between _directly_ connected adjacent ASN's.  I would add that since BGPSec does not make any attempt to sign the BGP community Attribute, it follows that even in this most limited case BGPSec is not able to certify

During the design team discussions of what parts of bgp to sign, the
decision was made not to cover communities and other attributes
since.. which community means what? which are important? which aren't?
can one AS set 701:666 and send that along to 701? what about 70:112?
(as rob austein said: "What are the security semantics of a
community?") Also, what about (as danny pointed out a few meetings
ago) the networks that strip all communities on ingress so routes with
all relevant attributes equal but different community sets don't cause
extra headache/etc.


> (authenticate?) that a given BGP route *should* or *should not* be propagated to AS'es 2+ hops away.  What if one stripped the NO_EXPORT or NO_ADVERTISE community off and re-announced that BGP route -- is that not considered a MiTM attack, just as bad (or, worse?) as fraudulently inserting one's self into the AS_PATH?

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.

-chris