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

Shane Amante <shane@castlepoint.net> Fri, 06 April 2012 15:21 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 3195321F85C6 for <sidr@ietfa.amsl.com>; Fri, 6 Apr 2012 08:21:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 moxWgjS-ao4J for <sidr@ietfa.amsl.com>; Fri, 6 Apr 2012 08:21:11 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF1B21F857A for <sidr@ietf.org>; Fri, 6 Apr 2012 08:21:07 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id 67E25268063; Fri, 6 Apr 2012 09:21:06 -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; Fri, 06 Apr 2012 09:21:06 -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=65525; data-bytes=0
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Shane Amante <shane@castlepoint.net>
In-Reply-To: <4F7EFD25.5020709@bbn.com>
Date: Fri, 6 Apr 2012 09:21:05 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D97C133-3EFD-4FD5-98B3-942530BD543C@castlepoint.net>
References: <64B29EFD-5C6E-4D0C-8E4F-92A2B5A86279@castlepoint.net> <p06240803cb99d283e548@[10.108.69.44]> <8D2985D4-07C3-42EE-A694-DAF24D34F84A@castlepoint.net> <4F7EFD25.5020709@bbn.com>
To: Andrew Chi <achi@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: Fri, 06 Apr 2012 15:21:14 -0000

On Apr 6, 2012, at 8:26 AM, Andrew Chi wrote:
> 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?


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