Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks
The information below is for an old version of the document.
This is an older version of an Internet-Draft that was ultimately published as RFC 7359.
|RFC stream||Internet Engineering Task Force (IETF)|
GENART Telechat review Almost Ready
GENART Telechat review (of -03) Almost Ready
GENART Last Call review (of -02) Almost Ready
SECDIR Last Call review (of -02) Has Issues
OPSDIR Last Call review (of -02) Has Nits
|Additional resources||Mailing list discussion|
|Stream||WG state||Submitted to IESG for Publication|
|Document shepherd||Warren "Ace" Kumari|
|Shepherd write-up||Show Last changed 2013-10-21|
|IESG||IESG state||IESG Evaluation::AD Followup|
Needs a YES.
|Responsible AD||Joel Jaeggli|
|Send notices email@example.com, firstname.lastname@example.org|
|IANA||IANA review state||Version Changed - Review Needed|
opsec F. Gont Internet-Draft Huawei Technologies Intended status: Informational March 3, 2014 Expires: September 4, 2014 Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks draft-ietf-opsec-vpn-leakages-04 Abstract The subtle way in which the IPv6 and IPv4 protocols co-exist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) products, may inadvertently result in VPN traffic leaks. That is, traffic meant to be transferred over an encrypted and integrity protected VPN connection may leak out of such connection and be sent in the clear on the local network towards the final destination. This document discusses some scenarios in which such VPN 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 4, 2014. 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 Gont Expires September 4, 2014 [Page 1] Internet-Draft VPN traffic leakages March 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. IPv4 and IPv6 co-existence . . . . . . . . . . . . . . . . . 4 4. Virtual Private Networks in IPv4/IPv6 dual-stack hosts/networks . . . . . . . . . . . . . . . . . . . . . . . 4 5. Inadvertent VPN traffic-leakages in legitimate scenarios . . 5 6. VPN traffic-leakage attacks . . . . . . . . . . . . . . . . . 5 7. Mitigations to VPN traffic-leakage vulnerabilities . . . . . 6 7.1. Fixing VPN client software . . . . . . . . . . . . . . . 6 7.2. Operational Mitigations . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction It is a very common practice for users to employ VPN software when employing a public (and possibly-rogue) local network. This is typically done not only to gain access to remote resources may not otherwise accessible from the public Internet, but also to secure the host's traffic against attackers that might be connected to the same local network as the victim host. The latter case constitutes the problem space of this document. Indeed, it is sometimes assumed that employing a VPN connection makes the use of insecure protocols (e.g., that transfer sensitive information in the clear) acceptable, as a VPN provides security services (such as data integrity and/or confidentiality) for all communications made over that VPN. However, this document illustrates that under certain circumstances, some traffic might not be mapped onto the VPN and thus be sent in the clear on the local network. Many VPN products that are typically employed for the aforementioned VPN connections only support the IPv4 protocol: that is, they perform the necessary actions such that IPv4 traffic is sent over the VPN connection, but they do nothing to secure IPv6 traffic originated Gont Expires September 4, 2014 [Page 2] Internet-Draft VPN traffic leakages March 2014 from (or being received at) the host employing the VPN client. However, the hosts themselves are typically dual-stacked: they support (and enable by default) both IPv4 and IPv6 (even if such IPv6 connectivity is simply "dormant" when they connect to IPv4-only networks). When the IPv6 connectivity of such hosts is enabled, they may end up employing an IPv6-unaware VPN client in a dual-stack network. This may have "unexpected" consequences, as explained below. The subtle way in which the IPv4 and IPv6 protocols interact and co- exist in dual-stacked networks might, either inadvertently or as a result of a deliberate attack, result in VPN traffic leakages -- that is, traffic meant to be transferred over a VPN connection could leak out of the VPN connection and be transmitted in the clear from the local network to the final destination, without employing the VPN services at all. Section 3 provides some background about IPv6 and IPv4 co-existence, 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. 2. Terminology When employing the term "Virtual Private Network" (or its acronym, "VPN"), this document refers to IPsec-based or TLS-based tunnels, where traffic is encapsulated and sent from a client to a middle-box, to access multiple network services (possibly employing different transport and/or application protocols). Our use of the term "Virtual Private Networks" excludes the so-called SSL/TLS VPN portals (a front-end provided by the middlebox to add security to a normally-unsecured site). 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 additionally considers the so-called "split-tunnel" case, where some subset of the traffic is sent through the VPN, while other traffic is send 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 Gont Expires September 4, 2014 [Page 3] Internet-Draft VPN traffic leakages March 2014 the user's access or the ability for researchers to have options to access sites they may not be able to through the gateway. 3. IPv4 and IPv6 co-existence The co-existence of the IPv4 and IPv6 protocols has a number of interesting and subtle aspects that may have "surprising" consequences. While IPv6 is not backwards-compatible with IPv4, the two protocols are "glued" together by the Domain Name System (DNS). 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 "co-existence" 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. 4. Virtual Private Networks in IPv4/IPv6 dual-stack hosts/networks Many Virtual Private Network (VPN) implementations do not support the IPv6 protocol -- or, what is worse, they completely ignore IPv6. This typically means that, when establishing a VPN connection, the VPN software takes care of the IPv4 connectivity by, e.g. inserting 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 (or completely ignored), any packets destined to an IPv6 address will be sent in the clear using the local IPv6 router. That is, the VPN software will do nothing about the IPv6 traffic. Gont Expires September 4, 2014 [Page 4] Internet-Draft VPN traffic leakages March 2014 The underlying reason for which these VPN leakages may occur is that, while IPv4 and IPv6 are two different protocols incompatible with each other, the two protocols are "glued" together by the Domain Name System. Therefore, for dual-stacked systems, it is not possible to secure the communication with another system without securing both protocols (IPv6 and IPv4). 5. Inadvertent VPN traffic-leakages in legitimate scenarios Consider a dual-stacked host that employs IPv4-only VPN software to establish a VPN connection with a VPN server, and that such host now connects to a dual-stacked network (that provides both IPv6 and IPv4 connectivity). If some application on the client means to communicate with a dual-stacked destination, the client will typically query both A and AAAA DNS resource records. Since the host will have both IPv4 and IPv6 connectivity, and the intended destination will have both A and AAAA DNS resource records, one of the possible outcomes is that the host will employ IPv6 to communicate with the intended destination. Since the VPN software does not support IPv6, the IPv6 traffic will not employ the VPN connection, and hence will have neither integrity nor confidentiality protection from the source host to the final destination. This could inadvertently expose sensitive traffic that was assumed to be secured by the VPN software. In this particular scenario, the resulting VPN traffic leakage is a side-effect of employing IPv6-unaware VPN software in a dual-stacked host/network. 6. VPN traffic-leakage attacks A local attacker could deliberately trigger IPv6 connectivity on the victim host by sending forged ICMPv6 Router Advertisement messages [RFC4861]. Such packets could be sent by employing standard software such as rtadvd [RTADVD], or by employing packet-crafting tools such as [SI6-Toolkit] or THC-IPv6 [THC-IPv6]. Once IPv6 connectivity has been enabled, communications with dual-stacked systems could result in VPN 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 leakages for any destination systems: an attacker could simply advertise himself as the local recursive DNS server by sending forged Router Advertisement messages [RFC4861] that include the corresponding 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. Gont Expires September 4, 2014 [Page 5] Internet-Draft VPN traffic leakages March 2014 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, and hence the "malicious" recursive DNS servers would be preferred over the legitimate ones advertised by the VPN server. 7. Mitigations to VPN traffic-leakage vulnerabilities 7.1. Fixing VPN client software There are a number of possible mitigations for the VPN traffic- leakage vulnerability discussed in this document. If the VPN client is configured by administrative decision to redirect all IPv4 traffic to the VPN, it should: 1. If IPv6 is not supported in the VPN software, disable IPv6 support in all network interfaces. NOTE: For IPv6-unaware VPN clients, the most simple mitigation (although not necessarily the most desirable one) would be to disable IPv6 support in all network interface cards when a VPN connection is meant to be employed. Thus, applications on the host running the VPN client software will have no other option than to employ IPv4, and hence they will simply not even try to send/process IPv6 traffic. 2. If IPv6 is supported in the VPN software, ensure that all IPv6 traffic is also sent via the VPN. 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. 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. Additionally, VPN clients that support IPv6 should mitigate all Neighbor Discovery (ND) attacks that may introduce new entries in the routing table, such as attacks based on forged Router Advertisement messages containing more specific routes [RFC4191], forged ICMPv6 Redirect messages, etc. Gont Expires September 4, 2014 [Page 6] Internet-Draft VPN traffic leakages March 2014 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 [I-D.ietf-opsec-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. 7.2. Operational Mitigations While the desired mitigation for the issues discussed in this document is for VPN clients to be IPv6-aware, we note that in scenarios where this would be unfeasible, and administrator may want to disable IPv6 connectivity on all network interfaces of the node employing the IPv6-unaware VPN client. 8. IANA Considerations This document has no actions for IANA. 9. Security Considerations This document discusses how traffic meant to be transferred over a VPN connection can leak out of the VPN, and hence appear in the clear on the local network. This is the result of employing IPv6-unaware VPN client software on dual-stacked hosts. Possible ways to mitigate this problem include fixing the VPN client software, or disabling IPv6 connectivity on all network interfaces when the previous option is not feasible. 10. Acknowledgements 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, Warren Kumari, Henrik Lund Kramshoj, Barry Leiba, Kathleen Moriarty, Thomas Osterried, Jim Small, Martin Vigoureux, and Andrew Yourtchenko for providing valuable comments on earlier versions of this document. Gont Expires September 4, 2014 [Page 7] Internet-Draft VPN traffic leakages March 2014 11. References 11.1. Normative References [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. [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012. 11.2. Informative References [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. [I-D.ietf-opsec-dhcpv6-shield] Gont, F., Will, W., and G. Velde, "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers", draft-ietf- opsec-dhcpv6-shield-02 (work in progress), February 2014. [SI6-Toolkit] "SI6 Networks' IPv6 toolkit", <http://www.si6networks.com/tools/ipv6toolkit>. [THC-IPv6] "The Hacker's Choice IPv6 Attack Toolkit", <http://www.thc.org/thc-ipv6/>. [RTADVD] "rtadvd(8) manual page", <http://www.freebsd.org/cgi/ man.cgi?query=rtadvd&sektion=8>. Gont Expires September 4, 2014 [Page 8] Internet-Draft VPN traffic leakages March 2014 [SSL-VPNs] Hoffman, P., "SSL VPNs: An IETF Perspective", IETF 72, SAAG Meeting., 2008, <http://www.ietf.org/proceedings/72/slides/saag-4.pdf>. Author's Address Fernando Gont Huawei Technologies Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Phone: +54 11 4650 8472 Email: email@example.com URI: http://www.si6networks.com Gont Expires September 4, 2014 [Page 9]