> -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Florian Weimer > Sent: Tuesday, December 20, 2011 2:01 AM > To: Fernando Gont > Cc: ipv6@ietf.org > Subject: Re: Fragmentation-related security issues > > * Fernando Gont: > > > The second I-D is entitled 'Processing of IPv6 "atomic" fragments' > > (http://tools.ietf.org/id/draft-gont-6man-ipv6-atomic-fragments- > 00.txt). > > Its abstract is: > > > > ---- 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? > > > 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. > > 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).
Stateless IPv6/IPv4 translators set the upper 16 bits to 0 when translating from IPv4 to IPv6; IPv6 hosts do not need to ignore the upper 16 bits of the Identification field. http://tools.ietf.org/html/rfc6145#section-4.1, "Translating IPv4 Headers into IPv6 Headers", ... Identification: The low-order 16 bits copied from the Identification field in the IPv4 header. The high-order 16 bits set to zero. -d > Clearly, this is > not desirable. > > -- > Florian Weimer <fwei...@bfk.de> > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstraße 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
