[ipv6hackers] Implications of IPv6 on network firewalls

[Fernando Gont]

On 11/24/2011 06:42 PM, Owen DeLong wrote:
>>> Nor would I think that blocking PMTU-D is basic functionality in IPv6.
>>
>> Huh? Breaking PMTUD is not "basic functionality" in IPv4. And it happens
>> in the IPv4 in the same way it *also* happens in IPv6 already.
> 
> Yes, but, it's far more crippling in IPv6 because everyone expects to have
> to work around it in IPv4. Hopefully in IPv6 we can avoid that.

I've seen that problem in IPv6 already. So expecting IPv6 to work (given
our IPv4 experience, and given that we've already implemented black-hole
detection) is simply asking for trouble.



>> Prettending that IPv6 provides something that IPv4 does not is has been
>> an IPv6 selling argument that should be tagged as "failure" with no
>> shame. "96 more bits, no magic".
> 
> I'm not trying to use the differences as a selling point in IPv6. 

I didn't mean it was *your* selling point. But it has been widely-used
way too much, already.


> I'm trying to point
> out that crippling IPv6 deployments with IPv4-think is not a good idea.

Actually, I'd hope that we'd apply our IPv4-lessons to IPv6. The sort of
bugs/vulnerabilities I've seen in v6 implementations seem to indicate
that in most cases, we haven't (including RHT0, etc.).


> The idea that there is absolute parity between what is basic functionality in
> IPv4 and IPv6 is nonsensical at best.

Not sure what you mean...


>>> My assertion is that within 10 years, multicast routing in IPv6 will be much
>>> more widespread than it is today. 
>>
>> My assertion is that I wouldn't increase the attack exposure for what
>> you *think/*expect* could be used/widely_deployed in ten years.
> 
> I don't see MLDv2 or MLD snooping as an increase in the attack exposure,
> so, perhaps we disagree here.

Sorry, I should have said "attack surface" rather than "attack
exposure". (more complexity, more probability to f* up)



>>>> *My* recommendation is to run MLDv1 (as opposed to MLDv2), and *not* to
>>>> disable MLD completely. (FWIW, the node requirements RFC does not even
>>>> mandate MLDv2, but a lightwight version of it).
>>>
>>> MLDv2 carries significant advantages if you are routing multicast across multiple
>>> segments.
>>
>> Which you usually aren't.
> 
> Speak for yourself. In IPv6, this will very likely be the rule and not the exception.

I used present tense, you used future tense. There lies our "disagreement".


>>>>> It may not be the case for many networks today, but, I certainly hope that will
>>>>> change going forward in IPv6. Especially when you consider that case b isn't
>>>>> limited to global multicast. It's actually applicable to any multicast scope
>>>>> larger than link. (Multicast address ≥ff02::/16).
>>>>
>>>> My take is that if you have an application that needs it, deploy it. If
>>>> not, don't.
>>>
>>> My point is that the number of networks that have need for it is likely to radically
>>> increase in the moderately near term future.
>>
>> At which point which could radically increase the deployment of MLDv2,
>> if we really need it.
> 
> That's rather circular logic, isn't it?

It's rather KISS principle, I'd say.... which security-wise is usually
your friend.




>>>> Yep, but usually you don't want to get hacked today for what you might
>>>> be using in the future. That said, I argued in favor of MLDv1 (as
>>>> opposed to MLDv2), and did *not* argue in favor of disabling MLD completely.
>>>
>>> I don't see MLDv2 making you more likely to get hacked than MLDv1.
>>
>> I suggest:
>>
>> 1) Take a look at the MLDv1 spec, and then take a look at the MLDv2 spec.
>> 2) If you don't see a huge difference in terms of complexity, take a
>> nap, and go back to step one.
> 
> Of course there's a difference in complexity.

hence there's a difference in the probability of having vulnerable
implementations.



>> Note: given the number of implementations that got much more basic stuff
>> (ND, etc) wrong, it's very realistic to expect that they f* up with MLDv2.
>>
> 
> Sigh... When you would like to discuss fact and not FUD, let me know.

Talk to Microsoft, FreeBSD and others, and then come back and tell me
whether what I said was FUD, or whether I was referring to stuff that
has been affecting vendors for more than a year.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492