On 01/27/2012 07:13 PM, Fernando Gont wrote: > On 01/27/2012 06:08 PM, Philip Homburg wrote: >>>> So any system that is too busy to keep destination cache entries for a long >>>> time will effectively send fragments with a random number. >>> >>> There are always tradeoffs in the IP-ID generation algorithms. If you >>> don't like any of the forementioned approaches, you may have a set of >>> counters (say, 1024, 2048, or 65K, if you will), using an approach >>> similar to that of algorithm 2 in my flowlabel I-D. >> >> I'm not really keeping track of flowlabel stuff. Do you have a more specific >> reference? draft-gont-6man-flowlabel-security-02 doesn't seem to have an >> algorithm 2. And I couldn't find any other flowlabel draft with your name on >> it. > > Please see pages 9-11 of > <http://tools.ietf.org/id/draft-gont-6man-flowlabel-security-02.txt>. > Page 11 contains a sample output of the double-hash algorithm, which you > can compare with the sample output of algorithm #1 in page 9. > > If you wanted to keep say, 1K or 65K counters (as a tradeoff between > security and "avoiding excessive state"), you could select the FL as:
Let me clarify this a bit, and add a few more bits... With the hash-based approach, you essentially have two elements: the hash function, and the counter. The hash function adds the randomness, while the counter produces the monotonically increasing sequence. >From a FL frequency-reuse perspective, you'd have one counter per destination, such that if flow #1 gets, say, FL 1000, flow #2 will get 1001, and so on. This approach is possible to implement if you keep the counter in the Destinations Cache (which is the obvious place to store it, since there's one Destinations Cache entry per destination IPv6 address). On the other extreme, you might have a single global counter (which you'd keep somewhere in the IPv6 code, but not in any particular Destination Cache entry. The two problems with this approach are: 1) If you keep a single counter, an attacker could possibly count the number of new flaws established by a target system 2) Some FL values will be unnecessarily skipped (see the sample output for algorithm #1 in draft-gont-6man-flowlabel-security) A middle-ground would be to have an array of counters (neither one global counter, nor one counter per destination). -- This is algorithm #2 in the flowlabel-security I-D. With this algorithm, even if you were to discard entries from the Destinations Cache, it would still work (the counters are kept in the IPv6 code, but not in any Destinations Cache entry -- and the counters are shared between different flows). 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. Hope this one helps to clarify things a bit... Thanks! Best regards, -- 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 --------------------------------------------------------------------
