Most networks have partial deployment of IPv6 often without IT realizing it. It’s time to take stock of the security implications before attackers do.

Internet Protocol version 4 (IPv4), the networking standard on which the Internet has been built, is expected to reach its IP address limit of roughly 4.3 billion in a few years. While most enterprises can survive for now with just a handful of IP addresses (thanks to Network Address Translators—NATs—which allow multiple devices to be connected to the public Internet with a single public IPv4 address), the burgeoning number of Internet-connected mobile devices and non-traditional objects like cars, appliances and smart meters demands that the Internet’s phone book expand its listings.

Enter Internet Protocol version 6 (IPv6). IPv6 was designed to succeed IPv4 and accommodate the future growth of the Internet by providing a much larger address pool than IPv4. Hopefully, this isn’t the first time you’ve read about IPv6: awareness activities, such as the World IPv6 Launch Day, and the deployment of IPv6 in large content providers such as Google and Facebook, has been going on for years, and recently resulted in a spike of emerging IPv6 deployments and global IPv6 traffic.

Enterprise information security teams have largely been able to ignore IPv6, until now. A wave of adoption among Internet infrastructure providers and networking product vendors is about to crash over enterprise IT departments; many teams that haven’t worked with IPv6 before will suddenly be charged with securing it.

IPv6 Security Implications

There are a number of reasons why organizations should be concerned about the security implications of the IPv6 protocol suite. First, most operating systems include some sort of IPv6 support by default; this means that networks have at least partial deployment of IPv6, often without IT realizing it. The IPv6 support could be leveraged by attackers for a number of malicious purposes such as evading network security controls or triggering VPN leakages. Secondly, IPv4 and IPv6 will co-exist for some time, so it will become common for allegedly “IPv4-only” nodes to communicate with IPv6 nodes through the aid of transition or co-existence technologies. This means attackers can more easily obfuscate attacks using IPv4 and IPv6. Finally, many organizations will need to deploy IPv6 sooner or later, and quickly learn the ins and outs of IPv6 security so that an informed deployment and transition plan can be implemented.

IPv6 Security Considerations

While it is tempting to analyze the security implications of a communications technology based on a security assessment of the technology, the effective security level of emerging IPv6 deployments will depend on several facets coming together:

Expertise of the technical personnel with respect to the IPv6 protocol suite

Availability of skilled human resources

Maturity level of IPv6 implementations

IPv6 support in security products

Complexity of the resulting networks (and of the Internet in general)

Most enterprise IT staffs have many years of experience with the IPv4 protocols. This experience is not only reflected in the staff’s ability to build networks, but also its ability to detect problems, and to differentiate between normal vs. anomalous traffic patterns. The same personnel typically have little to no experience with IPv6.

As a result, many IPv6 deployments may overlook security implications, and communications will be subject to fewer controls than their IPv4 counterparts. Therefore, IPv6 will likely become “the weakest link in the chain” of an organization’s network security.

Even if an organization decides to hire specialists in this area, or to outsource IPv6-related tasks, the lack of highly skilled professionals will become evident as IT consultants remain focused on the larger pool of IPv4 clients. This will not only have an effect on consulting and hiring costs, but may also mean that these tasks might end up being carried out by personnel with sub-optimal skills.

The maturity of implementations plays an important role in the security of emerging IPv6 deployments. Software has bugs, and it will take time for IPv6 implementations to reach the maturity level of IPv4 implementations. Based on the number of vulnerability advisories that have been published over the years about IPv4 implementations, it is not hard to conclude that it has taken quite a few years for IPv4 implementations to achieve acceptable maturity levels.

IPv6 is no different in this respect. Software bugs with security implications might be discovered and maliciously exploited by attackers, before vendors get a chance to fix them.

Besides the technical expertise of the IT staff, and the virtues, or lack thereof, of the IPv6 protocols, the effective security level of emerging IPv6 deployments will depend, to a large extent, on the availability of IPv6 security products, and the security features in the products. After all, these are the tools that finally enforce security controls on a network.

Security products today have less support for IPv6 than for IPv4 in terms of variety of products, availability of features and performance. Many firewalls simply do not support IPv6. When products claim to support IPv4 and IPv6, it is not unusual for them to contain more IPv4 features. And even when a security product claims to have feature parity, there might still be differences in how those features are implemented. It is not unusual for security devices to implement IPv4 functionality in hardware, and IPv6 functionality in software. Therefore, a security device might be able to handle some packet rates for IPv4, but unable to support the same traffic levels in IPv6—and this limits the scenarios in which IPv6 functionality can be deployed.

Finally, since IPv6 is not backwards-compatible with IPv4, there are a variety of transition technologies that aim to facilitate the co-existence of both Internet protocols, and eventually, complete migration to IPv6. These technologies range from dual-stack, to tunnels (whether configured or automatic), translators (NAT64, CGN) or different types of proxies. As the number of IPv6 deployments increase, so will the use of such transition technologies. Whether an organization deploys IPv6 or not, the Internet as a whole will become a far more complex network than the one we are used to today. This will have implications on every aspect of network operation and management, including security. When tracing an attack source, you may have to trace the attacker behind one or more translators, tunnels, and the like. When monitoring network traffic for malicious patterns, the use of tunnels (whether intentional or not) might make traffic analysis much more difficult (if at all possible) than in IPv4.

IPv4 vs. IPv6: A Brief Comparison

From a functional point of view, IPv6 is no different from IPv4: it simply provides a “best effort” datagram delivery service. However, IPv6 uses different protocols and mechanisms to provide such service, and that is where most of the operational and security implications arise.

With plenty of IPv6 addresses, it is likely that every host connected to an IPv6 network will be assigned a global IPv6 address. This global addressability might in turn increase host exposure.

IPv4 NATs enable multiple devices to connect to the public Internet using a single public IPv4 address, but firewall functionality is limited to “only allowing outgoing connections.” Emerging IPv6 deployments will not need to employ NATs. Unless a proper firewall is deployed to protect internal nodes, IPv6 deployment might result in increased host exposure. Although different, this is closely related to the global addressability issue.

The typical IPv6 subnet is composed of 264 addresses, so it will have a much lower host density (i.e. number of hosts per number of available addresses). This will make traditional address scanning “attacks” more difficult than in IPv4. As a result, security practitioners will have to evolve how they do network reconnaissance when performing penetration tests.

Other than the increased address space, IPv6 protocols tend to have increased extensibility. An IPv4 packet can carry a maximum of 40 bytes of options, whereas an IPv6 packet can (at least in theory), carry an unlimited number of options. Unfortunately, this flexibility is seldom used for legitimate purposes; which makes the enforcement of security policies and monitoring of network traffic much more painful.

Most aspects that play a key role in the security implications of IPv6 are not related to the technical features of the IPv6 protocols including the limited availability of skilled personnel and IPv6 security products, and the lack of mature IPv6 implementations.

IPv6 Security Myths

One of the myths about IPv6 is that it has “improved security.” However, generally speaking, there are no security features in IPv6 that were not readily available for IPv4.

It is widely assumed that “IPv6 will lead to increased IPsec usage,” probably because, from a protocol-specifications point of view, IPsec support used to be mandatory for IPv6 implementations (but not for IPv4 implementations). In practice, however, many IPv6 implementations never honored this requirement (to an extent that this requirement has been removed from IPv6 implementations). And, even then, IPsec implementation or support does not necessarily result in IPsec usage. Many issues that led to a low level of deployment of IPsec are still valid for IPv6, and there are no legitimate reasons to believe that the actual use of IPsec will increase with the deployment of IPv6.

Finally, some argue that the increased address space will mean that all IPv6 nodes will be directly reachable from the public IPv6 Internet (a property usually referred to as “end-to-end connectivity”) and that, as a result, the security paradigm will change from network-centric to host-centric. Note, however, that most IPv4 networks currently employ a “hybrid” security paradigm, and that will continue with IPv6. Any changes in this area will not be motivated by IPv6 itself.

Where To Go From Here

It should now be evident that the security implications of IPv6 should be a concern not only to organizations planning to deploy IPv6, but also to organizations operating (allegedly) IPv4-only networks. A number of actions are warranted to mitigate the security implications of IPv6, and to allow for a smooth transition to this “new” Internet protocol:

Creation of a test lab for the IPv6 protocols, devices, and applications

Development of an IPv6 deployment plan

Training key technical staff is mandatory to address the challenges presented by the new Internet protocol. This is independent of whether an organization plans to deploy IPv6 in the short or near term.

Most general-purpose systems include some sort of IPv6 support “enabled by default,” so concrete actions (such as enforcement of packet filtering) are needed in order to mitigate the security implications of IPv6 on the existing “IPv4-only” networks.

Since the necessary expertise can only be learned through practice, it will be essential to build an “IPv6 test lab” (separate from any production networks), on which technical staff can build their expertise with the IPv6 protocols (virtualization technologies might be of help in this area).

Finally, an IPv6 deployment plan should be established to prepare for the deployment of the new Internet protocol. This plan need not imply IPv6 deployment through the organization in the short term, but rather prepare the organization for eventual IPv6 deployment. The deployment plan should cover IPv6 training of all technical staff, IPv6 requirements when purchasing software or hardware devices, and an IPv6 test lab.

Sooner or later your organization will need to deploy IPv6—in fact, your network probably already has partially deployed IPv6. It’s time to take stock of the security implications before the attackers do. Time is indeed running out.

About the authorFernando Gont is a networking and security consultant, who has worked on a number of projects on behalf of the UK National Infrastructure Security Coordination Centre (NISCC) and the UK Centre for the Protection of National Infrastructure (CPNI). Gont is an active participant at the Internet Engineering Task Force, where he contributes to several working groups, and has authored a number of RFCs (Request for Comments). Send comments on this column to feedback@infosecuritymag.com.

Start the conversation

0 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.