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

[David Mandelberg <[e-mail]>]

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 
signer.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/