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

David Mandelberg <> Wed, 09 September 2015 00:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1EA161B3823 for <>; Tue, 8 Sep 2015 17:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TDoWkzl5m1_v for <>; Tue, 8 Sep 2015 17:05:19 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 928C51B3822 for <>; Tue, 8 Sep 2015 17:05:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1441757119; bh=K8f2LrT9Z9l+wnpln5lzbXSVMpS6yqldEBEqWvGvsVk=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=HW+t86K8zrV3Gt3obp6ffGE/Q61W2GXRzLgGOk3sanqIuaeTAVIJYaZJMXKnZwysw0r2Fwy17rz+1dK4qqfnrAAxc/zPtH+EjUrzbZK6GH5+W3lHfrbkyuHRpsfFYqq2KqVlqFe06v+peIqYCgxpGitr1AN1Ld58u6ea+3J5QI6Z8P6i4vXJfxpF1seFzquN+9K676RiLugKBXFJFclQbJ/pNg5C8aWJ+K5KepRrD9dYmfd0f0FS1aIZjtw3WuQJdI9jkHPa0ZglJUGJPlhyIBLc9DySNKrZVK4r1d7juoR3BMj0aiS0t+6WTmQ0y6yNiiTlrM9eDp6IxoCNsN8CqA==
Received: from [] by with NNFMP; 09 Sep 2015 00:05:19 -0000
Received: from [] by with NNFMP; 09 Sep 2015 00:05:18 -0000
Received: from [] by with NNFMP; 09 Sep 2015 00:05:18 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: IV5DRywVM1lMbU8zSG8UFoXFIDChXjMEP.3gCqL9lDEMYRH qAo3ViZPnJxHTMx6xF2cVfUOUnVJobJK85H9vL.HCuRZ0Ud2PVb5sKqMsX99 jDjUipPxWQF6XfxcW0xpsQvlvrNflSX9BeEELT7P3cuY8PsoiD3CSPUiUP5f xvvx43MMl6TE9.bsMxF9I_q4qJdT7P8T.qc8ZUK5GYlzrlUy7.Au3c8emc5r GzvByccnVWnhGGav8yKQa4SdZ5vgzAi3.Pkm4tPhg66gHrO8G2WWMNVRsXU_ .j0_dtCHOXOUHzwUPHmhxkA88d5TmCKPygNWBtZXi8QF1IRKuLsr4sNceT2F pGcKYJUD4Brqdao1VYviY1M3XBUdWbswRPpzQX_VeijuRih8UGzWk4pJfAlQ NBCg5otTYiub55173OFvpZkCuOWx6_fRa6rEAkggQ_3NCkgAyWIpdPUtkgMN XcUTcurvygbDozvgB1Syq7YqieikgnmvHIx3y3QK.tjX2brtEsCz1p8orUMf 8YbewbJr0RKSPPUdCkaKKJVmRy8xOwzQ9zuTkmg--
X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708-
Received: from ( []) by (Postfix) with ESMTPSA id D52F61C6095 for <>; Tue, 8 Sep 2015 20:05:16 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Tue, 08 Sep 2015 20:05:16 -0400
From: David Mandelberg <>
In-Reply-To: <>
References: <> <>
Message-ID: <>
User-Agent: Roundcube Webmail/0.7.2
Archived-At: <>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Sep 2015 00:05:21 -0000

On 2015-08-26 22:49, Rob Austein wrote:
> At Wed, 26 Aug 2015 17:26:24 -0400, David Mandelberg wrote:
> ...
>> 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).
> Agreed, assuming this means adding the (theoretically invariant)
> fields from the data to be signed in section 4.1 to the data to be
> signed in section 4.2.
> Taking "Origin AS Number" in section 4.1 as equivalent to "Signer's 
> AS
> Number" in section 4.2, this leaves the algorithm suite identifier,
> the AFI, the SAFI, and the NLRI to be added to the data to be signed
> in section 4.2.  I doubt that there's any practical attack based on
> fiddling with the algorithm suite identifier (I'd expect any games
> there to cause validation failure, end of story), but maybe somebody
> has a more twisted imagination than mine, and, given that the
> algorithm suite ID is one byte long, I don't think it's worth trying
> to optimize that byte out of the section 4.2 signature.
> Presumably we want to keep the existing signature chaining, so I
> wouldn't remove anything from the data to be signed in section 4.2,
> just add the fields that are currently only present in section 4.1.
> David, if this is consistent with what you meant, cool, if not, say 
> on.

It is not consistent with what I meant, so I'll be more explicit about 
what I meant. I meant to remove the signature chaining, and have each AS 
sign the data that is currently covered by signature chaining. I.e., 
each AS (origin or intermediary) would sign the same data structure 
(with different, but related, data in the structure):

Target AS Number (4 octets)
AS Count (4 octets)
<AS Count> instances of:
     AS Number (4 octets)
<AS Count> instances of:
     pCount (1 octet)
     Flags (1 octet)
Algorithm Suite Id. (1 octet)
AFI (2 octets)
SAFI (1 octet)
NLRI (variable)

The sequence of AS Numbers is split from the sequence of (pCount, 
Flags) to preserve alignment, but the two sequences form a single 
logical sequence of (AS Number, pCount, Flags). (This could also be 
represented with 2 bytes of padding per AS, without 4-byte alignment, or 
with 3 parallel sequences; I don't really care which.) Regardless of the 
logical sequence's representation, the first (AS Number, pCount, Flags) 
entry corresponds to (Origin AS Number, pCount, Flags) from section 4.1. 
Subsequent entries correspond to (Signer's AS Number, pCount, Flags) 
from section 4.2, in order from the origin's next hop to the current 

David Eric Mandelberg / dseomn