[ipv6hackers] "Stick to limited IPv6 deployments, businesses warned"

[Owen DeLong]

On Aug 23, 2012, at 06:55 , Jim Small <jim.small at cdw.com> wrote:

> Marc,
> 
>>> "If some network engineer says 'let's make a global company all
>>> IPv6', I would fire that guy, because it costs millions and the
>>> benefit is zero."
>> 
>> several things in the article wrong and I asked to review the article
>> before it goes online (he told me their technical security article
>> writer left a week ago), that statemnt is mine however :-)
>> 
>> what I am talking about is enabling IPv6 internally. There is no need
>> for this. no business need. So anybody wanting to do this without
>> necessity should be fired.
> 
> I see it differently.  While the urgency is for Internet connectivity and not necessarily for internal use, if the Internet is increasingly IPv6 and my internal users can't access this how is that good/effective?  I am not focused on deploying internally per se, but all organizations need to have internal labs setup and should have at least one test/pilot network which has IPv6 Internet access.
> 
> 
Consider also that the people responsible for maintaining your public facing IPv6 stuff need some way to get to it over IPv6 to make sure it is working properly.

Saying that there is no business case is about as intelligent as saying that everything should move urgently. The reality is somewhere in between.

There are many business cases for internal deployment. In some enterprises, this will be to the entire enterprise. For some enterprises, this will be limited to public facing content. For most, it will be a combination of partial internal rollout and a (nearly) complete rollout of public-facing services and content.

>> I also always advice that companies should IPv6 enable the front-end
>> DMZ. but nothing else.
> 
> So how do their internals users, developers, and IT people get at the IPv6 Internet?  How do they get operational experience with running and deploying IPv6 if they only do it in one externally facing network?  Many companies have older hardware that can't deal with IPv6 which will force things like ISATAP.  I agree this isn't desirable but putting your head in the sand and doing the bare minimum is foolish from a security point of view.  Did you see this on a panic driven ISP deployment of IPv6 in your own back yard?
> http://blog.ioshints.info/2012/07/analyst-driven-ipv6-deployment.html

Ding!!

Additionally, most of the security issues that Mark (and others) keep harping on in IPv6 aren't any worse than the ones we've lived with for years in IPv4. In some cases, they're different, but the attack surface and risk factors overall are about the same. While I'm all for addressing the security problems in IPv6 (and was all for addressing them in IPv4), I don't think it makes sense to stand in front of the internet and say "stop growing until we fix this." (which is effectively what you say when you say only do limited deployments).

> 
> If companies wait, when they start scrambling to deploy IPv6 how secure will their setup be?  It is crucial to act now and deploy IPv6 incrementally and methodically to gain experience and learn how to do it right and securely.
> 

Exactly correct.

Security, like all things, needs to be considered in the larger context. The most secure server is one with no external connections to network or power. It's also the least useful.

I don't, for one second, agree that it necessarily costs millions to make a global company all IPv6. It certainly can, but that will depend on the organization and how they go about the roll-out. In many cases, an IPv6 roll-out can be accomplished along side other technology refreshes without significant additional cost.

While I wouldn't tell most enterprises "let's deploy IPv6 everywhere today", I would tell most of them "let's stop deploying anything that doesn't include IPv6 today."

I do like that the article thinks IPv6 only provides trillions of addresses. Certainly in that case, it might be hardly worth the effort. ;-)
Fortunately, as you know, it's quite a bit larger than that.

The fake router RA vulnerabilities are well known and relatively well understood. Vendors are working on it and most have reasonable initial solutions with progress being made towards more complete solutions. However, I do not see this as being any worse in most cases than a rogue DHCP server which is a vulnerability in IPv4 that has not been fixed even to this day. In fact, DHCPv4 doesn't even have the equivalent of RA Guard available.

Owen