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

Shane Amante <shane@castlepoint.net> Thu, 29 March 2012 13:04 UTC

Return-Path: <shane@castlepoint.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E416521F8993 for <sidr@ietfa.amsl.com>; Thu, 29 Mar 2012 06:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.158
X-Spam-Level:
X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLRKa4hp13on for <sidr@ietfa.amsl.com>; Thu, 29 Mar 2012 06:04:38 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id A48FC21F8986 for <sidr@ietf.org>; Thu, 29 Mar 2012 06:04:29 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id 35547268063; Thu, 29 Mar 2012 07:04:29 -0600 (MDT)
Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 29 Mar 2012 07:04:28 -0600 (MDT) (envelope-from shane@castlepoint.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=54011; data-bytes=0
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_3A651CA3-A674-4267-93F1-4D8CDE7A503C"
From: Shane Amante <shane@castlepoint.net>
In-Reply-To: <p06240803cb99d283e548@[10.108.69.44]>
Date: Thu, 29 Mar 2012 15:04:25 +0200
Message-Id: <8D2985D4-07C3-42EE-A694-DAF24D34F84A@castlepoint.net>
References: <64B29EFD-5C6E-4D0C-8E4F-92A2B5A86279@castlepoint.net> <p06240803cb99d283e548@[10.108.69.44]>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.1257)
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2012 13:04:40 -0000

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