Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt

[Brian E Carpenter <[e-mail]>]

On 2012-01-24 15:49, Fernando Gont wrote:
> Hi, Brian,
> 
> On 01/23/2012 10:18 PM, Brian E Carpenter wrote:
>> I really don't like the use of the counter in Fernando's proposed algorithm:
>>
>>  Flow Label = counter + F(Source Address, Destination Address, Secret Key)
>>
>> It seems to me that it introduces significant predictability for a malicious
>> observer of the packets leaving a given source.
> 
> As noted off-list, I personally think that rather than proposing a
> single algorithm, we should describe a set of algorithms, a la RFC 6056
> -- as there a number of tradeoffs-
> 
> 
>> Effectively the equivalent algorithm in RFC 6437 is
>>
>>  Flow Label = F(Srce Addr, Dest Addr, Protocol #, Srce Port, Dest Port, Secret Key)
>>
>> which is less predictable, even if the port number is not randomized.
> 
> If the attacker can predict the algorithm in
> draft-gont-6man-flowlabel-security-02.txt, he knows the IPv6 addresses
> of the two endpoints, and the secret key. So I don't see what'd be the
> real improvement of this variant.

With your proposal, after observing label N, you can (with reasonable probability)
predict label N+1; you don't need this to be 100% accurate to cause trouble.

> 
> That said, it also seems technically incorrect: If you expect the
> resulting (src ip, dst ip, flow label) to be unique, then introducing
> the port numbers in F() could lead to unnecessary collisions.

Sure, as noted in the new RFC: a statistically small rate of collisions
does not significantly bias load sharing.

> 
> Yes, now that the requirement of uniqueness has been relaxed, collisions
> are less important... but I don't see what's the "gain" of the modified
> expression you suggest above.

That label 4502 will essentially never be followed by label 4503,
which your method explictly allows (your Table 1). Include the counter in
the input to the hash function and this problem disappears.

Regards
     Brian