Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 6169 Ericsson
Category: Informational D. Thaler
ISSN: 2070-1721 Microsoft
J. Hoagland
Symantec
April 2011
Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 6169 Ericsson
Category: Informational D. Thaler
ISSN: 2070-1721 Microsoft
J. Hoagland
Symantec
April 2011
Security Concerns with IP Tunneling
IP隧道的安全问题
Abstract
摘要
A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues.
本备忘录中记录了IP隧道的一些安全问题。本文档的目标读者包括网络管理员和未来的协议开发人员。本文件的主要目的是提高对部署的IP隧道安全问题的认识，并提出缓解这些问题的策略。
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/rfc6169.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6169.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
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.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................2
2. Tunnels May Bypass Security .....................................3
2.1. Network Security Bypass ....................................3
2.2. IP Ingress and Egress Filtering Bypass .....................5
2.3. Source Routing after the Tunnel Client .....................6
3. Challenges in Inspecting and Filtering Content of
Tunneled Data Packets ...........................................7
3.1. Inefficiency of Selective Network Filtering of All
Tunneled Packets ...........................................7
3.2. Problems with Deep Packet Inspection of Tunneled
Data Packets ...............................................8
4. Increased Exposure Due to Tunneling .............................9
4.1. NAT Holes Increase Attack Surface ..........................9
4.2. Exposure of a NAT Hole ....................................11
4.3. Public Tunnels Widen Holes in Restricted NATs .............12
5. Tunnel Address Concerns ........................................13
5.1. Feasibility of Guessing Tunnel Addresses ..................13
5.2. Profiling Targets Based on Tunnel Address .................14
6. Additional Security Concerns ...................................15
6.1. Attacks Facilitated by Changing Tunnel Server Setting .....15
7. Mechanisms to Secure the Use of Tunnels ........................17
8. Acknowledgments ................................................18
9. Security Considerations ........................................18
10. Informative References ........................................18
1. Introduction ....................................................2
2. Tunnels May Bypass Security .....................................3
2.1. Network Security Bypass ....................................3
2.2. IP Ingress and Egress Filtering Bypass .....................5
2.3. Source Routing after the Tunnel Client .....................6
3. Challenges in Inspecting and Filtering Content of
Tunneled Data Packets ...........................................7
3.1. Inefficiency of Selective Network Filtering of All
Tunneled Packets ...........................................7
3.2. Problems with Deep Packet Inspection of Tunneled
Data Packets ...............................................8
4. Increased Exposure Due to Tunneling .............................9
4.1. NAT Holes Increase Attack Surface ..........................9
4.2. Exposure of a NAT Hole ....................................11
4.3. Public Tunnels Widen Holes in Restricted NATs .............12
5. Tunnel Address Concerns ........................................13
5.1. Feasibility of Guessing Tunnel Addresses ..................13
5.2. Profiling Targets Based on Tunnel Address .................14
6. Additional Security Concerns ...................................15
6.1. Attacks Facilitated by Changing Tunnel Server Setting .....15
7. Mechanisms to Secure the Use of Tunnels ........................17
8. Acknowledgments ................................................18
9. Security Considerations ........................................18
10. Informative References ........................................18
With NAT devices becoming increasingly more prevalent, there have recently been many tunneling protocols developed that go through NAT devices or firewalls by tunneling over UDP or TCP. For example, Teredo [RFC4380], Layer Two Tunneling Protocol Version 2 (L2TPv2) [RFC2661], and Layer Two Tunneling Protocol Version 3 (L2TPv3) [RFC3931] all tunnel IP packets over UDP. Similarly, many Secure Socket Layer (SSL) VPN solutions that tunnel IP packets over HTTP (and hence over TCP) are deployed today.
随着NAT设备变得越来越普遍，最近开发了许多隧道协议，通过UDP或TCP隧道通过NAT设备或防火墙。例如，Teredo[RFC4380]、第二层隧道协议版本2（L2TPv2）[RFC2661]和第二层隧道协议版本3（L2TPv3）[RFC3931]通过UDP传输所有隧道IP数据包。类似地，今天部署了许多安全套接字层（SSL）VPN解决方案，这些解决方案通过HTTP（从而通过TCP）传输IP数据包。
This document discusses security concerns with tunneling IP packets and includes recommendations where relevant.
本文档讨论隧道IP数据包的安全问题，并包括相关建议。
The primary intent of this document is to help improve security deployments using tunnel protocols. In addition, the document aims to provide information that can be used in any new or updated tunnel protocol specification. The intended audience of this document includes network administrators and future protocol developers.
本文档的主要目的是帮助改进使用隧道协议的安全部署。此外，本文件旨在提供可用于任何新的或更新的隧道协议规范的信息。本文档的目标读者包括网络管理员和未来的协议开发人员。
Tunneled IP traffic may not receive the intended level of inspection or policy application by network-based security devices unless such devices are specifically tunnel aware. This reduces defense in depth and may cause security gaps. This applies to all network-located devices and to any end-host-based firewalls whose existing hooking mechanism(s) would not show them the IP packet stream after the tunnel client does decapsulation or before it does encapsulation.
隧道式IP通信可能无法通过基于网络的安全设备接收到预期级别的检查或策略应用，除非此类设备具有特定的隧道感知能力。这会减少纵深防御，并可能导致安全漏洞。这适用于所有位于网络中的设备以及任何基于终端主机的防火墙，这些防火墙的现有挂接机制在隧道客户端解除封装后或封装前不会向它们显示IP数据包流。
Evasion by tunneling is often a problem for network-based security devices such as network firewalls, intrusion detection and prevention systems, and router controls. To provide such functionality in the presence of tunnels, the developer of such devices must add support for parsing each new protocol. There is typically a significant lag between when the security developer recognizes that a tunnel will be used (or will be remotely usable) to a significant degree and when the parsing can be implemented in a product update, the update can be tested and released, and customers can begin using the update. Late changes in the protocol specification or in the way it is implemented can cause additional delays. This becomes a significant security concern when a delay in applied coverage is occurring frequently.
隧道规避通常是基于网络的安全设备（如网络防火墙、入侵检测和预防系统以及路由器控制）的一个问题。为了在存在隧道的情况下提供这种功能，这种设备的开发人员必须添加对解析每个新协议的支持。当安全开发人员意识到隧道将在很大程度上被使用（或将被远程使用）时，与在产品更新中实现解析、测试和发布更新以及客户开始使用更新之间，通常存在明显的延迟。协议规范或其实现方式的延迟更改可能会导致额外的延迟。当应用覆盖的延迟频繁发生时，这成为一个重要的安全问题。
One way to cut down on this lag is for security developers to follow the progress of new IETF protocols, but this will still not account for any new proprietary protocols.
减少这种滞后的一种方法是让安全开发人员跟踪新IETF协议的进展，但这仍然不会考虑任何新的专有协议。
For example, for L2TP or Teredo, an unaware network security device would inspect or regulate the outer IP and the IP-based UDP layer as normal, but it would not recognize that there is an additional IP layer contained inside the UDP payload to which it needs to apply the same controls as it would to a native packet. (Of course, if the device discards the packet due to something in the IP or UDP header, such as referring to an unknown protocol, the embedded packet is no longer a concern.) In addition, if the tunnel does encryption, the network-based security device may not be able to do much, just as if IPsec end-to-end encryption were used without tunneling.
例如，对于L2TP或Teredo，不知情的网络安全设备会像正常情况一样检查或调节外部IP和基于IP的UDP层，但它不会识别UDP有效负载中包含的附加IP层，它需要对其应用与对本机数据包相同的控制。（当然，如果设备由于IP或UDP报头中的某些内容而丢弃数据包，例如引用未知协议，则嵌入的数据包不再是问题。）此外，如果隧道进行加密，则基于网络的安全设备可能无法做很多事，就像在没有隧道的情况下使用IPsec端到端加密一样。
Network security controls not being applied must be a concern to those that set them up, since those controls are supposed to provide an additional layer of defense against external attackers. If network controls are being bypassed due to the use of tunneling, the strength of the defense (i.e., the number of layers of defense) is reduced. Since security administrators may have a significantly reduced level of confidence without this layer, this becomes a concern to them.
未应用的网络安全控制必须引起设置这些控制的人的关注，因为这些控制应该提供额外的防御层来抵御外部攻击者。如果由于使用隧道而绕过网络控制，则防御强度（即防御层数）会降低。由于没有这一层，安全管理员的信心可能会显著降低，因此这成为他们关注的问题。
One implication of the security control bypass is that defense in depth has been reduced, perhaps down to zero unless a local firewall is in use as recommended in [RFC4380]. However, even if there are host-based security controls that recognize tunnels and all controls that were maintained by the network are available on the host, security administrators may not have configured them with full security control parity. Thus, there may be gaps in desired coverage.
安全控制旁路的一个含义是，纵深防御已经减少，可能降至零，除非按照[RFC4380]中的建议使用本地防火墙。但是，即使存在识别隧道的基于主机的安全控制，并且网络维护的所有控制都在主机上可用，安全管理员也可能没有将它们配置为完全安全控制奇偶校验。因此，期望的覆盖范围可能存在差距。
Compounding this is that, unlike what would be the case for native IP, some network administrators will not even be aware that their hosts are globally reachable if the tunnel provides connectivity to/from the Internet; for example, they may not be expecting this for hosts behind a stateful firewall. In addition, Section 3.2 discusses how it may not be efficient to find all tunneled traffic for network devices to examine.
更复杂的是，与本机IP不同，如果隧道提供与Internet的连接，一些网络管理员甚至不会意识到他们的主机是全局可访问的；例如，他们可能不希望有状态防火墙后面的主机出现这种情况。此外，第3.2节讨论了查找所有隧道流量以供网络设备检查的效率可能不高的原因。
Security administrators who do not consider tunneling an acceptable risk should disable tunnel functionality either on the end nodes (hosts) or on the network nodes at the perimeter of their network. However, there may be an awareness gap. Thus, due to the possible negative security consequences, tunneling functionality should be
不考虑隧道化可接受风险的安全管理员应禁用端节点（主机）或其网络周边的网络节点上的隧道功能。然而，可能存在意识差距。因此，由于可能产生的负面安全后果，隧道功能应该是安全的
easy to disable on the host and through a central management facility if one is provided.
易于在主机上禁用，如果提供中央管理设施，则可通过中央管理设施禁用。
To minimize security exposure due to tunnels, we recommend that a tunnel be an interface of last resort, independent of IP version. Specifically, we suggest that when both native and tunneled access to a remote host is available, the native access be used in preference to tunneled access except when the tunnel endpoint is known to not bypass security (e.g., an IPsec tunnel to a gateway provided by the security administrator of the network). This should also promote greater efficiency and reliability.
为了最大限度地减少由于隧道而带来的安全风险，我们建议隧道作为最后的接口，独立于IP版本。具体而言，我们建议，当对远程主机的本机和隧道访问都可用时，本机访问优先于隧道访问，除非已知隧道端点未绕过安全性（例如，到网络安全管理员提供的网关的IPsec隧道）。这也将提高效率和可靠性。
Note that although Rule 7 of [RFC3484], Section 6 will prefer native connectivity over tunnels, this rule is only a tie-breaker when a choice is not made by earlier rules; hence, tunneling mechanisms that are tied to a particular range of IP address space will be decided based on the prefix precedence. For example, using the prefix policy mechanism of [RFC3484], Section 2.1, Teredo might have a precedence of 5 so that native IPv4 is preferred over Teredo.
请注意，尽管[RFC3484]第6节的规则7更倾向于本机连接，而不是隧道，但当先前的规则没有做出选择时，该规则只是一个平局断路器；因此，绑定到特定IP地址空间范围的隧道机制将基于前缀优先级来决定。例如，使用[RFC3484]第2.1节中的前缀策略机制，Teredo的优先级可能为5，因此本机IPv4优先于Teredo。
IP addresses inside tunnels are not subject to ingress and egress filtering in the network they tunnel over, unless extraordinary measures are taken. Only the tunnel endpoints can do such filtering.
隧道内的IP地址在隧道所经过的网络中不受入口和出口过滤的影响，除非采取特殊措施。只有隧道端点可以执行此类过滤。
Ingress filtering (sanity-checking incoming destination addresses) and egress filtering (sanity-checking outgoing source addresses) are done to mitigate attacks and to make it easier to identify the source of a packet and are considered to be a good practice. For example, ingress filtering at the network perimeter should not allow packets with a source address that belongs to the network to enter the network from outside the network. This function is most naturally (and in the general case, by requirement) done at network boundaries. Tunneled IP traffic bypassing this network control is a specific case of Section 2.1, but is illustrative.
入口过滤（健全性检查传入目的地地址）和出口过滤（健全性检查传出源地址）用于减轻攻击，并使其更容易识别数据包的源，被认为是一种良好的做法。例如，网络周边的入口过滤不应允许具有属于网络的源地址的数据包从网络外部进入网络。此功能最自然地（在一般情况下，根据需要）在网络边界完成。绕过该网络控制的隧道式IP流量是第2.1节的一个具体情况，但只是说明性的。
Tunnel servers can apply ingress and egress controls to tunneled IP addresses passing through them to and from tunnel clients.
隧道服务器可以将入口和出口控制应用于隧道IP地址，通过隧道IP地址进出隧道客户端。
Tunnel clients could make an effort to conduct ingress and egress filtering.
隧道客户端可以努力进行入口和出口过滤。
Implementations of protocols that embed an IPv4 address in a tunneled IPv6 address directly between peers should perform filtering based on checking the correspondence.
直接在对等方之间的隧道IPv6地址中嵌入IPv4地址的协议的实现应基于检查对应关系执行过滤。
Implementations of protocols that accept tunneled packets directly from a server, relay, or protocol peer do filtering the same way as it would be done on a native link with traffic from a router.
直接从服务器、中继或协议对等方接收隧道数据包的协议实现的过滤方式与使用路由器流量在本机链路上进行过滤的方式相同。
Some protocols such as 6to4 [RFC3056], Teredo, and the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] allow both other hosts and a router over a common tunnel. To perform host-based filtering with such protocols, a host would need to know the outer IP address of each router from which it could receive traffic, so that packets from hosts beyond the router will be accepted even though the source address would not embed the router's IP address. Router addresses might be learned via SEcure Neighbor Discovery (SEND) [RFC3971] or some other mechanism (e.g., [RFC5214], Section 8.3.2).
一些协议，如6to4[RFC3056]、Teredo和站点内自动隧道寻址协议（ISATAP）[RFC5214]允许其他主机和路由器通过公共隧道。要使用此类协议执行基于主机的过滤，主机需要知道每个路由器的外部IP地址，以便接收来自路由器以外主机的数据包，即使源地址不会嵌入路由器的IP地址。路由器地址可以通过安全邻居发现（SEND）[RFC3971]或某些其他机制（例如[RFC5214]，第8.3.2节）学习。
If the encapsulated IP packet specifies source routing beyond the recipient tunnel client, the host may forward the IP packet to the specified next hop. This may be unexpected and contrary to administrator wishes and may have bypassed network-based source-routing controls.
如果封装的IP分组指定了超出接收方隧道客户端的源路由，则主机可以将IP分组转发到指定的下一跳。这可能是意外的，与管理员的愿望相反，并且可能绕过了基于网络的源路由控制。
A detailed discussion of issues related to source routing can be found in [RFC5095] and [SECA-IP].
有关源路由相关问题的详细讨论，请参见[RFC5095]和[SECA-IP]。
Tunnel clients should by default discard tunneled IP packets that specify additional routing, as recommended in [RFC5095] and [SECA-IP], though they may also allow the user to configure what source-routing types are allowed. All pre-existing source-routing controls should be upgraded to apply these controls to tunneled IP packets as well.
按照[RFC5095]和[SECA-IP]中的建议，默认情况下，隧道客户端应丢弃指定额外路由的隧道IP数据包，尽管它们也允许用户配置允许的源路由类型。所有预先存在的源路由控制都应该升级，以便将这些控制应用于隧道IP数据包。
3. Challenges in Inspecting and Filtering Content of Tunneled Data Packets
3. 检查和过滤隧道数据包内容的挑战
3.1. Inefficiency of Selective Network Filtering of All Tunneled Packets
3.1. 选择性网络过滤所有隧道数据包的低效性
There is no mechanism that both efficiently and immediately filters all tunneled packets (other than the obviously faulty method of filtering all packets). This limits the ability to prevent tunnel use on a network.
没有一种机制既能有效又能立即过滤所有隧道数据包（过滤所有数据包的明显错误方法除外）。这限制了防止在网络上使用隧道的能力。
Given concerns about tunnel security or a network's lack of preparedness for tunnels, a network administrator may wish to simply block all use of tunnels that bypass security policies. He or she may wish to do so using network controls; this could be either due to not having the capability to disable tunneling on all hosts attached to the network or due to wanting an extra layer of prevention.
考虑到对隧道安全的担忧或网络对隧道缺乏准备，网络管理员可能希望简单地阻止所有绕过安全策略的隧道的使用。他或她可能希望使用网络控制来实现这一点；这可能是因为没有能力在连接到网络的所有主机上禁用隧道，也可能是因为需要额外的一层预防。
One simple method of doing this easily for many tunnel protocols is to block outbound packets to the UDP or TCP port used (e.g., destination UDP port is 3544 for Teredo, UDP port 1701 for L2TP, etc.). This prevents a tunnel client from establishing a new tunnel. However, existing tunnels will not necessarily be affected if the blocked port is used only for initial setup. In addition, if the blocking is applied on the outside of the client's NAT device, the NAT device will retain the port mapping for the client. In some cases, however, blocking all traffic to a given outbound port (e.g., port 80) may interfere with non-tunneled traffic so this should be used with caution.
对于许多隧道协议来说，一种简单的方法是阻止到所用UDP或TCP端口的出站数据包（例如，Teredo的目标UDP端口是3544，L2TP的UDP端口是1701，等等）。这会阻止隧道客户端建立新的隧道。但是，如果阻塞端口仅用于初始设置，则现有隧道不一定会受到影响。此外，如果阻塞应用于客户端NAT设备的外部，则NAT设备将保留客户端的端口映射。但是，在某些情况下，阻塞到给定出站端口（例如端口80）的所有流量可能会干扰非隧道流量，因此应谨慎使用。
Another simple alternative, if the tunnel server addresses are well-known, is to filter out all traffic to/from such addresses.
另一个简单的替代方法是，如果隧道服务器地址是众所周知的，则过滤掉进出此类地址的所有通信量。
The other approach is to find all packets to block in the same way as would be done for inspecting all packets (Section 3.2). However, this presents difficulties in terms of efficiency of filtering, as is discussed in Section 3.2.
另一种方法是以与检查所有数据包相同的方式查找要阻塞的所有数据包（第3.2节）。然而，如第3.2节所述，这在过滤效率方面存在困难。
Developers of protocols that tunnel over UDP or TCP (including HTTP) to reach the Internet should disable their protocols in networks that wish to enforce security policies on the user traffic. (Windows, for example, disables Teredo by default if it detects that it is within an enterprise network that contains a Windows domain controller.)
通过UDP或TCP（包括HTTP）隧道到达Internet的协议的开发人员应在希望对用户流量实施安全策略的网络中禁用其协议。（例如，如果Windows检测到Teredo位于包含Windows域控制器的企业网络中，则默认情况下禁用Teredo。）
Administrators of such networks may wish to filter all tunneled traffic at the boundaries of their networks. It is sufficient to filter out the tunneled connection requests (if they can be identified) to stop further tunneled traffic. The easiest mechanism for this would be to filter out outgoing traffic sent to the destination port defined by the tunneling protocol and incoming traffic with that source port. Similarly, in certain cases, it is also possible to use the IP protocol field to identify and filter tunneled packets. For example, 6to4 [RFC3056] is a tunneling mechanism that uses IPv4 packets to carry encapsulated IPv6 packets and can be identified by the IPv4 protocol type 41.
此类网络的管理员可能希望过滤其网络边界处的所有隧道流量。过滤掉隧道连接请求（如果可以识别）就足以阻止进一步的隧道通信。最简单的机制是过滤掉发送到隧道协议定义的目标端口的传出流量和该源端口的传入流量。类似地，在某些情况下，也可以使用IP协议字段来识别和过滤隧道包。例如，6to4[RFC3056]是一种隧道机制，它使用IPv4数据包来携带封装的IPv6数据包，并且可以通过IPv4协议类型41来识别。
There is no efficient mechanism for network-based devices, which are not the tunnel endpoint, to inspect the contents of all tunneled data packets the way they can for native packets. This makes it difficult to apply the same controls as they do to native IP.
对于不是隧道端点的基于网络的设备，没有有效的机制来检查所有隧道数据包的内容，就像检查本地数据包一样。这使得很难将相同的控件应用于本机IP。
Some tunnel protocols are easy to identify, such as if all data packets are encapsulated using a well-known UDP or TCP port that is unique to the protocol.
有些隧道协议很容易识别，例如，如果所有数据包都使用该协议特有的众所周知的UDP或TCP端口进行封装。
Other protocols, however, either use dynamic ports for data traffic or else share ports with other protocols (e.g., tunnels over HTTP).
但是，其他协议使用动态端口进行数据通信，或者与其他协议共享端口（例如，HTTP上的隧道）。
The implication of this is that network-based devices that wish to passively inspect (and perhaps selectively apply policy to) all encapsulated traffic must inspect all TCP or UDP packets (or at least all packets not part of a session that is known not to be a tunnel). This is imperfect since a heuristic must then be applied to determine if a packet is indeed part of a tunnel. This may be too slow to make use of in practice, especially if it means that all TCP or UDP packets must be taken off of the device's "fast path".
这意味着，希望被动检查（并且可能选择性地将策略应用于）所有封装流量的基于网络的设备必须检查所有TCP或UDP数据包（或者至少所有不属于已知非隧道的会话的数据包）。这是不完美的，因为必须应用启发式来确定数据包是否确实是隧道的一部分。这可能太慢，无法在实践中使用，尤其是当它意味着所有TCP或UDP数据包都必须从设备的“快速路径”中删除时。
One heuristic that can be used on packets to determine if they are tunnel-related or not is as follows. For each known tunnel protocol, attempt parsing the packet as if it were a packet of that protocol destined to the local host (i.e., where the local host has the destination address in the inner IP header, if any). If all syntax checks pass, up to and including the inner IP header (if the tunnel does not use encryption), then treat the packet as if it were a tunneled packet of that protocol.
一种可用于数据包以确定它们是否与隧道相关的启发式方法如下。对于每个已知的隧道协议，尝试解析数据包，就像它是该协议的数据包，目的地是本地主机（即，本地主机在内部IP报头中有目的地地址，如果有的话）。如果所有语法检查都通过，包括内部IP报头（如果隧道不使用加密），则将该数据包视为该协议的隧道数据包。
It is possible that non-tunneled packets will be treated as if they were tunneled packets using this heuristic, but tunneled packets (of the known types of tunnels) should not escape inspection, absent implementation bugs.
使用这种启发式方法，非隧道数据包可能会被视为隧道数据包，但隧道数据包（已知类型的隧道）不应逃避检查，因为没有实现错误。
For some protocols, it may be possible to monitor setup exchanges to know to expect that data will be exchanged on certain ports later. (Note that this does not necessarily apply to Teredo, for example, since communicating with another Teredo client behind a cone NAT [RFC5389] device does not require such signaling. In such cases this control will not work. However, deprecation of the cone bit as discussed in [RFC5991] means this technique may indeed work with updated Teredo implementations.)
对于某些协议，可以监视设置交换，以了解数据稍后将在某些端口上交换。（请注意，这不一定适用于Teredo，例如，因为与cone NAT[RFC5389]设备后面的另一个Teredo客户端通信不需要此类信令。在这种情况下，此控制将不起作用。但是，如[RFC5991]中所述，取消使用cone位。）这意味着此技术可能确实适用于更新的Teredo实现。）
As illustrated above, it should be clear that inspecting the contents of tunneled data packets is highly complex and often impractical. For this reason, if a network wishes to monitor IP traffic, tunneling across, as opposed to tunneling to, the security boundary is not recommended. For example, to provide an IPv6 transition solution, the network should provide native IPv6 connectivity or a tunnel solution (e.g., ISATAP or 6over4 [RFC2529]) that encapsulates data packets between hosts and a router within the network.
如上所述，应该清楚的是，检查隧道数据包的内容是非常复杂的，并且通常是不切实际的。因此，如果网络希望监视IP流量，则不建议通过隧道而不是通过隧道来监视安全边界。例如，为了提供IPv6过渡解决方案，网络应提供本机IPv6连接或隧道解决方案（例如，ISATAP或6over4[RFC2529]），该解决方案封装网络内主机和路由器之间的数据包。
If the tunnel allows inbound access from the public Internet, the opening created in a NAT device due to a tunnel client increases its Internet attack surface area. If vulnerabilities are present, this increased exposure can be used by attackers and their programs.
如果隧道允许从公共互联网进行入站访问，则由于隧道客户端在NAT设备中创建的开口会增加其互联网攻击表面积。如果存在漏洞，攻击者及其程序可能会使用这种增加的暴露。
If the tunnel allows inbound access only from a private network (e.g., a remote network to which one has VPNed), the opening created in the NAT device still increases its attack surface area, although not as much as in the public Internet case.
如果隧道仅允许从专用网络（例如，已接入VPN的远程网络）进行入站访问，则在NAT设备中创建的开口仍然会增加其攻击表面积，尽管没有在公共互联网情况下那么多。
When a tunnel is active, a mapped port is maintained on the NAT device through which remote hosts can send packets and perhaps establish connections. The following sequence is intended to sketch out the processing on the tunnel client host that can be reached through this mapped port; the actual processing for a given host may be somewhat different.
当隧道处于活动状态时，NAT设备上会保留一个映射端口，远程主机可以通过该端口发送数据包并可能建立连接。以下顺序旨在勾勒出可通过该映射端口访问的隧道客户端主机上的处理；给定主机的实际处理可能有所不同。
1. Link-layer protocol processing
1. 链路层协议处理
2. (Outer) IP host firewall processing
2. （外部）IP主机防火墙处理
3. (Outer) IP processing by stack
3. （外部）通过堆栈的IP处理
4. UDP/TCP processing by stack
4. UDP/TCP协议栈处理
5. Tunnel client processing
5. 隧道客户端处理
6. (Inner) IP host firewall processing
6. （内部）IP主机防火墙处理
7. (Inner) IP processing by stack
7. （内部）通过堆栈进行IP处理
8. Various upper layer processing may follow
8. 随后可能会进行各种上层处理
The inner firewall (and other security) processing may or may not be present, but if it is, some of the inner IP processing may be filtered. (For example, [RFC4380], Section 7.1 recommends that an IPv6 host firewall be used on all Teredo clients.)
内部防火墙（和其他安全）处理可能存在，也可能不存在，但如果存在，则可能会过滤一些内部IP处理。（例如，[RFC4380]，第7.1节建议在所有Teredo客户端上使用IPv6主机防火墙。）
(By the virtue of the tunnel being active, we can infer that the inner host firewall is unlikely to do any filtering based on the outer IP.) Any of this processing may expose vulnerabilities an attacker can exploit; similarly, these may expose information to an attacker. Thus, even if firewall filtering is in place (as is prudent) and filters all incoming packets, the exposed area is larger than if a native IP Internet connection were in place, due to the processing that takes place before the inner IP is reached (specifically, the UDP/TCP processing, the tunnel client processing, and additional IP processing, especially if one is IPv4 and the other is IPv6).
（由于隧道处于活动状态，我们可以推断内部主机防火墙不太可能基于外部IP进行任何过滤。）任何此类处理都可能暴露攻击者可以利用的漏洞；类似地，这些可能会将信息暴露给攻击者。因此，即使防火墙过滤到位（谨慎起见）并过滤所有传入数据包，由于在到达内部IP之前进行的处理，暴露区域也比本地IP Internet连接到位时大（特别是UDP/TCP处理、隧道客户端处理和附加IP处理，特别是当一个是IPv4，另一个是IPv6时）。
One possibility is that a layer 3 (L3) targeted worm makes use of a vulnerability in the exposed processing. The main benefit tunneling provides to worms is enabling L3 reachability to the end host. Even a thoroughly firewalled host could be subject to a worm that spreads with a single UDP packet if the right remote code vulnerability is present.
一种可能性是，针对第3层（L3）的蠕虫利用公开处理中的漏洞。隧道为蠕虫提供的主要好处是使L3能够访问终端主机。如果存在正确的远程代码漏洞，即使是完全防火墙的主机也可能受到蠕虫的影响，该蠕虫通过单个UDP数据包传播。
This problem seems inherent in tunneling being active on a host, so the solution seems to be to minimize tunneling use.
这个问题似乎是在主机上活动的隧道中固有的，因此解决方案似乎是最小化隧道使用。
For example, tunneling can be active only when it is really needed and only for as long as needed. So, the tunnel interface can be initially not configured and only used when it is entirely the last resort. The interface should then be deactivated (ideally, automatically) again as soon as possible. Note, however, that the hole will remain in the NAT device for some amount of time after this, so some processing of incoming packets is inevitable unless the client's native IP address behind the NAT device is changed.
例如，隧道只能在真正需要时激活，并且只能在需要的时间内激活。因此，隧道接口最初不可配置，仅在完全是最后手段时使用。然后应尽快再次停用该接口（理想情况下是自动停用）。然而，请注意，在此之后，该漏洞将在NAT设备中保留一段时间，因此，除非更改NAT设备后面的客户端的本机IP地址，否则对传入数据包的一些处理是不可避免的。
Attackers are more likely to know about a tunnel client's NAT hole than a typical hole in the NAT device. If they know about the hole, they could try to use it.
与NAT设备中的典型漏洞相比，攻击者更可能知道隧道客户端的NAT漏洞。如果他们知道这个洞，他们可以试着利用它。
There are at least three reasons why an attacker may be more likely to learn of the tunnel client's exposed port than a typical NAT exposed port:
与典型的NAT暴露端口相比，攻击者更可能了解隧道客户端暴露端口的原因至少有三个：
1. The NAT mapping for a tunnel is typically held open for a significant period of time and kept stable. This increases the chance of it being discovered.
1. 隧道的NAT映射通常在相当长的一段时间内保持开放并保持稳定。这增加了被发现的机会。
2. In some protocols (e.g., Teredo), the external IP address and port are contained in the client's address that is used end-to-end and possibly even advertised in a name resolution system. While the tunnel protocol itself might only distribute this address in IP headers, peers, routers, and other on-path nodes still see the client's IP address. Although this point does not apply directly to protocols that do not construct the inner IP address based on the outer IP address (e.g., L2TP), the inner IP
2. 在某些协议（例如Teredo）中，外部IP地址和端口包含在端到端使用的客户端地址中，甚至可能在名称解析系统中公布。虽然隧道协议本身可能只在IP报头中分发此地址，但对等方、路由器和其他路径节点仍然可以看到客户端的IP地址。尽管这一点不直接适用于不基于外部IP地址（例如L2TP）构建内部IP地址的协议，但内部IP
address is still known to peers, routers, etc., and can still be reached by attackers without their knowing the external IP address or port.
对等方、路由器等仍然知道该地址，攻击者仍然可以在不知道外部IP地址或端口的情况下访问该地址。
3. Sending packets over a tunnel often results in more message exchanges due to the tunneling protocol, as well as messages being seen by more parties (e.g., due to a longer path length), than sending packets natively, offering more chances for visibility into the port and address in use.
3. 由于隧道协议，通过隧道发送数据包通常会导致更多的消息交换，以及更多方看到的消息（例如，由于更长的路径长度），而不是以本机方式发送数据包，从而提供更多机会查看正在使用的端口和地址。
The recommendation from Section 4.1 seems to apply here as well: minimize tunnel use.
第4.1节的建议似乎也适用于此：尽量减少隧道使用。
Tunnels that allow inbound connectivity from the Internet (e.g., Teredo, tunnel brokers, etc.) essentially disable the filtering behavior of the NAT for all tunnel client ports. This eliminates NAT devices filtering for such ports and may eliminate the need for an attacker to spoof an address.
允许从Internet进行入站连接的隧道（例如Teredo、隧道代理等）基本上禁用了NAT对所有隧道客户端端口的过滤行为。这消除了NAT设备对此类端口的过滤，并可能消除攻击者伪造地址的需要。
NATs that implement Address-Dependent or Address and Port-Dependent Filtering [RFC4787] limit the source of incoming packets to just those that are a previous destination. This poses a problem for tunnels that intend to allow inbound connectivity from the Internet.
实现地址相关或地址和端口相关过滤[RFC4787]的NAT将传入数据包的源限制为仅为前一个目的地的数据包。这给打算允许从Internet进行入站连接的隧道带来了问题。
Various protocols (e.g., Teredo, Session Traversal Utilities for NAT (STUN) [RFC5389], etc.) provide a facility for peers, upon request, to become a previous destination. This works by sending a "bubble" packet via a server, which is passed to the client and then sent by the client (through the NAT) to the originator.
各种协议（例如，Teredo、NAT会话遍历实用程序（STUN）[RFC5389]等）根据请求为对等方提供了成为前一个目的地的便利。其工作原理是通过服务器发送一个“气泡”数据包，该数据包被传递给客户机，然后由客户机（通过NAT）发送给发起人。
This removes any NAT-based barrier to attackers sending packets in through the client's service port. In particular, an attacker would no longer need to either be an actual previous destination or forge its addresses as a previous destination. When forging, the attacker would have had to learn of a previous destination and then would face more challenges in seeing any returned traffic.
这消除了攻击者通过客户端服务端口发送数据包的任何基于NAT的障碍。特别是，攻击者不再需要是实际的前一个目的地或伪造其地址作为前一个目的地。伪造时，攻击者必须了解以前的目的地，然后在查看任何返回的流量时将面临更多的挑战。
If the tunnel can provide connectivity to the Internet, the tunnel client should run a host firewall on the tunnel interface. Also, minimizing public tunnel use (see Section 4.1.3) would lower the attack opportunity related to this exposure.
如果隧道可以提供到Internet的连接，则隧道客户端应在隧道接口上运行主机防火墙。此外，尽量减少公共隧道的使用（见第4.1.3节）将降低与此暴露相关的攻击机会。
For some types of tunneling protocols, it may be feasible to guess IP addresses assigned to tunnels, either when looking for a specific client or when looking for an arbitrary client. This is in contrast to native IPv6 addresses in general but is no worse than for native IPv4 addresses today.
对于某些类型的隧道协议，在查找特定客户端或任意客户端时，猜测分配给隧道的IP地址可能是可行的。这通常与本机IPv6地址形成对比，但并不比今天的本机IPv4地址差。
For example, some protocols (e.g., 6to4 and Teredo) use well-defined address ranges. As another example, using well-known public servers for Teredo or tunnel brokers also implies using a well-known address range.
例如，一些协议（例如6to4和Teredo）使用定义良好的地址范围。另一个例子是，为Teredo或隧道代理使用知名的公共服务器也意味着使用知名的地址范围。
Several tunnel protocols use endpoint addresses that can be algorithmically derived from some known values. These addresses are structured, and the fields contained in them can be fairly predictable. This reduces the search space for an attacker and reduces the resistance of the address to scanning attacks.
一些隧道协议使用端点地址，这些端点地址可以通过算法从一些已知值派生。这些地址是结构化的，其中包含的字段可以相当容易地预测。这减少了攻击者的搜索空间，并降低了地址对扫描攻击的抵抗力。
It is recommended that tunnel protocol developers use tunnel endpoint addresses that are not easily guessable. When the tunnel endpoint addresses are structured and fairly guessable, it is recommended that the implementation use any unused fields in the address to provide additional entropy to the address in order to reduce the address-scanning risks. For example, this could be done by setting these unused fields to some random values.
建议隧道协议开发人员使用不易猜测的隧道端点地址。当隧道端点地址是结构化的且相当容易猜测时，建议实现使用地址中任何未使用的字段为地址提供额外的熵，以降低地址扫描风险。例如，这可以通过将这些未使用的字段设置为一些随机值来实现。
An attacker encountering an address associated with a particular tunneling protocol or well-known tunnel server has the opportunity to infer certain relevant pieces of information that can be used to profile the host before sending any packets. This can reduce the attacker's footprint and increase the attacker's efficiency.
遇到与特定隧道协议或已知隧道服务器相关的地址的攻击者有机会在发送任何数据包之前推断出某些可用于分析主机的相关信息。这可以减少攻击者的足迹并提高攻击者的效率。
The tunnel address reveals some information about the nature of the client:
隧道地址揭示了有关客户性质的一些信息：
o That a host has a tunnel address associated with a given protocol means that the client is running on some platform for which there exists a tunnel client implementation of that protocol. In addition, if some platforms have that protocol installed by default and if the host's default rules for using it make it susceptible to being in use, then the protocol is more likely to be running on such a platform than on one where it is not used by default. For example, as of this writing, seeing a Teredo address suggests that the host it is on is probably running Windows.
o 主机具有与给定协议关联的隧道地址意味着客户端正在某个平台上运行，该平台上存在该协议的隧道客户端实现。此外，如果某些平台默认安装了该协议，并且主机使用该协议的默认规则使其易于使用，则该协议更有可能在此类平台上运行，而不是在默认情况下不使用该协议的平台上运行。例如，在撰写本文时，看到Teredo地址表明它所在的主机可能正在运行Windows。
o Similarly, the use of an address associated with a particular tunnel server also suggests some information. Tunnel client software is often deployed, installed, and/or configured using some degree of automation. It seems likely that the majority of the time, the tunnel server that results from the initial configuration will go unchanged from the initial setting. Moreover, the server that is configured for use may be associated with a particular means of installation, which often suggests the platform. For example, if the server field in a Teredo address is one of the IPv4 addresses to which teredo.ipv6.microsoft.com resolves, the host is likely running Windows.
o 类似地，使用与特定隧道服务器关联的地址也会显示一些信息。隧道客户端软件通常使用某种程度的自动化进行部署、安装和/或配置。在大多数情况下，由初始配置产生的隧道服务器很可能与初始设置保持不变。此外，配置为使用的服务器可能与特定的安装方式相关联，这通常建议使用平台。例如，如果Teredo地址中的服务器字段是Teredo.ipv6.microsoft.com解析到的IPv4地址之一，则主机可能正在运行Windows。
o The external IPv4 address of a NAT device can, of course, be readily associated with a particular organization or at least an ISP; hence, putting this address in an IPv6 address reveals this information. However, this is no different than using a native IP address and is therefore not new with tunneling.
o 当然，NAT设备的外部IPv4地址可以容易地与特定组织或至少ISP相关联；因此，将此地址放在IPv6地址中会显示此信息。但是，这与使用本机IP地址没有什么不同，因此对于隧道来说并不新鲜。
o It is also possible that external client port numbers may be more often associated with particular client software or the platform on which it is running. The usefulness of this for platform determination is, however, reduced by the different NAT port
o 外部客户端端口号也可能更经常地与特定客户端软件或运行该软件的平台相关联。然而，不同的NAT端口降低了这种平台确定的有用性
number assignment behaviors. In addition, the same observations would apply to use of UDP or TCP over native IP as well; hence, this is not new with tunneling.
数字分配行为。此外，同样的观察结果也适用于通过本机IP使用UDP或TCP；因此，这对于隧道来说并不新鲜。
The platform, tunnel client software, or organization information can be used by an attacker to target attacks more carefully. For example, an attacker may decide to attack an address only if it is likely to be associated with a particular platform or tunnel client software with a known vulnerability. (This is similar to the ability to guess some platforms based on the Organizationally Unique Identifier (OUI) in the Extended Unique Identifier (EUI)-64 portion of an IPv6 address generated from a Media Access Control (MAC) address, since some platforms are commonly used with interface cards from particular vendors.)
攻击者可以使用平台、隧道客户端软件或组织信息更仔细地瞄准攻击。例如，只有当地址可能与具有已知漏洞的特定平台或隧道客户端软件关联时，攻击者才可能决定攻击该地址。（这类似于根据媒体访问控制（MAC）地址生成的IPv6地址的扩展唯一标识符（EUI）-64部分中的组织唯一标识符（OUI）猜测某些平台的能力，因为某些平台通常与特定供应商的接口卡一起使用。）
If installation programs randomize the server setting, they would reduce the extent to which they can be profiled. Similarly, administrators can choose to change the default setting to reduce the degree to which they can be profiled ahead of time.
如果安装程序将服务器设置随机化，则会降低对其进行分析的程度。类似地，管理员可以选择更改默认设置，以减少提前分析的程度。
Randomizing the tunnel client port in use would mitigate any profiling that can be done based on the external port, especially if multiple tunnel clients did this. Further discussion on randomizing ports can be found at [RFC6056].
随机化使用中的隧道客户端端口将减少基于外部端口可以完成的任何分析，特别是在多个隧道客户端这样做的情况下。关于随机端口的进一步讨论可参见[RFC6056]。
It is recommended that tunnel protocols minimize the propagation of knowledge about whether the NAT is a cone NAT.
建议隧道协议尽量减少有关NAT是否为锥形NAT的知识传播。
If an attacker could change either a tunnel client's server setting or the IP addresses to which a configured host name resolves (e.g., by intercepting DNS queries) AND if the tunnel is not authenticated, the attacker would become a man in the middle. This would allow them to at least monitor peer communication and at worst to impersonate the remote peer.
如果攻击者可以改变隧道客户端的服务器设置或配置主机名解析的IP地址（例如，通过拦截DNS查询），并且如果隧道未被认证，攻击者将成为中间人。这将允许他们至少监视对等通信，最坏情况下模拟远程对等通信。
A client's server has good visibility into the client's communication with IP peers. If the server were switched to one that records this information and makes it available to third parties (e.g.,
客户端服务器对客户端与IP对等方的通信具有良好的可见性。如果服务器切换到记录此信息并使其可供第三方使用的服务器（例如。，
advertisers, competitors, spouses, etc.), then sensitive information would be disclosed, especially if the client's host prefers the tunnel over native IP. Assuming the server provides good service, the user would not have reason to suspect the change.
广告商、竞争对手、配偶等），则敏感信息将被披露，特别是如果客户的主机更喜欢隧道而不是本地IP。假设服务器提供了良好的服务，用户就没有理由怀疑更改。
Full interception of IP traffic could also be arranged (including pharming), which would allow any number of deception or monitoring attacks, including phishing. We illustrate this with an example phishing attack scenario.
还可以安排完全拦截IP流量（包括欺骗），这将允许任何数量的欺骗或监视攻击，包括网络钓鱼。我们通过一个钓鱼攻击场景示例来说明这一点。
It is often assumed that the tunnel server is a trusted entity. It may be possible for malware or a malicious user to quietly change the client's tunnel server setting and have the user be unaware that their trust has been misplaced for an indefinite period of time. However, malware or a malicious user can do much worse than this, so this is not a significant concern. Hence, it is only important that an attacker on the network cannot change the client's server setting.
通常假定隧道服务器是受信任的实体。恶意软件或恶意用户可能会悄悄更改客户端的隧道服务器设置，并让用户不知道他们的信任已被无限期地错误放置。然而，恶意软件或恶意用户可能比这更糟糕，因此这不是一个重要的问题。因此，网络上的攻击者不能更改客户端的服务器设置才是重要的。
1. A phisher sets up a malicious tunnel server (or tampers with a legitimate one). This server, for the most part, provides correct service.
1. 网络钓鱼者设置恶意隧道服务器（或篡改合法的隧道服务器）。该服务器在很大程度上提供了正确的服务。
2. An attacker, by some means, switches the host's tunnel server setting or spoofs a DNS reply to point to the above server. If neither DNS nor the tunnel setup is secured (i.e., if the client does not authenticate the information), then the attacker's tunnel server is seen as legitimate.
2. 攻击者通过某种方式切换主机的隧道服务器设置或伪造DNS回复以指向上述服务器。如果DNS和隧道设置都不安全（即，如果客户端未验证信息），则攻击者的隧道服务器被视为合法。
3. A user on the victim host types their bank's URL into his/her browser.
3. 受害者主机上的用户在其浏览器中键入银行的URL。
4. The bank's hostname resolves to one or more IP addresses, and the tunnel is selected for socket connection for whatever reason (e.g., the tunnel provides IPv6 connectivity, and the bank has an IPv6 address).
4. 银行的主机名解析为一个或多个IP地址，并且出于任何原因（例如，隧道提供IPv6连接，银行具有IPv6地址）选择隧道进行套接字连接。
5. The tunnel client uses the server for help in connecting to the bank's IP address. Some tunneling protocols use a separate channel for signaling versus data, but this still allows the server to place itself in the data path by an appropriate signal to the client. For example, in Teredo, the client sends a ping request through a server, which is expected to come back through a data relay, and a malicious server can simply send it back itself to indicate that is a data relay for the communication.
5. 隧道客户端使用服务器帮助连接到银行的IP地址。一些隧道协议使用单独的通道来发送信号和发送数据，但这仍然允许服务器通过向客户端发送适当的信号将自己置于数据路径中。例如，在Teredo中，客户端通过服务器发送ping请求，该请求预计将通过数据中继返回，而恶意服务器可以简单地将其自身发送回以指示该服务器是用于通信的数据中继。
6. The rest works pretty much like any normal phishing transaction, except that the attacker acts as a tunnel server (or data relay, for protocols such as Teredo) and a host with the bank's IP address.
6. 其余的工作原理与任何普通的网络钓鱼交易非常相似，只是攻击者充当隧道服务器（或数据中继，适用于Teredo等协议）和具有银行IP地址的主机。
This pharming-type attack is not unique to tunneling. Switching DNS server settings to a malicious DNS server or DNS cache poisoning in a recursive DNS resolver could have a similar effect.
这种欺骗类型的攻击并不是隧道所独有的。将DNS服务器设置切换到恶意DNS服务器或递归DNS解析程序中的DNS缓存中毒可能会产生类似的效果。
In general, anti-phishing and anti-fraud provisions should help with aspects of this, as well as software that specifically monitors for tunnel server changes.
一般来说，反钓鱼和反欺诈条款以及专门监控隧道服务器更改的软件都应该对此有所帮助。
Perhaps the best way to mitigate tunnel-specific attacks is to have the client authenticate either the tunnel server or at least the means by which the tunnel server's IP address is determined. For example, SSL VPNs use https URLs and hence authenticate the server as being the expected one. When IPv6 Router Advertisements are sent over the tunnel, another mechanism is to use SEcure Neighbor Discovery (SEND) [RFC3971] to verify that the client trusts the server.
也许减轻隧道特定攻击的最佳方法是让客户端验证隧道服务器，或者至少验证确定隧道服务器IP地址的方法。例如，SSL VPN使用https URL，因此将服务器验证为预期的服务器。当通过隧道发送IPv6路由器广告时，另一种机制是使用安全邻居发现（SEND）[RFC3971]来验证客户端是否信任服务器。
On the host, it should require an appropriate level of privilege in order to change the tunnel server setting (as well as other non-tunnel-specific settings such as the DNS server setting, etc.). Making it easy to see the current tunnel server setting (e.g., not requiring privilege for this) should help detection of changes.
在主机上，它应该需要适当的权限级别才能更改隧道服务器设置（以及其他非隧道特定的设置，如DNS服务器设置等）。轻松查看当前的隧道服务器设置（例如，不需要特权）应有助于检测更改。
The scope of the attack can also be reduced by limiting tunneling use in general but especially in preferring native IPv4 to tunneled IPv6 when connecting to peers who are accessible over IPv4, as doing so helps mitigate attacks that are facilitated by changing the tunnel server setting. Please refer to Section 3 of [TUNNEL-LOOPS] for a detailed description and mitigation measures for a class of attacks based on IPv6 automatic tunnels.
还可以通过限制隧道使用来减少攻击范围，特别是在连接到通过IPv4可访问的对等方时，更倾向于使用本机IPv4而不是隧道IPv6，因为这样做有助于减轻通过更改隧道服务器设置而促进的攻击。有关基于IPv6自动隧道的一类攻击的详细说明和缓解措施，请参阅[TUNNEL-LOOPS]第3节。
This document described several security issues with tunnels. This does not mean that tunnels need to be avoided at any cost. On the contrary, tunnels can be very useful if deployed, operated, and used properly. The threats against IP tunnels are documented here. If the threats can be mitigated, network administrators can efficiently and securely use tunnels in their network. Several measures can be taken in order to secure the operation of IPv6 tunnels:
本文档描述了隧道的几个安全问题。这并不意味着需要不惜任何代价避免修建隧道。相反，如果部署、操作和使用得当，隧道可能非常有用。这里记录了针对IP隧道的威胁。如果可以缓解这些威胁，网络管理员就可以高效、安全地使用其网络中的隧道。为了确保IPv6隧道的运行安全，可以采取以下几种措施：
o Operating on-premise tunnel servers/relays so that the tunneled traffic does not cross border routers.
o 运行本地隧道服务器/中继，以便隧道传输不会跨越边界路由器。
o Setting up internal routing to steer traffic to these servers/ relays
o 设置内部路由以引导到这些服务器/中继的流量
o Setting up of firewalls [RFC2979] to allow known and controllable tunneling mechanisms and disallow unknown tunnels.
o 设置防火墙[RFC2979]以允许已知和可控的隧道机制，并禁止未知隧道。
The authors would like to thank Remi Denis-Courmont, Fred Templin, Jordi Palet Martinez, James Woodyatt, Christian Huitema, Brian Carpenter, Nathan Ward, Kurt Zeilenga, Joel Halpern, Erik Kline, Alfred Hoenes, and Fernando Gont for reviewing earlier versions of the document and providing comments to make this document better.
作者要感谢雷米·丹尼斯·库尔蒙、弗雷德·坦普林、乔迪·帕莱特·马丁内斯、詹姆斯·伍迪亚特、克里斯蒂安·惠特马、布赖恩·卡彭特、内森·沃德、库尔特·泽林加、乔尔·哈尔潘、埃里克·克莱恩、阿尔弗雷德·霍恩斯和费尔南多·冈特审查了该文件的早期版本，并提供了使该文件更好的意见。
This entire document discusses security concerns with tunnels.
整个文档讨论了隧道的安全问题。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2529]Carpenter，B.和C.Jung，“在没有明确隧道的IPv4域上传输IPv6”，RFC 2529，1999年3月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.，和B.帕尔特，“第二层隧道协议“L2TP”，RFC 26611999年8月。
[RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC2979]弗里德，N.，“互联网防火墙的行为和要求”，RFC 2979，2000年10月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]Lau，J.，Ed.，Townsley，M.，Ed.，和I.Goyret，Ed.，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年3月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.，Ed.，和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007.
[RFC5095]Abley，J.，Savola，P.，和G.Neville Neil，“IPv6中0型路由头的弃用”，RFC 5095，2007年12月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]Templin，F.，Gleeson，T.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 52142008年3月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo Security Updates", RFC 5991, September 2010.
[RFC5991]Thaler，D.，Krishnan，S.，和J.Hoagland，“Teredo安全更新”，RFC 59912010年9月。
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011.
[RFC6056]Larsen，M.和F.Gont，“传输协议端口随机化建议”，BCP 156，RFC 6056，2011年1月。
[SECA-IP] Gont, F., "Security Assessment of the Internet Protocol version 4", Work in Progress, April 2011.
[SECA-IP]Gont，F.，“互联网协议版本4的安全评估”，正在进行的工作，2011年4月。
[TUNNEL-LOOPS] Nakibly, G. and F. Templin, "Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", Work in Progress, March 2011.
[TUNNEL-LOOPS]Nakbly，G.和F.Templin，“使用IPv6自动隧道的路由环路攻击：问题陈述和建议的缓解措施”，正在进行的工作，2011年3月。
Authors' Addresses
作者地址
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
苏雷什·克里希南·爱立信德卡里大道8400号。加拿大皇家山镇
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Dave Thaler微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
James Hoagland Symantec Corporation 350 Ellis St. Mountain View, CA 94043 USA
詹姆斯·霍格兰·赛门铁克公司美国加利福尼亚州埃利斯圣山景城350号，邮编94043
EMail: Jim_Hoagland@symantec.com
URI: http://symantec.com/
EMail: Jim_Hoagland@symantec.com
URI: http://symantec.com/