I have read this draft and support it, as it provides a valuable security update to IPv6.
Nits: s/A received "atomic fragments" should be "reassembled" from the contents of that sole fragment./ Each received "atomic fragment" should be individually "reassembled" from the contents of that sole fragment./ /Many implementations fail to perform validation checks on the received ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and [RFC5927]./ Although RFC4443 is a standard track document, none of the language in Section 5.2 contains RFC2119 keywords. RFC5927 is informational. You may consider this a separate but related issue to atomic fragments, but does validation checking of ICMPv6 messages need to be addressed further in your current ID? I think your current ID stands alone whether these validation checks are performed or not. Are we then really justified in chastising implementors who ignore these recommendations by somehow implying they've 'failed'? Suggested alternative s/Many implementations fail to/Many implementations do not/ regards, RayH The IESG wrote: > The IESG has received a request from the IPv6 Maintenance WG (6man) to > consider the following document: > - 'Processing of IPv6 "atomic" fragments' > <draft-ietf-6man-ipv6-atomic-fragments-03.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > i...@ietf.org mailing lists by 2013-01-16. Exceptionally, comments may be > sent to i...@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > The IPv6 specification allows packets to contain a Fragment Header > without the packet being actually fragmented into multiple pieces (we > refer to these packets as "atomic fragments"). 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 some implementations as > "fragmented traffic". Thus, by forging ICMPv6 "Packet Too Big" error > messages an attacker can cause hosts to employ "atomic fragments", > and then 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 fragmentation-based attack > vectors against traffic employing "atomic fragments" are completely > eliminated. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
