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

[Jakob Heitz <[e-mail]>]

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.



________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of Shane Amante
Sent: Thursday, March 29, 2012 6:04 AM
To: Stephen Kent
Cc: sidr wg list
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening

Steve,

Thanks for the response.  First, a high-level comment before more specific responses below.

The challenge I'm having is trying to reconcile threats against the existing AS4_PATH attribute vs. threats against the BGP_Path_Signature attribute.  More specifically, the AS4_PATH attribute is used by the BGP protocol for loop detection, (i.e.: if I find my own ASN in the AS4_PATH, today, then I drop the route because the BGP protocol considers that a routing information loop).  So, the question is: if/when BGPSEC is deployed, will BGP be expected to perform this loop detection check on the AS4_PATH attribute /prior/ to verification of the BGPSEC_Path_Signature attribute or after?  If it's before, then there's the potential for someone to forge a AS4_PATH attribute to cause a receiver to drop a BGP UPDATE causing a DoS attack.  OTOH, if loop detection is after verification of the BGPSEC_Path_Signature attribute, then this may be another form of DoS attack, given that the UPDATE needs to be run through crypto processors, (which like general purpose CPU's have a finite # of Ops/sec they can run), to check the BGPSEC_Path_Signature validity before going through protocol correctness checks on AS4_PATH attribute.  There may be a third answer, which is that the SIDR WG will deprecate the AS4_PATH attribute and replace it with the BGPSEC_Path_Signatures attribute, but even in this case I think the same two choices I just outlined need to be decided upon.

I don't see an easy answer here; however, I suspect that from a security PoV, there is likely a "preference" to verify the BGPSEC_Path_Signature attribute, first, before running protocol correctness checks (loop avoidance), which may result in the threat of a DoS.  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 and/or to the feasibility of unvalidated paths carried in the control plane, (until they are later, perhaps "lazily", validated via a background process).


Please see below.

On Mar 29, 2012, at 11:07 AM, Stephen Kent wrote:
Shane,

To expand on my comments at the mic earlier today on this draft, I think there is universal acknowledgment that there should be statements that attacks involving path shortening should be acknowledged as a "threat" in this document.

Section 4.2, near the top of page 12,  addresses this attack, in the BGPSEC context:

      Secure Path Downgrade: A router might remove signatures from a
      BGPSEC update that it receives, when forwarding this update to a
      BGPSEC-enabled neighbor.  This behavior violates the BGPSEC spec
      and thus is considered an attack.
This is the path shortening attack, expressed in terms of an attack against a BGPSEC-protected path.

I suspect that this, and other, text was written a little while ago when there was a much tighter coupling of the AS4_PATH attribute & the proposed BGPSEC_Path_Signature attribute.  However, given recent discussions around (ab)using pCount = 0 for Route Servers at IX'es, ASN migrations, etc., then perhaps Section 4.2 of this draft should be revisited in light of whether the BGP Path Selection algorithm is going to use data from the AS4_PATH attribute, at all, (even after verification of the BGPSEC_Path_Attribute) and the potential for various DoS threats that /may/ have wrt availability vs. validity of reachability ...


OTOH, with respect to path-lengthening, my comment was NOT aimed at the normal, operation practice of AS_PATH prepending for the purposes of Traffic Engineering.

Section 4.2, bottom of page 11, says:

      AS Insertion: A router might insert one or more ASNs, other than
      its own ASN, into an update message.  This violates the BGP spec
      and thus is considered an attack.
This seems to address the K/P attack, in the BGPSEC context.

Same comment as above.  At a minimum, can the above text be more clear on whether those statements are in relation to the AS4_PATH attribute or BGPSEC_Path_Attributes attribute, or both?


The larger point here is that documenting, preferably in this I-D, the Kapela/Pilsov threat and other threats related to upgrade/downgrade threats discussed at the Prague IETF allows us to more holistically consider whether, or not, BGPSEC addresses it.

So, ignoring the "threat" vs. "attack" terminology issue that we discussed at the mic :-), I could add some text to describe classes of attacks in terms of vanilla BGP, as well as BGPSEC.  But, RFC 4272 already did this in a fair level of detail, so I didn't see the need for this doc to include an attack enumeration for BGP.

When discussing security, it is generally preferable to define what constitutes secure or "correct" operation for a protocol, rather than trying to enumerate attacks against the protocol. If one wants to be more specific, then one can
describe classes of attacks, and provide some illustrative examples. That's what we have tried to do here.

Understood.


Not sure I understand you last comment:

d)  Further, what if an attacker did this to valid, BGPSEC-signed paths that he/she was originating and/or receiving and propagating downstream toward other ASN's?

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?

Thanks,

-shane