Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11

["Keyur Patel (keyupate)" <[e-mail]>]

Hi David,


On 2/10/15, 1:48 PM, "David Mandelberg" <[e-mail]> wrote:

>All, while coming up with the example below, I realized another issue.
>The structure in 4.1 doesn't include an Address Family Identifier.
>Unless I missed something, this means that a signature for 1.2.0.0/16
>would be exactly the same as a signature for 102::/16. This would be a
>much more practical attack than the one I originally though of.


But, isn¹t this issue covered by origin-AS validation?

Regards,
Keyur



>
>Michael, response to your comment is below.
>
>On 02/10/2015 12:09 PM, Michael Baer wrote:
>> I don't believe this is a problem.  The signature is calculated by
>> creating a digest of the data and then creating a signature from that
>> digest.  I'm definitely not a cryptography expert, but my understanding
>> of digest functions generally is that with even slightly differing
>> input, the resulting set of bits should be completely different.
>> Assuming the digest function chosen is not flawed, there shouldn't be a
>> set of bits from the digest of 4.1 that could be used to successfully
>> replace the digest of 4.2, except by chance.
>
>You're right about digest algorithms being highly sensitive to changes
>in the input, but the issue I described is when the two inputs are
>equal, not just similar. For example, if a router signed the below
>values in the structure from 4.2:
>
>Target AS Number = 0x01020304
>Origin AS Number = 0x05060708
>pCount = 0x01
>Flags = 0x00
>Most Recent Sig Field = 0x00700102030405060708090a0b0c0d0e (See Sriram's
>email for why this would never actually happen with the current
>algorithm suite's signature length.)
>
>Then the router signed the digest of the bytes
>0x0102030405060708010000700102030405060708090a0b0c0d0e. However, these
>exact same bytes could appear to have come from the structure in 4.1
>with these values:
>
>Target AS Number = 0x01020304
>Origin AS Number = 0x05060708
>pCount = 0x01
>Flags = 0x00
>Algorithm Suite Id = 0x00
>NLRI Length = 0x70 (112 bits = 14 bytes)
>NLRI Prefix = 0x0102030405060708090a0b0c0d0e
>
>Note that the first 16 bits of 4.2's Most Recent Sig Field can't be any
>values. The first 8 have to match the Algorithm Suite ID (1 possible
>value). The next 8 have to be a valid number of bits for the number of
>bytes in the prefix (8 possible values). This means that there's only a
>2^-13 chance that a single random Most Recent Sig Field of the
>appropriate length could be reinterpreted successfully. However, with
>more than 2^13 signatures floating around the Internet, that's not good
>odds.
>
>-- 
>David Eric Mandelberg / dseomn
>http://david.mandelberg.org/
>