Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening

From: Andrew Chi <[email-masked]>
Date: Fri, 06 Apr 2012 10:26:45 -0400

On 3/29/2012 9:04 AM, Shane Amante wrote:
>Regardless, I think
> that its best to acknowledge, in this draft, that there is a threat of
> DoS to the availability of the BGP control plane

Maybe I'm missing something.

Intermediate routers or MITM entities can always drop updates.  If 
BGPSEC is enabled, then forging an AS4_PATH or modifying 
BGPSEC_PATH_Signature achieves no more than dropping the update.

Can you give a specific example of DoS that applies only to 
BGPSEC-enabled routers?

-Andrew

---

From: Shane Amante <[email-masked]>
Date: Fri, 6 Apr 2012 09:21:05 -0600

On Apr 6, 2012, at 8:26 AM, Andrew Chi wrote:
> Intermediate routers or MITM entities can always drop updates.  If BGPSEC is enabled, then forging an AS4_PATH or modifying BGPSEC_PATH_Signature achieves no more than dropping the update.
> 
> Can you give a specific example of DoS that applies only to BGPSEC-enabled routers?

RFC 4271, Section 9.1.2, "Phase 2: Route Selection":
---snip---
   If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
   route should be excluded from the Phase 2 decision function.  AS loop
   detection is done by scanning the full AS path (as specified in the
   AS_PATH attribute), and checking that the autonomous system number of
   the local system does not appear in the AS path.  Operations of a BGP
   speaker that is configured to accept routes with its own autonomous
   system number in the AS path are outside the scope of this document.
---snip---

So, what if there's a "bad actor" and he/she forges and AS4_PATH and/or BGPSEC_Path_Signature with the intent of making *another* AS, which is 'playing by the rules of BGP and/or BGPSEC', drop the UPDATE?  As I said previously, there's two things to think about here:
a)  BGP performs loop detection on the AS_PATH attribute *before* verifying any BGPSEC_Path_Signature, in which case you drop the UPDATE, thus causing a DoS because you're not propagating what *may* be legitimate reachability info further downstream.
b)  BGP performs loop detection on the AS_PATH attribute only /after/ verifying the BGPSEC_Path_Signature is valid, in which case there is a /potential/ for another type of DoS, because there will always be a limited amount of crypto verifications/sec that can be performed.  There's also the concern that this will slow down propagation of reachability information, because it first needs to be crypto-verified before it's used/propagated.  Note, this is unlikely to be a problem during "steady-state", but is more likely to appear during some amount of churn in BGP due to link and/or router failures, for example.

Note, there is likely no easy answer here, but it would be good for the WG to think about the problem and see if it could recommend a "best practice" to operators ...

In addition, I believe there is a substantially larger question here for the WG: is SIDR planning to, eventually, change RFC4271 so that AS loop detection is no longer performed on the AS_PATH attribute and, instead, is going to be performed only on the BGPSEC_Path_Signature attribute?  If so, is SIDR "allowed" to make that change or will this change be made within the IDR WG?

-shane

---

From: Andrew Chi <[email-masked]>
Date: Fri, 06 Apr 2012 12:20:32 -0400

> a)  BGP performs loop detection on the AS_PATH attribute *before* verifying any BGPSEC_Path_Signature, in which case you drop the UPDATE, thus causing a DoS because you're not propagating what *may…

Right, I'm familiar with loop detection and K/P.

If someone has modified AS_PATH to cause another AS to drop it, then 
they inserted someone else's AS.  This no longer counts as "legitimate 
reachability info", and therefore it should be dropped, and the sooner 
the better.

It sounds like there's another issue mixed up in here (but perhaps not 
in scope of the -bgpsec-threats document): you're trying to resolve the 
ambiguity on what to do with AS_PATH, as Matt notes at the end of the 
following section.

http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-02#section-5

    EDITOR'S NOTE: Text will be inserted here for dealing with the
    AS_PATH attribute.  Note that the BGPGSEC_Path_Signatures attribute
    now contains all of the information needed to construct the AS_PATH
    attribute.  Therefore, there seem to be two options.  One option the
    BGPSEC speaker checks the AS_PATH attribute against the information
    in the BGPSEC_Path_Signatures attribute and returns "Not Good" if the
    two do not match.  The other option is that the BGPSEC speaker
    discards anything in the AS_PATH attribute and reconstructs the
    AS_PATH from the data in the BGPSEC_Path_Signatures attribute.  I
    believe that there are no interoperability problems if the choice
    between these two options is left up to the BGPSEC speaker.

> b)  BGP performs loop detection on the AS_PATH attribute only /after/ verifying the BGPSEC_Path_Signature is valid, in which case there is a /potential/ for another type of DoS, because there will…

Yes, this is true -- there's always DoS by feeding garbage to your 
neighbor, BGPSEC or not, but crypto lets you waste more CPU.  DoS on a 
BGP router is mentioned briefly at the end of 4.1 -- would you like more 
text?

---

From: Shane Amante <[email-masked]>
Date: Fri, 6 Apr 2012 11:02:36 -0600

On Apr 6, 2012, at 10:20 AM, Andrew Chi wrote:
> If someone has modified AS_PATH to cause another AS to drop it, then they inserted someone else's AS.  This no longer counts as "legitimate reachability info", and therefore it should be dropped, and the sooner the better.

But the problem is: how do you know it's *not* "legitimate reachability info" if you've (only) based the decision to drop the UPDATE based on unverified info in the AS_PATH attribute?  If you do, that's a _threat_ of a DoS attack, which presumably the whole point of BGPSEC is designed to protect against.

At some point in the future, the SIDR WG will resolve *how* it's going to prescribe that BGP loop detection is supposed to work.  Either way, it needs to acknowledge there are two types of potential threats:
a)  Use unverified AS_PATH info for loop detection; or,
b)  Use verified BGPSEC_Path_Signature info for loop detection.
Ultimately, if the SIDR WG prescription *eventually* resolves that loop detection is only going to be performed on the BGPSEC_Path_Signature attribute, then the text in sidr-threats can be modified, at that future point in time, to say something like:
- Attacks against BGP loop detection are mitigated by only using verified info on the path from reconstruction of the path in BGPSEC_Path_Signature; however,
- This has the potential to introduce a DoS on the BGP control plane itself, either through normal operation (high churn) or an operator injecting false UPDATE's, into the system, which exceed the capacity of routers to perform crypto verification fast enough ...

> It sounds like there's another issue mixed up in here (but perhaps not in scope of the -bgpsec-threats document): you're trying to resolve the ambiguity on what to do with AS_PATH, as Matt notes at the end of the following section.
> 

Given the above, then I suggest the next revision of draft-ietf-sidr-bgpsec-protocol explicitly says: "Updates: RFC 4271" and that future updates of draft-ietf-sidr-bgpsec-protocol start to be shared with IDR WG mailing list, (particularly in light of discussions at the recent IDR WG meeting where the SIDR co-chairs have pointed out the need for cooperation between SIDR & IDR).  I do not believe that the SIDR WG is in a position to make a call as to whether, or to what extent, there are going to be interoperability concerns with legacy, non-BGPSEC capable routers wrt AS_PATH loop detection ... IMO, that should be the responsibility and call of the IDR WG.

> Yes, this is true -- there's always DoS by feeding garbage to your neighbor, BGPSEC or not, but crypto lets you waste more CPU.  DoS on a BGP router is mentioned briefly at the end of 4.1 -- would you like more text?

Yes.  I think the text "... DoS attacks against BGP routers" is extremely vague, because there are two things that come to mind:
a)  A packet DDoS attack against the router, which may not have anything to do with the BGP control plane itself -- i.e.: some attacker trying to overwhelm links with too much traffic causing [severe] packet loss; and,
b)  A DoS attack against the actual BGP _control_plane_ itself.  More specifically, threats that either:
    i)  overwhelm the I/O, CPU (and/or, memory) capabilities of the BGP router; and,
    ii) in the future, overwhelm a new component, namely, the crypto verification capabilities of the BGP protocol.

I care about the latter (b), in the context of the SIDR WG, and I believe that is what the current text in Section 4.1 is attempting to say, just not well enough, yet.

Thanks,

-shane

---

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 6 Apr 2012 18:10:52 +0000

Speaking as regular ol' member

Shane, I'm having some trouble following your argument.

Here's what I think you are saying.

You are exploring options for dropping an update based on detecting a loop - whether the loop detection should be before or after the check of the path signatures.

If you do the loop detection first, you say, that's a potential dos attack, because....

    "But the problem is: how do you know it's *not* "legitimate reachability info"
    if you've (only) based the decision to drop the UPDATE based on unverified info 
    in the AS_PATH attribute?  If you do, that's a _threat_ of a DoS attack, which 
    presumably the whole point of BGPSEC is designed to protect against."

And that's where I lose you.  I don't see why detecting the loop first provides a dos attack

Case 1: If the update has actually looped, then dropping the update because of loop detection is just fine.

Case 2: If the update has not actually looped, then someone has managed to inject an AS (yours) into the AS_PATH *illegitimately* (the update did not actually go trough your AS).  So dropping the update is just fine here also, because this is an attack.

In this case, testing the bgpsec signatures will necessarily fail.  So dropping the update because of loop detection is not a denial of service.  Whether you do loop detection first or bgpsec signature test first, the update will be dropped.

So where's the dos attack?

(Do note that the bgpsec signatures would detect this at the first point that checked the signatures, so your neighbor would have spotted the injection - unless it was the source of the injection.)

--Sandy, regular ol' member
________________________________________
From: [email-masked] [[email-masked]] on behalf of Shane Amante [[email-masked]]
Sent: Friday, April 06, 2012 1:02 PM
To: Andrew Chi
Cc: sidr wg list
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening &        lengthening

Thanks,

-shane
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Andrew Chi <[email-masked]>
Date: Fri, 06 Apr 2012 15:21:31 -0400

> (Do note that the bgpsec signatures would detect this at the first point that checked the signatures, so your neighbor would have spotted the injection - unless it was the source of the injection.)

So I think I finally see what Shane's getting at.  Let's say:

- I'm a bad actor (A)
- Bob is my neighbor (B)
- Charlie is Bob's neighbor (C)

A is trying to cause B and C to have different views of the world.  In 
addition, we must assume:

- B's router ignores AS_PATH and just uses BGPSEC_Path_Signature
- C's router checks both AS_PATH and BGPSEC_Path_Signature

As the bad actor, A injects C into the AS_PATH (malicious), but 
processes BGPSEC_Path_Signature normally, and sends the update to B.

- B verifies BGPSEC_Path_Signature only, passes it to C
- C detects a loop in AS_PATH and drops the update

A has just caused B to accept an update while simultaneously causing C 
to drop it silently.  While not a very strong attack (B could always 
filter the route anyway), I could imagine it being a starting point for 
causing confusion.

This is solved by prescribing that AS_PATH/AS4_PATH is ignored when 
BGPSEC is enabled, but Shane has a good point that we might need to 
coordinate with IDR on this.  I defer to the WG chairs on that coordination.

-Andrew

---

From: Andrew Chi <[email-masked]>
Date: Fri, 06 Apr 2012 15:36:16 -0400

Oops:  s/BGPSEC_Path_Signature/BGPSEC_Path_Signatures/

---

From: Stephen Kent <[email-masked]>
Date: Mon, 9 Apr 2012 22:20:37 -0400

At 3:04 PM +0200 3/29/12, Shane Amante wrote:
>Steve,
>
>Thanks for the response.  First, a high-level comment before more 
>specific responses below.

Shane,  sorry to be so late in replying.  I think you and Andrew have 
already discussed a number of the issues you raised below, so I'll 
just make a few, brief comments.

First, as Sriram noted, BGPSEC carries only the secure AS path info, 
not the old
As path attribute. So there cannot be a mismatch between the two, and 
loop detection should work. Because of the signature requirements, no 
bogus ASN's can appear in the secured path, no hops can be stripped, 
etc. It's an implementation decision as to whether a router checks 
the secured path data before validating the sigs to detect a loop. 
One might do this to avoid wasting cycles on crypto.

>...
>There is text about MITM threat in Section 4.2; however, that seems 
>to relate to crypto security between two adjacent routers over, say, 
>a directly connected link.  However, what about MITM attacks that 
>create what appear to be valid BGPSEC_Path_Signature attribute that 
>would pass verification by downstream parties?

I still do not understand. Unless a MITM has access to the private 
keys for the BGP routers in question, it cannot generate sigs that 
will validate when checked by downstream parties.'

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 9 Apr 2012 22:12:56 -0400

At 9:46 AM -0400 3/29/12, Jakob Heitz wrote:
>Let's just require that BGPSEC capable routers
>also support 4 byte AS. Then we don't need to worry
>about AS4_PTH.
>
>--
>Jakob Heitz.

This is already a requirement. See the BGPSEC protocol spec, page 4:

  By indicating support for receiving BGPSEC update messages, a BGP 
speaker is, in particular, indicating that the following are true:

    o  The BGP speaker understands the BGPSEC_Path_Signatures 
attribute (see Section 3).

    o  The BGP speaker supports 4-byte AS numbers (see RFC 4893).