Hello, Florian, On 12/20/2011 07:00 AM, Florian Weimer wrote: >> ---- cut here ---- >> IPv6 allows packets to contain a Fragment Header, without the packet >> being actually fragmented into multiple pieces. Such packets >> typically result from hosts that have received an ICMPv6 "Packet Too >> Big" error message that advertises a "Next-Hop MTU" smaller than 1280 >> bytes, and are currently processed by hosts as "fragmented >> traffic". > > Does such traffic actually occur in the wild, or would it only be used > in attacks?
They have been seen in the wild. That aside, I don't know whether e.g. NAT64 or the like used this (.e.g, whether they are used for transition technologies as envisioned in RFC 2460). However, it might also be the case that such "atomic fragments" are generated when communicating through networks that do not really have a MTU >= 1280. In such scenarios there might be some for of gateway that sends the ICMPv6 PTB advertising a Next-Hop MTU smaller than 1280, thus resulting in atomic fragments (such that it's easier for the "gateway" to fragment the IPv6 packets). BTW, I seem to recall that when doing some testing, Linux doesn't react to ICMPv6 PTB < 1280 as indicated in the specs. Can you confirm this? ANd, if so, if this a bug, or "intented" behavior? >> By forging ICMPv6 "Packet Too Big" error messages an attacker can >> cause hosts to employ "atomic fragments", and the launch any >> fragmentation-based attacks against such traffic. This document >> discusses the generation of the aforementioned "atomic fragments", >> the corresponding security implications, and formally updates RFC >> 2460 and RFC 5722 such that the attack vector based on "atomic >> fragments" is completely eliminated. > > My feeling is that such atomic fragments should be dropped from the > protocol. There seems to be stuff relying on them.... That aside, there's the proposal by Mark Andrews which would add yet another use case for these atomic fragments. > Per previous WG discussion, when reassembling such atomic fragments, > IPv6 implementations must ignore the upper 16 bits of the fragment ID > (otherwise the stateless v4/v6 gateways won't work). Clearly, this is > not desirable. I may be missing something, but: when sending from the v6 side to the v4 side, we can probably assume that only the low order 16 bits of the Fragment Identification field are used (whether you set the rest of the bits or not, it doesn't matter -- particularly if the Fragment Identification for each destination is a linear function (as e.g. in the algorithm proposed in the I-D)). That is, you don't really need to do anything special with the high order bits. Am I missing something? Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
