draft-ietf-opsec-vpn-leakages-00.txt   draft-ietf-opsec-vpn-leakages-01.txt 
Operational Security Capabilities for F. Gont Operational Security Capabilities for F. Gont
IP Network Infrastructure (opsec) Huawei Technologies IP Network Infrastructure (opsec) Huawei Technologies
Internet-Draft December 12, 2012 Internet-Draft June 25, 2013
Intended status: Informational Intended status: Informational
Expires: June 15, 2013 Expires: December 27, 2013
Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ Virtual Private Network (VPN) traffic leakages in dual-stack hosts/
networks networks
draft-ietf-opsec-vpn-leakages-00 draft-ietf-opsec-vpn-leakages-01
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) products, may inadvertently
result in VPN traffic leaks. That is, traffic meant to be result in VPN traffic leaks. That is, traffic meant to be
transferred over a VPN connection may leak out of such connection and transferred over a VPN connection may leak out of such connection and
be transferred in the clear on the local network. This document be transferred in the clear from the local network to the final
discusses some scenarios in which such VPN leakages may occur, either destination. This document discusses some scenarios in which such
as a side effect of enabling IPv6 on a local network, or as a result VPN leakages may occur, either as a side effect of enabling IPv6 on a
of a deliberate attack from a local attacker. Additionally, it local network, or as a result of a deliberate attack from a local
discusses possible mitigations for the aforementioned issue. attacker. Additionally, it discusses possible mitigations for the
aforementioned 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 June 15, 2013. This Internet-Draft will expire on December 27, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 21 skipping to change at page 2, line 22
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IPv4 and IPv6 co-existence . . . . . . . . . . . . . . . . . . 4 2. IPv4 and IPv6 co-existence . . . . . . . . . . . . . . . . . . 4
3. Virtual Private Networks in IPv4/IPv6 dual-stack 3. Virtual Private Networks in IPv4/IPv6 dual-stack
hosts/networks . . . . . . . . . . . . . . . . . . . . . . . . 5 hosts/networks . . . . . . . . . . . . . . . . . . . . . . . . 5
4. VPN traffic-leakages in legitimate scenarios . . . . . . . . . 6 4. VPN traffic-leakages in legitimate scenarios . . . . . . . . . 6
5. VPN traffic-leakage attacks . . . . . . . . . . . . . . . . . 7 5. VPN traffic-leakage attacks . . . . . . . . . . . . . . . . . 7
6. Mitigations to VPN traffic-leakage vulnerabilities . . . . . . 8 6. Mitigations to VPN traffic-leakage vulnerabilities . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
It is a very common practice for employees working at remote It is a very common practice for employees working at remote
locations to establish a VPN connection with their office or home locations to establish a VPN connection with their office or home
office. This is typically done to gain access to some resources only office. This is typically done to gain access to some resources only
available within the company's network, but also to secure the host's available within the company's network, but also to secure the host's
traffic against attackers that might be connected to the same remote traffic against attackers that might be connected to the same remote
location. In some scenarios, it is even assumed that employing a VPN location. In some scenarios, it is even assumed that employing a VPN
connection makes the use of insecure protocols (e.g. that transfer connection makes the use of insecure protocols (e.g. that transfer
skipping to change at page 3, line 35 skipping to change at page 3, line 35
connectivity is simply "dormant" when they connect to IPv4-only connectivity is simply "dormant" when they connect to IPv4-only
networks). When the IPv6 connectivity of such hosts is enabled, they networks). When the IPv6 connectivity of such hosts is enabled, they
may end up employing an IPv6-unaware VPN client in a dual-stack may end up employing an IPv6-unaware VPN client in a dual-stack
network. This may have "unexpected" consequences, as explained network. This may have "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 traffic leakages -- that
is, traffic meant to be transferred over a VPN connection could leak is, traffic meant to be transferred over a VPN connection could leak
out of the VPN connection and be transmitted in the clear on the out of the VPN connection and be transmitted in the clear from the
local network, without employing the VPN services at all. local network to the final destination, without employing the VPN
services at all.
Section 2 provides some background about IPv6 and IPv4 co-existence, Section 2 provides some background about IPv6 and IPv4 co-existence,
summarizing how IPv4 and IPv4 interact on a typical dual-stacked summarizing how IPv6 and IPv4 interact on a typical dual-stacked
network. Section 3 describes the underlying problem that leads to network. Section 3 describes the underlying problem that leads to
the aforementioned VPN traffic leakages. Section 4 describes the aforementioned VPN traffic leakages. Section 4 describes
legitimate scenarios in which such traffic leakages might occur, legitimate scenarios in which such traffic leakages might occur,
while Section 5 describes how VPN traffic leakages can be triggered while Section 5 describes how VPN traffic leakages can be triggered
by deliberate attacks. by deliberate attacks.
2. IPv4 and IPv6 co-existence 2. 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
interesting and subtle aspects that may have "surprising" interesting and subtle aspects that may have "surprising"
skipping to change at page 4, line 32 skipping to change at page 4, line 32
than one address of each family is available) varies from one than one address of each family is available) varies from one
protocol implementation to another, with many host implementations protocol implementation to another, with many host implementations
preferring IPv6 addresses over IPv4 addresses. preferring IPv6 addresses over IPv4 addresses.
[RFC6724] specifies an algorithm for selecting a destination [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.
This "co-existence" between IPv6 and IPv4 means that, when a dual- As a result of this "co-existence" between IPv6 and IPv4, when a
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.
3. Virtual Private Networks in IPv4/IPv6 dual-stack hosts/networks 3. Virtual Private Networks in IPv4/IPv6 dual-stack hosts/networks
Many Virtual Private Network (VPN) implementations do not support the Many Virtual Private Network (VPN) implementations do not support the
IPv6 protocol -- or, what is worse, they completely ignore IPv6. IPv6 protocol -- or, what is worse, they completely ignore IPv6.
This typically means that, when establishing a VPN connection, the This typically means that, when establishing a VPN connection, the
VPN software takes care of the IPv4 connectivity by, e.g. inserting VPN software takes care of the IPv4 connectivity by, e.g. inserting
an IPv4 default route that causes all IPv4 traffic to be sent over an IPv4 default route that causes all IPv4 traffic to be sent over
the VPN connection (as opposed to sending the traffic in the clear, the VPN connection (as opposed to sending the traffic in the clear,
employing the local router). However, if IPv6 is not supported (or employing the local router). However, if IPv6 is not supported (or
completely ignored), any packets destined to an IPv6 address will be completely ignored), any packets destined to an IPv6 address will be
sent in the clear using the local IPv6 router. That is, the VPN sent in the clear using the local IPv6 router. That is, the VPN
software will do nothing about the IPv6 traffic. software will do nothing about the IPv6 traffic.
The underlying problem here is that while IPv4 and IPv6 are two The underlying problem here is that while IPv4 and IPv6 are two
different protocols incompatible with each other, the two protocols different protocols incompatible with each other, the two protocols
are glued together by the Domain Name System. Therefore, for dual- are glued together by the Domain Name System. Therefore, for dual-
stacked systems, it is not possible to secure secure the stacked systems, it is not possible to secure the communication with
communication with another system without securing both protocols another system without securing both protocols (IPv6 and IPv4).
(IPv6 and IPv4).
4. VPN traffic-leakages in legitimate scenarios 4. VPN 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 the host now establish a VPN connection with a VPN server, and that such host now
attaches 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 needs 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 aforementioned system. Since the VPN software communicate with the aforementioned system. 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 will be sent in the clear on the local network. connection, and will be sent in the clear on from local network 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 IPv6- resulting VPN traffic leakage is a side-effect of employing IPv6-
unaware software in a dual-stacked host/network. unaware software in a dual-stacked host/network.
5. VPN traffic-leakage attacks 5. VPN 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 the [SI6-Toolkit] or THC-IPv6 [THC-IPv6]. Once IPv6 connectivity as [SI6-Toolkit] or THC-IPv6 [THC-IPv6]. Once IPv6 connectivity has
has been enabled, communications with dual-stacked systems could been enabled, communications with dual-stacked systems could result
result in VPN traffic leakages, as previously mentioned. in VPN 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 leakages for any
destination systems: an attacker could simply advertise himself as destination systems: an attacker could simply advertise himself as
the local recursive DNS server by sending forged Router Advertisement the local recursive DNS server by sending forged Router Advertisement
messages [RFC4861] that include the corresponding RDNSS option messages [RFC4861] that include the corresponding RDNSS option
[RFC6106], and then perform a DNS spoofing attack such that he can [RFC6106], and then perform a DNS spoofing attack such that he can
become a "Man in the Middle" and intercept the corresponding traffic. become a "Man in the Middle" and intercept the corresponding traffic.
skipping to change at page 8, line 11 skipping to change at page 8, line 11
over IPv4-based ones, and hence the "malicious" recursive DNS over IPv4-based ones, and hence the "malicious" recursive DNS
servers would be preferred over the legitimate ones advertised by servers would be preferred over the legitimate ones advertised by
the VPN server. the VPN server.
6. Mitigations to VPN traffic-leakage vulnerabilities 6. Mitigations to VPN traffic-leakage vulnerabilities
There are a number of possible mitigations for the VPN traffic- There are a number of possible mitigations for the VPN 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 traffic for IPv4 to the VPN, it should: redirect all IPv4 traffic to the VPN, it should:
1. If IPv6 is not supported, disable IPv6 support in all network 1. If IPv6 is not supported, disable IPv6 support in all network
interfaces interfaces.
For IPv6-unaware VPN clients, the most simple mitigation For IPv6-unaware VPN clients, the most simple mitigation
(although not necessarily the most desirable one) would be to (although not necessarily the most desirable one) would be to
disable IPv6 support in all network interface cards when a VPN disable IPv6 support in all network interface cards when a VPN
connection is meant to be employed. Thus, applications on the connection is meant to be employed. Thus, applications on the
host running the VPN client software will have no other option host running the VPN client software will have no other option
than to employ IPv4, and hence they will simply not even try than to employ IPv4, and hence they will simply not even try
to send/process IPv6 traffic. to send/process IPv6 traffic.
2. If IPv6 is supported, ensure that all IPv6 traffic is also sent 2. If IPv6 is supported, ensure that all IPv6 traffic is also sent
via the VPN via the VPN.
If the VPN client is configured to only send a subset of IPv4 If the VPN client is configured to only send a subset of IPv4
networks to the VPN tunnel (split-tunnel mode), and the VPN client networks to the VPN tunnel (split-tunnel mode), then:
does not support IPv6, it should disable IPv6 as well. If it
supports IPv6, it is the administrators responsibility to ensure that 1. If the VPN client does not support IPv6, it should disable IPv6
the correct corresponding sets of IPv4 and IPv6 networks get routed support in all network interfaces.
into the VPN tunnel.
2. If the VPN client supports IPv6, it is the administrators
responsibility to ensure that the correct corresponding sets of
IPv4 and IPv6 networks get routed into the VPN tunnel.
Additionally, VPN clients that support IPv6 should mitigate all ND- Additionally, VPN clients that support IPv6 should mitigate all ND-
based attacks that may introduce new entries in the routing table, based attacks that may introduce new entries in the routing table,
such attacks based on forged RA messages containing more specific such as attacks based on forged RA messages containing more specific
routes [RFC4191], forged ICMPv6 Redirect messages, etc. routes [RFC4191], forged ICMPv6 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.gont-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.).
Besides, popular implementations of RA-Guard are known to be Besides, popular implementations of RA-Guard are known to be
vulnerable to evasion attacks vulnerable to evasion attacks
[I-D.ietf-v6ops-ra-guard-implementation]. [I-D.ietf-v6ops-ra-guard-implementation].
7. IANA Considerations 7. IANA Considerations
skipping to change at page 12, line 39 skipping to change at page 13, line 39
[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.
[I-D.ietf-v6ops-ra-guard-implementation] [I-D.ietf-v6ops-ra-guard-implementation]
Gont, F., "Implementation Advice for IPv6 Router Gont, F., "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)", Advertisement Guard (RA-Guard)",
draft-ietf-v6ops-ra-guard-implementation-07 (work in draft-ietf-v6ops-ra-guard-implementation-07 (work in
progress), November 2012. progress), November 2012.
[I-D.gont-opsec-dhcpv6-shield] [I-D.ietf-opsec-dhcpv6-shield]
Gont, F. and W. Liu, "DHCPv6-Shield: Protecting Against Gont, F., Liu, W., and G. Velde, "DHCPv6-Shield:
Rogue DHCPv6 Servers", draft-gont-opsec-dhcpv6-shield-01 Protecting Against Rogue DHCPv6 Servers",
(work in progress), October 2012. draft-ietf-opsec-dhcpv6-shield-00 (work in progress),
December 2012.
[IPv6-Hackers] [IPv6-Hackers]
"IPv6 Hackers mailing-list", "IPv6 Hackers mailing-list",
http://lists.si6networks.com/listinfo/ipv6hackers/. http://lists.si6networks.com/listinfo/ipv6hackers/.
[OPSEC-LIST] [OPSEC-LIST]
"OPSEC WG mailing-list", "OPSEC WG mailing-list",
https://www.ietf.org/mailman/listinfo/opsec. https://www.ietf.org/mailman/listinfo/opsec.
[SI6-Toolkit] [SI6-Toolkit]
 End of changes. 21 change blocks. 
46 lines changed or deleted 52 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/