Hackers Target IPv6
If your IPv6 strategy is to delay implementation as long as you can, you still must address IPv6 security concerns right now.
If you plan to deploy IPv6 in a dual-stack configuration with IPv4, you're still not off the hook when it comes to security. And if you think you can simply turn off IPv6, that's not going to fly either.
[Panic time: How well prepared are you for IPv6?]
The biggest looming security threat lies in the fact that enterprise networks already have tons of IPv6 enabled devices, including every device running Windows Vista or Windows 7, Mac OS/X, all Linux devices and BSD.
And unlike its predecessor, DHCP for IPv4, IPv6 doesn't require manual configuration. This stateless auto-configuration feature means that "IPv6-enabled devices are just waiting for a single router advertisement to identify themselves on the network," says Eric Vyncke, Distinguished Systems Engineer at Cisco and co-author of the book "IPv6 Security."
He cautions that "IPv4-only routers and switches don't recognize or respond to IPv6 device announcements, but a rogue IPv6 router could send and interpret this traffic."
Stateless auto-configuration allows any IPv6-enabled device to communicate with other IPv6 network devices and services on the same LAN. To do this, the device advertises its presence and is located via the IPv6 Neighbor Discovery Protocol (NDP).
But left unmanaged, NDP may be a bit too neighborly, possibly exposing devices to attackers anxious to glean information about what's going on inside the network, or even allowing the device itself to be taken over and turned into a "zombie."
Vyncke says the threat is real. "We have observed worldwide that bots are increasing their use of IPv6 as a covert channel to communicate with their botmaster." Among its many disguises, IPv6-enabled malware can take the form of a malicious payload encapsulated in one or more IPv4 messages. Without IPv6-specific security measures such as deep packet inspection, this type of payload may pass through the IPv4 perimeter and DMZ defenses undetected.
SEND (SEcure Neighbor Discovery) is the IETF solution to Layer-2 IPv6 threats such as rogue RA and NDP spoofing, which equate to IPv4 threats named rogue DHCP and ARP spoofing. Some OS vendors support SEND, while others, notably Microsoft and Apple, do not.
Cisco and the IETF are in the process of implementing the same security mechanisms for IPv6 that are currently used to protect IPv4 against these threats.
The IETF has a working group SAVI (Source Address Validation) and Cisco is implementing a three-phase plan to upgrade its IOS that started in 2010 and will be fully implemented by sometime in 2012, depending upon the switch type.
Vyncke notes that some of the more common IPv6 security risks are accidentally created by an improperly configured end-user device on the network, and that proper configuration and IPv6 security measures would eliminate many of these risks.
"The answer to this type of problem is to deploy native IPv6, and to protect IPv6 traffic at the same level and against the same kinds of threats you already defend in IPv4," Vyncke explains.
The IPSec Myth
There's a common perception that IPv6 is natively more secure than IPv4 because IPSec support is mandatory in IPv6. "This is a myth that needs to be debunked," Vyncke says.
He points out that, aside from the practical challenges associated with the broad-scale implementation of IPSec, the content of IPSec-encapsulated traffic becomes invisible to devices (routers/switches/firewalls), thereby interfering with their important security functions.
For this reason, Vyncke, who is also an active member of the IETF and the author of RFC 3585, reports that an IETF working group is considering a change that would make IPSec support "recommended" rather than "required" in IPv6 implementations.
Regarding disabling IPv6, Vyncke says it's a bad idea for two reasons. One, Microsoft has said that disabling IPv6 on Windows 2008 constitutes an unsupported configuration. And Vyncke says trying to disable IPv6 is a head-in-the-sand strategy that delays the inevitable and could make security worse because IPv6 enabled devices are going to be showing up on the network whether IT wants it or not.
Next Page: Momentum building...