IPv6 security: shall we wait or not?

Could “wait and see” be the best IPv6 strategy?

2011 was supposed to be THE year for IPv6. The depletion of version 4 addresses from the top level provider (IANA) and the announcement of “IPv6 world day” on June 8th, set the tone. The message was that we need IPv6 and we need it now!  While tech-Nostrasdamuses have never been in short supply in the IT sector, this particular message gained traction in the media. Put simply, it was a nice story: the exponential growth of the Internet has continued to the point where we now need more IP addresses than there are people on earth.

There are a few facts we can’t deny here: in an ever-growing e-world, IPv4 addresses will soon run out. In fact, certain Internet Providers in Asia, already facing this challenge, have successfully moved to IPv6, most notably for their IP-TV offerings. This has given rise to a whole section of the Internet that cannot be accessed from IPv4 addresses.

However, if we must advise IT professionals in Europe and the US, we can’t rely solely on this macroscopic analysis. If you’ll permit an analogy with global warming, this is a problem for everyone, but not (yet) everyone’s problem. And with IPv6 too, there are some “inconvenient truths”. Let’s review them here, playing devil’s advocate in order to balance the conventional wisdom.

You don’t need IPv6 (yet)

A familiar struggle for most IT professionals is priority management. There are usually more projects than time and resources allow, and every two years or sooner, a new technology emerges to challenge that capacity even further. So if IPv6 is not quite as urgent as industry pundits would have us believe, this is something important to know, since it will allow us to prioritise more time-critical projects like creating a Disaster Recovery Plan or migrating key services to the Cloud.

Unless you are a hosting company which failed to reserve enough IPv4 address space to be safe for the next 5 years (in which case, you have no one to blame but yourself), you really don’t have too much to worry about. There are many reasons for this, starting with the fact that it’s not actually in the ISP’s best interest to switch. After all, no ISP wants to be the first to deny delivery of IPv4 connectivity. This is the reason why most Internet providers are preparing to optimize their existing IPv4 address pool. First, they will share public IP addresses among their customers. In a few years or even months, your “box” (customer premise equipment or CPE) will give you a private IP address to be shared with your neighbors. Using Large Scale NAT (LSN), the ISP will then give you access to the public address space. This will both give the IPv4 world a few more years reprieve as well as freeing more IPv4 addresses for re-use by public servers.

So you still have some time, but maybe you wonder, “Since IPv6 is ready, why not start now?There are, in fact, some good reasons to wait.

IPv6 presents a risk

This statement might freeze you in horror (or disbelief, or both), but from a security perspective, IPv6 may pose more of a threat than an improvement. Despite several modifications aimed at increasing security, these changes, far from fixing everything, actually present new risks. Let’s look at this in more detail.

First, the best of the IPv6 security enhancements is already available within IPv4: IPSec. Even if this becomes mandatory with IPv6, most security professionals already use encryption and tunneling as a security measure in the IPv4 world.

Second, IPv6 did not solve any of the threats present at the level of the LAN. We could even say that it has probably made LAN security harder to attain. The stateless auto-configuration of IP addresses (SLAAC) is unsecured by design. Once a node has configured its own local IP address, it polls to check that no other node on the LAN owns the same IP. If an affirmative response is received, then the address creation process is halted. This means that a malicious user only need answer “yes” to any Duplicate Address Detection poll, and we effectively have Denial of Service on the LAN. For those familiar with ARP spoofing, this is nothing essentially new, but it’s a pity nobody took this opportunity to fix it.

Third, IPv6 adds millions of fresh new lines of code onto Internet. Think about it : new code in the router, host and switch to handle the new protocol, but also new code in almost every connected application : web server and modules (such as PHP), log and monitoring applications, etc. So much new code in the wild presents a tantalizing new playground for hackers, and the hundreds of IPv6-related CVE alerts seem to confirm this.

Every time you enable an IPv6 stack, you add risk to your infrastructure. Isn’t the role of IT Security to minimize risks, or at least make that risk acceptable, when compared to the benefits of the change?

 

Clearly, for a European or American IT department, there is no short-term benefit in an IPv6 migration, and a whole Pandora’s box of risk.

 

NAT IS a security measure

Another bogus challenge which IPv6 raises, is that you should be able to avoid NAT operations. There are so many addresses available, that each company is going to receive a big enough prefix to allocate a global IP address to every node of its network. The problem is that, even if we all agree that NAT has its limitations, it remains a very convenient workaround to a failing security policy. To convince IT administrators that they should use only global IP addresses in their infrastructure is a real, if not impossible, challenge. Until 2010, NAT was still one of the security measures checked by the PCI-DSS certification (Version 1.2). If you ask an administrator how safe his network would be without the NAT operations, most will answer “I don’t know, probably just as safe”. The point is, they are not willing to check, and will therefore probably consider continuing use of NAT with IPv6. Of course, this is only change management, and every argument in favor of NAT in IPv6 can be countered. But in the end, there are still a lot of NAT addicts in the IT world, and you can bet, they will prefer to keep their LAN in a NATed IPv4 configuration, rather than to switch to a Global IPv6 address scheme.

IPv6 is not ready for massive adoption

I know, this is a shock, but after 15 years of preparation, IPv6 is not fully ready. Maybe the latest specifications are ok, but they are not implemented everywhere. Let’s review some facts.

The Secure Neighbor Discover (SEND) protocol, required to make safe automatic address configuration, is not implemented in the Operating System stacks. DHCPv6 is not recommended, but some of the IPv6 stacks still don’t accept the DNS server allocation through stateless configuration. DNS is a critical component of the architecture (since you probably won’t remember a lot of IPv6 addresses), but DNSSEC is not widely deployed, plus it breaks the compatibility with the address configuration.

 In addition to these technical facts, there is an important open question. Unless you are Google or some other giant US company, you probably won’t be able to buy an IPv6 prefix, since these are reserved mainly for Internet Providers. So, if nothing changes, you will be bound to your ISP.

You don’t have the budget anyway

Another inconvenient truth with IPv6 is that it is going to cost a lot of money.
“Wait a minute!” I hear you shout, “This only requires a software upgrade”. Yes, that’s the theory! In practice though, since the v6 addresses are 4 times the length of the v4s’, you’ll have to check every equipment for compatibility. Once you know it might be compatible, you’ll have to assess that it can operate at the same level of performance, or suffer the performance drop when you are going to switch. Of course, some vendors will play the game and deliver software upgrades. Some will, without any doubt, neglect to mention the negative performance impact, leaving you to make the discovery only once implemented across your entire production network. Then you’ll be faced with the non-trivial challenge of defending a budget increase - just to deliver the same level of service you were enjoying before.

 In addition to standard equipment (laptops, servers, switches, routers), you may have industry-specific devices such as large-format printers (Architects, design houses) or complex imaging machines (clinics, hospitals) for which migration to IPv6 will present additional work.

 Before you start, you need to evaluate the total cost (devices + time spent), and don’t forget the regular updates, because as we told previously, you should expect a lot of vulnerability patches.

You’ve confused me now, what should I tell my boss ?

So now what ? You are convinced that it’s safer to wait, but you’ve been asked to make the network IPv6-ready. Having time does not mean you should not prepare. It just means that you can choose the pace of change, and justify it.

It seems a shame that compatibility with existing networks was not a higher priority (or at least more effectively achieved) in the design and creation of IPv6. Unfortunately, several of the changes incorporated actually increase the level risk in switching to IPv6, rather than, as we had all hoped, reduce it. The result of this will now likely be an unnecessarily long transition.

 The intent of this article is not to repudiate IPv6. As we have explained, there are good reasons to plan for its global adoption. The only point in question is the timing of this transition. To blindly embrace the change, simply because of hype and without due attention to the consequences, could be to expose your network to unnecessary levels of risk. Unnecessary - because according to Google, only 0.4% of their traffic is IPv6-based. Are you ready to explain how your whole network was compromised, due to an IPv6 flaw, for sake of 0.4% of your traffic?

Nothing prevents you from starting right now. Just plan it well, prepare a safe architecture for the v4/v6 cohabitation times, and don’t rush it, there is no prize for being an early adopter.

For example, you could start by restricting IPv6 to a non-critical DMZ. Use a split DNS architecture for the IPv6 public servers, then either take the risk of a dual stack server, or use a reverse application proxy to transmits IPv6 requests to IPv4 servers. It will taste like IPv6, smell like IPv6, but your risk profile will be limited for the time being.

 What do you think? Shall you wait? Don’t hesitate to share your experience or your thoughts in the comment section.

Photo courtesy of Ducklover Bonnie