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.
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.
Momentum building
Security threats aside, there is a growing business case for IPv6 that is getting harder to sweep under the rug. Banks and online brokerages already face the challenge of losing communication with international customers whose networks no longer support IPv4.
Companies like Telefonica and T-Mobile are embracing IPv6 in a big way, especially for their European bases. And the U.S. government, which has been steadily migrating to IPv6, is clamoring for providers and vendors to deliver more IPv6 products and services.
“You never want to be in a position where you can’t interact with your customers,” says Keith Stewart, director of Brocade Communications Systems Applications Delivery Products. Nevertheless, sharing the prevalent view among network vendors, Stewart sees a gradual migration to IPv6.
“A wholesale upgrade to IPv6 across the Internet is neither practical nor effective,” Stewart says. “Customers need a balanced, practical approach.” He notes that service providers, who consume addresses faster than anyone else, are first in line for IPv6 upgrades, followed by content hosts (Google and Facebook), and finally end-users, whose home routers are still 99% IPv4-based.
When Brocade needed to move to IPv6, it took existing load balancers and turned on IPv6 translation to public-facing services, preserving IPv4 connectivity on the internal network. “The public stack is the most important. Pick a smaller project where you can make a business case to communicate with IPv6 customers. When building out your next set of services, demand that it’s dual-stack capable or translation-capable for older IPv4 architectures. This allows you to build a business-facing ROI as your teams gain competence with IPv6. Any transition should be designed to be seamless for the end user,” Stewart says.
Juniper Networks reports that up to now the majority of its customers requesting IPv6 services are from the education and government sectors, specifically university research labs and governmental units seeking to comply with federal IPv6 mandates.
Juniper predicts increased IPv6 activity for 2012, especially among service providers. “IPv4 address exhaustion is becoming a significant problem for our customers around the world,” says Alain Durand, director of software engineering, Platform and Systems Division CTO group. Even so, Durand expects that most IPv6 deployments will be smaller projects with IPv6 implemented as an “add-on” (dual-stack) to existing IPv4 public-facing services. “To deal with the growing shortage of IPv4 addresses, customers always have the option of adding another layer of NAT,” Durand says.
While there is no way to predict with certainty exactly how long it will take until all IPv4 addresses are exhausted, the daily statistics compiled by Geoff Huston, chief scientist at APNIC, are frequently cited as a reliable source. Huston’s model, which is based on public data sources derived from data published by the IANA and the Regional Internet Registries, predicts full depletion of all remaining unallocated IPv4 addresses by 2014.
However, it is important to note that Huston’s model does not factor in addresses which may be held by private organizations for future use or sale. For example, it would not factor in the more than 600,000 IPv4 addresses recently acquired by Microsoft under its purchase of bankrupt Nortel’s assets. While it may be safe to assume that sufficient IPv4 addresses will be available in the near term, many predict costs to rise as the supply dwindles.
Without established best practices for IPv6, many network managers have been reluctant to act. But with increasing security threats and concerns about losing communication with customers who are already migrating to IPv6-only systems, waiting for others go first and doing nothing in the meantime isn’t the ‘position-neutral’ stance that it might seem.
The planning phase is a good time to establish or re-establish ties with a trusted network vendor who can provide architecture and security guidance, together with scalable solutions for a broad array of migration options.
Perschke is co-owner of two IT services firms specializing in web hosting, SaaS (cloud) application development and RDBMS modeling and integration. Susan also has executive responsibility for risk management and network security at her companies’ data center. She can be reached at susan@arcseven.com.