Hi, Ray, >>> /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?
No, I don't (as long as v6 implementations implement this spec). Atomic fragments, when processed as specified in draft-ietf-6man-ipv6-atomic-fragments-03.txt, behave exactly as unfragmented traffic (modulo the need to remove the Frag header, of course). > 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? Exactly. The problem is that some implementations try to reassemble the atomic fragments with other existing fragments -- i.e., the flaw is in the reassembly process, rather than in the atomic fragments themselves. > Given the potential adverse effects on middleware boxes such as > firewalls, I'm thinking you consider them harmful per se. Of all the fragmentation cases, the atomic fragment case is the last I would worry about. (the worst being draft-ietf-6man-oversized-header-chain). That said, v6 fragmentation as a whole is probably going to have a very hard time, unless we were to enforce very tight constraints (e.g. "the whole header chain should be present in the first, say, 512 bytes") -- but at the time this wg did not even buy the requirement of the header chain to be in the first 1280 bytes (that's how we gor to the current requirement of "the complete header chain must be present in the first fragment). >>> 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, Atomic fragments are not harmful per-se, since they can be processes as unfragmented traffic. *Real* fragmented traffic could be deemed as harmful, though. (or as "unlikely to survive the Internet", if you prefer ;-) ). > 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? What should be done is validate ICMPv6 PTB according to: 1) the embedded payload, and, 2) progress on the connection (actually, you're probably good enough even doing just the later). The idea behind "2)" is simple: If you get an ICMPv6 PTB, it's because your packets are being dropped (as a consequence of using a packet size that is too large). So if the ICMPv6 PTB refers to e.g. a TCP connection, you could just queue the received ICMPv6 PTB, and only honour it when/if theres a TCP timeout at the TCP layer. FWIW: 1) I implemented this on OpenBSD years ago, and the patch was ported to NetBSD -- so both OSes have been employing this for years. 2) This approach is documented in RFC5927. Now, if you wonder how things are the way they are specs-wise, my take is: 1) RFC5927 went informational because it was done in TCP in the 2004- timeframe. (was plagged by neverending nitpicking non-sensiscal discussions which were out of touch with running code). 2) RFC4443 somehow assumed that RFC1122 had to apply to ICMPv6 in the same way it applied to ICMP(v4) -- hence the validation of ICMPv6 PTB was not included as mandatory (fair enough... they either had to downref RFC5927, or incorporate half of that RFC into RFC4443) So, with that state of affairs with ICMPv6 PTB validation, sloppy processing of atomic-fragments (which draft-ietf-6man-ipv6-atomic-fragments-03.txt fixes), and sloppy Frag ID generators in many iplementations (and we at the ietf/a wg not doing something about it, yet), we have v6 implementations that...mm.. suck big time :-) in this area. > 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. See Section 4 and Section 7 of RFC 5927. One might argue that this wg might want to produce some version of RFC 5927 for ICMPv6, which doesn't focus on any specific upper-layer protocol (i.e., doesn't focus on TCP attacks). Thoughts? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
