[ipv6hackers] Implications of IPv6 on network firewalls

[Fernando Gont]

On 11/24/2011 05:30 PM, Owen DeLong wrote:
>>> I guess that depends on your definition of basic functionality.
>>>
>>> In IPv6, IPSEC is implemented in extension headers. I would consider that
>>> basic functionality.
>>
>> I consider "basic functionality" that which parallels what we currently
>> do with IPv4.
> 
> That's absurd. I would never think that NAT is basic functionality in IPv6.

Yep, I should have said "modulo NAT". But, anyway, take a "reality
pill", and be prepared for some IPv6 NAT deployment. (Not to mention the
IPv6 NAT err.. sorry.. "NPT" that was standardized by the IETF).

(Note that I *like* it... but "not liking it" won't make it go away).



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



> Nor would I consider it reasonable in IPv6 to do half a dozen other things
> that are common behavior in IPv6.
> 
> The definition of basic functionality in IPv6 is different from IPv4. Pretending
> that it is not gets in the way of deploying IPv6 rationally.

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



>>>> a) Your local network is supported by an MLD-snooping switch, or,
>>>> b) You're using "global" multicast (as opposed to link-local multicast)
>>>
>>> Both of which I would consider basic functionality in IPv6.
>>
>> Is your assessment that most networks have deployed e.g. multicast
>> routing protocols?
> 
> 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.



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


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


>>>> So my advice would be that, rather than disabling MLD completely, you
>>>> use MLDv1 (instead of MLDv2), and use MLDv2 only if you're expecting to
>>>> use non-local multicast.
>>>
>>> My advice is that most people should be expecting to use non-local multicast
>>> in their futures.
>>
>> 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.

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.

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