draft-ietf-opsec-vpn-leakages-06.txt   rfc7359.txt 
opsec F. Gont Internet Engineering Task Force (IETF) F. Gont
Internet-Draft Huawei Technologies Request for Comments: 7359 Huawei Technologies
Intended status: Informational April 24, 2014 Category: Informational August 2014
Expires: October 26, 2014 ISSN: 2070-1721
Layer-3 Virtual Private Network (VPN) tunnel traffic leakages in dual- Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages
stack hosts/networks in Dual-Stack Hosts/Networks
draft-ietf-opsec-vpn-leakages-06
Abstract Abstract
The subtle way in which the IPv6 and IPv4 protocols co-exist in The subtle way in which the IPv6 and IPv4 protocols coexist in
typical networks, together with the lack of proper IPv6 support in typical networks, together with the lack of proper IPv6 support in
popular Virtual Private Network (VPN) tunnel products, may popular Virtual Private Network (VPN) tunnel products, may
inadvertently result in VPN tunnel traffic leaks. That is, traffic inadvertently result in VPN tunnel traffic leakages. That is,
meant to be transferred over an encrypted and integrity protected VPN traffic meant to be transferred over an encrypted and integrity-
tunnel may leak out of such tunnel and be sent in the clear on the protected VPN tunnel may leak out of such a tunnel and be sent in the
local network towards the final destination. This document discusses clear on the local network towards the final destination. This
some scenarios in which such VPN tunnel traffic leakages may occur as document discusses some scenarios in which such VPN tunnel traffic
a result of employing IPv6-unaware VPN software. Additionally, this leakages may occur as a result of employing IPv6-unaware VPN
document offers possible mitigations for this issue. software. Additionally, this document offers possible mitigations
for this issue.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. 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.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc7359.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 26, 2014. 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 Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IPv4 and IPv6 co-existence . . . . . . . . . . . . . . . . . 5 3. IPv4 and IPv6 Coexistence . . . . . . . . . . . . . . . . . . 5
4. Virtual Private Networks in IPv4/IPv6 dual-stack 4. Virtual Private Networks in IPv4/IPv6 Dual-Stack
hosts/networks . . . . . . . . . . . . . . . . . . . . . . . 5 Hosts/Networks . . . . . . . . . . . . . . . . . . . . . . . 6
5. Inadvertent VPN tunnel traffic leakages in legitimate 5. Inadvertent VPN Tunnel Traffic Leakages in Legitimate
scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. VPN tunnel traffic leakage attacks . . . . . . . . . . . . . 6 6. VPN Tunnel Traffic Leakage Attacks . . . . . . . . . . . . . 7
7. Mitigations to VPN tunnel traffic leakage vulnerabilities . . 7 7. Mitigations to VPN Tunnel Traffic Leakage Vulnerabilities . . 8
7.1. Fixing VPN client software . . . . . . . . . . . . . . . 7 7.1. Fixing VPN Client Software . . . . . . . . . . . . . . . 8
7.2. Operational Mitigations . . . . . . . . . . . . . . . . . 8 7.2. Operational Mitigations . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
It is a very common practice for users to employ VPN software when It is a very common practice for users to employ VPN software when
employing a public (and possibly-rogue) local network. This is employing a public (and possibly rogue) local network. This is
typically done not only to gain access to remote resources that may typically done not only to gain access to remote resources that may
not otherwise be accessible from the public Internet, but also to not otherwise be accessible from the public Internet, but also to
secure the host's traffic against attackers that might be connected secure the host's traffic against attackers that might be connected
to the same local network as the victim host. The latter case to the same local network as the victim host. The latter case
constitutes the problem space of this document. Indeed, it is constitutes the problem space of this document. Indeed, it is
sometimes assumed that employing a VPN tunnel makes the use of sometimes assumed that employing a VPN tunnel makes the use of
insecure protocols (e.g., that transfer sensitive information in the insecure protocols (e.g., that transfer sensitive information in the
clear) acceptable, as a VPN tunnel provides security services (such clear) acceptable, as a VPN tunnel provides security services (such
as data integrity and/or confidentiality) for all communications made as data integrity and/or confidentiality) for all communications made
over it. However, this document illustrates that under certain over it. However, this document illustrates that under certain
circumstances, some traffic might not be mapped onto the VPN tunnel circumstances, some traffic might not be mapped onto the VPN tunnel
and thus be sent in the clear on the local network. and thus might be sent in the clear on the local network.
Many VPN products that are typically employed for the aforementioned Many VPN products that are typically employed for the aforementioned
VPN tunnels only support the IPv4 protocol: that is, they perform the VPN tunnels only support the IPv4 protocol: that is, they perform the
necessary actions such that IPv4 traffic is sent over the VPN tunnel, necessary actions such that IPv4 traffic is sent over the VPN tunnel,
but they do nothing to secure IPv6 traffic originated from (or being but they do nothing to secure IPv6 traffic originated from (or being
received at) the host employing the VPN client. However, the hosts received at) the host employing the VPN client. However, the hosts
themselves are typically dual-stacked: they support (and enable by themselves are typically dual-stacked: they support (and enable by
default) both IPv4 and IPv6 (even if such IPv6 connectivity is simply default) both IPv4 and IPv6 (even if such IPv6 connectivity is simply
"dormant" when they connect to IPv4-only networks). When the IPv6 "dormant" when they connect to IPv4-only networks). When the IPv6
connectivity of such hosts is enabled, they may end up employing an connectivity of such hosts is enabled, they may end up employing an
IPv6-unaware VPN client in a dual-stack network. This may have IPv6-unaware VPN client in a dual-stack network. This may have
"unexpected" consequences, as explained below. "unexpected" consequences, as explained below.
The subtle way in which the IPv4 and IPv6 protocols interact and co- The subtle way in which the IPv4 and IPv6 protocols interact and
exist in dual-stacked networks might, either inadvertently or as a coexist in dual-stacked networks might, either inadvertently or as a
result of a deliberate attack, result in VPN tunnel traffic leakages result of a deliberate attack, result in VPN tunnel traffic leakages
-- that is, traffic meant to be transferred over a VPN tunnel could -- 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 leak out of the VPN tunnel and be transmitted in the clear from the
local network to the final destination, without employing the VPN local network to the final destination, without employing the VPN
services at all. services at all.
Since this issue is specific to VPN solutions that route layer-3 Since this issue is specific to VPN solutions that route Layer 3
traffic, it is applicable to the following types of VPN technologies: traffic, it is applicable to the following types of VPN technologies:
o IPsec-based VPN tunnel o IPsec-based VPN tunnels
o SSL/TLS VPN tunnel o SSL/TLS VPN tunnels
NOTE: see Section 2 for a definition and description of these NOTE: see Section 2 for a definition and description of these
terms. terms.
Section 2 clarifies the terminology employed throughout this Section 2 clarifies the terminology employed throughout this
document. Section 3 provides some background about IPv6 and IPv4 co- document. Section 3 provides some background about IPv6 and IPv4
existence, summarizing how IPv6 and IPv4 interact on a typical dual- coexistence, summarizing how IPv6 and IPv4 interact on a typical
stacked network. Section 4 describes the underlying problem that dual-stacked network. Section 4 describes the underlying problem
leads to the aforementioned VPN traffic leakages. Section 5 that leads to the aforementioned VPN traffic leakages. Section 5
describes legitimate scenarios in which such traffic leakages might describes legitimate scenarios in which such traffic leakages might
occur, while Section 6 describes how VPN traffic leakages can be occur, while Section 6 describes how VPN traffic leakages can be
triggered by deliberate attacks. Finally, Section 7 discusses triggered by deliberate attacks. Finally, Section 7 discusses
possible mitigation for the aforementioned issue. possible mitigations for the aforementioned issue.
2. Terminology 2. Terminology
When employing the term "Virtual Private Network tunnel" (or "VPN When employing the term "Virtual Private Network tunnel" (or "VPN
tunnel"), this document refers to IPsec-based or SSL/TLS-based tunnel"), this document refers to VPN tunnels based on IPsec or SSL/
tunnels, where layer-3 packets are encapsulated and sent from a TLS, where Layer 3 packets are encapsulated and sent from a client to
client to a middle-box, to access multiple network services (possibly a middlebox, to access multiple network services (possibly employing
employing different transport and/or application protocols). different transport and/or application protocols).
IPsec-based VPN tunnels simply employ IPsec in tunnel mode to IPsec-based VPN tunnels simply employ IPsec in tunnel mode to
encapsulate ans transfer layer-3 packets over the VPN tunnel. On the encapsulate and transfer Layer 3 packets over the VPN tunnel. On the
other hand, the term "SSL/TLS-based VPN tunnels" warrants a other hand, the term "SSL/TLS-based VPN tunnels" warrants a
clarification, since two different technologies are usually referred clarification, since two different technologies are usually referred
to as "SSL/TLS VPN": to as "SSL/TLS VPN":
SSL VPN tunnel: SSL/TLS VPN tunnel:
A technology that encapsulates traffic from a client to a A technology that encapsulates traffic from a client to a
middlebox. In essence, an SSL/TLS VPN tunnel acts just like an middlebox. In essence, an SSL/TLS VPN tunnel acts just like an
IPsec-based tunnel, but instead employs SSL/TLS for encryption, IPsec-based tunnel, but instead employs SSL/TLS for encryption and
and some proprietary/unspecified mechanism for encapsulation and some proprietary/unspecified mechanism for encapsulation and
routing. routing.
SSL VPN portal: SSL/TLS VPN portal:
A front-end provided by the middlebox to add security to a A front-end provided by the middlebox to add security to a
normally-unsecured site. A TLS/SSL VPN portal is typically normally unsecured site. An SSL/TLS VPN portal is typically
application specific, wrapping the specific protocol, such as application specific, wrapping the specific protocol, such as
HTTP, to provide access to specific services on a network. In HTTP, to provide access to specific services on a network. In
such case, the SSL/TLS VPN portal would be accessed just like any such a case, the SSL/TLS VPN portal would be accessed just like
HTTPS URL. TLS/SSL VPN portals are used when one wants to any HTTPS URL. SSL/TLS VPN portals are used when one wants to
restrict access and only provide remote users to very specific restrict access and only provide remote users to very specific
services on the network. SSL/TLS VPN portals do not require an services on the network. SSL/TLS VPN portals do not require an
agent and the policy is typically more liberal from organizations agent, and the policy is typically more liberal from organizations
allowing access from anywhere via this access method. All other allowing access from anywhere via this access method. All other
traffic on the system may be routed directly to the destination, traffic on the system may be routed directly to the destination,
whether it is IPv4, IPv6, or even other service level (HTTP) whether it is IPv4, IPv6, or even other service level (HTTP)
destination addresses. destination addresses.
Our document focuses on layer-3 VPNs that employ IPsec-based or SSL/ 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. TLS-based tunnels, and excludes the so-called SSL/TLS VPN portals.
Both IPsec-basec and TLS/SSL-based VPN tunnels are designed to route Both IPsec-based and SSL/TLS-based VPN tunnels are designed to route
layer-3 traffic via de VPN tunnel through to VPN tunnel server. Layer 3 traffic via the VPN tunnel through to the VPN tunnel server.
Typically, these solutions are agent-based, meaning that software is Typically, these solutions are agent based, meaning that software is
required on the client end-point to establish the VPN tunnel and required on the client endpoint to establish the VPN tunnel and
manage access control or routing rules. This provides an opportunity manage access control or routing rules. This provides an opportunity
for controls to be managed through that application as well as on the for controls to be managed through that application as well as on the
client endpoint. client endpoint.
NOTE: Further discussion of SSL-based VPNs can be found in NOTE: Further discussion of SSL-based VPNs can be found in
[SSL-VPNs]. [SSL-VPNs].
We note that, in addition to the general case of "send all traffic We note that, in addition to the general case of "send all traffic
through the VPN", this document considers the so-called "split- through the VPN", this document considers the so-called "split-
tunnel" case, where some subset of the traffic is sent through the tunnel" case, where some subset of the traffic is sent through the
VPN, while other traffic is sent to its intended destination with a VPN, while other traffic is sent to its intended destination with a
direct routing path (i.e., without employing the VPN tunnel). We direct routing path (i.e., without employing the VPN tunnel). We
note that many organizations will prevent split-tunneling in their note that many organizations will prevent split-tunneling in their
VPN configurations if they would like to make sure the users data VPN configurations if they would like to make sure the users data
goes through a gateway with protections (malware detection, URL goes through a gateway with protections (malware detection, URL
filtering, etc.), but others are more interested in performance of filtering, etc.), but others are more interested in performance of
the user's access or the ability for researchers to have options to the user's access or the ability for researchers to have options to
access sites they may not be able to through the gateway. access sites they may not be able to through the gateway.
3. IPv4 and IPv6 co-existence 3. IPv4 and IPv6 Coexistence
The co-existence of the IPv4 and IPv6 protocols has a number of The coexistence of the IPv4 and IPv6 protocols has a number of
interesting and subtle aspects that may have "surprising" interesting and subtle aspects that may have "surprising"
consequences. While IPv6 is not backwards-compatible with IPv4, the consequences. While IPv6 is not backwards-compatible with IPv4, the
two protocols are "glued" together by the Domain Name System (DNS). two protocols are "glued" together by the Domain Name System (DNS).
For example, consider a site (say, www.example.com) that has both For example, consider a site (say, www.example.com) that has both
IPv4 and IPv6 support. The corresponding domain name IPv4 and IPv6 support. The corresponding domain name
(www.example.com, in our case) will contain both A and AAAA DNS (www.example.com, in our case) will contain both A and AAAA DNS
resource records (RRs). Each A record will contain one IPv4 address, resource records (RRs). Each A record will contain one IPv4 address,
while each AAAA record will contain one IPv6 address -- and there while each AAAA record will contain one IPv6 address -- and there
might be more than one instance of each of these record types. Thus, might be more than one instance of each of these record types. Thus,
when a dual-stacked client application means to communicate with when a dual-stacked client application means to communicate with
www.example.com, it can request both A and AAAA records, and use any www.example.com, it can request both A and AAAA records and use any
of the available addresses. The preferred address family (IPv4 or of the available addresses. The preferred address family (IPv4 or
IPv6) and the specific address that will be used (assuming more than IPv6) and the specific address that will be used (assuming more than
one address of each family is available) varies from one protocol one address of each family is available) varies from one protocol
implementation to another, with many host implementations preferring implementation to another, with many host implementations preferring
IPv6 addresses over IPv4 addresses. IPv6 addresses over IPv4 addresses.
NOTE: [RFC6724] specifies an algorithm for selecting a destination NOTE: [RFC6724] specifies an algorithm for selecting a destination
address from a list of IPv6 and IPv4 addresses. [RFC6555] address from a list of IPv6 and IPv4 addresses. [RFC6555]
discusses the challenge of selecting the most appropriate discusses the challenge of selecting the most appropriate
destination address, along with a proposed implementation approach destination address, along with a proposed implementation approach
that mitigates connection-establishment delays. that mitigates connection-establishment delays.
As a result of this "co-existence" between IPv6 and IPv4, when a As a result of this "coexistence" between IPv6 and IPv4, when a dual-
dual-stacked client means to communicate with some other system, the stacked client means to communicate with some other system, the
availability of A and AAAA DNS resource records will typically affect availability of A and AAAA DNS resource records will typically affect
which protocol is employed to communicate with that system. which protocol is employed to communicate with that system.
4. Virtual Private Networks in IPv4/IPv6 dual-stack hosts/networks 4. Virtual Private Networks in IPv4/IPv6 Dual-Stack Hosts/Networks
Many VPN tunnel implementations do not support the IPv6 protocol -- Many VPN tunnel implementations do not support the IPv6 protocol --
or, what is worse, they completely ignore IPv6. This typically means or, what is worse, they completely ignore IPv6. This typically means
that, once a VPN tunnel has been established, the VPN software takes that, once a VPN tunnel has been established, the VPN software takes
care of the IPv4 connectivity by, e.g. inserting an IPv4 default 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 route that causes all IPv4 traffic to be sent over the VPN tunnel (as
(as opposed to sending the traffic in the clear, employing the local opposed to sending the traffic in the clear, employing the local
router). However, if IPv6 is not supported (or completely ignored), router). However, if IPv6 is not supported (or completely ignored),
any packets destined to an IPv6 address will be sent in the clear 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 using the local IPv6 router. That is, the VPN software will do
nothing about the IPv6 traffic. nothing about the IPv6 traffic.
The underlying reason for which these VPN leakages may occur is that, The underlying reason for which these VPN leakages may occur is that,
for dual-stacked systems, it is not possible to secure the for dual-stacked systems, it is not possible to secure the
communication with another system without securing both protocols communication with another system without securing both protocols
(IPv6 and IPv4). Therefore, as long as the traffic for one of these (IPv6 and IPv4). Therefore, as long as the traffic for one of these
protocols is not secured, there is the potential for VPN traffic protocols is not secured, there is the potential for VPN traffic
leakages. leakages.
5. Inadvertent VPN tunnel traffic leakages in legitimate scenarios 5. Inadvertent VPN Tunnel Traffic Leakages in Legitimate Scenarios
Consider a dual-stacked host that employs IPv4-only VPN software to Consider a dual-stacked host that employs IPv4-only VPN software to
establish a VPN tunnel with a VPN server, and that such host now establish a VPN tunnel with a VPN server, and that said host now
connects to a dual-stacked network (that provides both IPv6 and IPv4 connects to a dual-stacked network (that provides both IPv6 and IPv4
connectivity). If some application on the client means to connectivity). If some application on the client means to
communicate with a dual-stacked destination, the client will communicate with a dual-stacked destination, the client will
typically query both A and AAAA DNS resource records. Since the host typically query both A and AAAA DNS resource records. Since the host
will have both IPv4 and IPv6 connectivity, and the intended will have both IPv4 and IPv6 connectivity, and the intended
destination will have both A and AAAA DNS resource records, one of destination will have both A and AAAA DNS resource records, one of
the possible outcomes is that the host will employ IPv6 to the possible outcomes is that the host will employ IPv6 to
communicate with the intended destination. Since the VPN software communicate with the intended destination. Since the VPN software
does not support IPv6, the IPv6 traffic will not employ the VPN does not support IPv6, the IPv6 traffic will not employ the VPN
connection, and hence will have neither integrity nor confidentiality tunnel; hence, it will have neither integrity nor confidentiality
protection from the source host to the final destination. protection from the source host to the final destination.
This could inadvertently expose sensitive traffic that was assumed to This could inadvertently expose sensitive traffic that was assumed to
be secured by the VPN software. In this particular scenario, the be secured by the VPN software. In this particular scenario, the
resulting VPN tunnel traffic leakage is a side-effect of employing resulting VPN tunnel traffic leakage is a side effect of employing
IPv6-unaware VPN software in a dual-stacked host/network. IPv6-unaware VPN software in a dual-stacked host/network.
6. VPN tunnel traffic leakage attacks 6. VPN Tunnel Traffic Leakage Attacks
A local attacker could deliberately trigger IPv6 connectivity on the A local attacker could deliberately trigger IPv6 connectivity on the
victim host by sending forged ICMPv6 Router Advertisement messages victim host by sending forged ICMPv6 Router Advertisement messages
[RFC4861]. Such packets could be sent by employing standard software [RFC4861]. Such packets could be sent by employing standard software
such as rtadvd [RTADVD], or by employing packet-crafting tools such such as rtadvd [RTADVD], or by employing packet-crafting tools such
as [SI6-Toolkit] or THC-IPv6 [THC-IPv6]. Once IPv6 connectivity has as SI6 Network's IPv6 Toolkit [SI6-Toolkit] or THC's IPv6 Attack
been enabled, communications with dual-stacked systems could result Toolkit [THC-IPv6]. Once IPv6 connectivity has been enabled,
in VPN tunnel traffic leakages, as previously described. 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 While this attack may be useful enough (due to the increasing number
of IPv6-enabled sites), it will only lead to traffic leakages when of IPv6-enabled sites), it will only lead to traffic leakages when
the destination system is dual-stacked. However, it is usually the destination system is dual-stacked. However, it is usually
trivial for an attacker to trigger such VPN tunnel traffic leakages trivial for an attacker to trigger such VPN tunnel traffic leakages
for any destination systems: an attacker could simply advertise for any destination system: an attacker could simply advertise
himself as the local recursive DNS server by sending forged Router himself as the local recursive DNS server by sending forged Router
Advertisement messages [RFC4861] that include the corresponding RDNSS Advertisement messages [RFC4861] that include the corresponding
option [RFC6106], and then perform a DNS spoofing attack such that he Recursive DNS Server (RDNSS) option [RFC6106], and then perform a DNS
can become a "Man in the Middle" and intercept the corresponding spoofing attack such that he can become a "man in the middle" and
traffic. As with the previous attack scenario, packet-crafting tools intercept the corresponding traffic. As with the previous attack
such as [SI6-Toolkit] and [THC-IPv6] can readily perform this 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 NOTE: Some systems are known to prefer IPv6-based recursive DNS
servers over IPv4-based ones, and hence the "malicious" recursive servers over IPv4-based ones; hence, the "malicious" recursive DNS
DNS servers would be preferred over the legitimate ones advertised servers would be preferred over the legitimate ones advertised by
by the VPN server. the VPN server.
7. Mitigations to VPN tunnel traffic leakage vulnerabilities 7. Mitigations to VPN Tunnel Traffic Leakage Vulnerabilities
At the time of this writing, a large number of VPN implementations At the time of this writing, a large number of VPN implementations
have not yet addressed the issue of VPN tunnel traffic leakages. have not yet addressed the issue of VPN tunnel traffic leakages.
Most of these implementations simply ignore IPv6, and hence IPv6 Most of these implementations simply ignore IPv6; hence, IPv6 traffic
traffic leaks out of the VPN tunnel. Some VPN-tunnel implementations leaks out of the VPN tunnel. Some VPN tunnel implementations handle
handle IPv6, but not properly. For example, they may be able to IPv6, but not properly. For example, they may be able to prevent
prevent inadvertent VPN tunnel traffic leakages arising in legitimate inadvertent VPN tunnel traffic leakages arising in legitimate dual-
dual-stack networks, but fail to properly handle the myriad of stack networks, but they may fail to properly handle the myriad of
vectors available to an attacker for injecting "more specific vectors available to an attacker for injecting "more specific
routes", such as ICMPv6 Router Advertisement messages with Prefix routes", such as ICMPv6 Router Advertisement messages with Prefix
Information Options and/or Route Information Options, and ICMPv6 Information Options and/or Route Information Options, and ICMPv6
Redirect messages. Redirect messages.
Clearly, the issue of VPN tunnel traffic leakages warrants proper Clearly, the issue of VPN tunnel traffic leakages warrants proper
IPv6 support in VPN tunnel implementations. IPv6 support in VPN tunnel implementations.
7.1. Fixing VPN client software 7.1. Fixing VPN Client Software
There are a number of possible mitigations for the VPN tunnel traffic There are a number of possible mitigations for the VPN tunnel traffic
leakage vulnerability discussed in this document. leakage vulnerability discussed in this document.
If the VPN client is configured by administrative decision to If the VPN client is configured by administrative decision to
redirect all IPv4 traffic to the VPN, it should: redirect all IPv4 traffic to the VPN, it should:
1. If IPv6 is not supported in the VPN software, disable IPv6 1. If IPv6 is not supported in the VPN software, disable IPv6
support in all network interfaces. support in all network interfaces.
NOTE: For IPv6-unaware VPN clients, the most simple mitigation NOTE: For IPv6-unaware VPN clients, the most simple mitigation
would be to disable IPv6 support in all network interface would be to disable IPv6 support in all network interface
cards when a VPN connection is meant to be employed. Thus, cards when a VPN tunnel is meant to be employed. Thus,
applications on the host running the VPN client software will applications on the host running the VPN client software will
have no other option than to employ IPv4, and hence they will have no other option than to employ IPv4; hence, they will
simply not even try to send/process IPv6 traffic. We note simply not even try to send/process IPv6 traffic. We note
that this should only be regarded as a temporary workaround, that this should only be regarded as a temporary workaround,
since the proper mitigation would be to correctly handle IPv6 since the proper mitigation would be to correctly handle IPv6
traffic. traffic.
2. If IPv6 is supported in the VPN software, ensure that all IPv6 2. If IPv6 is supported in the VPN software, ensure that all IPv6
traffic is also sent via the VPN. traffic is also sent via the VPN.
NOTE: This would imply, among other things, properly handling NOTE: This would imply, among other things, properly handling
any vectors that might be employed by an attacker to install any vectors that might be employed by an attacker to install
IPv6 routes at the victim system (such as ICMPv6 Router IPv6 routes at the victim system (such as ICMPv6 Router
Advertisement messages with Prefix Information Options or Advertisement messages with Prefix Information Options or
Route information Options [RFC4191], ICMPv6 Redirect messages, Route information Options [RFC4191], ICMPv6 Redirect messages,
etc.). We note that properly handling all the aforementioned etc.). We note that properly handling all the aforementioned
vectors may prove to be non-trivial. vectors may prove to be nontrivial.
If the VPN client is configured to only send a subset of IPv4 traffic If the VPN client is configured to only send a subset of IPv4 traffic
to the VPN tunnel (split-tunnel mode), then: to the VPN tunnel (split-tunnel mode), then:
1. If the VPN client does not support IPv6, it should disable IPv6 1. If the VPN client does not support IPv6, it should disable IPv6
support in all network interfaces. support in all network interfaces.
NOTE: As noted above, this should only be regarded as a NOTE: As noted above, this should only be regarded as a
temporary workaround, since the proper mitigation would be to temporary workaround, since the proper mitigation would be to
correctly handle IPv6 traffic. correctly handle IPv6 traffic.
2. If the VPN client supports IPv6, it is the administrators 2. If the VPN client supports IPv6, it is the administrators
responsibility to ensure that the correct corresponding sets of responsibility to ensure that the correct corresponding sets of
IPv4 and IPv6 networks get routed into the VPN tunnel. IPv4 and IPv6 networks get routed into the VPN tunnel.
NOTE: As noted above, this would imply, among other things, NOTE: As noted above, this would imply, among other things,
properly handling any vectors that might be employed by an properly handling any vectors that might be employed by an
attacker to install IPv6 routes at the victim system, and that attacker to install IPv6 routes at the victim system. This
this may prove to be a non-trivial task. may prove to be a nontrivial task.
A network may prevent local attackers from successfully performing A network may prevent local attackers from successfully performing
the aforementioned attacks against other local hosts by implementing the aforementioned attacks against other local hosts by implementing
First-Hop Security solutions such as Router Advertisement Guard (RA- First-Hop Security solutions such as Router Advertisement Guard
Guard) [RFC6105] and DHCPv6-Shield [I-D.ietf-opsec-dhcpv6-shield]. (RA-Guard) [RFC6105] and DHCPv6-Shield [DHCPv6-SHIELD]. However, for
However, for obvious reasons, a host cannot and should not rely on obvious reasons, a host cannot and should not rely on this type of
this type of mitigations when connecting to an open network mitigations when connecting to an open network (cybercafe, etc.).
(cybercafe, etc.).
NOTE: Besides, popular implementations of RA-Guard are known to be NOTE: Besides, popular implementations of RA-Guard are known to be
vulnerable to evasion attacks [RFC7113]. vulnerable to evasion attacks [RFC7113].
Finally, we note that if (eventually) IPv6-only VPN implementations Finally, we note that if (eventually) IPv6-only VPN implementations
become available, similar issues to the ones discussed in this become available, similar issues to the ones discussed in this
document could arise if these IPv6-only VPN implementations do document could arise if these IPv6-only VPN implementations do
nothing about the IPv4 traffic. nothing about the IPv4 traffic.
7.2. Operational Mitigations 7.2. Operational Mitigations
While the desired mitigation for the issues discussed in this While the desired mitigation for the issues discussed in this
document is for VPN clients to be IPv6-aware, we note that in document is for VPN clients to be IPv6 aware, we note that in
scenarios where this would be unfeasible, and administrator may want scenarios where this would be unfeasible, an administrator may want
to disable IPv6 connectivity on all network interfaces of the node to disable IPv6 connectivity on all network interfaces of the node
employing the IPv6-unaware VPN client. employing the IPv6-unaware VPN client.
8. IANA Considerations 8. Security Considerations
This document has no actions for IANA.
9. Security Considerations
This document discusses how traffic meant to be transferred over a This document discusses how traffic meant to be transferred over a
VPN tunnel can leak out of such tunnel, and hence appear in the clear VPN tunnel can leak out of such a tunnel and, hence, appear in the
on the local network. This is the result of employing IPv6-unaware clear on the local network. This is the result of employing
VPN client software on dual-stacked hosts. IPv6-unaware VPN client software on dual-stacked hosts.
The proper mitigation of this issue is to correctly handle IPv6 The proper mitigation of this issue is to correctly handle IPv6
traffic in the VPN client software. However, in scenarios in which traffic in the VPN client software. However, in scenarios in which
such mitigation is unfeasible, an administrator may choose to disable such a mitigation is unfeasible, an administrator may choose to
IPv6 connectivity on all network interfaces of the host employing the disable IPv6 connectivity on all network interfaces of the host
VPN client. employing the VPN client.
10. Acknowledgements 9. Acknowledgements
The author would like to thank Kathleen Moriarty and Paul Hoffman who The author would like to thank Kathleen Moriarty and Paul Hoffman who
contributed text that was readily incorporated into Section 2 of this contributed text that was readily incorporated into Section 2 of this
document. document.
The author of this document would like to thank (in alphabetical The author of this document would like to thank (in alphabetical
order) Cameron Byrne, Spencer Dawkins, Gert Doering, Stephen Farrell, order) Cameron Byrne, Spencer Dawkins, Gert Doering, Stephen Farrell,
Seth Hall, Paul Hoffman, Tor Houghton, Russ Housley, Joel Jaeggli, Seth Hall, Paul Hoffman, Tor Houghton, Russ Housley, Joel Jaeggli,
Alastair Johnson, Merike Kaeo, Panos Kampanakis, Stephen Kent, Warren Alastair Johnson, Merike Kaeo, Panos Kampanakis, Stephen Kent, Henrik
Kumari, Henrik Lund Kramshoj, Barry Leiba, Kathleen Moriarty, Thomas Lund Kramshoj, Warren Kumari, Barry Leiba, Kathleen Moriarty, Thomas
Osterried, Jim Small, Martin Vigoureux, and Andrew Yourtchenko for Osterried, Jim Small, Martin Vigoureux, and Andrew Yourtchenko for
providing valuable comments on earlier versions of this document. providing valuable comments on earlier draft versions of this
document.
11. References The author wishes to express deep and heartfelt gratitude to Enrique
Garcia and Vicenta Tejedo, for their precious love and support.
11.1. Normative References 10. References
10.1. Normative References
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010. 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, [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012. (IPv6)", RFC 6724, September 2012.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 10.2. Informative References
Dual-Stack Hosts", RFC 6555, April 2012.
11.2. Informative References [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. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
February 2011. February 2011.
[RFC7113] Gont, F., "Implementation Advice for IPv6 Router [RFC7113] Gont, F., "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)", RFC 7113, February 2014. Advertisement Guard (RA-Guard)", RFC 7113, February 2014.
[I-D.ietf-opsec-dhcpv6-shield] [RTADVD] "rtadvd(8) manual page", <http://www.freebsd.org/cgi/
Gont, F., Will, W., and G. Velde, "DHCPv6-Shield: man.cgi?query=rtadvd&sektion=8>.
Protecting Against Rogue DHCPv6 Servers", draft-ietf-
opsec-dhcpv6-shield-02 (work in progress), February 2014.
[SI6-Toolkit] [SI6-Toolkit]
"SI6 Networks' IPv6 toolkit", SI6 Networks, "SI6 Networks' IPv6 Toolkit",
<http://www.si6networks.com/tools/ipv6toolkit>. <http://www.si6networks.com/tools/ipv6toolkit>.
[THC-IPv6] [SSL-VPNs] Hoffman, P., "SSL VPNs: An IETF Perspective", IETF 72,
"The Hacker's Choice IPv6 Attack Toolkit", SAAG Meeting, 2008,
<http://www.thc.org/thc-ipv6/>.
[RTADVD] "rtadvd(8) manual page", <http://www.freebsd.org/cgi/
man.cgi?query=rtadvd&sektion=8>.
[SSL-VPNs]
Hoffman, P., "SSL VPNs: An IETF Perspective", IETF 72,
SAAG Meeting., 2008,
<http://www.ietf.org/proceedings/72/slides/saag-4.pdf>. <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 Author's Address
Fernando Gont Fernando Gont
Huawei Technologies Huawei Technologies
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fgont@si6networks.com EMail: fgont@si6networks.com
URI: http://www.si6networks.com URI: http://www.si6networks.com
 End of changes. 67 change blocks. 
155 lines changed or deleted 168 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/