On 01/29/2012 04:46 PM, Brian E Carpenter wrote: >> A similar approach could be implemented for the generation of >> Fragment Identification values. >> >> Thus, even if you needed to empty the Destinations Cache, you'd >> still have the benefit that the algorithm: * Makes the IDs (either >> FL or Fragment ID) difficult to guess by an off-path attacker * >> Minimize the reuse frequency of the corresponding IDs. > > I think it's a mistake to draw a strong analogy between the flow > label and the fragment ID.
Well, both of the algorithms I was describing had the same goals -- hence the comment. > When the flow label is used for any form of load distribution, it > really doesn't matter if occasional flows share the same label > value, as long as this is statistially rare. It just means that the > two flows might happen to follow the same path - so what? Thus, a > completely stateless algorithm is fine and the counter brings no > benefit. I don't quite understand why you tag the hash based-algorithm as stateful, or, put another way, why you don't tag as "stateful" your algorithm as well. The second variant in draft-gont-6man-flowlabel-security requires a set of e.g. 256 (or more) system-wide counters. That's it. If you flag the algorithm as stateful just because of that, you may as well tag any algorithm that uses a PRNG as "stateful", because the PRNG usually implies internal state, too. That said, picking a random number is seen by some as "expensive" (as opposed to just increment a counter). So there you have a trade-off, too. (e.g., the hash-based approach may be cheaper CPU-wise). Thanks, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
