On 20. Dec 2011, at 11:44 , [email protected] 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), 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. 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. /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 [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
