> -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Bjoern A. Zeeb > Sent: Monday, January 02, 2012 2:11 PM > To: sth...@nethelp.no > Cc: ipv6@ietf.org > Subject: Re: Fragmentation-related security issues > > On 20. Dec 2011, at 11:44 , sth...@nethelp.no wrote: > > Hey, > > I guess I should follow-up on this one. > > >>> 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? > > > > Such traffic absolutely occurs in the wild. I have three reasonably > > busy name servers where this is logged as an error from the ipfw > code, > > e.g. > > and I know of a couple of more people who have seen it and have ways to > trigger it with legitimate servers. I have never tracked things down > in more detail at some point back. > > > > Dec 16 14:04:04 slem kernel: IPFW2: IPV6 - Invalid Fragment Header > > ... > > This is because these name servers haven't (yet) been upgraded to a > > FreeBSD version where bug report kern/145733 haven't been fixed. It > > *is* fixed in newer FreeBSD versions, e.g. 8.2-STABLE. > > And given I am responsible for both committing the original "block" and > the relaxed version let me elaborate a bit on this: > > Contrary to how a lot of people seem to read RFC 2460, especially the > last > paragraph of section 5 (also subject to Florian's Errata 2843),
Errata 2843, http://www.rfc-editor.org/errata_search.php?eid=2843, will break stateless IPv6/IPv4 translation, which was originally defined in RFC2765 and superseded by RFC6145 (published April 2011). > I basically read (in) the past: > > 4.5 "The Fragment header is used by an IPv6 source to send a packet > larger > than would fit in the path MTU to its destination." > > ``You shall not add a fragment header unless you really need to''. > > The only way you must add a fragment header for a packet size below > 1280 is > when it is a packet going to a v4 destination (i.e. say through NAT64 > these > days). How you can track this (if you can) and how you get that > information > is beyond the scope of 2460 but you need to know to be able to. > Otherwise > you shall not. > > This is the reason ipfw originally dropped what people now seem to call > "atomic fragments". > > When I PR started to look at the PR I consulted briefly with Bob and > the > outcome of the short exchange for me was: > > - the "atomic frags" do not seem to hurt in this particular filtering > case > and could possibly be allowed. > - I prepared an errata text suggesting that the text in 4.5 was > clarified > allowing "atomic frags" but discouraging their usage, especially > given > aforementioned errata threatens to remove the paragraph from section > 5, > which is the only real reason people seem to think they are valid. > > > While I still feel that these "atomic frags" should be sent to the > packet > shredder on first sight it seemed to match reality (and especially > operational impact) better. However I left a sysctl for individuals to > control their preference. > > > Another thing on the "atomic frags" I was (partly) shown was that they > seemed > to have a length in the 50 octets size which would even be way below > other > minimums. So I am really not feeling too confident that it's not just > silly > stacks or software bugs and it would really be thrilling if people > could figure > out OS and version and reason why some systems send them. > > > On the entire "fragmentation related security issues" topic, I feel we > are > seriously heading into wrong directions to just more complications > rather than > simplifications. > > The idea of having the fragment offset to stay compatible the way > things worked > in IPv4 certainly was a great idea and has later proven to be a PITA. Agreed, it's a PITA. Fragmentation is a PITA, though, not just this one aspect of it. > What I'd > really like to have is a silly fragment counter 1..n, so no overlapping > possible > (and not just not allowed on paper anymore as that does not remove that > code > to check from the stacks), simple handling of duplicate fragments, and > no > "atomic frags" allowed. > Luckily the fragment header still has a lot of spare space that could > allow > to indicate which scheme is used and dropping a packet unless a bit is > set > (not being set indicating the old scheme) is really easy to implement, > esp. > after a transition period and ripping the old code out would be as well > then;-) > I 'd really not want to add even more complicated house keeping and > stuff > long term. We're sortof in the middle of the IPv6/IPv4 transition now, though.. -d > /bz > > -- > Bjoern A. Zeeb You have to have > visions! > It does not matter how good you are. It matters what good you do! > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
