[sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees

David Mandelberg <david@mandelberg.org> Wed, 26 August 2015 21:26 UTC

Return-Path: <david@mandelberg.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id D6FCC1B2DA7 for <sidr@ietfa.amsl.com>; Wed, 26 Aug 2015 14:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id J-oKP5ayp8qF for <sidr@ietfa.amsl.com>; Wed, 26 Aug 2015 14:26:27 -0700 (PDT)
Received: from nm4-vm5.access.bullet.mail.bf1.yahoo.com (nm4-vm5.access.bullet.mail.bf1.yahoo.com []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 666AC1B2BDF for <sidr@ietf.org>; Wed, 26 Aug 2015 14:26:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1440624386; bh=ThxMh+rWPcwbjcM3q6ZEiF9u24kx9hXgp8NNjq+r39M=; h=Date:From:To:Subject:From:Subject; b=XpuqWfJxw96LF6AB/H/Dhl0cHUX0qdXIceNeXqT6Ou0o23GQIKiIGCZQSkJS7dHb0dgfrkl43SWC1lz2GcrYgAu2LMfGcWtoiIr/SnGj4lWKQIVsM0DQwbPnZrzuJ6IgxjzVxJ8dmqyWRqmZRO1hp/JYT0j5XklekJ9msXiWhFQW3YKp48TTXuab2JyLJzn3xmNoqR8wPZeenHq0ciBNokqamkwIv2vqVen0xhiEpdrzF0YBBKVhha1+JSkQkW4z2idNiPNf8qYUKZVBip47tdRTHjpSCdSvGyOEXqqA9MQPmjUj2Nnf9L3LwGPaRVAoQeQhy/JTy6DYlms/dSSv3w==
Received: from [] by nm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2015 21:26:26 -0000
Received: from [] by tm5.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2015 21:26:26 -0000
Received: from [] by smtp119.sbc.mail.ne1.yahoo.com with NNFMP; 26 Aug 2015 21:26:26 -0000
X-Yahoo-Newman-Id: 489018.65989.bm@smtp119.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: BgaGT48VM1mUoZ5oqhyqsyfzt9cs7WPP2oTvFxEzsmWz2GE rp.Xo8m3IHX1bKgn72Va.tYkZmRJs6zXX_XZ0bv.FgeNLjlpYS1vA0PvDooH hv1vUOSe5KYKrVmwckSpDwbVb_jTZWakNKWH99iZF6YEZOdzZ0FXK7qRCfPz WamISzFc0BCHiYdHYdmjnhwdX_i8lj.2GnqlkHCRD6HieAkNbP_QikpdnTYX OzYx4W_bd4jRL0MoE2JbaMjDyjCNZVxNbG1LzQqrpi7GneatvgK0ddxtmySa WZ6FIoSEE1bMWJ_vBXeHSdLV6bJu8S.prio9sXWRRicaOmfsJreSVj.054Me R1oHIJhNf3r8dMBlKMj1q8C4PhgZ_NaFi70tNiq14my.ey0MM5zimA8kPfu8 qAB1Dkdj29lWQoyNI0zZH8D21_RLycdLwDR6OjfLFwYR0Jlt4iDu4Yvh61eo mDzge4TUlmuFYwfbI2OLAbiuI2.Xxfx6ncDP1glqRY1GIjZE_dCWajYwBMJw QO4dSSIsTuv_w70olvCEMIGtnDnh2KRJ4K1td9w--
X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708-
Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net []) by uriel.mandelberg.org (Postfix) with ESMTPSA id B20131C6095 for <sidr@ietf.org>; Wed, 26 Aug 2015 17:26:24 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Wed, 26 Aug 2015 17:26:24 -0400
From: David Mandelberg <david@mandelberg.org>
To: sidr@ietf.org
Message-ID: <f12cf36b3ee80798852c3fa13485b50d@mail.mandelberg.org>
X-Sender: david@mandelberg.org
User-Agent: Roundcube Webmail/0.7.2
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/czM-2u8RxM4d4YfovOtodc3rXwc>
Subject: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 26 Aug 2015 21:26:29 -0000

Hi all,

I think I found an issue with draft-ietf-sidr-bgpsec-protocol-13's 
security guarantees. Apologies that I didn't catch this earlier, before 
WGLC ended.

The security guarantee with the issue is in section 7.1, "For each AS 
in the path, a BGPsec speaker authorized by the holder of the AS number 
intentionally chose (in accordance with local policy) to propagate the 
route advertisement to the subsequent AS in the path."

It appears that this guarantee will not always hold. Specifically, if 
two non-adjacent ASes conspire, and they are separated by a sequence of 
ASes that sign path data that they have not verified, then the 
conspiring ASes can violate the guarantee. The ASes that signed path 
data they didn't verify are behaving properly, since the spec says "In 
particular, the BGPsec attribute SHOULD NOT be removed even in the case 
where the BGPsec update message has not been that has not successfully 
validated." I have not yet been able to come up with a practical attack 
that uses this issue to do anything particularly bad, but I am concerned 
that one might exist.

I think this problem might be fixed if we modify the protocol to sign 
all of the preceding signed data (rather than just the immediate, 
previous signature).


David Eric Mandelberg / dseomn