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

Shane Amante <shane@castlepoint.net> Wed, 28 March 2012 13:56 UTC

Return-Path: <shane@castlepoint.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 786A321F898B for <sidr@ietfa.amsl.com>; Wed, 28 Mar 2012 06:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Tmr-oSw9Nt5z for <sidr@ietfa.amsl.com>; Wed, 28 Mar 2012 06:56:45 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net []) by ietfa.amsl.com (Postfix) with ESMTP id A5A5621F8967 for <sidr@ietf.org>; Wed, 28 Mar 2012 06:56:45 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id 0AA01268063; Wed, 28 Mar 2012 07:56:45 -0600 (MDT)
Received: from host2.tcb.net ( []) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 28 Mar 2012 07:56:44 -0600 (MDT) (envelope-from shane@castlepoint.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=; client-port=50011; data-bytes=0
From: Shane Amante <shane@castlepoint.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 28 Mar 2012 15:56:41 +0200
Message-Id: <64B29EFD-5C6E-4D0C-8E4F-92A2B5A86279@castlepoint.net>
To: sidr wg list <sidr@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
Subject: [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: Wed, 28 Mar 2012 13:56:46 -0000

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.

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.

My concern is one that is related to the purported Kapela/Pilosov "threat".  Specifically, think of the following scenario:
a)  Someone is forging an AS4_PATH towards another (remote) party, to stimulate then to drop the UPDATE.
b)  An implementation is checking the AS4_PATH attribute to see if they find their ASN in there. If they find their own ASN, they consider this UPDATE as being looped and, per BGP protocol, should drop it.
c)  I can see a scenario where, similar to GTSM, implementers might have a [strong] preference to verify the AS4_PATH does not have any loops /first/, before doing any crypto verification on BGPSEC_Path_Signatures, since crypto verification is "[much] more expensive".
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?

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.