Security challenges emerge with the launch of IPv6

TUESDAY, APRIL 17, 2012
|

No doubt, the impending global launch of the IPv6 protocol on June 6 ushers in a new era in the evolution and widespread adoption of Internet infrastructure around the globe.

 

The world has already had a small taste of what is to come – in June of last year, during World IPv6 Day. Spearheaded by the Internet Society, the effort galvanised more than 1,000 websites, tech companies and ISPs to collectively switch to IPv6 for a total of 24 hours in an effort to "test drive" the protocol to predetermine and mitigate any possible glitches that might occur during an actual launch.
 
On June 6, top tech organisations and Web leaders such as Google, Facebook and Yahoo!, among others, will make the leap to the updated Internet protocol in an official worldwide launch. Yes, this time, it’s here to stay.
 
And the transition has become increasingly necessary. The current IPv4 protocol, which can handle around 3.7 billion addresses, has simply run out of address space, thanks in part to the mobile device explosion. Meanwhile IPv6, for all intents and purposes, has unlimited address capacity to accommodate a rapidly growing global Internet and mobile infrastructure.
 
However, with the impending launch of the IPv6 protocol worldwide, researchers and IT professionals are anticipating some challenges, especially on the security front.
 
For one, the relative newness and lack of knowledge around the IPv6 protocol will inevitably pave the way for misconfigurations, compatibility issues and other implementation gaffes. There is not the institutional knowledge around IPv6 the way there is around IPv4, which has been around for decades and enjoys an extensive knowledge base.
 
But perhaps the biggest security issue is that many security network devices are equipped with capabilities that allow them to forward IPv6 traffic, but not inspect it. And, because IPv6 is enabled by default on many platforms in networks today – such as Windows 7 – IPv6 compliant systems are already installed in their networks.
 
Most systems that are not IPv6 enabled have the ability to handle a work-around, which is to wrap an IPv6 packet with an IPv4 header. They read the header, but they cannot read the contents of the packet itself. They cannot do their normal deep packet inspection, and they just forward the packet. Only when they have a dual stack implementation would they be allowed to simultaneously allow network security functionality to both process and fully inspect packets from both the IPv4 and IPv6 protocols.
 
Several vendors have this functionality – but not all – and that’s one of the risks facing network security professionals today. People have to make sure that their security product can inspect IPv6 traffic. If it can just forward IPv6 traffic, it could be forwarding malicious content.
 
Even with a dual stack implementation, however, organisations need to determine if they have the same feature set enabled for the IPv4 protocol as they do for IPv6. If not, the network security devices could be overlooking critical pieces of malicious traffic that could potentially compromise their network.
 
Some of the policies in IPv4 and technologies you rely upon may only work in IPv4 and not IPv6, which means gaps in your security coverage. In this case, however, knowing is not even half the battle. Upgrading networking security infrastructure to accommodate IPv6 is no small undertaking and will likely take years to be phased in completely. Subsequently, many organisations, facing potentially costly and time-consuming hardware upgrades, are not planning to embrace IPv6 any time soon.
 
Yet enterprises cannot shy away from the issue for too long. Following the June 5 launch, a lot more IPv6 traffic will hit their networks. When IPv6 is going to be 5 to 10 per cent of your data – rather than a fraction of a per cent – upgrade avoidance becomes much harder to justify. CIOs need to start pondering the problem soon.
 
Peerapong Jongvibool is the country manager for Fortinet (Thailand).