The imminent exhaustion of freely available IPv4 addresses has, over a number of years, led to the incorporation of IPv6 support by most general-purpose operating systems. However, many applications, such as VPN client and server software, have been lagging behind to become IPv6-ready. This results in scenarios in which dual-stacked hosts employ IPv6-unaware VPN software, thus opening the door to security vulnerabilities, such as VPN traffic leaks.
Introduction: The risk of VPN leaks
Employees who work from remote locations commonly establish virtual private network (VPN) connections to access services that are only available within a company's network and to secure the corresponding traffic that must otherwise traverse insecure networks. In some scenarios, it is assumed that employing a VPN connection makes the use of insecure protocols (e.g., that transfer sensitive information in the clear) acceptable, since the VPN provides security services, such as confidentiality for all communications made over the VPN.
Many VPN connections support only the IPv4 protocol. However, the hosts that employ these technologies are typically dual-stacked, meaning they support (and enable by default) both IPv4 and IPv6. Currently, many hosts only employ IPv4 because most networks do not provide IPv6 connectivity. IPv6 support is still present at the host, but waiting to be enabled. And when that happens, the host may unknowingly use an IPv6-unaware VPN in a dual-stack network.
The subtle way in which the IPv4 and IPv6 protocols interact and coexist in dual-stacked networks might, either inadvertently or as a result of a deliberate attack, result in security issues associated with a VPN leak. Traffic meant to be transferred over a VPN connection could leak out of the VPN connection and be sent in the clear on the local network, without employing the VPN services at all.
IPv4 and IPv6 interactions
The coexistence of the IPv4 and IPv6 protocols has a number of interesting and subtle aspects that may result in surprising consequences. While IPv6 is not backward-compatible with IPv4, the two protocols are "glued" together by the Domain Name System (DNS). For dual-stacked systems that rely on name resolution services (such as those the DNS provides), it's impossible to secure the communication between two systems without securing both protocols.
Many VPN implementations do not support the IPv6 protocol or, worse, they completely ignore IPv6. When establishing a VPN connection, the VPN software typically inserts an IPv4 default route that causes all IPv4 traffic to be sent over the VPN connection (as opposed to sending the traffic in the clear, employing the local router). However, if IPv6 is not supported, any packets destined for an IPv6 address are sent in the clear using the local IPv6 router. The VPN software does nothing to secure the IPv6 traffic.
For example, consider a site (say, www.example.com) that supports both IPv4 and IPv6. The corresponding domain name contains both A and AAAA DNS resource records (RRs). Each A record contains one IPv4 address, while each AAAA record contains one IPv6 address. There can be more than one instance of each of these record types. When a dual-stacked client application attempts to communicate with a server, it can request both A and AAAA RRs and use any of the available addresses. The preferred address family (IPv4 or IPv6) and specific address that will be used (assuming more than one address of each family is available) varies from one implementation to another, with many host implementations preferring IPv6 addresses over IPv4 addresses.
Accidental and deliberate VPN traffic leaks
Consider a dual-stacked host that employs IPv4-only VPN software to establish a VPN connection with a server. What would happen if the host attaches to a dual-stacked network? If an application at the host attempts to communicate with a dual-stacked system, it typically queries both A and AAAA DNS resource records. If the host supports both IPv4 and IPv6 connectivity but prefers an IPv6 destination address, even though the other system has both A and AAAA DNS resource records, the host will employ IPv6 to communicate with the aforementioned system. If the VPN software does not support IPv6, the IPv6 traffic will not employ the VPN connection; instead, it will be sent in the clear via the local IPv6 router.
This inadvertently exposes potentially sensitive traffic that is assumed to be secured by the VPN software. In this particular scenario, the resulting VPN leak is a side effect of employing IPv6-unaware software (the VPN) in a dual-stacked network.
Explaining the RFCs
RFC 6724 specifies an algorithm for selecting a destination address from a list of IPv6 and IPv4 addresses. RFC 6555, entitled "Happy Eyeballs: Success with Dual-Stack Hosts," discusses the challenge of selecting the most appropriate destination address, along with a proposed implementation approach.
An inadvertent VPN traffic leak is not the only concern stemming from this issue. By pretending to be a local IPv6 router, a local attacker could deliberately trigger IPv6 connectivity on the victim host by sending forged ICMPv6 Router Advertisement messages. Such packets could be sent by employing standard software such as rtadvd or by employing packet-crafting tools such as the IPv6 toolkit. Once IPv6 connectivity is enabled, communications with dual-stacked systems could result in VPN traffic leaks, as previously discussed.
While such an attack is useful enough due to the increasing number of IPv6-enabled sites, it only leads to traffic leakage when the destination system is dual-stacked. However, triggering such VPN leakage for any destination system is a trivial matter. An attacker could simply pose as the local recursive DNS server by sending forged Router Advertisement messages that include the corresponding RDNSS option, and then perform a DNS spoofing attack to become the man in the middle and intercept the corresponding traffic. As with the inadvertent leak scenario, packet-crafting tools such as the IPv6 toolkit can easily perform this attack.
VPN leak mitigations
There are a number of possible mitigations that can be put in place to avoid VPN leak issues with dual-stacked networks. The simplest option (though not necessarily the most desirable) is to disable IPv6 support in all network interface cards when a VPN connection is meant to be employed. Applications on the host running the VPN client software will only be able to employ IPv4, which the VPN software should be well-prepared to secure.
A network may prevent local attackers from successfully performing the aforementioned attacks against other local hosts by implementing first-hop security models such as Router Advertisement Guard (RA-Guard) and DHCPv6-Shield. However, for obvious reasons, a host cannot rely on these mitigations when connecting to an open network. Keep in mind that popular implementations of RA-Guard are also known to be vulnerable to evasion attacks.
Some might argue that the most complete mitigation would be to incorporate IPv6 support in the VPN software and have the VPN server provide IPv6 connectivity. Besides being unfeasible in many current scenarios, such a mitigation might prove to be non-trivial because IPv6's auto-configuration provides a number of ways for routers (and attackers) to insert alternative routing information. For example, an attacker could still cause IPv6 traffic leakages by performing a number of Neighbor Discovery attacks, such as sending forged ICMPv6 Redirect messages, forged Router Advertisements with Route Information options (i.e., "more specific routes"), forged Router Advertisements that advertise "high priority" routers, etc. Even if VPN software supports IPv6, some VPN implementations will likely still be vulnerable to this type of attack in the near term.
The subtle interaction of the IPv6 and IPv4 protocols, along with the (unfortunately) established assumption that IPv6 security is only a concern if one plans to deploy IPv6, can have consequences such as inadvertent VPN traffic leak. As most general purpose operating systems are dual-stacked, most networks are at least partially dual-stacked, which means the security implications of IPv6 cannot be ignored. The Internet's need for an increased address space necessitates the widespread adoption and deployment of the IPv6 protocol. However, such adoption and deployment should encompass a thorough understanding of the corresponding security implications.
About the author:
Fernando Gont currently works for SI6 Networks as an Internet security and engineering consultant, and 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). He 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). Gont 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