Will IPv6 Make Us Unsafe?

We see security as a major stumbling block in enterprise migrations from IPv4 to IPv6. For starters, the code is mostly untested, and too few of our current network security products support IPv6, something the black hat community is banking on. And there's widespread confusion--the idea that some characteristics of IPv6 make it intrinsically more secure than IPv4 is, sadly, just plain false, and information security teams are largely in the dark on how to help their companies safely transition.

Consider the "NAT-bashing" slide, a fixture in IPv6 presentations. Presenters gleefully list all the reasons Network Address Translation is evil, and explain how an abundance of IPv6 addresses will finally let us eliminate what was always supposed to be a temporary address-conservation kludge and get back to a true peer-to-peer Internet. High-fives ensue.

Except, IT security professionals don't share the enthusiasm. Let's face it, IPv6 idealists can wave their fists at NAT all they want, but there are legitimate concerns about losing the ability to shield internal address schemes.

No wonder, then, that among the sessions InformationWeek Analytics presented at the recent Interop conference, by far the most popular was our program on IPv6 with a focus on security. A quick show of hands revealed that most attendees are still in the planning stages of their deployments, par for the course among companies we work with. The good news is that they can take advantage of the lessons learned by telecom carriers and ISPs, which tend to be well along the road to IPv6. And while many conventional enterprise security systems will need to change to work in a v6 network, the upgrade also provides opportunities for improvement--possibly even an outright reimagining of your security strategy.

A prime opportunity to see how all this works in real life is World IPv6 Day, set for June 8. This is a milestone in the transition from IPv4 to IPv6, when companies including Akamai, Facebook, Google, and Yahoo will offer their content over IPv6 for 24 hours. The event will provide valuable data on connectivity, ranging from simple system misbehavior to the amount of user traffic that will switch to IPv6 when content is available over the 128-bit version of IP. We're also fielding our first InformationWeek Analytics IPv6 Survey now through June 13, to see where our readers are on the migration curve. We'll share our results in an upcoming report.

Best Practices: IPv6 Transition

Deploying IPv6: Gateway To the Next-Gen Internet
Become an InformationWeek Analytics subscriber and get our full report on IPv6 security.

This report includes 15 pages of action-oriented analysis including:

Get This And All Our Reports

The Perimeter Problem

Back to security. One thing that quickly becomes clear when rolling out IPv6 is that network systems themselves are the easy part of the project, so much so that it's become accepted wisdom to start a deployment in the center and work outward. Difficulties present themselves in greater numbers as you make your way toward the network edge, where users are connected to services. Envision a "core-to-edge" deployment strategy with your IPv6-enabled network in the middle, surrounded by concentric perimeters of services. Closest to the center are the services essential to the fundamental operation of the network: DNS, DHCP, and the like. Around that perimeter are the services necessary to both manage the network and provide support: Think configuration management, change policy enforcement, monitoring, alarming, and logging.The outside perimeter comprises your security bulwark: firewalls, access control lists, intrusion detection and prevention systems, and the policies enforced by them. The order in which systems are tackled under this model reflects the current v6 readiness of our systems.

If your company lists support for IPv6 among the must-have criteria when purchasing new security gear, you're ahead of the game--and likely frustrated that there isn't more such gear available. While network architects have long had a wide variety of IPv6-capable routers and support systems to choose from, security products have lagged the rest of the industry. Incredibly, until recently, relatively few firewalls had useful IPv6 capabilities, and there are still significant limitations.

Security Mythology

We hear all the time that IPv6 is intrinsically more secure than IPv4. This misconception likely springs from the fact that support for authentication and encryption is integral to the IPv6 specification. Problem is, a capability called for in a spec does not necessarily translate into a capability that works in an actual network. In fact, our experience shows that few IPv6 implementations provide "built-in" authentication and encryption, and end-to-end IPv6 sessions are not automatically secured. Again, a limitation of vendor implementations of the specification.

Another facet of the IPv6 security myth stems from characteristics of the protocol that, while not directly security-related, do have security implications. For example, you'll often hear that IPv6's huge address space makes it immune to port scanning. Assuming a port scanner could "hit" one address per second, a scan of the entire address space of a 64-bit subnet would take upward of 584 billion years. That's an impressive stat, but it ignores the fact that smart subnet spies are already selective about the ports they scan and predictive about the IP addresses they target. Yes, port scanning is more problematic on a typical IPv6 subnet--for both snoops and for your own security team--compared with almost any IPv4 subnet. But stating that IPv6 is immune to scanning is just plain wrong.

And don't assume that because most network engineers aren't yet familiar with IPv6, the bad guys aren't either. In fact, as we discuss in our full report, the opposite is true: There are black hats out there who see IPv6 as a once-in-a-lifetime opportunity. So much new code, so much time to probe for flaws.

It's up to you to ensure that your systems are protected and your security personnel are educated. The best place to start identifying potential vulnerabilities is to understand key differences between IPv6 and IPv4 that affect security. Here are seven areas to know:

Neighbor Discovery Protocol: NDP is essential to the operation of IPv6. It replaces several functions performed by separate protocols under IPv4, such as router discovery and redirects, and enables new functions for IPv6. However, NDP also presents a range of exploits for an attacker who can gain local access to a subnet.

ICMPv6: The ICMP messaging protocol is a favorite vector for denial-of-service and CPU attacks, and guarding against ICMP message floods is a fundamental security best practice. But IPv6 is more dependent on ICMP than is IPv4, so simply blocking all ICMP messages at security checkpoints will break some IPv6 functions.

Fragmentation: Fragmentation attacks are another old favorite that might be given a new spin by IPv6. Unlike IPv4, IPv6 routers don't fragment packets. Instead, the spec requires the originating end system either to test the maximum transmission units along a path to a destination and fragment accordingly or to fragment all packets exceeding 1,280 bytes--the smallest MTU an IPv6 interface is allowed to support.

Extension Headers: IPv6 economizes its default header by eliminating optional fields. Instead, when an optional capability, such as fragmentation, source routing, encryption, or authentication is required, an applicable extension header is inserted between the default IPv6 header and the packet payload. Unfortunately, attackers can abuse extension headers in a number of ways, as we discuss in our full report.

5 Key Considerations

For IPv6 Security

Security involves more than firewalls and access control lists. Are all your IP systems ready for IPv6? How about your processes and people? Training is critical. Some networking systems process IPv6 in software vs. hardware support for IPv4. Can you say CPU depletion attacks? Many modern operating systems enable IPv6 by default. Do you know where all instances of these operating systems reside? IPv6 standards and code are new, and new code is buggy. There have been security holes found, and more will come to light as v6 systems are put into production. Monitor and patch. Black hats are studying IPv6 closely, looking for new attack vectors. Your security team needs to do the same

Flow Labels: The Flow Label field is the only field in the default IPv6 header that has no analogous function in the IPv4 header. It's intended to enable efficient processing of microflows for improved service classification, but mainstream network systems do not yet use it. An intentionally miswritten Flow Label value could create a covert channel.

Automatic Tunnels: Automatic tunneling mechanisms, such as 6to4 and Teredo, are supported by most host operating systems. They're used to create IPv6 connectivity over an IPv4-only network or segment, but they may also be used to create an unsecured channel, and most lack a means of authentication.

Large-Scale NAT: Also called Carrier-Grade NAT, or CGN, LSN isn't a part of the IPv6 specification, but it is often associated with IPv6 transitional architectures. LSN setups allow network operators to centralize their public IPv4 address pools, thus extending their useful lives by multiplexing more IPv4 flows to each address. These centralized NATs--often single points of failure for tens of thousands of end systems--represent attractive targets for CPU or address pool depletion attacks.

Beyond Black Hats

Security goes beyond deflecting attacks. You must also guard against unintended side effects that can bring down portions of your network as effectively as any denial-of-service exploit. In the case of IPv6, there are two key nonmalicious threats to watch for.

First, don't assume that because you achieve a given performance level from a network system running IPv4 you will realize the same performance when you add IPv6. A router that processes and forwards IPv4 packets in hardware might process IPv6 packets in software. A firewall's CPU might slow significantly when it processes IPv6, particularly if extension headers are involved. The other major nonmalicious threat to your IPv6 network is lack of training. From the very different address format to the key protocol differences between IPv4 and IPv6, your network operators and engineers need to be prepared.

Watch For Bugs

IPv6 implementations almost always mean running code that hasn't yet undergone production vetting. A router vendor might have supported OSPFv2 for almost 20 years, but OSPFv3 for IPv6? It's new--and very likely buggy. Did your firewall vendor release IPv6 support only within the past couple of years--or even months? Then there are surprises awaiting you. This isn't an indictment of sloppy development work; we all depend on extensive production deployments to reveal problems. Yet worldwide, IPv6 is still in its early stages of use, meaning even IPv6 implementations that were written years ago may just be getting their first large-scale field tests.

Even standards bodies are occasionally guilty of overlooking security risks. Two infamous examples of early oversights in IETF specifications were an IPv6 source routing vulnerability that opened the possibility of amplification attacks and firewall bypasses, and an ICMPv6 vulnerability that allowed ping-pong attacks on point-to-point links. Both vulnerabilities were well known in IPv4 and had long been corrected in earlier standards, but were simply overlooked in initial IPv6 specifications. And while these mistakes have been corrected in newer versions of the protocol, you need to assume that some operating systems in your network incorporate the older, problematic standards--which brings us right back to awareness, communication, and testing.

New Opportunities

5 Key Policy Changes

in IPv6

Extension headers Neighbor Discovery Protocol Heavier dependencey on ICMP Flow labels No NAT66--get over it

The transition from IPv4 to IPv6 is a major evolution. It's also unavoidable, unless retirement is in your near-term plans. And although IPv6 presents some new security challenges, none of them are insurmountable given the right preparation. In fact, smart CIOs are looking at the transition as an opportunity. Are your security practices and systems all that you want them to be? If not, an IPv6 deployment can be the perfect time to assess your situation and improve or replace your current security architecture and practices.

The transition to IPv6 is also an opportunity for us as a community to reconsider the way security is practiced. Are firewalls and intrusion detection systems sufficient protection? All of the 1,000-plus respondents to our latest InformationWeek Analytics Strategic Security Survey use firewalls, and 93% have intrusion detection/prevention systems in place. But walls have never truly protected us--maybe it's time to consider a new outlook, like moving to a model of end-to-end authentication and encryption, creating "zones of protection" around individual hosts and servers, and adding improved algorithms for threat analysis and interdiction. And maybe IPv6 can help us get there.

Jeff Doyle is president of Jeff Doyle and Associates. He specializes in IP routing protocols, MPLS, and IPv6 and has worked globally with large IP service provider networks.

InformationWeek: May 30, 2011 Issue

Download a free PDF of InformationWeek magazine
(registration required)