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: Flow Label = table[G(Source Address, Destination Address, Secret Key1)] and use the following pseudo code: /* Initialization at system boot time */ for(i = 0; i < TABLE_LENGTH; i++) table[i] = random(); /* Flow Label selection function */ index = G(local_IP, remote_IP, secret_key2); count = 1048576; do { flowlabel = table[index] % 1048576; table[index]++; if(three-tuple is unique) return flowlabel; count--; } while (count > 0); /* Set the Flow Label to 0 if there is no unused Flow Label */ return 0; You could even include only the remote prefix (rather than the full remote IPv6 address) in the hash function, such that you can reduce the attacker chances of searching the entire "counter" space. >> I'd argue that the scenario that you're describing, while not uncommon, >> probably does not apply for the general case. So it would not be unfair >> to have, at least for those scenarios, some specialized policy such as >> the one described above. > > PMTUD is just a mess. > > For IPv4, either you have an mtu of 1500 or you use mss clamping. Relying on > pmtud gives a bad user experience. Since IPv4 MTUs can be as low as 296, and since I doubt you clamp the MSS to such a low value, you still rely on PMTUD. (Hopefully you system imlements PMTUD + PLPMTUD for blackhole detection). > For IPv6, the situation is not any better. But there is new option, servers > may simply set their mtu to 1280 and no more pmtu problems. > > PMTU blackhole detection is surprisingly uncommon. It is implemented in OpenBSD, I recall it bein implemented in Windows... so I don't think it is uncommon. > IPv6 also lacks NAT, Well, it doesn't: <http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html> >> Not sure what you mean. As long as one packet gets lost, the IP ID space >> will get trashed. If another packet reuses the same ID, then it's very >> likely that the reassembly process will fail, and it may be even >> possible that some of the legitimate fragments remain in the fragment >> reassembly buffer, trashing the IP ID space. > > With random IDs, every packet that arrives has a 1/65536 chance of colliding > with a packet that is awaiting reassembly. Total chance depends on the > reassembly timeout and the packets rate. And most importantly, the loss rate. Add a bad combination of reassembly timeout + loss rate + data rate, and you're toast. See e.g. <http://www.rfc-editor.org/rfc/rfc4963.txt> >>> So, as far as I can tell, the risk that something goes wrong if you don't se >> nd >>> the fragment header is something very close to zero. The chance that sending >>> the fragment header is actually beneficial is also very small. >> >> So... you're essentially relying on guesswork because: >> >> a) You consider that requiring the translator to send an ICMPv6 PTB is >> way too much, (which is already a requirement for PMTUD), and, > > I don't particularly care about the translators. There are other sources of this traffic. It has been reported on the list that this traffic has been found on the wild. Since such traffic is already there, you need to support atomic fragments. And if you're going to support it (which you should), the then IMO the most sensible way to do it is as indicated in the atomic fragments I-D. >> b) You consider that processing atomic fragments as described in >> draft-gont-6man-ipv6-atomic-fragment is... what? > > One option is that hosts behind such translators will have mss clamping > because > PMTU doesn't work anyhow. This is very likely, because you need that on the > current IPv4 network. As noted above: 1) Why value would you use for clamping? (if it's anything >296, then it doesn't relieve you from relying on PMTUD) 2) As noted, there are other sources of atomic fragments. > Effectively, we are saying that it was an enormous mistake to not include > fragmentation in the IPv6 header and that we removed it from the routers. That's a completely different discussion. Me, I'm just trying to improve what we have (which does not necessarily mean that I love the current state of affairs). Even if you wanted to, it's probably way too late to start from a clean slate. 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 --------------------------------------------------------------------
