RFC 7359

Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks

📅 published August 2014, from ietf

RFC 7359: Layer 3 VPN Tunnel Traffic Leakages in Dual-Stack Hosts/Networks 🎀

Okay bestie, this one is from F. Gont at Huawei Technologies, dated August 2014. It's marked Informational 💅, so it's giving "here's a heads-up," not "you must do this." It's published under ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so it's a standalone vibe ✨.

Abstract ✨

So IPv6 and IPv4 live together in most networks, and lots of popular VPN tunnel products don't really handle IPv6 yet 😭. That combo can accidentally cause VPN tunnel traffic leakages. Basically, stuff that's supposed to travel through an encrypted, integrity-protected VPN tunnel escapes and gets sent in the clear on the local network to its final destination. This doc walks through some scenarios where that happens because the VPN software is IPv6-unaware, and it also suggests some mitigations 🛡️.

Status of This Memo 📝

This document is not an Internet Standards Track specification. It's published for informational purposes 🌸.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🤓.

For the current status, any errata, and how to give feedback, head to http://www.rfc-editor.org/info/rfc7359 🔗.

IESG Note 🚩

This is the part where the IESG gets a little spicy 🌶️. The document describes information leakage in VPN software and blames it on the software not being able to handle IPv6. The IESG doesn't think that's the right way to frame it.

They agree that if a device supports more than one address family, not being able to apply policy across all of them is a defect. But inadvertent or maliciously induced leakage can also happen because of any unencrypted interface on the system, including split tunnel configurations inside the VPN software itself. Some attacks are unique to an IPv6 interface, sure, but this kind of leakage is a general problem, not something that only shows up with IPv6-unaware VPN software. So the IESG says the document doesn't adequately cover the general issue 💀.

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) as they stand on the publication date. Read those carefully, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🎀.

Table of Contents 🗂️

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

1. Introduction 🦋

Everyone's using VPNs on sketchy public Wi-Fi these days 📶. People do it to reach remote resources that aren't reachable from the public Internet, but also to protect their traffic from attackers sitting on that same local network. The second reason is the problem space of this document 🕵️‍♀️.

It's sometimes assumed that once you're in a VPN tunnel, using insecure protocols (the ones that send sensitive stuff in the clear) is totally fine, since the tunnel gives data integrity and/or confidentiality for everything. But this document shows that in some situations, certain traffic doesn't actually get mapped onto the tunnel, and it ends up sent in the clear on the local network. Not it 😭.

Lots of VPN products only support IPv4. They make sure IPv4 traffic goes through the tunnel, but they do nothing to protect IPv6 traffic that the host sends or receives while using the VPN client 🙈. Meanwhile, hosts are usually dual-stacked. They support both IPv4 and IPv6, and they have both enabled by default, even though IPv6 might just be "dormant" when they connect to an IPv4-only network 💤. So once IPv6 connectivity is turned on, a host can end up running an IPv6-unaware VPN client on a dual-stack network. That can have "unexpected" consequences, which we'll get into below 👀.

How IPv4 and IPv6 interact on dual-stacked networks is subtle 🧠. Accidentally, or because someone attacked on purpose, that interaction can cause VPN tunnel traffic leakages. In other words, traffic meant for the VPN could slip out of the tunnel and get transmitted in the clear from the local network to its final destination, without using VPN services at all. Literally a total fail 💀.

This issue is specific to VPN solutions that route Layer 3 traffic, so it applies to these VPN technologies:

  • IPsec-based VPN tunnels 🔐
  • SSL/TLS VPN tunnels 🔒

NOTE: see Section 2 for a definition and description of these terms.

Section 2 is the terminology bit 📚. Section 3 gives some background on how IPv6 and IPv4 coexist, and how they interact on a typical dual-stacked network 🌐. Section 4 describes the underlying problem that causes these leakages ✨. Section 5 covers legitimate scenarios where leakages might happen, and Section 6 covers how deliberate attacks can trigger them 😈. Finally, Section 7 talks about how to mitigate all of this 🛠️.

2. Terminology 📖

When this doc says "Virtual Private Network tunnel" (or "VPN tunnel"), it means VPN tunnels built on IPsec or SSL/TLS. In these tunnels, Layer 3 packets get encapsulated and sent from a client to a middlebox, so the client can reach multiple network services. Those services might use different transport and/or application protocols 🎀.

IPsec-based VPN tunnels just use IPsec in tunnel mode to encapsulate and move Layer 3 packets over the tunnel 🔐. SSL/TLS-based VPN tunnels need a bit more explaining, though, because people use "SSL/TLS VPN" to mean two totally different things 👯‍♀️:

SSL/TLS VPN tunnel: A technology that encapsulates traffic from a client to a middlebox. Basically, an SSL/TLS VPN tunnel acts just like an IPsec-based tunnel, except it uses SSL/TLS for encryption, plus some proprietary or unspecified mechanism for encapsulation and routing 🧩.

SSL/TLS VPN portal: A front-end that a middlebox provides to add security to a site that would otherwise be unsecured 🚪. An SSL/TLS VPN portal is usually application-specific, wrapping a particular protocol such as HTTP so you can reach specific services on a network. You access it just like any HTTPS URL 🌍. Portals are used when someone wants to restrict access and only give remote users access to very specific services on the network. They don't need an agent, and the policy is usually more relaxed for organizations that allow access from anywhere through this method. All other traffic on the system can be routed directly to its destination, whether that's IPv4, IPv6, or even another service-level (HTTP) destination address 💫.

This document focuses on Layer 3 VPNs that use IPsec-based or SSL/TLS-based tunnels. It leaves out the so-called SSL/TLS VPN portals 🚫.

Both IPsec-based and SSL/TLS-based VPN tunnels are built to route Layer 3 traffic through the tunnel to the VPN tunnel server 🚇. These solutions are usually agent-based, which means the client endpoint needs software to set up the tunnel and to manage access control or routing rules. That gives the application a chance to manage controls, and the client endpoint can handle some controls too 🎛️.

NOTE: Further discussion of SSL-based VPNs can be found in [SSL-VPNs].

This document also looks at the so-called "split-tunnel" case, not just the general "send all traffic through the VPN" case 🍓. In a split tunnel, some subset of the traffic goes through the VPN, while the rest goes directly to its intended destination over a direct routing path (so, without the tunnel). Lots of organizations block split-tunneling so they can make sure users' data goes through a gateway with protections like malware detection and URL filtering 🛡️. Others care more about the performance of the user's access, or they want researchers to be able to reach sites they might not be able to get to through the gateway 🔬.

3. IPv4 and IPv6 Coexistence ✨

okay bestie, so IPv4 and IPv6 living side by side is lowkey one of the most chaotic, plot-twisty parts of the whole internet 💅. IPv6 is NOT backwards-compatible with IPv4, like at all, but the two get "glued" together by the Domain Name System (DNS) 🧚. The DNS is literally the matchmaker here 💖.

Picture a site, say www.example.com, that supports both IPv4 and IPv6 🌸. That name gets both A and AAAA DNS resource records (RRs) 🎀. Each A record holds one IPv4 address, each AAAA record holds one IPv6 address, and there can be more than one of each type 🦋. So when a dual-stacked client app wants to talk to www.example.com, it can ask for both A and AAAA records and use whichever addresses it has available 💜. Which family gets picked (IPv4 or IPv6), and which exact address gets used (if there's more than one of a family), depends on the protocol implementation 👑. Lots of host implementations are obsessed with IPv6 and prefer it over IPv4 🌈.

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. 🫶

So yeah, this "coexistence" thing means that when a dual-stacked client wants to reach some other system, whether it has A and AAAA records will usually decide which protocol gets used to talk to it 🔥. Iconic behaviour, honestly 😭.

4. Virtual Private Networks in IPv4/IPv6 Dual-Stack Hosts/Networks 🔐

ngl, a lot of VPN tunnel implementations don't support IPv6 🙈. Or even worse, they completely ignore it 💀. Usually, once the tunnel is up, the VPN software handles the IPv4 side by, e.g., inserting an IPv4 default route so all IPv4 traffic goes through the tunnel 🦋. The alternative would be sending that traffic in the clear through the local router. But if IPv6 isn't supported (or gets ignored), any packet headed for an IPv6 address goes out in the clear through the local IPv6 router 😱. The VPN software just does nothing about the IPv6 traffic. Not it 🙅‍♀️.

Why does this leak happen? For dual-stacked systems, you can't secure communication with another system without securing both protocols (IPv6 and IPv4) 🍓. So as long as the traffic for one of these protocols isn't secured, there's potential for VPN traffic leakage 💜.

5. Inadvertent VPN Tunnel Traffic Leakages in Legitimate Scenarios 🌸

Let's say we've got a dual-stacked host running IPv4-only VPN software 💅. It sets up a VPN tunnel with a VPN server, then connects to a dual-stacked network (one that offers both IPv6 and IPv4) 🌐. If an app on the client wants to reach a dual-stacked destination, the client will usually query both A and AAAA records 🎀. The host has both IPv4 and IPv6 connectivity, and the destination has both kinds of records, so one possible outcome is that the host uses IPv6 to reach the destination ✨. Since the VPN software doesn't support IPv6, that IPv6 traffic skips the tunnel 😭. That means it gets neither integrity nor confidentiality protection from the source host to the final destination 💀.

This can accidentally expose sensitive traffic that everyone assumed was locked down by the VPN 🙈. In this case, the leak is just a side effect of using IPv6-unaware VPN software on a dual-stacked host or network 🫠.

6. VPN Tunnel Traffic Leakage Attacks 🚨

A local attacker could deliberately trigger IPv6 connectivity on the victim host by sending forged ICMPv6 Router Advertisement messages [RFC4861] 😈. They could use standard software like rtadvd [RTADVD], or packet-crafting tools like SI6 Network's IPv6 Toolkit [SI6-Toolkit] or THC's IPv6 Attack Toolkit [THC-IPv6] 🧰. Once IPv6 is enabled, talking to dual-stacked systems can cause VPN tunnel traffic leakage, like we just covered 💔.

This attack is useful enough (there are more and more IPv6-enabled sites, after all) 📈, but it only causes leaks when the destination is dual-stacked 🤔. Still, it's usually super easy for an attacker to trigger leaks for any destination 😬. The attacker can simply advertise themselves as the local recursive DNS server by sending forged Router Advertisement messages [RFC4861] that include the Recursive DNS Server (RDNSS) option [RFC6106] 👀. Then they perform a DNS spoofing attack so they become a "man in the middle" and intercept the traffic 😈💀. Same as the previous scenario, [SI6-Toolkit] and [THC-IPv6] can do this pretty readily 🧪.

NOTE: Some systems are known to prefer IPv6-based recursive DNS servers over IPv4-based ones 🤯. So the "malicious" recursive DNS servers would get picked over the legitimate ones the VPN server advertised 😭.

7. Mitigations to VPN Tunnel Traffic Leakage Vulnerabilities 🛡️

As of this writing, a huge number of VPN implementations still haven't fixed VPN tunnel traffic leakage 😩. Most of them just ignore IPv6, so IPv6 traffic leaks right out of the tunnel 🫣. Some VPN tunnel implementations do handle IPv6, but not properly 🙃. For example, they might stop leaks in legit dual-stack networks, but fail to handle the whole mess of ways an attacker can inject "more specific routes" 🕸️. Those include ICMPv6 Router Advertisement messages with Prefix Information Options and/or Route Information Options, plus ICMPv6 Redirect messages 🌀.

Clearly, VPN tunnel traffic leakage calls for proper IPv6 support in VPN tunnel implementations 👑✨.

7.1. Fixing VPN Client Software 💻

There are a bunch of possible mitigations for the VPN tunnel traffic leakage vulnerability covered in this document 🎀.

If the VPN client is set up 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 simplest mitigation is to disable IPv6 support in all network interface cards when a VPN tunnel is meant to be used 🙌. Then applications on the host running the VPN client have no choice but to use IPv4, so they won't even try to send or process IPv6 traffic 💅. This should only be treated as a temporary workaround 🩹, since the proper fix is to correctly handle IPv6 traffic 💖.
  1. If IPv6 is supported in the VPN software, make sure all IPv6 traffic also goes through the VPN.
NOTE: This means, among other things, properly handling any vectors an attacker might use to install IPv6 routes on the victim system (such as ICMPv6 Router Advertisement messages with Prefix Information Options or Route information Options [RFC4191], ICMPv6 Redirect messages, etc.) 🕵️‍♀️. Handling all of these vectors properly may turn out 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 is still to correctly handle IPv6 traffic 💜.
  1. 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 means, among other things, properly handling any vectors an attacker might use to install IPv6 routes on the victim system 🫠. This may prove to be a nontrivial task 😭.

A network can stop local attackers from pulling off the attacks above against other local hosts by running First-Hop Security solutions such as Router Advertisement Guard (RA-Guard) [RFC6105] and DHCPv6-Shield [DHCPv6-SHIELD] 🔒. But for obvious reasons, a host cannot and should not rely on this kind of mitigation when connecting to an open network (a cybercafe, etc.) 🚫☕.

NOTE: Besides, popular implementations of RA-Guard are known to be vulnerable to evasion attacks [RFC7113] 😬.

Finally, if IPv6-only VPN implementations show up (eventually), similar issues to the ones in this document could arise if those IPv6-only VPN implementations do nothing about the IPv4 traffic 👀.

7.2. Operational Mitigations 🛠️

The ideal fix for the issues in this document is for VPN clients to be IPv6 aware 💖. But where that's unfeasible, an administrator may want to disable IPv6 connectivity on all network interfaces of the node running the IPv6-unaware VPN client 🫶.

8. Security Considerations 🚨🔐

This document talks about how traffic meant for a VPN tunnel can leak out of that tunnel and show up in the clear on the local network 😱. This happens when IPv6-unaware VPN client software runs on dual-stacked hosts 💀.

The proper fix is to correctly handle IPv6 traffic in the VPN client software 👑. But if that's unfeasible, an administrator may choose to disable IPv6 connectivity on all network interfaces of the host running the VPN client 🙏.

9. Acknowledgements 💌

The author would like to thank Kathleen Moriarty and Paul Hoffman, who contributed text that was readily incorporated into 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 also wishes to express deep and heartfelt gratitude to Enrique Garcia and Vicenta Tejedo, for their precious love and support 🥹💜.

10. References 📚

10.1. Normative References ✨

okay bestie, these are the normative refs, the ones you need to actually read to follow the spec 📚🫶

[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.

10.2. Informative References 🌸

these ones are the extra reading 🧚 background, tools, and talks that are super useful but not required to get the core idea 💅

[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/>.

Author's Address 💖

Fernando Gont
Huawei Technologies
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires  1706
Argentina

Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI:   http://www.si6networks.com
📦 where this page comes from