On 09/25/2013 02:32 PM, Warren Kumari wrote: >> >> Unless you have a very sloppy IPv6 implementation (that does not >> enforce limits on the maximum number of queued fragments), an >> attacker will only be able to DoS communication instances (e.g. TCP >> connections) that employ fragmentation. Such fragmentation attacks >> won't have any effect on non-fragmented traffic. > > > http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-01 Section > 2.1.4 says, amongst other things: > > Another incentive toward dropping of fragments is the > disproportionate number of software errors still being encountered > in fragment processing. Since this code is exercised less > frequently than the rest of the stack, bugs remain longer in the code > before they are detected. Some of these software errors can > introduce vulnerabilities subject to exploitation.
I must admit I have not yet read Tom's draft, and I'm not necessarily arguing that there are no buggy implementations of IPv6 fragment reassembly. But I stand by my statement that if an implementation cannot properly handle IPv6 fragment reassembly (which is essentially the same as IPv4 fragment reassembly, with a long history of bugs and known fixes), the implementation is immature. My take is that, unfortunately, many IPv6 implementations are immature -- and I'm not talking just about fragment reassembly, but about IPv6 implementations in general. If one looks carefully at the kind of bugs being found in them (whether that's IPv6 fragment reassembly or IPv6 NC implementation), it's not difficult to assess that at least some of them are as mature as some IPv4 implementations in the mid/late 90's. So if we're going to cut down/filter anything with buggy implementations, we might find our self more than we might want to (so to speak ;-) ). That said, I understand an operator filtering fragments to address a current problem it has. But let's call a lemon a lemon: the problem is not IPv6 fragmentation per se, but rather the underlying buggy implementation. There are a number of reason why the current situation may be what it is: 1) Different folks working on the IPv6 code than the folks who worked on the IPv4 code at the time. 2) We not simply having understood the lessons from the IPv4 world. 3) Lack of guidance about how to avoid known implementation flaws. 4) A mix of th above. FWIW, my take is that the one *we* can tackle is "3", and that has been the spirit of some of the documents I've authored. > There has also been discussion that for things like routers you can > just do X to protect the device control plane / only care about > traffic directed to the device itself. Agreed. But, isn't that orthogonal to the discussion regarding filtering fragments altogether? -- i.e., the ongoing discussions seem to argue that folks are filtering fragments, no matter which device they are directed to. > Anyway, I figured folk might find this interesting: > http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130925-ipv6vfr I did find the pointer interesting (thanks!). If folks know more about this vulnerability, please feel free to share. (e.g., is i an IPv6 version of the Ping o' Death?). Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
