draft-ietf-opsec-vpn-leakages-04.txt   draft-ietf-opsec-vpn-leakages-05.txt 
opsec F. Gont opsec F. Gont
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational March 3, 2014 Intended status: Informational April 24, 2014
Expires: September 4, 2014 Expires: October 26, 2014
Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ Layer-3 Virtual Private Network (VPN) tunnel traffic leakages in dual-
networks stack hosts/networks
draft-ietf-opsec-vpn-leakages-04 draft-ietf-opsec-vpn-leakages-05
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 co-exist 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) products, may inadvertently popular Virtual Private Network (VPN) tunnel products, may
result in VPN traffic leaks. That is, traffic meant to be inadvertently result in VPN tunnel traffic leaks. That is, traffic
transferred over an encrypted and integrity protected VPN connection meant to be transferred over an encrypted and integrity protected VPN
may leak out of such connection and be sent in the clear on the local tunnel may leak out of such tunnel and be sent in the clear on the
network towards the final destination. This document discusses some local network towards the final destination. This document discusses
scenarios in which such VPN leakages may occur as a result of some scenarios in which such VPN tunnel traffic leakages may occur as
employing IPv6-unaware VPN software. Additionally, this document a result of employing IPv6-unaware VPN software. Additionally, this
offers possible mitigations for this issue. 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 4, 2014. This Internet-Draft will expire on October 26, 2014.
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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IPv4 and IPv6 co-existence . . . . . . . . . . . . . . . . . 4 3. IPv4 and IPv6 co-existence . . . . . . . . . . . . . . . . . 4
4. Virtual Private Networks in IPv4/IPv6 dual-stack 4. Virtual Private Networks in IPv4/IPv6 dual-stack
hosts/networks . . . . . . . . . . . . . . . . . . . . . . . 4 hosts/networks . . . . . . . . . . . . . . . . . . . . . . . 5
5. Inadvertent VPN traffic-leakages in legitimate scenarios . . 5 5. Inadvertent VPN tunnel traffic leakages in legitimate
6. VPN traffic-leakage attacks . . . . . . . . . . . . . . . . . 5 scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Mitigations to VPN traffic-leakage vulnerabilities . . . . . 6 6. VPN tunnel traffic leakage attacks . . . . . . . . . . . . . 6
7.1. Fixing VPN client software . . . . . . . . . . . . . . . 6 7. Mitigations to VPN tunnel traffic leakage vulnerabilities . . 6
7.2. Operational Mitigations . . . . . . . . . . . . . . . . . 7 7.1. Fixing VPN client software . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7.2. Operational Mitigations . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9
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 may not typically done not only to gain access to remote resources that may
otherwise accessible from the public Internet, but also to secure the not otherwise be accessible from the public Internet, but also to
host's traffic against attackers that might be connected to the same secure the host's traffic against attackers that might be connected
local network as the victim host. The latter case constitutes the to the same local network as the victim host. The latter case
problem space of this document. Indeed, it is sometimes assumed that constitutes the problem space of this document. Indeed, it is
employing a VPN connection makes the use of insecure protocols (e.g., sometimes assumed that employing a VPN tunnel makes the use of
that transfer sensitive information in the clear) acceptable, as a insecure protocols (e.g., that transfer sensitive information in the
VPN provides security services (such as data integrity and/or clear) acceptable, as a VPN tunnel provides security services (such
confidentiality) for all communications made over that VPN. However, as data integrity and/or confidentiality) for all communications made
this document illustrates that under certain circumstances, some over it. However, this document illustrates that under certain
traffic might not be mapped onto the VPN and thus be sent in the circumstances, some traffic might not be mapped onto the VPN tunnel
clear on the local network. and thus 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 connections only support the IPv4 protocol: that is, they perform VPN tunnels only support the IPv4 protocol: that is, they perform the
the necessary actions such that IPv4 traffic is sent over the VPN necessary actions such that IPv4 traffic is sent over the VPN tunnel,
connection, but they do nothing to secure IPv6 traffic originated but they do nothing to secure IPv6 traffic originated from (or being
from (or being received at) the host employing the VPN client. received at) the host employing the VPN client. However, the hosts
However, the hosts themselves are typically dual-stacked: they themselves are typically dual-stacked: they support (and enable by
support (and enable by default) both IPv4 and IPv6 (even if such IPv6 default) both IPv4 and IPv6 (even if such IPv6 connectivity is simply
connectivity is simply "dormant" when they connect to IPv4-only "dormant" when they connect to IPv4-only networks). When the IPv6
networks). When the IPv6 connectivity of such hosts is enabled, they connectivity of such hosts is enabled, they may end up employing an
may end up employing an IPv6-unaware VPN client in a dual-stack IPv6-unaware VPN client in a dual-stack network. This may have
network. This may have "unexpected" consequences, as explained "unexpected" consequences, as explained below.
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 co-
exist in dual-stacked networks might, either inadvertently or as a exist in dual-stacked networks might, either inadvertently or as a
result of a deliberate attack, result in VPN traffic leakages -- that result of a deliberate attack, result in VPN tunnel traffic leakages
is, traffic meant to be transferred over a VPN connection could leak -- that is, traffic meant to be transferred over a VPN tunnel could
out of the VPN connection 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.
Section 3 provides some background about IPv6 and IPv4 co-existence, Section 2 clarifies the terminology employed throughout this
summarizing how IPv6 and IPv4 interact on a typical dual-stacked document. Section 3 provides some background about IPv6 and IPv4 co-
network. Section 4 describes the underlying problem that leads to existence, summarizing how IPv6 and IPv4 interact on a typical dual-
the aforementioned VPN traffic leakages. Section 5 describes stacked network. Section 4 describes the underlying problem that
legitimate scenarios in which such traffic leakages might occur, leads to the aforementioned VPN traffic leakages. Section 5
while Section 6 describes how VPN traffic leakages can be triggered describes legitimate scenarios in which such traffic leakages might
by deliberate attacks. occur, while Section 6 describes how VPN traffic leakages can be
triggered by deliberate attacks. Finally, Section 7 discusses
possible mitigation for the aforementioned issue.
2. Terminology 2. Terminology
When employing the term "Virtual Private Network" (or its acronym, When employing the term "Virtual Private Network tunnel" (or "VPN
"VPN"), this document refers to IPsec-based or TLS-based tunnels, tunnel"), this document refers to IPsec-based or SSL/TLS-based
where traffic is encapsulated and sent from a client to a middle-box, tunnels, where layer-3 packets are encapsulated and sent from a
to access multiple network services (possibly employing different client to a middle-box, to access multiple network services (possibly
transport and/or application protocols). employing different transport and/or application protocols).
Our use of the term "Virtual Private Networks" excludes the so-called IPsec-based VPN tunnels simply employ IPsec in tunnel mode to
SSL/TLS VPN portals (a front-end provided by the middlebox to add encapsulate ans transfer layer-3 packets over the VPN tunnel. On the
security to a normally-unsecured site). Further discussion of SSL- other hand, the term "SSL/TLS-based VPN tunnels" warrants a
based VPNs can be found in [SSL-VPNs]. clarification, since two different technologies are usually referred
to as "SSL/TLS VPN":
SSL VPN tunnel: A technology that encapsulates traffic from a client
to a middlebox. In essence, an SSL/TLS VPN tunnel acts just like
an IPsec-tunnel client and server, but instead employs SSL/TLS for
encryption, and some proprietary/unspecified mechanism for
encapsulation and routing.
SSL VPN portal: A front-end provided by the middlebox to add
security to a normally-unsecured site. The VPN portal is accessed
just like any HTTPS URL.
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.
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 We note that, in addition to the general case of "send all traffic
through the VPN", this document additionally considers the so-called through the VPN", this document considers the so-called "split-
"split-tunnel" case, where some subset of the traffic is sent through tunnel" case, where some subset of the traffic is sent through the
the VPN, while other traffic is send to its intended destination with VPN, while other traffic is sent to its intended destination with a
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 co-existence
The co-existence of the IPv4 and IPv6 protocols has a number of The co-existence of the IPv4 and IPv6 protocols has a number of
skipping to change at page 4, line 41 skipping to change at page 5, line 12
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 "co-existence" between IPv6 and IPv4, when a
dual-stacked client means to communicate with some other system, the dual-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 Virtual Private Network (VPN) implementations do not support the Many VPN tunnel implementations do not support the IPv6 protocol --
IPv6 protocol -- or, what is worse, they completely ignore IPv6. or, what is worse, they completely ignore IPv6. This typically means
This typically means that, when establishing a VPN connection, the that, once a VPN tunnel has been established, the VPN software takes
VPN software takes care of the IPv4 connectivity by, e.g. inserting care of the IPv4 connectivity by, e.g. inserting an IPv4 default
an IPv4 default route that causes all IPv4 traffic to be sent over route that causes all IPv4 traffic to be sent over the VPN connection
the VPN connection (as opposed to sending the traffic in the clear, (as opposed to sending the traffic in the clear, employing the local
employing the local router). However, if IPv6 is not supported (or router). However, if IPv6 is not supported (or completely ignored),
completely ignored), any packets destined to an IPv6 address will be any packets destined to an IPv6 address will be sent in the clear
sent in the clear using the local IPv6 router. That is, the VPN using the local IPv6 router. That is, the VPN software will do
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,
while IPv4 and IPv6 are two different protocols incompatible with for dual-stacked systems, it is not possible to secure the
each other, the two protocols are "glued" together by the Domain Name communication with another system without securing both protocols
System. Therefore, for dual-stacked systems, it is not possible to (IPv6 and IPv4). Therefore, as long as the traffic for one of these
secure the communication with another system without securing both protocols is not secured, there is the potential for VPN traffic
protocols (IPv6 and IPv4). leakages.
5. Inadvertent VPN 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 connection with a VPN server, and that such host now establish a VPN tunnel with a VPN server, and that such 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 connection, and hence 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 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 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-Toolkit] or THC-IPv6 [THC-IPv6]. Once IPv6 connectivity has
been enabled, communications with dual-stacked systems could result been enabled, communications with dual-stacked systems could result
in VPN traffic leakages, as previously described. 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 leakages for any trivial for an attacker to trigger such VPN tunnel traffic leakages
destination systems: an attacker could simply advertise himself as for any destination systems: an attacker could simply advertise
the local recursive DNS server by sending forged Router Advertisement himself as the local recursive DNS server by sending forged Router
messages [RFC4861] that include the corresponding RDNSS option Advertisement messages [RFC4861] that include the corresponding RDNSS
[RFC6106], and then perform a DNS spoofing attack such that he can option [RFC6106], and then perform a DNS spoofing attack such that he
become a "Man in the Middle" and intercept the corresponding traffic. can become a "Man in the Middle" and intercept the corresponding
traffic. As with the previous attack scenario, packet-crafting tools
As with the previous attack scenario, packet-crafting tools such as such as [SI6-Toolkit] and [THC-IPv6] can readily perform this attack.
[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, and hence the "malicious" recursive
DNS servers would be preferred over the legitimate ones advertised DNS servers would be preferred over the legitimate ones advertised
by the VPN server. by the VPN server.
7. Mitigations to VPN traffic-leakage vulnerabilities 7. Mitigations to VPN tunnel traffic leakage vulnerabilities
At the time of this writing, a large number of VPN implementations
have not yet addressed the issue of VPN tunnel traffic leakages.
Most of these implementations simply ignore IPv6, and hence IPv6
traffic leaks out of the VPN tunnel. Some VPN-tunnel implementations
handle IPv6, but not properly. For example, they may be able to
prevent inadvertent VPN tunnel traffic leakages arising in legitimate
dual-stack networks, but fail to properly handle the myriad of
vectors available to an attacker for injecting "more specific
routes", such as ICMPv6 Router Advertisement messages with Prefix
Information Options and/or Route Information Options, and ICMPv6
Redirect messages.
Clearly, the issue of VPN tunnel traffic leakages warrants proper
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 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
(although not necessarily the most desirable one) would be to would be to disable IPv6 support in all network interface
disable IPv6 support in all network interface cards when a VPN cards when a VPN connection is meant to be employed. Thus,
connection is meant to be employed. Thus, applications on the applications on the host running the VPN client software will
host running the VPN client software will have no other option have no other option than to employ IPv4, and hence they will
than to employ IPv4, and hence they will simply not even try simply not even try to send/process IPv6 traffic. We note
to send/process IPv6 traffic. that this should only be regarded as a temporary workaround,
since the proper mitigation would be to correctly handle IPv6
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
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 non-trivial.
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
temporary workaround, since the proper mitigation would be to
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.
Additionally, VPN clients that support IPv6 should mitigate all NOTE: As noted above, this would imply, among other things,
Neighbor Discovery (ND) attacks that may introduce new entries in the properly handling any vectors that might be employed by an
routing table, such as attacks based on forged Router Advertisement attacker to install IPv6 routes at the victim system, and that
messages containing more specific routes [RFC4191], forged ICMPv6 this may prove to be a non-trivial task.
Redirect messages, etc.
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 (RA-
Guard) [RFC6105] and DHCPv6-Shield [I-D.ietf-opsec-dhcpv6-shield]. Guard) [RFC6105] and DHCPv6-Shield [I-D.ietf-opsec-dhcpv6-shield].
However, for obvious reasons, a host cannot and should not rely on However, for obvious reasons, a host cannot and should not rely on
this type of mitigations when connecting to an open network this type of 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
skipping to change at page 7, line 36 skipping to change at page 8, line 38
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. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9. Security Considerations 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 connection can leak out of the VPN, and hence appear in the clear VPN tunnel can leak out of such tunnel, and hence appear in the clear
on the local network. This is the result of employing IPv6-unaware on the local network. This is the result of employing IPv6-unaware
VPN client software on dual-stacked hosts. VPN client software on dual-stacked hosts.
Possible ways to mitigate this problem include fixing the VPN client The proper mitigation of this issue is to correctly handle IPv6
software, or disabling IPv6 connectivity on all network interfaces traffic in the VPN client software. However, in scenarios in which
when the previous option is not feasible. such mitigation is unfeasible, an administrator may choose to disable
IPv6 connectivity on all network interfaces of the host employing the
VPN client.
10. Acknowledgements 10. Acknowledgements
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, Warren Kumari, Alastair Johnson, Merike Kaeo, Panos Kampanakis, Stephen Kent, Warren
Henrik Lund Kramshoj, Barry Leiba, Kathleen Moriarty, Thomas Kumari, Henrik Lund Kramshoj, 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 versions of this document.
11. References 11. References
11.1. Normative References 11.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.
 End of changes. 29 change blocks. 
121 lines changed or deleted 167 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/