Over time, a number of myths have arisen about the security properties and features of IPv6. This technical article,
which is a part of the SearchSecurity.com mini learning guide, IPv6 tutorial: Understanding IPv6 security issues, threats, defenses, provides a realistic evaluation of IPv6 from a security standpoint, and dismantles many of the myths that have been perpetuated regarding its security capabilities.
IPv6, the latest version of the Internet Protocol, is expected to coexist with and eventually replace IPv4, providing a larger address space to foster growth of the Internet for the near future.
However, since the protocol was first specified, a number of myths have arisen about its properties in the areas of quality of service (QoS), “plug-and-play” features and particularly security. Many of these myths have been fueled by IPv6 proponents, who may have thought their marketing-heavy statements would foster the deployment of IPv6. Unfortunately, not only did such an attempt fail (as IPv6 is only just now taking hold because v4 addresses are running out), but many of these myths are also believed to be fact, leading to incorrect expectations regarding the properties and features that IPv6 provides.
Let's examine the most common IPv6 myths that have arisen regarding the protocol's security:
Myth #1. “IPv6 is more secure than IPv4, since security was considered during the design of the protocol, rather than as an afterthought.”
The origins of this myth go back to the early specification of IPv6. At the time, IPsec support was made mandatory for IPv6, and it was expected that IPv6+IPsec would be widely deployed in the short term, and vendors wouldn’t bother to add IPsec support to IPv4 implementations. However, the assumptions proved to be false: Virtually all popular IPv4 implementations incorporated support for IPsec, and IPv4+IPsec was deployed much earlier than any significant level of deployment of IPv6 (not to mention IPv6+IPsec).
It is also usually argued that network address translation (NAT) would have prevented the deployment of IPsec for end-to-end security, and that, since IPv6 will eliminate the need for NAT (see Myth #3 below), end-to-end IPsec use will become ubiquitous. This assumption is false, since many (if not most) of the factors that have prevented widespread deployment of IPsec for general use with IPv4 (such as the requirement for a Public Key Infrastructure) remain the same for IPv6.
While recently published reports and papers continue to fuel the belief that IPv6 deployments will lead to an increase of IPsec usage, this idea seems to be based, if anything, on hope rather than facts.
Myth #2: “IPv6 will return the end-to-end principle to the Internet, and hence security architectures will switch from mostly network-centric, to host-centric.”
One of the core design principles of the Internet is usually referred to as the “end-to-end principle," and argues in favor of a “dumb network,” with most of the “intelligence” or complex decision-making capabilities residing with the hosts. This principle leads to an architecture in which the network simply forwards datagrams from a source host to a destination host (or set of hosts) without further interpretation of the forwarded datagrams. In the IPv4 Internet, this principle is violated by a number of devices, with IPv4 NATs probably being the most popular and most widely deployed.
It is argued that an IPv6-only Internet where no IPv6 NATs are deployed (see myth #3 below) would return the end-to-end principle to the Internet. However, it should be noted that, even though the vast amount of address space provided by IPv6 could provide unique IP addresses for each device that connects to the Internet, for many security administrators or users, the end-to-end principle is not necessarily a desired property.
For example, administrators may not necessarily be willing to have every host on a network be directly reachable from any arbitrary host on the Internet, an unintended consequence with IPv6 that could make a network more vulnerable to outside attackers. Thus, admins may prefer a network architecture where only return traffic is allowed (i.e., incoming traffic is allowed only if it is in response to communications that originated from the internal network).
Therefore, the typical IPv6 subnet will most likely need to be protected by a stateful firewall that only allows communications originating from the inside network. So at least in terms of packet filtering, the architecture of the typical IPv6 subnet will be no different from that of the typical IPv4 subnet. For what it's worth, recent work by the Internet Engineering Task Force (IETF) on simple security capabilities in Customer Premises Equipment (CPE) seems to indicate momentum in that direction.
Myth #3: “IPv6 networks will be NAT-free.”
This myth is closely related to myth #2 and is based on the assumption that, since IPv6 provides plenty of address space, NATs will not be deployed in IPv6 networks. However, this assumption deserves a more careful and thorough analysis.
During the time of IPv6's coexistence with IPv4 and the transition to an IPv6-only Internet (assuming the latter is beginning), there has been increased use of NATs. On one hand, since most transition/coexistence technologies do not relieve hosts from the need of IPv4 addresses, the so-called Carrier-Grade NATs (CGNs) will most likely be widely deployed, thus leading to an increased use of NATs in the IPv4 Internet. On the other hand, the only transition/co-existence technology that relieves networks of the need of IPv4 addresses is NAT64, which allows IPv6-only nodes to communicate with IPv4-only nodes, but introduces yet another type of NAT, both in the IPv4 Internet and the IPv6 Internet.
The potential of deployment of network address translation – port translation (NAT-PTs) in the IPv6 Internet deserves a careful analysis as well. While IPv4 NATs were introduced as a stop-gap for IPv4 address consumption, they are usually perceived as providing benefits in the area of host/network masquerading, and blocking incoming connections to the internal network (since as a side-effect of its mode of operation, the NAT device will only allow communications initiated from the internal network). While it can be argued that blocking incoming connections can be easily achieved with a normal stateful firewall (without performing address and port translation), and host/network masquerading does not add much in terms of security, it is also true that humans tend to resist change, and, thus, some network administrators architect their IPv6 subnets to parallel their IPv4 subnets, i.e., deploying a IPv6 NAT-PT to act as a gateway to the Internet for the internal nodes. So it seems in most IPv6 network architecture scenarios, NAT is likely to remain in some form.
Myth #4: “The vast IPv6 address space will make IPv6 address scans unfeasible.”
It is assumed that the increased IPv6 address space will make IPv6 address scans unfeasible. However, this statement is made based on two assumptions that are not necessarily true in all cases. First, it is assumed that host IPv6 addresses will be uniformly distributed over the whole address space assigned to the corresponding subnet. Secondly, it’s assumed an attacker will perform address scanning using a brute-force approach.
However, studies of the policies used to assign IPv6 addresses indicate they are not uniformly distributed; rather they follow specific patterns, such as those resulting from stateless auto-configuration (SLAAC), manual configuration or use of IPv6 transition/coexistence technologies. Also, it has already been found in the wild that attackers are not performing IPv6 address scans with a brute-force approach, but rather they are trying to improve their scans by taking advantage of these known patterns of IPv6 address assignments.
Address-scan attacks can be mitigated in a number of ways. First, the so-called “privacy addresses” specified in RFC 4941 could be preferred over the “modified EUI-64 format Interface Identifiers” that are typically used for stateless address auto-configuration. Additionally, as indicated above, a stateful firewall that only allows return traffic could be deployed at the organizational perimeter, such that the probe packets sent by the attacker never reach the internal hosts.
It should also be noted that the reason why it is common to see brute-force address-scan attacks in IPv4 is because the protocol's limited address space makes it convenient for an attacker to employ such an approach (or, put another way, it is not worth the effort to develop more sophisticated/educated address scan strategies). This means that, not only will IPv6 address scans typically be more “educated,” but it is also possible that attackers will employ other network reconnaissance strategies, such as identifying “alive” hosts from the IPv6 addresses leaked out by application-layer protocols (e.g., in email headers), possibly in combination with use of popular Web search engines.
The goal of this article has been to shed some light on a number of myths built around IPv6 security features. As it is virtually impossible to achieve a secure IPv6 deployment without realistic assumptions and expectations, a discussion of the aforementioned IPv6 security myths is a necessary starting point.
About the author:
Fernando 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). As part of his work for these organizations, he has authored a series of documents with recommendations for network engineers and implementers of the Internet protocol suite. Gont is an active participant at the IETF (Internet Engineering Task Force), where he contributes to several working groups, and has authored a number of RFCs (Request for Comments). He is a regular speaker at a number of conferences, trade shows and technical meetings about information security, operating systems and Internet engineering. More information is available at his website: http://www.gont.com.ar.