draft-ietf-opsec-vpn-leakages-05.txt   draft-ietf-opsec-vpn-leakages-06.txt 
opsec F. Gont opsec F. Gont
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational April 24, 2014 Intended status: Informational April 24, 2014
Expires: October 26, 2014 Expires: October 26, 2014
Layer-3 Virtual Private Network (VPN) tunnel traffic leakages in dual- Layer-3 Virtual Private Network (VPN) tunnel traffic leakages in dual-
stack hosts/networks stack hosts/networks
draft-ietf-opsec-vpn-leakages-05 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 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) 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 leaks. That is, traffic
meant to be transferred over an encrypted and integrity protected VPN meant to be transferred over an encrypted and integrity protected VPN
tunnel may leak out of such tunnel and be sent in the clear on the tunnel may leak out of such tunnel and be sent in the clear on the
local network towards the final destination. This document discusses local network towards the final destination. This document discusses
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IPv4 and IPv6 co-existence . . . . . . . . . . . . . . . . . 4 3. IPv4 and IPv6 co-existence . . . . . . . . . . . . . . . . . 5
4. Virtual Private Networks in IPv4/IPv6 dual-stack 4. Virtual Private Networks in IPv4/IPv6 dual-stack
hosts/networks . . . . . . . . . . . . . . . . . . . . . . . 5 hosts/networks . . . . . . . . . . . . . . . . . . . . . . . 5
5. Inadvertent VPN tunnel traffic leakages in legitimate 5. Inadvertent VPN tunnel traffic leakages in legitimate
scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 5 scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. VPN tunnel traffic leakage attacks . . . . . . . . . . . . . 6 6. VPN tunnel traffic leakage attacks . . . . . . . . . . . . . 6
7. Mitigations to VPN tunnel traffic leakage vulnerabilities . . 6 7. Mitigations to VPN tunnel traffic leakage vulnerabilities . . 7
7.1. Fixing VPN client software . . . . . . . . . . . . . . . 7 7.1. Fixing VPN client software . . . . . . . . . . . . . . . 7
7.2. Operational Mitigations . . . . . . . . . . . . . . . . . 8 7.2. Operational Mitigations . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 3, line 21 skipping to change at page 3, line 21
"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 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 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
traffic, it is applicable to the following types of VPN technologies:
o IPsec-based VPN tunnel
o SSL/TLS VPN tunnel
NOTE: see Section 2 for a definition and description of these
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 co-
existence, summarizing how IPv6 and IPv4 interact on a typical dual- existence, summarizing how IPv6 and IPv4 interact on a typical dual-
stacked network. Section 4 describes the underlying problem that stacked network. Section 4 describes the underlying problem that
leads to the aforementioned VPN traffic leakages. Section 5 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 mitigation for the aforementioned issue.
skipping to change at page 3, line 45 skipping to change at page 4, line 7
tunnels, where layer-3 packets are encapsulated and sent from a tunnels, where layer-3 packets are encapsulated and sent from a
client to a middle-box, to access multiple network services (possibly client to a middle-box, to access multiple network services (possibly
employing different transport and/or application protocols). employing 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 ans 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: A technology that encapsulates traffic from a client SSL VPN tunnel:
to a middlebox. In essence, an SSL/TLS VPN tunnel acts just like A technology that encapsulates traffic from a client to a
an IPsec-tunnel client and server, but instead employs SSL/TLS for middlebox. In essence, an SSL/TLS VPN tunnel acts just like an
encryption, and some proprietary/unspecified mechanism for IPsec-based tunnel, but instead employs SSL/TLS for encryption,
encapsulation and routing. and some proprietary/unspecified mechanism for encapsulation and
routing.
SSL VPN portal: A front-end provided by the middlebox to add SSL VPN portal:
security to a normally-unsecured site. The VPN portal is accessed A front-end provided by the middlebox to add security to a
just like any HTTPS URL. normally-unsecured site. A TLS/SSL VPN portal is typically
application specific, wrapping the specific protocol, such as
HTTP, to provide access to specific services on a network. In
such case, the SSL/TLS VPN portal would be accessed just like any
HTTPS URL. TLS/SSL VPN portals are used when one wants to
restrict access and only provide remote users to very specific
services on the network. SSL/TLS VPN portals do not require an
agent and the policy is typically more liberal from organizations
allowing access from anywhere via this access method. All other
traffic on the system may be routed directly to the destination,
whether it is IPv4, IPv6, or even other service level (HTTP)
destination addresses.
Our document focuses on layer-3 VPNs that employ IPsec-based or SSL/ 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.
Further discussion of SSL-based VPNs can be found in [SSL-VPNs]. Both IPsec-basec and TLS/SSL-based VPN tunnels are designed to route
layer-3 traffic via de VPN tunnel through to VPN tunnel server.
Typically, these solutions are agent-based, meaning that software is
required on the client end-point to establish the VPN tunnel and
manage access control or routing rules. This provides an opportunity
for controls to be managed through that application as well as on the
client endpoint.
NOTE: Further discussion of SSL-based VPNs can be found in
[SSL-VPNs].
We note that, in addition to the general case of "send all traffic 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
skipping to change at page 9, line 7 skipping to change at page 9, line 26
VPN client software on dual-stacked hosts. 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 mitigation is unfeasible, an administrator may choose to disable
IPv6 connectivity on all network interfaces of the host employing the IPv6 connectivity on all network interfaces of the host employing the
VPN client. VPN client.
10. Acknowledgements 10. 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 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, Warren
Kumari, 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
 End of changes. 11 change blocks. 
16 lines changed or deleted 51 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/