On 01/24/2012 12:04 AM, Brian E Carpenter wrote: >>> 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.
If the attacker can *observe* labels, why would he bother to "guess" them? >> 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. Well, one should clearly state the threat model: If you're thinking about off-path attackers, then the fact that flow labels corresponding to the same set (src IP, dst IP) will be incremental is irrelevant (the attacker knows that the Flow-IDs are a monotonically-increasing sequence, but does not know where that sequence is). If the threat model is that we're concerned about on-path attacker, then: game over: the attacker will always know the FlowLabel values, regardless of the algorithm that we use. That said, and as noted above, it is interesting to offer alternatives. For example, if you implement the hash-based approach described in my I-D, the first flow label is "expensive", but the rest are really cheap: e.g., just add the counter to the value of F() that you have recorded in the destinations cache. OTOH, randomizing every FlowLabel might be more expensive. I personally think that rather than enforcing a single algorithm, we should offer a set of possible algorithms, and discuss the tradeoffs -- after all, not all implementations need to agree on the same algorithm. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
