[ipv6hackers] Implications of IPv6 on network firewalls

[Owen DeLong]

On Nov 24, 2011, at 3:54 PM, Fernando Gont wrote:

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

Agreed.

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

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

I'm not trying to use the differences as a selling point in IPv6. I'm trying to point
out that crippling IPv6 deployments with IPv4-think is not a good idea.

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

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

I don't see MLDv2 or MLD snooping as an increase in the attack exposure,
so, perhaps we disagree here.

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

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

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

Of course there's a difference in complexity.

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

Owen