Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7359 Huawei Technologies
Category: Informational August 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7359 Huawei Technologies
Category: Informational August 2014
ISSN: 2070-1721
Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks
第3层虚拟专用网（VPN）隧道双栈主机/网络中的流量泄漏
Abstract
摘要
The subtle way in which the IPv6 and IPv4 protocols coexist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) tunnel products, may inadvertently result in VPN tunnel traffic leakages. That is, traffic meant to be transferred over an encrypted and integrity-protected VPN tunnel may leak out of such a tunnel and be sent in the clear on the local network towards the final destination. This document discusses some scenarios in which such VPN tunnel traffic leakages may occur as a result of employing IPv6-unaware VPN software. Additionally, this document offers possible mitigations for this issue.
典型网络中IPv6和IPv4协议共存的微妙方式，加上流行的虚拟专用网络（VPN）隧道产品中缺乏适当的IPv6支持，可能会无意中导致VPN隧道流量泄漏。也就是说，要通过加密和完整性保护的VPN隧道传输的流量可能会从这样的隧道泄漏出来，并在本地网络上以明文形式发送到最终目的地。本文档讨论了一些场景，在这些场景中，由于使用了IPv6非感知VPN软件，可能会发生此类VPN隧道流量泄漏。此外，本文件还提供了该问题的可能缓解措施。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the 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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7359.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7359.
IESG Note
IESG注释
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.
本文档描述了VPN软件中的信息泄漏问题，并将该问题归因于该软件无法处理IPv6。我们认为这不是对问题的恰当描述。的确，当设备支持多个地址族时，无法将策略应用于该设备上的多个地址族是一个缺陷。尽管如此，由于存在系统上允许的任何未加密接口，包括VPN软件本身中的拆分隧道配置，也可能发生意外或恶意导致的信息泄漏。虽然存在一些IPv6接口特有的攻击，但本文档中描述的信息泄漏类型是一个一般性问题，并不是IPv6不知道VPN软件的情况所特有的。我们认为本文件没有充分描述一般性问题。
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IPv4 and IPv6 Coexistence . . . . . . . . . . . . . . . . . . 5
4. Virtual Private Networks in IPv4/IPv6 Dual-Stack
Hosts/Networks . . . . . . . . . . . . . . . . . . . . . . . 6
5. Inadvertent VPN Tunnel Traffic Leakages in Legitimate
Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. VPN Tunnel Traffic Leakage Attacks . . . . . . . . . . . . . 7
7. Mitigations to VPN Tunnel Traffic Leakage Vulnerabilities . . 8
7.1. Fixing VPN Client Software . . . . . . . . . . . . . . . 8
7.2. Operational Mitigations . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IPv4 and IPv6 Coexistence . . . . . . . . . . . . . . . . . . 5
4. Virtual Private Networks in IPv4/IPv6 Dual-Stack
Hosts/Networks . . . . . . . . . . . . . . . . . . . . . . . 6
5. Inadvertent VPN Tunnel Traffic Leakages in Legitimate
Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. VPN Tunnel Traffic Leakage Attacks . . . . . . . . . . . . . 7
7. Mitigations to VPN Tunnel Traffic Leakage Vulnerabilities . . 8
7.1. Fixing VPN Client Software . . . . . . . . . . . . . . . 8
7.2. Operational Mitigations . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
It is a very common practice for users to employ VPN software when employing a public (and possibly rogue) local network. This is typically done not only to gain access to remote resources that may not otherwise be accessible from the public Internet, but also to secure the host's traffic against attackers that might be connected to the same local network as the victim host. The latter case constitutes the problem space of this document. Indeed, it is sometimes assumed that employing a VPN tunnel makes the use of insecure protocols (e.g., that transfer sensitive information in the clear) acceptable, as a VPN tunnel provides security services (such as data integrity and/or confidentiality) for all communications made over it. However, this document illustrates that under certain circumstances, some traffic might not be mapped onto the VPN tunnel and thus might be sent in the clear on the local network.
在使用公共（可能是流氓）本地网络时，用户使用VPN软件是一种非常常见的做法。这样做通常不仅是为了访问可能无法从公共Internet访问的远程资源，而且是为了保护主机的通信量，防止攻击者与受害主机连接到同一本地网络。后一种情况构成本文件的问题空间。事实上，有时假设使用VPN隧道可以接受使用不安全协议（例如，以透明方式传输敏感信息），因为VPN隧道为通过它进行的所有通信提供安全服务（例如数据完整性和/或机密性）。但是，本文档说明了在某些情况下，某些流量可能不会映射到VPN隧道，因此可能会在本地网络上以明文形式发送。
Many VPN products that are typically employed for the aforementioned VPN tunnels only support the IPv4 protocol: that is, they perform the necessary actions such that IPv4 traffic is sent over the VPN tunnel, but they do nothing to secure IPv6 traffic originated from (or being received at) the host employing the VPN client. However, the hosts themselves are typically dual-stacked: they support (and enable by default) both IPv4 and IPv6 (even if such IPv6 connectivity is simply "dormant" when they connect to IPv4-only networks). When the IPv6 connectivity of such hosts is enabled, they may end up employing an IPv6-unaware VPN client in a dual-stack network. This may have "unexpected" consequences, as explained below.
通常用于上述VPN隧道的许多VPN产品仅支持IPv4协议：也就是说，它们执行必要的操作，以便通过VPN隧道发送IPv4流量，但它们不保护来自（或在）使用VPN客户端的主机的IPv6流量。但是，主机本身通常是双重堆叠的：它们支持（并默认启用）IPv4和IPv6（即使当它们连接到仅IPv4的网络时，这种IPv6连接只是“休眠”）。当这些主机的IPv6连接被启用时，它们最终可能会在双栈网络中使用不支持IPv6的VPN客户端。这可能会产生“意外”后果，如下所述。
The subtle way in which the IPv4 and IPv6 protocols interact and coexist in dual-stacked networks might, either inadvertently or as a result of a deliberate attack, result in VPN tunnel traffic leakages -- 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 local network to the final destination, without employing the VPN services at all.
IPv4和IPv6协议在双堆叠网络中相互作用和共存的微妙方式可能会无意中或由于蓄意攻击而导致VPN隧道流量泄漏，也就是说，打算通过VPN隧道传输的流量可能会从VPN隧道泄漏出来，并从本地网络以明文形式传输到最终目的地，而根本不使用VPN服务。
Since this issue is specific to VPN solutions that route Layer 3 traffic, it is applicable to the following types of VPN technologies:
由于此问题特定于路由第3层流量的VPN解决方案，因此适用于以下类型的VPN技术：
o IPsec-based VPN tunnels
o 基于IPsec的VPN隧道
o SSL/TLS VPN tunnels
o SSL/TLS VPN隧道
NOTE: see Section 2 for a definition and description of these terms.
注：有关这些术语的定义和说明，请参见第2节。
Section 2 clarifies the terminology employed throughout this document. Section 3 provides some background about IPv6 and IPv4 coexistence, summarizing how IPv6 and IPv4 interact on a typical dual-stacked network. Section 4 describes the underlying problem that leads to the aforementioned VPN traffic leakages. Section 5 describes legitimate scenarios in which such traffic leakages might occur, while Section 6 describes how VPN traffic leakages can be triggered by deliberate attacks. Finally, Section 7 discusses possible mitigations for the aforementioned issue.
第2节澄清了本文件中使用的术语。第3节提供了有关IPv6和IPv4共存的一些背景知识，总结了IPv6和IPv4在典型的双堆叠网络上的交互方式。第4节描述了导致上述VPN流量泄漏的根本问题。第5节描述了可能发生此类流量泄漏的合法场景，而第6节描述了故意攻击如何触发VPN流量泄漏。最后，第7节讨论了上述问题的可能缓解措施。
When employing the term "Virtual Private Network tunnel" (or "VPN tunnel"), this document refers to VPN tunnels based on IPsec or SSL/ TLS, where Layer 3 packets are encapsulated and sent from a client to a middlebox, to access multiple network services (possibly employing different transport and/or application protocols).
当使用术语“虚拟专用网络隧道”（或“VPN隧道”）时，本文档指基于IPsec或SSL/TLS的VPN隧道，其中第3层数据包被封装并从客户端发送到中间盒，以访问多个网络服务（可能采用不同的传输和/或应用协议）。
IPsec-based VPN tunnels simply employ IPsec in tunnel mode to encapsulate and transfer Layer 3 packets over the VPN tunnel. On the other hand, the term "SSL/TLS-based VPN tunnels" warrants a clarification, since two different technologies are usually referred to as "SSL/TLS VPN":
基于IPsec的VPN隧道只是在隧道模式下使用IPsec在VPN隧道上封装和传输第3层数据包。另一方面，术语“基于SSL/TLS的VPN隧道”需要澄清，因为两种不同的技术通常被称为“SSL/TLS VPN”：
SSL/TLS 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-based tunnel, but instead employs SSL/TLS for encryption and some proprietary/unspecified mechanism for encapsulation and routing.
SSL/TLS VPN隧道：一种将流量从客户端封装到中间箱的技术。本质上，SSL/TLS VPN隧道的作用类似于基于IPsec的隧道，而是使用SSL/TLS进行加密，并使用一些专有/未指定的机制进行封装和路由。
SSL/TLS VPN portal: A front-end provided by the middlebox to add security to a normally unsecured site. An SSL/TLS VPN portal is typically application specific, wrapping the specific protocol, such as HTTP, to provide access to specific services on a network. In such a case, the SSL/TLS VPN portal would be accessed just like any HTTPS URL. SSL/TLS 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.
SSL/TLS VPN门户：由中间件提供的前端，用于为通常不安全的站点增加安全性。SSL/TLS VPN门户通常是特定于应用程序的，包装特定的协议（如HTTP），以提供对网络上特定服务的访问。在这种情况下，可以像访问任何HTTPS URL一样访问SSL/TLS VPN门户。SSL/TLS VPN门户用于限制访问并仅向远程用户提供网络上非常特定的服务。SSL/TLS VPN门户不需要代理，并且对于允许通过这种访问方法从任何地方进行访问的组织来说，该策略通常更加自由。系统上的所有其他流量都可以直接路由到目标，无论是IPv4、IPv6还是其他服务级别（HTTP）目标地址。
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. Both IPsec-based and SSL/TLS-based VPN tunnels are designed to route Layer 3 traffic via the VPN tunnel through to the VPN tunnel server. Typically, these solutions are agent based, meaning that software is required on the client endpoint 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.
我们的文档重点介绍使用基于IPsec或基于SSL/TLS的隧道的第3层VPN，不包括所谓的SSL/TLS VPN门户。基于IPsec和基于SSL/TLS的VPN隧道设计用于通过VPN隧道将第3层流量路由到VPN隧道服务器。通常，这些解决方案是基于代理的，这意味着客户端端点上需要软件来建立VPN隧道和管理访问控制或路由规则。这为通过该应用程序以及在客户端端点上管理控件提供了机会。
NOTE: Further discussion of SSL-based VPNs can be found in [SSL-VPNs].
注：有关基于SSL的VPN的进一步讨论，请参见[SSL VPN]。
We note that, in addition to the general case of "send all traffic through the VPN", this document considers the so-called "split-tunnel" case, where some subset of the traffic is sent through the VPN, while other traffic is sent to its intended destination with a direct routing path (i.e., without employing the VPN tunnel). We note that many organizations will prevent split-tunneling in their VPN configurations if they would like to make sure the users data goes through a gateway with protections (malware detection, URL filtering, etc.), but others are more interested in performance of the user's access or the ability for researchers to have options to access sites they may not be able to through the gateway.
我们注意到，除了“通过VPN发送所有流量”的一般情况外，本文件还考虑了所谓的“拆分隧道”情况，其中一些流量子集通过VPN发送，而其他流量通过直接路由路径发送到其预期目的地（即，不使用VPN隧道）。我们注意到，如果许多组织希望确保用户数据通过具有保护（恶意软件检测、URL过滤等）的网关，他们将在其VPN配置中防止拆分隧道，但其他人更感兴趣的是用户访问的性能，或者研究人员能够选择访问他们可能无法通过网关访问的站点。
The coexistence of the IPv4 and IPv6 protocols has a number of interesting and subtle aspects that may have "surprising" consequences. While IPv6 is not backwards-compatible with IPv4, the two protocols are "glued" together by the Domain Name System (DNS).
IPv4和IPv6协议共存有许多有趣而微妙的方面，可能会产生“令人惊讶”的后果。虽然IPv6与IPv4不向后兼容，但这两个协议由域名系统（DNS）“粘合”在一起。
For example, consider a site (say, www.example.com) that has both IPv4 and IPv6 support. The corresponding domain name (www.example.com, in our case) will contain both A and AAAA DNS resource records (RRs). Each A record will contain one IPv4 address, while each AAAA record will contain one IPv6 address -- and there might be more than one instance of each of these record types. Thus, when a dual-stacked client application means to communicate with www.example.com, it can request both A and AAAA records and use any of the available addresses. The preferred address family (IPv4 or IPv6) and the specific address that will be used (assuming more than one address of each family is available) varies from one protocol implementation to another, with many host implementations preferring IPv6 addresses over IPv4 addresses.
例如，考虑一个具有IPv4和IPv6支持的站点（例如，www. Stask.com）。相应的域名（在本例中为www.example.com）将同时包含A和AAAA DNS资源记录（RRs）。每个A记录将包含一个IPv4地址，而每个AAAA记录将包含一个IPv6地址——并且每个记录类型可能有多个实例。因此，当双堆叠客户端应用程序意味着与www.example.com通信时，它可以请求a和AAAA记录并使用任何可用地址。首选地址系列（IPv4或IPv6）和将使用的特定地址（假设每个系列中有多个地址可用）因协议实现而异，许多主机实现首选IPv6地址而非IPv4地址。
NOTE: [RFC6724] specifies an algorithm for selecting a destination address from a list of IPv6 and IPv4 addresses. [RFC6555] discusses the challenge of selecting the most appropriate destination address, along with a proposed implementation approach that mitigates connection-establishment delays.
注意：[RFC6724]指定用于从IPv6和IPv4地址列表中选择目标地址的算法。[RFC6555]讨论了选择最合适的目标地址的挑战，以及缓解连接建立延迟的建议实施方法。
As a result of this "coexistence" between IPv6 and IPv4, when a dual-stacked client means to communicate with some other system, the availability of A and AAAA DNS resource records will typically affect which protocol is employed to communicate with that system.
由于IPv6和IPv4之间的这种“共存”，当双堆叠客户端打算与其他系统通信时，a和AAAA DNS资源记录的可用性通常会影响采用哪个协议与该系统通信。
Many VPN tunnel implementations do not support the IPv6 protocol -- or, what is worse, they completely ignore IPv6. This typically means that, once a VPN tunnel has been established, the 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 the VPN tunnel (as opposed to sending the traffic in the clear, employing the local router). However, if IPv6 is not supported (or completely ignored), 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 nothing about the IPv6 traffic.
许多VPN隧道实现不支持IPv6协议——或者更糟糕的是，它们完全忽略了IPv6。这通常意味着，一旦建立了VPN隧道，VPN软件通过插入导致所有IPv4流量通过VPN隧道发送的IPv4默认路由（而不是使用本地路由器在clear中发送流量）来处理IPv4连接。但是，如果不支持（或完全忽略）IPv6，则将使用本地IPv6路由器以明文形式发送任何发送到IPv6地址的数据包。也就是说，VPN软件对IPv6流量没有任何作用。
The underlying reason for which these VPN leakages may occur is that, for dual-stacked systems, it is not possible to secure the communication with another system without securing both protocols (IPv6 and IPv4). Therefore, as long as the traffic for one of these protocols is not secured, there is the potential for VPN traffic leakages.
这些VPN泄漏可能发生的根本原因是，对于双堆叠系统，如果不保护这两个协议（IPv6和IPv4），就不可能保护与另一个系统的通信。因此，只要这些协议之一的流量不安全，就有可能发生VPN流量泄漏。
Consider a dual-stacked host that employs IPv4-only VPN software to 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 connectivity). If some application on the client means to communicate with a dual-stacked destination, the client will typically query both A and AAAA DNS resource records. Since the host will have both IPv4 and IPv6 connectivity, and the intended destination will have both A and AAAA DNS resource records, one of the possible outcomes is that the host will employ IPv6 to communicate with the intended destination. Since the VPN software does not support IPv6, the IPv6 traffic will not employ the VPN tunnel; hence, it will have neither integrity nor confidentiality protection from the source host to the final destination.
考虑一个双栈主机，它只使用IPv4 VPN软件来建立带有VPN服务器的VPN隧道，并且该主机现在连接到一个双堆栈网络（它既提供IPv6又提供IPv4连接）。如果客户端上的某个应用程序打算与双堆叠目的地通信，则客户端通常会查询a和AAAA DNS资源记录。由于主机将同时具有IPv4和IPv6连接，并且预期目标将同时具有A和AAAA DNS资源记录，因此可能的结果之一是主机将使用IPv6与预期目标通信。由于VPN软件不支持IPv6，IPv6流量将不使用VPN隧道；因此，从源主机到最终目的地，它既没有完整性保护，也没有机密性保护。
This could inadvertently expose sensitive traffic that was assumed to be secured by the VPN software. In this particular scenario, the resulting VPN tunnel traffic leakage is a side effect of employing IPv6-unaware VPN software in a dual-stacked host/network.
这可能会无意中暴露假定由VPN软件保护的敏感流量。在此特定场景中，由此产生的VPN隧道流量泄漏是在双堆叠主机/网络中使用不知道IPv6的VPN软件的副作用。
A local attacker could deliberately trigger IPv6 connectivity on the victim host by sending forged ICMPv6 Router Advertisement messages [RFC4861]. Such packets could be sent by employing standard software such as rtadvd [RTADVD], or by employing packet-crafting tools such as SI6 Network's IPv6 Toolkit [SI6-Toolkit] or THC's IPv6 Attack Toolkit [THC-IPv6]. Once IPv6 connectivity has been enabled, communications with dual-stacked systems could result in VPN tunnel traffic leakages, as previously described.
本地攻击者可以通过发送伪造的ICMPv6路由器公告消息[RFC4861]，故意触发受害主机上的IPv6连接。此类数据包可通过使用标准软件（如RTADV[RTADV]）或通过使用数据包制作工具（如SI6 Network的IPv6 Toolkit[SI6 Toolkit]或THC的IPv6攻击Toolkit[THC-IPv6]）发送。一旦启用IPv6连接，与双堆叠系统的通信可能会导致VPN隧道流量泄漏，如前所述。
While this attack may be useful enough (due to the increasing number of IPv6-enabled sites), it will only lead to traffic leakages when the destination system is dual-stacked. However, it is usually trivial for an attacker to trigger such VPN tunnel traffic leakages for any destination system: an attacker could simply advertise himself as the local recursive DNS server by sending forged Router Advertisement messages [RFC4861] that include the corresponding Recursive DNS Server (RDNSS) option [RFC6106], and then perform a DNS spoofing attack such that he can become a "man in the middle" and intercept the corresponding traffic. As with the previous attack scenario, packet-crafting tools such as [SI6-Toolkit] and [THC-IPv6] can readily perform this attack.
虽然此攻击可能非常有用（由于支持IPv6的站点数量不断增加），但它只会在目标系统为双堆叠时导致流量泄漏。然而，攻击者触发任何目标系统的VPN隧道流量泄漏通常是微不足道的：攻击者只需发送伪造的路由器广告消息[RFC4861]，其中包括相应的递归DNS服务器（RDNS）选项[RFC6106]，即可将自己作为本地递归DNS服务器进行广告，然后执行DNS欺骗攻击，使其成为“中间人”，并拦截相应的流量。与前面的攻击场景一样，数据包制作工具（如[SI6 Toolkit]和[THC-IPv6]）可以轻松执行此攻击。
NOTE: Some systems are known to prefer IPv6-based recursive DNS servers over IPv4-based ones; hence, the "malicious" recursive DNS servers would be preferred over the legitimate ones advertised by the VPN server.
注意：已知一些系统更喜欢基于IPv6的递归DNS服务器，而不是基于IPv4的服务器；因此，与VPN服务器公布的合法DNS服务器相比，“恶意”递归DNS服务器更受欢迎。
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; 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 they may 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.
在撰写本文时，大量VPN实现尚未解决VPN隧道流量泄漏问题。这些实现中的大多数只是忽略了IPv6；因此，IPv6流量从VPN隧道泄漏。一些VPN隧道实现可以处理IPv6，但不能正确处理。例如，它们可能能够防止在合法的双栈网络中出现意外的VPN隧道流量泄漏，但它们可能无法正确处理攻击者可用于注入“更特定路由”的无数向量，例如，带有前缀信息选项和/或路由信息选项的ICMPv6路由器广告消息，以及ICMPv6重定向消息。
Clearly, the issue of VPN tunnel traffic leakages warrants proper IPv6 support in VPN tunnel implementations.
显然，VPN隧道流量泄漏的问题保证了VPN隧道实现中适当的IPv6支持。
There are a number of possible mitigations for the VPN tunnel traffic leakage vulnerability discussed in this document.
本文档中讨论的VPN隧道流量泄漏漏洞有许多可能的缓解措施。
If the VPN client is configured by administrative decision to redirect all IPv4 traffic to the VPN, it should:
如果通过管理决策将VPN客户端配置为将所有IPv4流量重定向到VPN，则应：
1. If IPv6 is not supported in the VPN software, disable IPv6 support in all network interfaces.
1. 如果VPN软件不支持IPv6，请在所有网络接口中禁用IPv6支持。
NOTE: For IPv6-unaware VPN clients, the most simple mitigation would be to disable IPv6 support in all network interface cards when a VPN tunnel is meant to be employed. Thus, applications on the host running the VPN client software will have no other option than to employ IPv4; hence, they will simply not even try to send/process IPv6 traffic. We note that this should only be regarded as a temporary workaround, since the proper mitigation would be to correctly handle IPv6 traffic.
注意：对于不知道IPv6的VPN客户端，最简单的缓解措施是在打算使用VPN隧道时，在所有网络接口卡中禁用IPv6支持。因此，运行VPN客户端软件的主机上的应用程序除了使用IPv4之外别无选择；因此，他们甚至不会尝试发送/处理IPv6流量。我们注意到，这只应被视为临时解决办法，因为适当的缓解措施是正确处理IPv6流量。
2. If IPv6 is supported in the VPN software, ensure that all IPv6 traffic is also sent via the VPN.
2. 如果VPN软件支持IPv6，请确保所有IPv6流量也通过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 nontrivial.
注意：除其他外，这意味着要正确处理攻击者可能用于在受害系统上安装IPv6路由的任何向量（例如带有前缀信息选项或路由信息选项[RFC4191]、ICMPv6重定向消息等）。我们注意到，正确处理上述所有向量可能是非常重要的。
If the VPN client is configured to only send a subset of IPv4 traffic to the VPN tunnel (split-tunnel mode), then:
如果VPN客户端配置为仅向VPN隧道发送IPv4流量的子集（拆分隧道模式），则：
1. If the VPN client does not support IPv6, it should disable IPv6 support in all network interfaces.
1. 如果VPN客户端不支持IPv6，则应在所有网络接口中禁用IPv6支持。
NOTE: As noted above, this should only be regarded as a temporary workaround, since the proper mitigation would be to correctly handle IPv6 traffic.
注意：如上所述，这只应被视为临时解决办法，因为适当的缓解措施是正确处理IPv6流量。
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.
2. 如果VPN客户端支持IPv6，则管理员有责任确保将正确的IPv4和IPv6网络组路由到VPN隧道中。
NOTE: As noted above, 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. This may prove to be a nontrivial task.
注意：如上所述，这意味着，除其他外，要正确处理攻击者可能用于在受害系统上安装IPv6路由的任何向量。这可能被证明是一项不平凡的任务。
A network may prevent local attackers from successfully performing the aforementioned attacks against other local hosts by implementing First-Hop Security solutions such as Router Advertisement Guard (RA-Guard) [RFC6105] and DHCPv6-Shield [DHCPv6-SHIELD]. However, for obvious reasons, a host cannot and should not rely on this type of mitigations when connecting to an open network (cybercafe, etc.).
通过实施第一跳安全解决方案，例如路由器广告保护（RA保护）[RFC6105]和DHCPv6屏蔽[DHCPv6屏蔽]，网络可以防止本地攻击者成功地对其他本地主机执行上述攻击。然而，出于显而易见的原因，主机在连接到开放网络（网吧等）时不能也不应该依赖这种缓解措施。
NOTE: Besides, popular implementations of RA-Guard are known to be vulnerable to evasion attacks [RFC7113].
注：此外，众所周知，RA Guard的流行实现容易受到规避攻击[RFC7113]。
Finally, we note that if (eventually) IPv6-only VPN implementations become available, similar issues to the ones discussed in this document could arise if these IPv6-only VPN implementations do nothing about the IPv4 traffic.
最后，我们注意到，如果（最终）只有IPv6的VPN实现可用，如果这些只有IPv6的VPN实现对IPv4流量没有任何影响，那么可能会出现与本文档中讨论的问题类似的问题。
While the desired mitigation for the issues discussed in this document is for VPN clients to be IPv6 aware, we note that in scenarios where this would be unfeasible, an administrator may want to disable IPv6 connectivity on all network interfaces of the node employing the IPv6-unaware VPN client.
虽然本文档中讨论的问题所需的缓解措施是让VPN客户端能够感知IPv6，但我们注意到，在不可行的情况下，管理员可能希望在使用IPv6不感知VPN客户端的节点的所有网络接口上禁用IPv6连接。
This document discusses how traffic meant to be transferred over a VPN tunnel can leak out of such a tunnel and, hence, appear in the clear on the local network. This is the result of employing IPv6-unaware VPN client software on dual-stacked hosts.
本文档讨论了拟通过VPN隧道传输的流量如何从此类隧道中泄漏出来，从而在本地网络上以明文形式出现。这是在双堆叠主机上使用不支持IPv6的VPN客户端软件的结果。
The proper mitigation of this issue is to correctly handle IPv6 traffic in the VPN client software. However, in scenarios in which such a mitigation is unfeasible, an administrator may choose to disable IPv6 connectivity on all network interfaces of the host employing the VPN client.
此问题的适当缓解措施是在VPN客户端软件中正确处理IPv6流量。但是，在这种缓解措施不可行的情况下，管理员可以选择在使用VPN客户端的主机的所有网络接口上禁用IPv6连接。
The author would like to thank Kathleen Moriarty and Paul Hoffman who contributed text that was readily incorporated into Section 2 of this document.
作者感谢Kathleen Moriarty和Paul Hoffman，他们提供的文本很容易被纳入本文件第2节。
The author of this document would like to thank (in alphabetical order) Cameron Byrne, Spencer Dawkins, Gert Doering, Stephen Farrell, Seth Hall, Paul Hoffman, Tor Houghton, Russ Housley, Joel Jaeggli, Alastair Johnson, Merike Kaeo, Panos Kampanakis, Stephen Kent, Henrik Lund Kramshoj, Warren Kumari, Barry Leiba, Kathleen Moriarty, Thomas Osterried, Jim Small, Martin Vigoureux, and Andrew Yourtchenko for providing valuable comments on earlier draft versions of this document.
本文件的作者谨（按字母顺序）感谢卡梅隆·伯恩、斯宾塞·道金斯、格特·多林、斯蒂芬·法雷尔、塞思·霍尔、保罗·霍夫曼、托尔·霍顿、罗斯·霍斯利、乔尔·贾格利、阿拉斯泰尔·约翰逊、梅里克·卡奥、帕诺斯·坎帕纳基斯、斯蒂芬·肯特、亨里克·隆德·克拉姆肖吉、沃伦·库马里、巴里·莱巴、凯瑟琳·莫里亚蒂、，Thomas Osterried、Jim Small、Martin Vigoureux和Andrew Yourtchenko对本文件的早期草案版本提供了宝贵的意见。
The author wishes to express deep and heartfelt gratitude to Enrique Garcia and Vicenta Tejedo, for their precious love and support.
作者谨向恩里克·加西亚和维森塔·特杰多表示深切和衷心的感谢，感谢他们宝贵的爱和支持。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191]Draves，R.和D.Thaler，“默认路由器首选项和更具体的路由”，RFC 41912005年11月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010.
[RFC6106]Jeong，J.，Park，S.，Beloeil，L.，和S.Madanapalli，“DNS配置的IPv6路由器广告选项”，RFC 61062010年11月。
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6555]Wing，D.和A.Yourtchenko，“快乐眼球：双堆栈主机的成功”，RFC 6555，2012年4月。
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6724]Thaler，D.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 67242012年9月。
[DHCPv6-SHIELD] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers", Work in Progress, July 2014.
[DHCPv6 SHIELD]Gont，F.，Liu，W.，和G.Van de Velde，“DHCPv6 SHIELD:防范恶意DHCPv6服务器”，正在进行的工作，2014年7月。
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011.
[RFC6105]Levy Abegnoli，E.，Van de Velde，G.，Popoviciu，C.，和J.Mohacsi，“IPv6路由器广告保护”，RFC 61052011年2月。
[RFC7113] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, February 2014.
[RFC7113]Gont，F.，“IPv6路由器广告防护（RA防护）的实施建议”，RFC 7113，2014年2月。
[RTADVD] "rtadvd(8) manual page", <http://www.freebsd.org/cgi/ man.cgi?query=rtadvd&sektion=8>.
[RTADV]“RTADV（8）手册页”<http://www.freebsd.org/cgi/ man.cgi？query=rtadv&sektion=8>。
[SI6-Toolkit] SI6 Networks, "SI6 Networks' IPv6 Toolkit", <http://www.si6networks.com/tools/ipv6toolkit>.
[SI6 Toolkit]SI6 Networks，“SI6 Networks的IPv6 Toolkit”<http://www.si6networks.com/tools/ipv6toolkit>.
[SSL-VPNs] Hoffman, P., "SSL VPNs: An IETF Perspective", IETF 72, SAAG Meeting, 2008, <http://www.ietf.org/proceedings/72/slides/saag-4.pdf>.
[SSL VPN]Hoffman，P.，“SSL VPN：IETF视角”，IETF 72，SAAG会议，2008年<http://www.ietf.org/proceedings/72/slides/saag-4.pdf>.
[THC-IPv6] The Hacker's Choice, "THC-IPV6 - attacking the IPV6 protocol suite", <http://www.thc.org/thc-ipv6/>.
[THC-IPv6]黑客的选择，“THC-IPv6-攻击IPv6协议套件”<http://www.thc.org/thc-ipv6/>.
Author's Address
作者地址
Fernando Gont Huawei Technologies Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
Fernando Gont Huawei Technologies Evaristo Carriego 2644 Haedo，布宜诺斯艾利斯省1706阿根廷
Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI: http://www.si6networks.com
Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI: http://www.si6networks.com