Internet Engineering Task Force (IETF) F. Gont Request for Comments: 7359 Huawei Technologies Category: Informational August 2014 ISSN: 2070-1721 Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks
AbstractThe subtle way in which the IPv6 and IPv4 protocols coexist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) tunnel products, may inadvertently result in VPN tunnel traffic leakages. That is, traffic meant to be transferred over an encrypted and integrity- protected VPN tunnel may leak out of such a tunnel and be sent in the clear on the local network towards the final destination. This document discusses some scenarios in which such VPN tunnel traffic leakages may occur as a result of employing IPv6-unaware VPN software. Additionally, this document offers possible mitigations for this issue. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7359.
IESG Note This document describes a problem of information leakage in VPN software and attributes that problem to the software's inability to deal with IPv6. We do not think this is an appropriate characterization of the problem. It is true that when a device supports more than one address family, the inability to apply policy to more than one address family on that device is a defect. Despite that, inadvertent or maliciously induced information leakage may also occur due to the existence of any unencrypted interface allowed on the system, including the configuration of split tunnels in the VPN software itself. While there are some attacks that are unique to an IPv6 interface, the sort of information leakage described by this document is a general problem that is not unique to the situation of IPv6-unaware VPN software. We do not think this document sufficiently describes the general issue. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. IPv4 and IPv6 Coexistence . . . . . . . . . . . . . . . . . . 5 4. Virtual Private Networks in IPv4/IPv6 Dual-Stack Hosts/Networks . . . . . . . . . . . . . . . . . . . . . . . 6 5. Inadvertent VPN Tunnel Traffic Leakages in Legitimate Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. VPN Tunnel Traffic Leakage Attacks . . . . . . . . . . . . . 7 7. Mitigations to VPN Tunnel Traffic Leakage Vulnerabilities . . 8 7.1. Fixing VPN Client Software . . . . . . . . . . . . . . . 8 7.2. Operational Mitigations . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11
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 VPN tunnel traffic leakages -- that is, traffic meant to be transferred over a VPN tunnel could leak out of the VPN tunnel and be transmitted in the clear from the local network to the final destination, without employing the VPN services at all. Since this issue is specific to VPN solutions that route Layer 3 traffic, it is applicable to the following types of VPN technologies: o IPsec-based VPN tunnels o SSL/TLS VPN tunnels NOTE: see Section 2 for a definition and description of these terms. Section 2 clarifies the terminology employed throughout this document. Section 3 provides some background about IPv6 and IPv4 coexistence, summarizing how IPv6 and IPv4 interact on a typical dual-stacked network. Section 4 describes the underlying problem that leads to the aforementioned VPN traffic leakages. Section 5 describes legitimate scenarios in which such traffic leakages might occur, while Section 6 describes how VPN traffic leakages can be triggered by deliberate attacks. Finally, Section 7 discusses possible mitigations for the aforementioned issue.
SSL/TLS VPN portal: A front-end provided by the middlebox to add security to a normally unsecured site. An SSL/TLS VPN portal is typically application specific, wrapping the specific protocol, such as HTTP, to provide access to specific services on a network. In such a case, the SSL/TLS VPN portal would be accessed just like any HTTPS URL. SSL/TLS VPN portals are used when one wants to restrict access and only provide remote users to very specific services on the network. SSL/TLS VPN portals do not require an agent, and the policy is typically more liberal from organizations allowing access from anywhere via this access method. All other traffic on the system may be routed directly to the destination, whether it is IPv4, IPv6, or even other service level (HTTP) destination addresses. Our document focuses on Layer 3 VPNs that employ IPsec-based or SSL/ TLS-based tunnels, and excludes the so-called SSL/TLS VPN portals. Both IPsec-based and SSL/TLS-based VPN tunnels are designed to route Layer 3 traffic via the VPN tunnel through to the VPN tunnel server. Typically, these solutions are agent based, meaning that software is required on the client endpoint to establish the VPN tunnel and manage access control or routing rules. This provides an opportunity for controls to be managed through that application as well as on the client endpoint. NOTE: Further discussion of SSL-based VPNs can be found in [SSL-VPNs]. We note that, in addition to the general case of "send all traffic through the VPN", this document considers the so-called "split- tunnel" case, where some subset of the traffic is sent through the VPN, while other traffic is sent to its intended destination with a direct routing path (i.e., without employing the VPN tunnel). We note that many organizations will prevent split-tunneling in their VPN configurations if they would like to make sure the users data goes through a gateway with protections (malware detection, URL filtering, etc.), but others are more interested in performance of the user's access or the ability for researchers to have options to access sites they may not be able to through the gateway.
For example, consider a site (say, www.example.com) that has both IPv4 and IPv6 support. The corresponding domain name (www.example.com, in our case) will contain both A and AAAA DNS resource records (RRs). Each A record will contain one IPv4 address, while each AAAA record will contain one IPv6 address -- and there might be more than one instance of each of these record types. Thus, when a dual-stacked client application means to communicate with www.example.com, it can request both A and AAAA records and use any of the available addresses. The preferred address family (IPv4 or IPv6) and the specific address that will be used (assuming more than one address of each family is available) varies from one protocol implementation to another, with many host implementations preferring IPv6 addresses over IPv4 addresses. NOTE: [RFC6724] specifies an algorithm for selecting a destination address from a list of IPv6 and IPv4 addresses. [RFC6555] discusses the challenge of selecting the most appropriate destination address, along with a proposed implementation approach that mitigates connection-establishment delays. As a result of this "coexistence" between IPv6 and IPv4, when a dual- stacked client means to communicate with some other system, the availability of A and AAAA DNS resource records will typically affect which protocol is employed to communicate with that system.
RFC4861]. Such packets could be sent by employing standard software such as rtadvd [RTADVD], or by employing packet-crafting tools such as SI6 Network's IPv6 Toolkit [SI6-Toolkit] or THC's IPv6 Attack Toolkit [THC-IPv6]. Once IPv6 connectivity has been enabled, communications with dual-stacked systems could result in VPN tunnel traffic leakages, as previously described. While this attack may be useful enough (due to the increasing number of IPv6-enabled sites), it will only lead to traffic leakages when the destination system is dual-stacked. However, it is usually trivial for an attacker to trigger such VPN tunnel traffic leakages for any destination system: an attacker could simply advertise himself as the local recursive DNS server by sending forged Router Advertisement messages [RFC4861] that include the corresponding Recursive DNS Server (RDNSS) option [RFC6106], and then perform a DNS spoofing attack such that he can become a "man in the middle" and intercept the corresponding traffic. As with the previous attack scenario, packet-crafting tools such as [SI6-Toolkit] and [THC-IPv6] can readily perform this attack.
NOTE: Some systems are known to prefer IPv6-based recursive DNS servers over IPv4-based ones; hence, the "malicious" recursive DNS servers would be preferred over the legitimate ones advertised by the VPN server.
2. If IPv6 is supported in the VPN software, ensure that all IPv6 traffic is also sent via the VPN. NOTE: This would imply, among other things, properly handling any vectors that might be employed by an attacker to install IPv6 routes at the victim system (such as ICMPv6 Router Advertisement messages with Prefix Information Options or Route information Options [RFC4191], ICMPv6 Redirect messages, etc.). We note that properly handling all the aforementioned vectors may prove to be nontrivial. If the VPN client is configured to only send a subset of IPv4 traffic to the VPN tunnel (split-tunnel mode), then: 1. If the VPN client does not support IPv6, it should disable IPv6 support in all network interfaces. NOTE: As noted above, this should only be regarded as a temporary workaround, since the proper mitigation would be to correctly handle IPv6 traffic. 2. If the VPN client supports IPv6, it is the administrators responsibility to ensure that the correct corresponding sets of IPv4 and IPv6 networks get routed into the VPN tunnel. NOTE: As noted above, this would imply, among other things, properly handling any vectors that might be employed by an attacker to install IPv6 routes at the victim system. This may prove to be a nontrivial task. A network may prevent local attackers from successfully performing the aforementioned attacks against other local hosts by implementing First-Hop Security solutions such as Router Advertisement Guard (RA-Guard) [RFC6105] and DHCPv6-Shield [DHCPv6-SHIELD]. However, for obvious reasons, a host cannot and should not rely on this type of mitigations when connecting to an open network (cybercafe, etc.). NOTE: Besides, popular implementations of RA-Guard are known to be vulnerable to evasion attacks [RFC7113]. Finally, we note that if (eventually) IPv6-only VPN implementations become available, similar issues to the ones discussed in this document could arise if these IPv6-only VPN implementations do nothing about the IPv4 traffic.
Section 2 of this document. The author of this document would like to thank (in alphabetical order) Cameron Byrne, Spencer Dawkins, Gert Doering, Stephen Farrell, Seth Hall, Paul Hoffman, Tor Houghton, Russ Housley, Joel Jaeggli, Alastair Johnson, Merike Kaeo, Panos Kampanakis, Stephen Kent, Henrik Lund Kramshoj, Warren Kumari, Barry Leiba, Kathleen Moriarty, Thomas Osterried, Jim Small, Martin Vigoureux, and Andrew Yourtchenko for providing valuable comments on earlier draft versions of this document. The author wishes to express deep and heartfelt gratitude to Enrique Garcia and Vicenta Tejedo, for their precious love and support. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010. [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012. [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. [DHCPv6-SHIELD] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers", Work in Progress, July 2014. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011. [RFC7113] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, February 2014. [RTADVD] "rtadvd(8) manual page", <http://www.freebsd.org/cgi/ man.cgi?query=rtadvd&sektion=8>. [SI6-Toolkit] SI6 Networks, "SI6 Networks' IPv6 Toolkit", <http://www.si6networks.com/tools/ipv6toolkit>. [SSL-VPNs] Hoffman, P., "SSL VPNs: An IETF Perspective", IETF 72, SAAG Meeting, 2008, <http://www.ietf.org/proceedings/72/slides/saag-4.pdf>. [THC-IPv6] The Hacker's Choice, "THC-IPV6 - attacking the IPV6 protocol suite", <http://www.thc.org/thc-ipv6/>.