On 09/26/2013 02:02 PM, Warren Kumari wrote:
>>> 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.

Oh, I know see your point. And... yes it's a... difficult situation.

I should say, though, that implementations have been found to have
trouble to parse extension headers, and probably also malformed packets
-- that's what I was meaning: implementations are immature in general.



>> 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).

My personal take (based on personal experience), is that there is a lot
to be found. :-)  -- and when it comes to vendor's response, some
desktop OS' vendors thing that e.g. a DoS vector based on NCE exhaustion
is not something they should be addressing. -- i.e., the future doesn't
look that bright, unfortunately.



> 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…

I understand. At the end of the day, the folk running the network needs
some pragmatism, more than a "what the world should be, but isn't" rant. :-)

Cheers,
-- 
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
--------------------------------------------------------------------

Reply via email to