inline. > Fernando Gont <mailto:fg...@si6networks.com> > 5 January 2013 23:55 > Hi, Ray, > > Thanks so much for your feedback! Please find my comments in-line... > > > On 01/05/2013 07:24 AM, Ray Hunter wrote: >> I have read this draft and support it, as it provides a valuable >> security update to IPv6. > > Thanks! > > >> 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./ > > Will apply this change to the next rev. > Ack. > >> /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? > > What I've tried to note with the above comment is how trivial it is to > trigger the use of IPv6 atomic fragments. > Agreed it's trivial.
Do you consider the existence of atomic fragments to be harmful per se? Or just the fact that they can adversely affect re-assembly at a host, and thus can be used as an attack vector on the destination host? Given the potential adverse effects on middleware boxes such as firewalls, I'm thinking you consider them harmful per se. >> I think your current ID stands alone whether these validation checks are >> performed or not. > > Agreed. But what I've tried to stress is that it is trivial to make any > connection employ atomic fragments -- hence it's not that the only > target of atomic-fragment attacks are those connections already employed > atomic fragments or fragmentation: it's trivial to trigger the use of > such fragments, and then perform a fragmentation-based attack... > Understood. But if we consider atomic fragments to be harmful per se, what concrete advice can we give implementors in a SHOULD clause in this ID on how to process received ICMPv6 Packet Too Big messages in order to make triggering atomic fragments less trivial? If we haven't got any advice on how to stop them being triggered, we can't really moan that it's trivial to trigger them. PMTUD is currently pretty fundamental for correct operation of IPv6. Re-reading RFC1981, it's tough to see what more anyone can sensibly do in a lightweight implementation. >> 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/ > > I'm fine with your proposed text. Should the resulting text then be: > > "Many implementations do not perform validation checks on the received > ICMPv6 error messages as recommended in Section 5.2 of [RFC4443] and > [RFC5927]" Yes, the version above. > ? > > Or can this be read as "they do not perform these validation checks, as > RFC4443 and RFC5927 recommend *not* to do so"? (English as second > language here) > > Thanks! > > Best regards, > Ray Hunter <mailto:v6...@globis.net> > 5 January 2013 11:24 > 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 > > ------------------------------------------------------------------------ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
