On Sep 25, 2013, at 3:38 PM, Fernando Gont <ferna...@gont.com.ar> wrote:
> 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. Yup, sure. No argument. > 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? -- Nope, I don't think so… There were discussions earlier saying that you don't need to filter in the network, you can just filter at the hosts, and on the device control plane (packets destined to the deviceS) and ignore transit traffic. This is an example of an issue where it is transit traffic that causes the issue. > i.e., the ongoing discussions seem to argue > that folks are filtering fragments, no matter which device they are > directed to. Yes, exactly. I have no way of knowing what all devices / hosts / systems will have buggy implementations, but I know that some will… Often times these bugs are triggered under unusual conditions / less often exercised code paths (if they were not, they would have already been found :-P). I won't know about the vulnerabilities when they are first discovered, and I really don'e want to be in the situation where all of my network is falling over. Even if the bugs are patched as soon as they are discovered (and are not being actively exploited), it takes significant time to regression test / smoke test new code, and significant time to upgrade an entire network. It therefore makes sense to try and limit the exposure / attack surface… W > > > >> 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 > > > -- Eagles soar but a weasel will never get sucked into a jet engine -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
