Network Working Group J. Touch
Request for Comments: 3884 ISI
Category: Informational L. Eggert
NEC
Y. Wang
ISI
September 2004
Network Working Group J. Touch
Request for Comments: 3884 ISI
Category: Informational L. Eggert
NEC
Y. Wang
ISI
September 2004
Use of IPsec Transport Mode for Dynamic Routing
使用IPsec传输模式进行动态路由
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
IESG Note
IESG注释
This document is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this document for any purpose, and in particular notes that it has not had IETF review for such things as security, congestion control or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment.
本文件不适用于任何级别的互联网标准。IETF不承认对本文件适用于任何目的的任何了解，特别注意到IETF没有对安全性、拥塞控制或与已部署协议的不当交互等事项进行审查。RFC编辑已自行决定发布本文件。本文档的读者在评估其实施和部署价值时应谨慎。
Abstract
摘要
IPsec can secure the links of a multihop network to protect communication between trusted components, e.g., for a secure virtual network (VN), overlay, or virtual private network (VPN). Virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside VNs because IP routing depends on references to interfaces and next-hop IP addresses. The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts. An alternative to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec transport mode, which we call IIPtran. IPIP encapsulation occurs as a separate initial step, as the result of a forwarding lookup of the VN packet. IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database (SAD) match on the tunnel header. IIPtran supports dynamic routing
IPsec可以保护多跳网络的链接，以保护受信任组件之间的通信，例如安全虚拟网络（VN）、覆盖或虚拟专用网络（VPN）。IPsec隧道模式建立的虚拟链路可能与VNs内的路由和转发冲突，因为IP路由取决于对接口和下一跳IP地址的引用。IPsec隧道模式规范在这个问题上是不明确的，因此即使是兼容的实现也不能被信任以避免冲突。隧道模式的另一种选择是使用非IPsec IPIP封装和IPsec传输模式，我们称之为IIPtran。IPIP封装作为单独的初始步骤进行，作为VN数据包转发查找的结果。IPsec传输模式使用通过隧道头上的安全关联数据库（SAD）匹配确定的SA处理结果（隧道）IP数据包。IIPtran支持动态路由
inside the VN without changes to the current IPsec architecture. IIPtran demonstrates how to configure any compliant IPsec implementation to avoid the aforementioned conflicts. IIPtran is also compared to several alternative mechanisms for VN routing and their respective impact on IPsec, routing, policy enforcement, and interactions with the Internet Key Exchange (IKE).
在VN内部，不更改当前IPsec体系结构。IIPtran演示了如何配置任何兼容的IPsec实现以避免上述冲突。IIPtran还与VN路由的几种替代机制及其对IPsec、路由、策略实施和与Internet密钥交换（IKE）交互的影响进行了比较。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Document History . . . . . . . . . . . . . . . . . . . . 3
2. Problem Description. . . . . . . . . . . . . . . . . . . . . . 4
2.1. IPsec Overview . . . . . . . . . . . . . . . . . . . . . 5
2.2. Forwarding Example . . . . . . . . . . . . . . . . . . . 6
2.3. Problem 1: Forwarding Issues . . . . . . . . . . . . . . 7
2.4. Problem 2: Source Address Selection . . . . . . . . . . 8
3. IIPtran: IPIP Tunnel Devices + IPsec Transport Mode . . . . . 9
3.1. IIPtran Details . . . . . . . . . . . . . . . . . . . . 10
3.2. Solving Problem 1: Forwarding Issues . . . . . . . . . . 11
3.3. Solving Problem 2: Source Address Selection . . . . . . 12
4. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Other Proposed Solutions . . . . . . . . . . . . . . . . 12
4.1.1. Alternative 1: IPsec with Interface SAs. . . . . 13
4.1.2. Alternative 2: IPsec with Initial
Forwarding Lookup. . . . . . . . . . . . . . . . 13
4.1.3. Alternative 3: IPsec with Integrated
Forwarding . . . . . . . . . . . . . . . . . . . 14
4.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. VN Routing Support and Complexity . . . . . . . 14
4.2.2. Impact on the IPsec Architecture . . . . . . . . 15
4.2.3. Policy Enforcement and Selectors . . . . . . . . 16
4.2.4. IKE Impact . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Summary and Recommendations . . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 21
A. Encapsulation/Decapsulation Issues . . . . . . . . . . . . . . 22
A.1. Encapsulation Issues . . . . . . . . . . . . . . . . . . 22
A.2. Decapsulation Issues . . . . . . . . . . . . . . . . . . 23
A.3. Appendix Summary . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Document History . . . . . . . . . . . . . . . . . . . . 3
2. Problem Description. . . . . . . . . . . . . . . . . . . . . . 4
2.1. IPsec Overview . . . . . . . . . . . . . . . . . . . . . 5
2.2. Forwarding Example . . . . . . . . . . . . . . . . . . . 6
2.3. Problem 1: Forwarding Issues . . . . . . . . . . . . . . 7
2.4. Problem 2: Source Address Selection . . . . . . . . . . 8
3. IIPtran: IPIP Tunnel Devices + IPsec Transport Mode . . . . . 9
3.1. IIPtran Details . . . . . . . . . . . . . . . . . . . . 10
3.2. Solving Problem 1: Forwarding Issues . . . . . . . . . . 11
3.3. Solving Problem 2: Source Address Selection . . . . . . 12
4. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Other Proposed Solutions . . . . . . . . . . . . . . . . 12
4.1.1. Alternative 1: IPsec with Interface SAs. . . . . 13
4.1.2. Alternative 2: IPsec with Initial
Forwarding Lookup. . . . . . . . . . . . . . . . 13
4.1.3. Alternative 3: IPsec with Integrated
Forwarding . . . . . . . . . . . . . . . . . . . 14
4.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. VN Routing Support and Complexity . . . . . . . 14
4.2.2. Impact on the IPsec Architecture . . . . . . . . 15
4.2.3. Policy Enforcement and Selectors . . . . . . . . 16
4.2.4. IKE Impact . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Summary and Recommendations . . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 21
A. Encapsulation/Decapsulation Issues . . . . . . . . . . . . . . 22
A.1. Encapsulation Issues . . . . . . . . . . . . . . . . . . 22
A.2. Decapsulation Issues . . . . . . . . . . . . . . . . . . 23
A.3. Appendix Summary . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
The IP security architecture (IPsec) consists of two modes, transport mode and tunnel mode [1]. Transport mode is allowed between two end hosts only; tunnel mode is required when at least one of the endpoints is a "security gateway" (intermediate system that implements IPsec functionality, e.g., a router.)
IP安全体系结构（IPsec）由两种模式组成，即传输模式和隧道模式[1]。仅允许在两个终端主机之间使用传输模式；当至少一个端点是“安全网关”（实现IPsec功能的中间系统，例如路由器）时，需要隧道模式
IPsec can be used to secure the links of a virtual network (VN), creating a secure VN. In a secure VN, trusted routers inside the network dynamically forward packets in the clear (internally), and exchange the packets on secure tunnels, where paths may traverse multiple tunnels. Contrast this to the conventional 'virtual private network' (VPN), which often assumes that paths tend to traverse one secure tunnel to resources in a secure core. A general secure VN allows this secure core to be distributed, composed of trusted or privately-managed resources anywhere in the network.
IPsec可用于保护虚拟网络（VN）的链接，从而创建安全的VN。在安全VN中，网络内的受信任路由器在clear（内部）中动态转发数据包，并在安全隧道上交换数据包，其中路径可能会穿越多个隧道。这与传统的“虚拟专用网络”（VPN）形成对比，后者通常假设路径倾向于穿过一个安全隧道到达安全核心中的资源。通用安全VN允许分布此安全核心，它由网络中任何位置的受信任或私有管理的资源组成。
This document addresses the use of IPsec to secure the links of a multihop, distributed VN. It describes how virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside the VN, due to the IP routing dependence on references to interfaces and next-hop IP addresses.
本文档介绍如何使用IPsec保护多跳分布式VN的链接。它描述了由于IP路由依赖于对接口和下一跳IP地址的引用，由IPsec隧道模式建立的虚拟链路如何与VN内的路由和转发冲突。
This document proposes a solution called IIPtran that separates the step of IP tunnel encapsulation from IPsec processing. The solution combines a subset of the current IPsec architecture with other Internet standards to arrive at an interoperable equivalent that is both simpler and has a modular specification.
本文档提出了一个名为IIPtran的解决方案，该解决方案将IP隧道封装步骤与IPsec处理分离。该解决方案将当前IPsec体系结构的一个子集与其他Internet标准相结合，以获得一个既简单又具有模块化规范的可互操作的等价物。
Later sections of this document compare IIPtran to other proposals for dynamic routing inside VPNs, focusing on the impact the different proposals have on the overall IPsec architecture, routing protocols, security policy enforcement, and the Internet Key Exchange (IKE) [9][10]. An appendix addresses IP tunnel processing issues in IPsec related to IPIP encapsulation and decapsulation.
本文档后面的部分将IIPtran与VPN内部动态路由的其他建议进行比较，重点介绍不同建议对整个IPsec体系结构、路由协议、安全策略实施和Internet密钥交换（IKE）的影响[9][10]。附录介绍了IPsec中与IPIP封装和反封装相关的IP隧道处理问题。
This document assumes familiarity with other Internet standards [1][2], notably with terminology and numerous acronyms therein.
本文件假定熟悉其他互联网标准[1][2]，尤其是其中的术语和众多首字母缩略词。
This document was first issued as an Internet Draft on March 10, 2000, entitled "Use of IPSEC Transport Mode for Virtual Networks," and was first presented in the IPsec WG at the 47th IETF in Adelaide in March 2000. It was subsequently revised and presented to the PPVPN WG at the 51st IETF in London in August 2001, to the IPsec WG at the 52nd IETF in Salt Lake City in December 2001, and to both the
本文件于2000年3月10日首次作为互联网草案发布，标题为“虚拟网络使用IPSEC传输模式”，并于2000年3月在阿德莱德举行的第47届IETF上首次在IPSEC工作组中提出。随后对其进行了修订，并于2001年8月在伦敦第51届IETF上提交给PPVPN工作组，于2001年12月在盐湖城第52届IETF上提交给IPsec工作组，以及
IPsec and PPVPN WGs at the 53rd IETF in Minneapolis in March 2002. Version 04 of this draft was submitted for publication as an Informational RFC based on suggestions by the IPsec WG in June 2002, and was under IESG review from then until version 07 was approved for publication in June 2004. During that time, it was substantively revised according to feedback from the IESG regarding interactions with the IPsec specification (RFC 2401 [1]) and other protocols, with regard to security and compatibility issues.
IPsec和PPVPN工作组于2002年3月在明尼阿波利斯举行的第53届IETF会议上。根据IPsec工作组于2002年6月提出的建议，本草案的04版作为信息RFC提交出版，并从那时起一直在IESG审查，直到07版于2004年6月批准出版。在此期间，根据IESG关于与IPsec规范（RFC 2401[1]）和其他协议交互的反馈，就安全性和兼容性问题对其进行了实质性修改。
Virtual networks connect subsets of resources of an underlying base network, and present the result as a virtual network layer to upper-layer protocols. Similar to a real network, virtual networks consist of virtual hosts (packet sources and sinks) and virtual routers (packet transits), both of which can have a number of network interfaces, and links, which connect multiple network interfaces together. Virtual links (also called tunnels, especially when point-to-point) are one-hop links in the VN topology, but are either direct links or paths (sequences of connected links) in the underlying base network.
虚拟网络连接底层基础网络的资源子集，并将结果作为虚拟网络层呈现给上层协议。与真实网络类似，虚拟网络由虚拟主机（数据包源和汇）和虚拟路由器（数据包传输）组成，两者都可以有多个网络接口，以及将多个网络接口连接在一起的链路。虚拟链路（也称为隧道，尤其是点到点时）是VN拓扑中的单跳链路，但在底层基础网络中是直接链路或路径（连接的链路序列）。
Base network hosts and routers can be part of multiple virtual networks at the same time, and their role in the base network does not need to coincide with their role in a virtual network (i.e., base network hosts may act as VN routers or hosts, as may base network routers).
基本网络主机和路由器可以同时是多个虚拟网络的一部分，它们在基本网络中的角色不需要与其在虚拟网络中的角色一致（即，基本网络主机可以充当VN路由器或主机，也可以充当基本网络路由器）。
It is important to note that this definition of a VN is more general than some other definitions, where the VN participation of end systems is limited. Some proposals only allow end systems to be part of a single VN, or even only allow them to be part of the VN and not the base network, substituting the VN for the Internet. The definition above explicitly allows hosts and routers to participate in multiple, parallel VNs, and allows layered VNs (VN inside VN).
需要注意的是，VN的这一定义比其他一些定义更一般，因为终端系统的VN参与有限。有些提案只允许终端系统成为单个VN的一部分，甚至只允许它们成为VN的一部分而不是基本网络，用VN代替Internet。上面的定义明确允许主机和路由器参与多个并行VN，并允许分层VN（VN中的VN）。
It can be useful for a VN to secure its virtual links [3][4], resulting in a VPN. This is not equivalent to end-to-end security, but can be useful when end hosts do not support secure communication themselves. It can provide an additional level of hop-by-hop network security to secure routing in the VPN and isolate the traffic of different VPNs.
对于VN来说，保护其虚拟链路[3][4]是非常有用的，这会产生VPN。这并不等同于端到端安全性，但在终端主机本身不支持安全通信时，这可能很有用。它可以提供额外的逐跳网络安全级别，以保护VPN中的路由并隔离不同VPN的流量。
The topology of an IPsec VPN commonly consists of IPsec tunnel mode virtual links, as required by the IPsec architecture when the communicating peers are gateway pairs, or a host and a gateway [1]. However, this current required use of IPsec tunnel mode can be incompatible with dynamic routing [3].
IPsec VPN的拓扑通常由IPsec隧道模式虚拟链路组成，这是IPsec体系结构在通信对等方是网关对或主机和网关时所要求的[1]。但是，当前需要使用的IPsec隧道模式可能与动态路由不兼容[3]。
The next section provides a short overview on IPsec transport and tunnel mode processing, as far as it is relevant for the understanding of the problem scenarios that follow. The following sections discuss routing problems in detail, based on a common example.
下一节将简要概述IPsec传输和隧道模式处理，因为它与理解接下来的问题场景相关。以下各节将根据一个常见示例详细讨论路由问题。
There are two modes of IPsec, transport mode and tunnel mode [1]. Transport mode secures portions of the existing IP header and the payload data of the packet, and inserts an IPsec header between the IP header and the payload; tunnel mode adds an additional IP header before performing similar operations. This section gives a short overview of the relevant processing steps for both modes.
IPsec有两种模式，传输模式和隧道模式[1]。传输模式保护现有IP报头的部分和分组的有效载荷数据，并在IP报头和有效载荷之间插入IPsec报头；隧道模式在执行类似操作之前添加额外的IP头。本节简要概述了两种模式的相关处理步骤。
In transport mode, IPsec inserts a security protocol header into outgoing IP packets between the original IP header and the packet payload (Figure 1) [5][6][11][12]. The contents of the IPsec header are based on the result of a "security association" (SA) lookup that uses the contents of the original packet header (Figure 1, arrow) as well as its payload (especially transport layer headers) to locate an SA in the security association database (SAD).
在传输模式下，IPsec将安全协议头插入原始IP头和数据包有效负载之间的传出IP数据包中（图1）[5][6][11][12]。IPsec头的内容基于“安全关联”（SA）查找的结果，该查找使用原始数据包头（图1，箭头）的内容及其有效负载（尤其是传输层头）在安全关联数据库（SAD）中定位SA。
Original Outbound Packet Outbound Packet (IPsec Transport Mode)
+-----------+---------+ +-----------+==============+---------+
| IP Header | Payload | | IP Header | IPsec Header | Payload |
+-----------+---------+ +-----------+==============+---------+
| ^
| |
+-------------+
SA Lookup
Original Outbound Packet Outbound Packet (IPsec Transport Mode)
+-----------+---------+ +-----------+==============+---------+
| IP Header | Payload | | IP Header | IPsec Header | Payload |
+-----------+---------+ +-----------+==============+---------+
| ^
| |
+-------------+
SA Lookup
Figure 1: Outbound Packet Construction under IPsec Transport Mode
图1:IPsec传输模式下的出站数据包构造
When receiving packets secured with IPsec transport mode, a similar SA lookup occurs based on the IP and IPsec headers, followed by a verification step after IPsec processing that checks the contents of the packet and its payload against the respective SA. The verification step is similar to firewall processing.
当接收使用IPsec传输模式保护的数据包时，将根据IP和IPsec头进行类似的SA查找，然后在IPsec处理后执行验证步骤，根据相应的SA检查数据包的内容及其有效负载。验证步骤类似于防火墙处理。
When using tunnel mode, IPsec prepends an IPsec header and an additional IP header to the outgoing IP packet (Figure 2). In essence, the original packet becomes the payload of another IP packet, which IPsec then secures. This has been described [1] as "a tunnel mode SA is essentially a [transport mode] SA applied to an IP tunnel." However, there are significant differences between the two, as described in the remainder of this section.
当使用隧道模式时，IPsec将IPsec头和附加的IP头预先添加到传出IP数据包（图2）。本质上，原始数据包成为另一个IP数据包的有效负载，然后由IPsec保护。这被描述为[1]“隧道模式SA本质上是应用于IP隧道的[传输模式]SA”。然而，正如本节其余部分所述，两者之间存在显著差异。
In IPsec tunnel mode, the IP header of the original outbound packet together with its payload (especially transport headers) determines the IPsec SA, as for transport mode. However, a tunnel mode SA also contains encapsulation information, including the source and destination IP addresses for the outer tunnel IP header, which is also based on the original outbound packet header and its payload (Figure 2, arrows).
在IPsec隧道模式下，原始出站数据包的IP报头及其有效负载（尤其是传输报头）决定IPsec SA，就像传输模式一样。然而，隧道模式SA还包含封装信息，包括外部隧道IP报头的源和目标IP地址，这也基于原始出站数据包报头及其有效负载（图2，箭头）。
Outbound Packet (IPsec Tunnel Mode)
+==================+==============+-----------------+---------+
| Tunnel IP Header | IPsec Header | Orig. IP Header | Payload |
+==================+==============+-----------------+---------+
^ ^ | |
| | | |
| +--------------+ |
| SA Lookup |
| |
+---------------------------------+
IP Encapsulation
Outbound Packet (IPsec Tunnel Mode)
+==================+==============+-----------------+---------+
| Tunnel IP Header | IPsec Header | Orig. IP Header | Payload |
+==================+==============+-----------------+---------+
^ ^ | |
| | | |
| +--------------+ |
| SA Lookup |
| |
+---------------------------------+
IP Encapsulation
Figure 2: Outbound Packet Construction under IPsec Tunnel Mode
图2:IPsec隧道模式下的出站数据包构造
When receiving packets secured with tunnel mode IPsec, an SA lookup occurs based on the contents of the IPsec header and the outer IP header. Next, the packet is decrypted or authenticated based on its IPsec header and the SA, followed by a verification step that checks the contents of the original packet and its payload (especially the inner IP header and transport headers) against the respective SA.
当接收由隧道模式IPsec保护的数据包时，将根据IPsec头和外部IP头的内容进行SA查找。接下来，基于分组的IPsec报头和SA对分组进行解密或认证，随后是验证步骤，该验证步骤根据相应SA检查原始分组的内容及其有效载荷（尤其是内部IP报头和传输报头）。
Consider a VPN topology with virtual links established by IPsec tunnel mode SAs, as would be required for compliance with [1]. Such hop-by-hop security can be useful, for example, to secure VN routing, and when legacy end systems do not support end-to-end IPsec themselves.
考虑一个具有IPsec隧道模式SAS建立的虚拟链路的VPN拓扑结构，这是符合[1 ]所要求的。例如，这种逐跳安全性对于保护VN路由以及传统终端系统本身不支持端到端IPsec时非常有用。
Virtual routers in a VN need to forward packets the same way regular Internet routers do: based on the destination IP address and the forwarding table. These two determine the next hop IP address the packet should be forwarded to (additional header fields and inner headers can be used, e.g., in policy routing.)
VN中的虚拟路由器需要像普通Internet路由器一样转发数据包：基于目标IP地址和转发表。这两个字段确定数据包应该转发到的下一跳IP地址（可以使用附加的报头字段和内部报头，例如在策略路由中）
In Figure 3, traffic arrives at gateway A on virtual link 1, having come from any of the virtual hosts upstream of that virtual link. There are two outgoing virtual links for this incoming traffic: out link 3 going to the VPN next-hop gateway B, and out link 4 going to the VPN next-hop gateway C.
在图3中，流量到达虚拟链路1上的网关A，来自该虚拟链路上游的任何虚拟主机。此传入流量有两个传出虚拟链路：外链路3到VPN下一跳网关B，外链路4到VPN下一跳网关C。
For this example, assume the incoming traffic is from a single VPN source X, going to a single VPN destination Y. Ellipses (...) represent multiple virtual links in Figure 3.
对于本例，假设传入流量来自单个VPN源X，流向单个VPN目的地Y。图3中的椭圆（…）表示多个虚拟链路。
B ---...---
/ \
/ 3 \
/ \
X ---...--- A D ---...--- Y
1 2 \ /
\ 4 /
\ /
C ---...---
B ---...---
/ \
/ 3 \
/ \
X ---...--- A D ---...--- Y
1 2 \ /
\ 4 /
\ /
C ---...---
Figure 3: Topology of a Virtual Network
图3：虚拟网络的拓扑
Two problems arise; one is forwarding of VN traffic over IPsec tunnel mode links, the other is source address selection on VN end systems.
出现了两个问题；一个是通过IPsec隧道模式链路转发VN流量，另一个是在VN端系统上选择源地址。
Assume a packet from source X to destination Y arrives on link 2 at gateway A. Gateway A now needs to both forward and encrypt the packet to make progress to the next hop gateway inside the VPN.
假设从源X到目的地Y的数据包到达网关a的链路2。网关a现在需要转发和加密该数据包，以进入VPN内的下一跳网关。
Dynamically routed gateways forward packets based on a forwarding table managed by a routing daemon that exchanges connectivity information with directly connected peers by communicating on its local interfaces. Entries in the forwarding table map destination IP addresses to the IP address of a next-hop gateway and an associated outbound interface.
动态路由网关基于路由守护进程管理的转发表转发数据包，路由守护进程通过在其本地接口上通信与直接连接的对等方交换连接信息。转发表中的条目将目标IP地址映射到下一跳网关和关联出站接口的IP地址。
The problem is that an intermediate router needs to pick a next hop gateway for a transit packet based on its destination IP address and the contents of the forwarding table. However, the IPsec architecture does not define if and how tunnel mode SAs are represented in the forwarding table.
问题是，中间路由器需要根据目的IP地址和转发表的内容为传输包选择下一跳网关。但是，IPsec体系结构没有定义转发表中是否以及如何表示隧道模式SA。
The problem occurs when A tries to decide how to forward the packet X->Y. In a regular IP network, this decision depends on a forwarding lookup on destination address Y, which indicates the IP address of the next-hop gateway and an associated outbound interface. In the case of a VN, forwarding lookups occur on virtual destination addresses. For the forwarding lookup on such a virtual destination address to succeed, routes through virtual interfaces (tunnels) must exist in the forwarding table.
当A尝试决定如何转发数据包X->Y时会出现问题。在常规IP网络中，此决定取决于对目标地址Y的转发查找，该地址指示下一跳网关和相关出站接口的IP地址。对于VN，在虚拟目标地址上进行转发查找。为了成功地对此类虚拟目标地址进行转发查找，转发表中必须存在通过虚拟接口（隧道）的路由。
There are two common implementation scenarios for tunnel mode SAs: One is based on firewall-like packet matching operations where tunnel mode SAs are not virtual interfaces, another is tunnel-based, and treats a tunnel mode SA as a virtual interface. The current IPsec architecture does not mandate one or the other.
隧道模式SA有两种常见的实现方案：一种是基于类似防火墙的数据包匹配操作，其中隧道模式SA不是虚拟接口，另一种是基于隧道的，并将隧道模式SA视为虚拟接口。当前的IPsec体系结构不强制使用其中一种。
Under the first approach, the presence of IPsec tunnel mode SAs is invisible to the IP forwarding mechanism. The lookup uses matching rules in the SA lookup process, closer to firewall matching than traditional IP forwarding lookups, and independent from existing IP forwarding tables. The SA lookup determines which virtual link the packet will be forwarded over, because the tunnel mode SA includes encapsulation information. This lookup and the subsequent tunnel mode processing both ignore the contents of the existing IP forwarding table, whether static or dynamic routing are used. This type of tunnel mode processing is thus incompatible with dynamically routed VPNs.
在第一种方法中，IPsec隧道模式SAs的存在对于IP转发机制是不可见的。查找在SA查找过程中使用匹配规则，比传统IP转发查找更接近防火墙匹配，并且独立于现有IP转发表。SA查找确定数据包将通过哪个虚拟链路转发，因为隧道模式SA包含封装信息。无论使用静态路由还是动态路由，此查找和后续的隧道模式处理都会忽略现有IP转发表的内容。因此，这种类型的隧道模式处理与动态路由VPN不兼容。
The second approach - requiring tunnel mode SAs to be interfaces - can be compatible with dynamically routed VPNs (see Section 4) depending on how it is implemented; however, IIPtran (see Section 3) has the additional benefit of greatly simplifying the IPsec architecture and related specifications, and of being compatible with all IPsec specification compliant implementations.
第二种方法-要求隧道模式SAs作为接口-可与动态路由VPN兼容（参见第4节），具体取决于其实现方式；但是，IIPtran（参见第3节）还有一个额外的好处，即大大简化了IPsec体系结构和相关规范，并且与所有符合IPsec规范的实现兼容。
A second issue is source address selection at the source host. When an application sends traffic to another host, the host must choose an IP source address for the IP packets before transmission.
第二个问题是源主机上的源地址选择。当应用程序向另一台主机发送流量时，主机必须在传输前为IP数据包选择IP源地址。
When an end system is connected to multiple networks, it must set the source address properly to receive return traffic over the correct network. When a node participates in a virtual network, it is always connected to two networks, the base network and the VN (more if it connects to at least two VNs.) The IPsec specification currently does not define how tunnel mode SAs integrate with source address selection.
当终端系统连接到多个网络时，它必须正确设置源地址，以便通过正确的网络接收返回流量。当一个节点参与虚拟网络时，它总是连接到两个网络，即基本网络和VN（如果它连接到至少两个VN，则更多）。IPsec规范目前没有定义隧道模式SAs如何与源地址选择集成。
For example, when communication occurs over a virtual network, the source address must lie inside the VN. When X sends to Y (Figure 3), the source address must be the IP address of X's local end of tunnel 1. If host A, which has multiple interfaces inside the VN, sends to Y, the source address must be the IP address of the local end of either tunnel 3 or 4.
例如，当通过虚拟网络进行通信时，源地址必须位于VN内部。当X发送到Y时（图3），源地址必须是X隧道1的本地端的IP地址。如果主机A（在VN内有多个接口）发送到Y，则源地址必须是隧道3或4的本地端的IP地址。
Most applications do not bind to a specific source IP address, and instead let the host pick one for their traffic [7]. Rules for source address selection that depend heavily on the notions of interfaces and routes.
大多数应用程序不绑定到特定的源IP地址，而是让主机为其流量选择一个[7]。源地址选择规则严重依赖于接口和路由的概念。
According to [7], the IP source address of an outbound packet should: (1) for directly connected networks derive from the corresponding interface, or (2) derive from existing dynamic or static route entries to the destination, or finally (3) derive from the interface attached to a default gateway.
根据[7]，出站数据包的IP源地址应该：（1）对于直接连接的网络，从相应的接口派生，或者（2）从到目的地的现有动态或静态路由条目派生，或者最后（3）从连接到默认网关的接口派生。
Because IPsec tunnel mode SAs are not required to be interfaces, rules (1) and (2) may not return a usable source address for a given packet. Consequently, VN packets will use the IP address of the local interface connecting to a default gateway as their source address. Often, a default gateway for a host provides connectivity in the base network underlying the VN. The outgoing packet will thus have a source address in the base network, and a destination address in the VN.
因为IPsec隧道模式SA不需要是接口，所以规则（1）和（2）可能不会返回给定数据包的可用源地址。因此，VN数据包将使用连接到默认网关的本地接口的IP地址作为其源地址。通常，主机的默认网关在VN底层的基础网络中提供连接。因此，传出分组在基本网络中具有源地址，在VN中具有目的地地址。
This can result in numerous problems, including applications that fail to operate at all, firewalls and admission control failures, and may even lead to compromised security. Consider two cases, one with IPsec tunnels configured with no wildcard tunnel addresses, the other using certain wildcards. In both cases, an application whose source address is set by RFC 1122 [7] rules may send packets (e.g.) with the source address of that host's base network (via the default route) and a destination address of the remote tunnel endpoint.
这可能导致许多问题，包括应用程序根本无法运行、防火墙和准入控制失败，甚至可能导致安全性受损。考虑两种情况，一个IPSec隧道配置为没有通配符隧道地址，另一个使用某些通配符。在这两种情况下，源地址由RFC 1122[7]规则设置的应用程序可以发送（例如）具有该主机的基本网络的源地址（通过默认路由）和远程隧道端点的目的地地址的包。
This section introduces a solution - called IIPtran - for the two issues identified above. IIPtran replaces IPsec tunnel mode with a combination of IPIP tunnel interfaces that support forwarding and source address selection (as per RFC 2003 [2]), followed by IPsec transport mode on the encapsulated packet.
本节针对上述两个问题介绍了一个名为IIPtran的解决方案。IIPtran将IPsec隧道模式替换为支持转发和源地址选择的IPIP隧道接口组合（根据RFC 2003[2]），然后是封装数据包上的IPsec传输模式。
The IPsec architecture [1] defines the appropriate use of IPsec transport mode and IPsec tunnel mode (host-to-host communication for the former, and all transit communication for the latter). IIPtran appears to violate this requirement, because it uses IPsec transport mode for transit communication.
IPsec体系结构[1]定义了IPsec传输模式和IPsec隧道模式的适当使用（前者为主机间通信，后者为所有传输通信）。IIPtran似乎违反了这一要求，因为它使用IPsec传输模式进行传输通信。
However, for an IPIP tunnel between security gateways, the gateways themselves source or sink base network traffic when tunneling - they act as hosts in the base network. Thus, IPsec transport mode is also appropriate, if not required, for encapsulated traffic, according to [1].
但是，对于安全网关之间的IPIP隧道，网关本身在隧道传输时会产生或接收基本网络流量，它们充当基本网络中的主机。因此，根据[1]，如果不需要，IPsec传输模式也适用于封装的通信量。
As a result, replacing IPsec tunnel mode with IPIP tunnel devices and IPsec transport mode is consistent with the existing architecture. Furthermore, this does not compromise the end-to-end use of IPsec, either inside a VPN or in the base network; it only adds IPsec protection to secure virtual links.
因此，用IPIP隧道设备和IPsec传输模式替换IPsec隧道模式与现有体系结构一致。此外，这不会影响IPsec的端到端使用，无论是在VPN内部还是在基本网络中；它只添加了IPsec保护来保护虚拟链接的安全。
The next sections will give a short overview of IPIP encapsulation, and show it combines with IPsec transport mode processing. This section will then discuss how IIPtran addresses each of the problems identified above.
下一节将简要概述IPIP封装，并展示它与IPsec传输模式处理的结合。然后，本节将讨论IIPtran如何解决上述每个问题。
IIPtran uses IPIP tunnels (as defined in RFC 2003 [2]), followed by IPsec transport mode on the encapsulated packet.
IIPtran使用IPIP隧道（如RFC 2003[2]中所定义），然后在封装的数据包上使用IPsec传输模式。
RFC 2003 [2] uniquely specifies IPIP encapsulation (placing an IP packet as payload inside another IP packet.) Originally developed for MobileIP, it has often been adopted when virtual topologies were required. Examples include virtual (overlay) networks to support emerging protocols such as IP Multicast, IPv6, and Mobile IP itself, as well as systems that provide private networks over the Internet (X-Bone [3] and PPVPN).
RFC 2003[2]唯一指定了IPIP封装（将一个IP包作为有效负载放置在另一个IP包中）。最初是为MobileIP开发的，通常在需要虚拟拓扑时采用。示例包括支持新兴协议（如IP多播、IPv6和移动IP本身）的虚拟（覆盖）网络，以及通过Internet提供专用网络的系统（X-Bone[3]和PPVPN）。
IPIP outbound packet processing, as specified by RFC 2003 [2], tunnels an existing IP packet by prepending it with another IP header (Figure 4.)
按照RFC 2003[2]的规定，IPIP出站数据包处理通过在现有IP数据包的前面加上另一个IP报头来对其进行隧道传输（图4）
Outbound Packet (IPIP Tunnel)
+==================+-----------------+---------+
| Tunnel IP Header | Orig. IP Header | Payload |
+==================+-----------------+---------+
^ |
| |
+------------------+
IPIP Encapsulation
Outbound Packet (IPIP Tunnel)
+==================+-----------------+---------+
| Tunnel IP Header | Orig. IP Header | Payload |
+==================+-----------------+---------+
^ |
| |
+------------------+
IPIP Encapsulation
Figure 4: Outbound Packet Construction for IPIP Tunnel
图4:IPIP隧道的出站数据包构造
IIPtran performs this IPIP processing as a first step, followed by IPsec transport mode processing on the resulting IPIP packet (Figure 5.)
IIPtran首先执行IPIP处理，然后对生成的IPIP数据包执行IPsec传输模式处理（图5）
Outbound Packet (IPIP Tunnel + IPsec Transport Mode)
+==================+==============+-----------------+---------+
| Tunnel IP Header | IPsec Header | Orig. IP Header | Payload |
+==================+==============+-----------------+---------+
^ | ^ |
| | | |
| +---------------+ |
| SA Lookup |
| |
+----------------------------------+
IPIP Encapsulation
Outbound Packet (IPIP Tunnel + IPsec Transport Mode)
+==================+==============+-----------------+---------+
| Tunnel IP Header | IPsec Header | Orig. IP Header | Payload |
+==================+==============+-----------------+---------+
^ | ^ |
| | | |
| +---------------+ |
| SA Lookup |
| |
+----------------------------------+
IPIP Encapsulation
Figure 5: Outbound Packet Construction for IPIP Tunnel with IPsec Transport Mode
图5：具有IPsec传输模式的IPIP隧道的出站数据包构造
A key difference between Figure 2 and Figure 5 is that in the proposed solution, the IPsec header is based on the outer IP header, whereas under IPsec tunnel mode processing, the IPsec header depends on the contents of the inner IP header and payload (see Section 2.1).
图2和图5之间的关键区别在于，在建议的解决方案中，IPsec报头基于外部IP报头，而在IPsec隧道模式处理下，IPsec报头取决于内部IP报头和有效负载的内容（参见第2.1节）。
However, the resulting VPN packet (Figure 5) on the wire cannot be distinguished from a VPN packet generated by IPsec tunnel mode processing (Figure 2); and the two methods inter-operate, given appropriate configurations on both ends [3].
然而，在线路上产生的VPN数据包（图5）无法与IPsec隧道模式处理产生的VPN数据包（图2）区分开来；如果两端都有适当的配置，这两种方法相互作用[3]。
A detailed discussion of the differences between IIPtran, IPsec tunnel mode, and other proposed mechanisms follows in Section 4. The remainder of this section will describe how IIPtran combines IPIP tunnel devices with IPsec transport mode to solve the problems identified in Section 2.
第4节详细讨论了IIPtran、IPsec隧道模式和其他拟议机制之间的差异。本节的其余部分将描述IIPtran如何将IPIP隧道设备与IPsec传输模式结合起来，以解决第2节中确定的问题。
Section 2.3 described how IP forwarding over IPsec tunnel mode SAs breaks, because tunnel mode SAs are not required to be network interfaces. IIPtran uses RFC 2003 IPIP tunnels [2] to establish the topology of the virtual network. RFC 2003 [2] requires that IPIP tunnels can be routed to, and have configurable addresses. Thus, they can be references in node's routing table (supporting static routing), as well as used by dynamic routing daemons for local communication of reachability information.
第2.3节描述了IPsec隧道模式SAs上的IP转发如何中断，因为隧道模式SAs不要求是网络接口。IIPtran使用RFC 2003 IPIP隧道[2]来建立虚拟网络的拓扑。RFC 2003[2]要求IPIP隧道可以路由到，并且具有可配置的地址。因此，它们可以作为节点路由表中的引用（支持静态路由），也可以被动态路由守护进程用于本地可达性信息通信。
RFC 2003 [2] addressed the issue of inserting an IPsec header between the two IP headers that are a result of IPIP encapsulation. IIPtran provides further details on this configuration, and demonstrates how it enables dynamic routing in a virtual network.
RFC 2003[2]解决了在IPIP封装的两个IP报头之间插入IPsec报头的问题。IIPtran提供了有关此配置的更多详细信息，并演示了它如何在虚拟网络中启用动态路由。
It is important to note that the RFC 2003 IPIP tunnels [2] already provide a complete virtual network that can support static or dynamic routing. The proposed solution of using IPIP tunnel with IPsec transport mode decouples IPsec processing from routing and forwarding. IIPtran's use of IPsec is limited to securing the links of the VN (creating a VPN), because IPsec (rightly) lacks internal support for routing and forwarding.
需要注意的是，RFC 2003 IPIP隧道[2]已经提供了一个完整的虚拟网络，可以支持静态或动态路由。建议的使用IPIP隧道和IPsec传输模式的解决方案将IPsec处理与路由和转发分离。IIPtran对IPsec的使用仅限于保护VN的链接（创建VPN），因为IPsec（正确地）缺乏对路由和转发的内部支持。
Section 2.4 gave an overview of IP source address selection and its dependence on interfaces and routes.
第2.4节概述了IP源地址选择及其对接口和路由的依赖性。
Using RFC 2003 IPIP tunnel devices [2] for VN links, instead of IPsec tunnel mode SAs, allows existing multihoming solutions for source address selection [1] to solve source address selection in this context as well. As indicated in Section 2.4, according to [1], the IP source address of an outbound packet is determined by the outbound interface, which is in turn determined by existing forwarding mechanism. Because IPIP tunnels are full-fledged interfaces with associated routes (as in Section 3.2 of [2]), the routes and address selection as specified in [1] can also operate as desired in the context of VN links.
将RFC 2003 IPIP隧道设备[2]用于VN链路，而不是IPsec隧道模式SAs，允许用于源地址选择的现有多宿主解决方案[1]也解决此上下文中的源地址选择问题。如第2.4节所示，根据[1]，出站数据包的IP源地址由出站接口确定，而出站接口又由现有的转发机制确定。由于IPIP隧道是具有相关路由的完整接口（如[2]第3.2节所述），因此[1]中规定的路由和地址选择也可以在VN链路的上下文中根据需要进行操作。
The previous sections described problems when IPsec tunnel mode provides VPN links, and proposed a solution. This section introduces a number of proposed alternatives, and compares their effect on the IPsec architecture, routing, and policy enforcement, among others, to IIPtran.
前面几节描述了IPsec隧道模式提供VPN链接时出现的问题，并提出了解决方案。本节介绍了许多建议的备选方案，并将其对IPsec体系结构、路由和策略实施的影响与IIPtran进行了比较。
This section gives a brief overview of a number of alternative proposals that aim at establishing support for dynamic routing for IPsec-secured VNs. The following section then compares these proposals in detail.
本节简要概述了旨在为IPsec安全的VN建立动态路由支持的许多备选方案。下一节将详细比较这些建议。
Although some of the alternatives also address the issues identified above, IIPtran alone also significantly simplifies and modularizes the IPsec architecture.
尽管一些替代方案也解决了上述问题，但IIPtran本身也显著简化和模块化了IPsec体系结构。
In the first alternative, each IPsec tunnel mode SA is required to act as a full-fledged network interface. This SA interface acts as the outbound interface of the virtual destination's forwarding table entry. IPsec dynamically updates the SA interface configuration in response to SAD changes, e.g., caused by IKE negotiation.
在第一个备选方案中，每个IPsec隧道模式SA都需要充当一个完整的网络接口。此SA接口充当虚拟目标的转发表条目的出站接口。IPsec动态更新SA接口配置，以响应SAD更改，例如由IKE协商引起的更改。
This approach supports dynamic routing and existing source address selection rules, but requires extensions to the IPsec architecture that define tunnel mode SA interfaces and their associated management procedures.
这种方法支持动态路由和现有的源地址选择规则，但需要对定义隧道模式SA接口及其相关管理过程的IPsec体系结构进行扩展。
It would necessitate recapitulating the definition of the entirety of RFC 2003 IPIP encapsulation [2], including the association of tunnels with interfaces, inside IPsec. This defeats the modular architecture of the Internet, and violates the specification of type 4 IP in IP packets as being uniquely defined by a single Internet standard (it is already standardized by [2]).
这将需要重新概括整个RFC 2003 IPIP封装的定义[2]，包括IPsec内隧道与接口的关联。这破坏了互联网的模块化体系结构，并违反了IP数据包中类型4 IP的规范，该规范由单一互联网标准唯一定义（已由[2]标准化）。
This solution also requires augmenting the IPsec specification to mandate an implementation detail, one that may be difficult to resolve with other IPsec designs, notably the BITS (bump-in-the-stack) alternative. Although the current IPsec specification is ambiguous and allows this implementation, an implementation-independent design is preferable.
此解决方案还需要扩充IPsec规范以强制执行实现细节，这可能很难用其他IPsec设计解决，尤其是BITS（堆栈中的凹凸）替代方案。尽管当前的IPsec规范不明确，并且允许这种实现，但最好采用独立于实现的设计。
A second alternative is the addition of an extra forwarding lookup before IPsec tunnel mode processing. This forwarding lookup will return a "virtual interface" identifier, which indicates how to route the packet [13]. Due to a lack of concrete documentation of this alternative at this time, proposed for an update pending to RFC 2401 [1], two variants are presumed possible:
第二种选择是在IPsec隧道模式处理之前添加额外的转发查找。此转发查找将返回一个“虚拟接口”标识符，该标识符指示如何路由数据包[13]。由于目前缺乏该备选方案的具体文件，建议对RFC 2401[1]进行更新，因此假定可能有两种变体：
In the first scenario, the extra forwarding lookup indicates the outbound interface of the final encapsulated tunnel mode packet, i.e., usually a physical interface in the base network. The tunnel mode SA lookup following the forwarding lookup will occur in the per-interface SAD associated with the respective virtual interface.
在第一个场景中，额外转发查找指示最终封装的隧道模式分组的出站接口，即，通常是基本网络中的物理接口。转发查找之后的隧道模式SA查找将在与相应虚拟接口关联的每个接口SAD中发生。
In the second scenario, the extra forwarding lookup returns an outbound tunnel SA interface. This solution seems to be equivalent to the one described above (Section 4.1.1), i.e., all tunnel mode SAs must be interfaces, and is not discussed separately below.
在第二个场景中，额外的转发查找返回出站隧道SA接口。该解决方案似乎等同于上述解决方案（第4.1.1节），即所有隧道模式SA必须是接口，下文不再单独讨论。
In the third alternative, the routing protocols and forwarding mechanisms are modified to consult both the routing tables and SADs to make forwarding decision. To prevent IPsec processing from interfering with routing, forwarding table lookup must precede SAD lookup.
在第三种方案中，修改路由协议和转发机制，以同时参考路由表和SAD来做出转发决策。为了防止IPsec处理干扰路由，转发表查找必须先于SAD查找。
This approach supports dynamic routing, but requires changes to routing mechanisms such that SAD contents are included in the route exchanges. It is unclear how transport-layer selectors would affect this approach.
此方法支持动态路由，但需要更改路由机制，以便在路由交换中包含SAD内容。目前尚不清楚传输层选择器将如何影响这种方法。
This section compares the three different alternatives and IIPtran according to a number of evaluation criteria, such as support for VN forwarding, or impact on the IPsec architecture.
本节将根据一些评估标准（如对VN转发的支持或对IPsec体系结构的影响）比较三种不同的备选方案和IIPtran。
This section investigates whether the three alternatives and IIPtran support VN routing, especially dynamic routing based on existing IP routing protocols.
本节研究三种备选方案和IIPtran是否支持VN路由，尤其是基于现有IP路由协议的动态路由。
Both IIPtran (IPIP tunnels + transport mode) and alternative 1 (per-SA interfaces) establish VN links as full-fledged devices that can be referred to in the routing table, as well as used for local communication by dynamic routing protocols. They both support static and dynamic VN routing.
IIPtran（IPIP隧道+传输模式）和备选方案1（每个SA接口）都将VN链路建立为可在路由表中引用的成熟设备，并通过动态路由协议用于本地通信。它们都支持静态和动态VN路由。
However, because the current IPsec architecture does not require tunnel mode SAs to behave similarly to interfaces (some implementers chose alternative 1, but it is not mandated by the specification), alternative 1 requires extensions to the current IPsec architecture that define the exact behavior of tunnel mode SAs. The proposed solution does not require any such changes to IPsec, and for tunnels RFC 2003 already specifies those requirements [2]. Furthermore, addition of those requirements would be redundant and potentially conflict with RFC 2003 [2].
但是，由于当前的IPsec体系结构不要求隧道模式SAs的行为与接口类似（一些实施者选择了备选方案1，但规范并未强制要求），备选方案1要求对当前IPsec体系结构进行扩展，以定义隧道模式SAs的确切行为。建议的解决方案不需要对IPsec进行任何此类更改，对于隧道，RFC 2003已经规定了这些要求[2]。此外，增加这些要求将是多余的，并可能与RFC 2003[2]发生冲突。
Alternative 3 supports dynamic VN routing, but requires modifying routing protocols and forwarding lookup mechanisms to act or synchronize based on SAD entries. This requires substantial changes to routing software and forwarding mechanisms in all participating nodes to interface to the internals of IPsec; this would require revising a large number of current Internet standards. It is also
备选方案3支持动态VN路由，但需要修改路由协议和转发查找机制，以便根据SAD条目进行操作或同步。这需要对所有参与节点中的路由软件和转发机制进行重大更改，以便与IPsec的内部接口；这需要修改大量现行互联网标准。也是
not clear how tunnel mode SAs that specify port selectors would operate under this scheme, since IP routing has no dependence on transport-layer fields.
由于IP路由不依赖于传输层字段，因此不清楚指定端口选择器的隧道模式SA在此方案下如何工作。
Alternative 2 does not support dynamic VN routing. The additional forwarding lookup before IPsec processing is irrelevant, because IPsec tunnel mode SAs are not represented as interfaces, and thus invisible to IP routing protocols.
备选方案2不支持动态VN路由。IPsec处理之前的额外转发查找是不相关的，因为IPsec隧道模式SA不表示为接口，因此对IP路由协议不可见。
Additionally, the forwarding lookup suggested for alternative 2 is not compatible with a weak ES model described in [1], which requires both an outbound interface indicator as well as the IP address of the next-hop gateway. For example, multiple tunnels can use the same outgoing interface and thus same SAD. The forwarding lookup would return only the interface; lacking the next-hop gateway, the correct SAD entry cannot be determined. Given the next-hop gateway would not help, because the SAD is not indexed by tunnel mode SA encapsulation destination IP address.
此外，为备选方案2建议的转发查找与[1]中描述的弱ES模型不兼容，后者既需要出站接口指示符，也需要下一跳网关的IP地址。例如，多个隧道可以使用相同的传出接口，从而使用相同的SAD。转发查找将只返回接口；缺少下一跳网关，无法确定正确的SAD条目。给定下一个跃点，网关将不会有帮助，因为SAD不是由隧道模式SA封装目标IP地址索引的。
Because alternative 2 fails to support VN routing, it will not be discussed in the remainder of this section.
由于备选方案2无法支持VN路由，因此本节的其余部分将不讨论该方案。
IIPtran recognizes that encapsulation is already a property of interface processing, and thus relies on IPIP tunnel devices to handle the IPIP encapsulation for VN links. Tunnel mode IPsec thus becomes unnecessary and can potentially be removed from the IPsec architecture, greatly simplifying the specification.
IIPtran认识到封装已经是接口处理的一个属性，因此依赖IPIP隧道设备来处理VN链路的IPIP封装。隧道模式IPsec因此变得不必要，并且可能从IPsec体系结构中删除，从而大大简化了规范。
Alternative 1 requires SAs to be represented as full-fledged interfaces, for the purpose of routing. SAD changes must furthermore dynamically update the configuration of these SA interfaces. The IPsec architecture thus needs extensions that define the operation of interfaces and their interactions with the forwarding table and routes.
备选方案1要求将SAs表示为完整的接口，用于路由。SAD更改还必须动态更新这些SA接口的配置。因此，IPsec体系结构需要定义接口操作及其与转发表和路由的交互的扩展。
Additionally, RFC 2401 [1] describes per-interface SADs as a component of IPsec. When tunnel mode SAs themselves act as interfaces, the function of per-interface SADs needs clarification as follows:
此外，RFC 2401[1]将每个接口SAD描述为IPsec的一个组件。当隧道模式SAs本身作为接口时，每个接口SADs的功能需要澄清如下：
First, each tunnel interface SAD must contain exactly one IPsec tunnel mode SA. Transport mode SAs are prohibited, because they would not result in IP encapsulation (the encapsulation header is part of the tunnel mode SA, a transport mode SA would not cause encapsulation), and thus lead to processing loops. Multiple tunnel mode SAs are prohibited, because dynamic routing algorithms construct
首先，每个隧道接口SAD必须恰好包含一个IPsec隧道模式SA。禁止传输模式SA，因为它们不会导致IP封装（封装头是隧道模式SA的一部分，传输模式SA不会导致封装），从而导致处理循环。禁止使用多隧道模式SA，因为动态路由算法
topology information based on per-interface communication. Merging different virtual links (tunnels) into a single SA interface can cause routing events on one virtual link to apply incorrectly to other links sharing an SA interface.
基于每个接口通信的拓扑信息。将不同的虚拟链路（隧道）合并到单个SA接口中可能会导致一个虚拟链路上的路由事件错误地应用于共享SA接口的其他链路。
Second, only the SAD of physical interfaces may contain IPsec transport mode SAs; otherwise, the current issues with VN routing remain unsolved.
第二，只有物理接口的SAD可以包含IPsec传输模式SAs；否则，VN路由的当前问题仍未解决。
In summary, these restrictions cause the SADs of SA interfaces to contain only tunnel mode SAs, and the SADs of regular interfaces to contain only transport mode SAs. Thus, tunnel encapsulation essentially becomes a unique property of the interface, and not IPsec.
总之，这些限制导致SA接口的SAD仅包含隧道模式SA，而常规接口的SAD仅包含传输模式SA。因此，隧道封装本质上成为接口的唯一属性，而不是IPsec。
IIPtran already recognizes this property. Consequently, it uses IPIP tunnels directly, and combines them with transport mode processing. By eliminating the use of tunnel mode, it removes the need for additional constraints on the contents of per-interface SAs.
IIPtran已识别此属性。因此，它直接使用IPIP隧道，并将它们与传输模式处理相结合。通过消除隧道模式的使用，它消除了对每个接口SA内容的附加约束的需要。
On receiving a packet, both IPsec tunnel mode and IIPtran decrypt and/or authenticate the packet with the same techniques. IPsec tunnel mode decapsulates and decrypts the packet in a single step, followed by a policy check of the inner packet and its payload against the respective IPsec tunnel mode SA. IIPtran uses IPsec transport mode to decrypt and verify the incoming packet, then passes the decrypted IPIP packet on to RFC 2003 IPIP processing [2]. At that point, IIPtran can support selector checks on both the header and its payload using firewall mechanisms, similar to IPsec tunnel mode processing.
在接收到数据包时，IPsec隧道模式和IIPtran都使用相同的技术对数据包进行解密和/或身份验证。IPsec隧道模式在单个步骤中解除对数据包的封装和解密，然后针对相应IPsec隧道模式SA对内部数据包及其有效负载进行策略检查。IIPtran使用IPsec传输模式对传入数据包进行解密和验证，然后将解密后的IPIP数据包传递给RFC 2003 IPIP处理[2]。此时，IIPtran可以使用防火墙机制支持对报头及其有效负载进行选择器检查，类似于IPsec隧道模式处理。
The primary difference between the two is that IPsec tunnel mode does not require a separate processing step for validating packets; once IPsec accepts them during the policy check during decapsulation, they are accepted. IIPtran requires additional processing on the decapsulated packets, to validate whether they conform to their respective IPsec policy.
两者之间的主要区别在于IPsec隧道模式不需要单独的处理步骤来验证数据包；一旦IPsec在解除封装期间的策略检查期间接受它们，它们就会被接受。IIPtran需要对解除封装的数据包进行额外处理，以验证它们是否符合各自的IPsec策略。
As noted in Section 5.2 of the IPsec architecture document [1], IPsec processing should retain information about what SAs matched a given packet, for subsequent IPsec or firewall processing. To allow for complex accept policies, it should be possible to reconstruct the format of the original packet at the time it first entered a machine based on saved processing context at any time during inbound
如IPsec体系结构文档[1]第5.2节所述，IPsec处理应保留与给定数据包相匹配的SA的信息，以便后续IPsec或防火墙处理。为了允许复杂的接受策略，应该可以在入站过程中的任何时候，基于保存的处理上下文，在原始数据包首次进入机器时重构原始数据包的格式
processing. IIPtran accepts incoming VN packets only if they have arrived over a specific IPIP tunnel that was secured with IPsec transport mode, but as a separate step following IPIP decapsulation.
处理。IIPtran仅在传入的VN数据包通过IPIP传输模式保护的特定IPIP隧道到达时才接受这些数据包，但这是IPIP解除封装后的一个单独步骤。
Note that IPsec tunnel mode and IIPtran are interoperable [3]. Experiments have verified this interoperability, notably because there are no differences in the resulting packets on the wire, given appropriate keys.
请注意，IPsec隧道模式和IIPtran是可互操作的[3]。实验已经验证了这种互操作性，特别是因为在给定适当密钥的情况下，网络上产生的数据包没有差异。
When looking up an SA for a given packet, IPsec allows selectors to match on the contents of the IP header and transport headers. IIPtran using existing IPsec cannot support transport header matches, because SA lookup occurs before decapsulation. A small extension to IPsec can address this issue in a modular way.
在查找给定数据包的SA时，IPsec允许选择器匹配IP头和传输头的内容。使用现有IPsec的IIPtran无法支持传输头匹配，因为SA查找发生在解除封装之前。IPsec的一个小扩展可以以模块化的方式解决这个问题。
RFC 2401 [1] explicitly recognizes that the transport layer header may be nested several headers deep inside the packet, and allows a system to (quote) "chain through the packet headers checking the 'Protocol' or 'Next Header' field until it encounters either one it recognizes as a transport protocol, or until it reaches one that isn't on its list of extension headers, or until it encounters an ESP header that renders the transport protocol opaque."
RFC 2401[1]明确识别传输层报头可以嵌套在数据包内部的多个报头中，并允许系统（引用）通过检查“协议”或“下一个标头”字段链接数据包标头，直到它遇到一个它识别为传输协议的标头，或者直到它到达一个不在其扩展标头列表中的标头，或者直到它遇到一个使传输协议不透明的ESP标头
With IIPtran, the SA lookup starts on the outer (tunnel) header, and selectors including port number information must thus traverse the inner IP header (and possibly other headers) before they can match on the transport headers. IIPtran thus requires that IP be a known IPsec "extension header." This recognizes that with IPIP encapsulation, IP VNs use the base IP network as a link layer. Although this small extension to IPsec is not explicitly required, it is already implied.
使用IIPtran，SA查找从外部（隧道）报头开始，因此，包含端口号信息的选择器必须遍历内部IP报头（可能还有其他报头），然后才能匹配传输报头。因此，IIPtran要求IP是一个已知的IPsec“扩展头”。这表明，通过IPIP封装，IP VN将基本IP网络用作链路层。虽然IPsec的这个小扩展不是明确需要的，但它已经暗示了。
Recognizing IP as a valid transport layer over IP also allows selectors to match on the contents of the inner ("transport") IP header. Thus, IPsec selectors under IIPtran can express the same set of policies as conventional IPsec tunnel mode.
将IP识别为IP上的有效传输层还允许选择器匹配内部（“传输”）IP报头的内容。因此，IIPtran下的IPsec选择器可以表示与传统IPsec隧道模式相同的策略集。
Note that in both cases, these policy enforcement rules violate layering by looking at information other than the outermost header. This is consistent with IPsec's current use of port-based selectors. The next section discusses that selectors may not be useful for virtual networks.
请注意，在这两种情况下，这些策略实施规则通过查看除最外层标头以外的信息来违反分层。这与IPsec当前使用的基于端口的选择器一致。下一节将讨论选择器对于虚拟网络可能没有用处。
For secure VN links established via IPsec tunnel mode SAs, the selectors for the inner (VN) source and destination IP addresses often need to be wildcarded to support dynamic routing in a VN. Thus, the limitation described in 4.2.3.1 (without the proposed extension) may not be important in a VN scenario.
对于通过IPsec隧道模式SAs建立的安全VN链路，内部（VN）源和目标IP地址的选择器通常需要通配符以支持VN中的动态路由。因此，在VN场景中，4.2.3.1中描述的限制（没有建议的扩展）可能并不重要。
Consider a four-node VN with nodes A, B, C, and N (Figure 6). Consider the case where N is either a new node joining an existing VPN, or an existing node that had been disconnected and was just rediscovered via dynamic routing.
考虑具有节点A、B、C和N的四节点VN（图6）。考虑N是连接现有VPN的新节点，或者已经断开并通过动态路由重新发现的现有节点的情况。
In this example, A has IPsec tunnel mode SAs to B and C. If the selectors for the virtual source and destination IP addresses for those SAs are not wildcards, the SA needs to be dynamically modified to permit packets from N to pass over the tunnels to B and C. This becomes quickly impractical as VPN sizes grow.
在此示例中，A具有到B和C的IPsec隧道模式SA。如果这些SA的虚拟源和目标IP地址的选择器不是通配符，则需要动态修改SA，以允许来自N的数据包通过隧道传输到B和C。随着VPN规模的增长，这很快变得不切实际。
B
/
/
/
N ------ A
\
\
\
C
B
/
/
/
N ------ A
\
\
\
C
Figure 6: Topology of a Virtual Network
图6：虚拟网络的拓扑结构
Thus, IPsec selectors appear much less useful in a VPN scenario than expected. A consequence might be that IIPtran - even without extensions to support the full expressiveness of tunnel mode SA selectors as described above - can still support the majority of VPN scenarios.
因此，IPsec选择器在VPN场景中的用处比预期的要小得多。结果可能是IIPtran—即使没有支持上述隧道模式SA选择器的完整表达能力的扩展—仍然可以支持大多数VPN场景。
One purpose of selectors matching on transport header content is policy routing. Different SAs can apply to different applications, resulting in different apparent virtual topologies. IIPtran supports policy routing in a more modular way, by having existing policy routing implementations forward traffic over multiple, parallel VNs. IIPtran supports arbitrary IP-based policy routing schemes, while policies are limited by the expressiveness of IPsec's selectors in the former case.
选择器匹配传输头内容的一个目的是策略路由。不同的SA可以应用于不同的应用程序，从而产生不同的明显虚拟拓扑。IIPtran通过使现有策略路由实现在多个并行VN上转发流量，以更模块化的方式支持策略路由。IIPtran支持任意基于IP的策略路由方案，而在前一种情况下，策略受到IPsec选择器表达能力的限制。
The Internet Key Exchange (IKE) [9][10] is a protocol to negotiate IPsec keys between end systems dynamically and securely. It is not a strictly required component of IPsec in the sense that two hosts can communicate using IPsec without having used IKE to negotiate keys (through manually keyed SAs, for example). Despite its name, IKE also acts as a tunnel management protocol (when IPsec tunnel mode SAs are configured), and negotiates security policies between the peers.
Internet密钥交换（IKE）[9][10]是在终端系统之间动态安全地协商IPsec密钥的协议。它不是严格要求的IPsec组件，因为两台主机可以使用IPsec进行通信，而无需使用IKE协商密钥（例如，通过手动设置密钥的SAs）。尽管名称不同，IKE还充当隧道管理协议（当配置IPsec隧道模式SAs时），并在对等方之间协商安全策略。
Alternatives 1 and 3 use existing IKE without changes.
备选方案1和3使用现有IKE，不作任何更改。
One possible approach to use IKE with IIPtran is to negotiate a tunnel mode SA, and then treat it as a transport mode SA against an IPIP tunnel when communicating with conventional peers. For policies that do not specify selectors based on transport-layer information, this establishes interoperability.
将IKE与IIPtran结合使用的一种可能方法是协商隧道模式SA，然后在与传统对等方通信时将其视为针对IPIP隧道的传输模式SA。对于不基于传输层信息指定选择器的策略，这将建立互操作性。
However, since IIPtran eliminates IPsec tunnel mode, it could also simplify IKE, by limiting it to its original purpose of key exchange. A new tunnel management protocol (e.g., ATMP [8]) would set up IPIP tunnels, use an as of yet unspecified second protocol to negotiate security policy, and then use IKE to exchange keys for use with the policy.
然而，由于IIPtran消除了IPsec隧道模式，它还可以通过将IKE限制在密钥交换的原始目的来简化IKE。一个新的隧道管理协议（如ATMP[8]）将建立IPIP隧道，使用尚未指定的第二个协议协商安全策略，然后使用IKE交换用于策略的密钥。
Current IKE operation would become a modular composition of separate protocols, similar to how IIPtran modularizes IPsec by combining existing Internet standards. For example, a VPN link creation could follow these steps: (1) IKE negotiation in the base network to secure (2) a subsequent tunnel management exchange [8] in the base network, followed by (3) IKE exchanges over the established tunnel to create a secure VPN link.
当前的IKE操作将成为独立协议的模块化组合，类似于IIPtran如何通过组合现有的Internet标准来模块化IPsec。例如，VPN链路创建可以遵循以下步骤：（1）在基础网络中进行IKE协商以确保（2）在基础网络中进行后续隧道管理交换[8]，然后（3）在已建立的隧道上进行IKE交换以创建安全的VPN链路。
This document addresses security considerations throughout, as they are a primary concern of proposed uses of IPsec.
本文档始终讨论安全注意事项，因为它们是提议使用IPsec的主要考虑事项。
The primary purpose of this document is to extend the use of IPsec to dynamically routed VPNs, which will extend the use of IPsec and, it is hoped, increase the security of VPN infrastructures using existing protocols.
本文档的主要目的是将IPsec的使用扩展到动态路由VPN，这将扩展IPsec的使用，并希望使用现有协议提高VPN基础设施的安全性。
This document presents a mechanism consistent with the current use of IPsec which supports dynamic routing inside a virtual network that uses IPsec to secure its links. It illustrates how current use of IPsec tunnel mode can fail to support dynamic VN routing (depending on the implementation), and compares IIPtran with several different alternatives. It finds that IIPtran, a composite of a subset of IPsec (i.e., transport mode) together with existing standard IPIP encapsulation, results in an interoperable, standards-conforming equivalent that is both simpler and modular.
本文档介绍了一种与当前使用的IPsec一致的机制，该机制支持在使用IPsec保护其链接的虚拟网络内进行动态路由。它说明了当前使用的IPsec隧道模式如何无法支持动态VN路由（取决于实现），并将IIPtran与几种不同的备选方案进行了比较。它发现，IIPtran是IPsec子集（即传输模式）与现有标准IPIP封装的组合，它产生了一个可互操作的、符合标准的等效物，既简单又模块化。
The authors would like to thank the members of the X-Bone and DynaBone projects at USC/ISI for their contributions to the ideas behind this document, notably (current) Greg Finn and (past) Amy Hughes, Steve Hotz and Anindo Banerjea.
作者要感谢USC/ISI X-Bone和DynaBone项目的成员，感谢他们为本文件背后的理念所做的贡献，特别是（现任）Greg Finn和（前任）Amy Hughes、Steve Hotz和Anido Banerjea。
The authors would also like to thank Jun-ichiro (itojun) Hagino and the KAME project for bringing IKE implications of this proposal to our attention, as well as implementing the mechanisms in this document in the KAME IPv6/IPsec network stack. Members of several IETF WGs (especially IPsec: Stephen Kent, PPVPN: Eric Vyncke, Paul Knight, various members of MobileIP) provided valuable input on the details of IPsec processing in earlier revisions of this document.
作者还想感谢Jun ichiro（itojun）Hagino和KAME项目，感谢他们提请我们注意本提案的IKE影响，以及在KAME IPv6/IPsec网络堆栈中实现本文件中的机制。几个IETF工作组的成员（特别是IPsec:Stephen Kent，PPVPN:Eric Vyncke，Paul Knight，MobileIP的各个成员）在本文档早期版本中提供了有关IPsec处理细节的宝贵意见。
Effort sponsored by the Defense Advanced Research Projects Agency (DARPA) and Air Force Research Laboratory, Air Force Materiel Command, USAF, under agreements number F30602-98-1-0200 entitled "X-Bone" and number F30602-01-2-0529 entitled "DynaBone".
美国国防高级研究计划局（DARPA）和美国空军空军装备司令部空军研究实验室根据编号为F30602-98-1-0200的“X骨”协议和编号为F30602-01-2-0529的“DynaBone”协议赞助的工作。
[1] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[1] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[2] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[2] Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[3] Touch, J., "Dynamic Internet overlay deployment and management using the X-Bone", Computer Networks Vol. 36, No. 2-3, July 2001.
[3] Touch，J.，“使用X-Bone的动态互联网覆盖部署和管理”，计算机网络第36卷，第2-3期，2001年7月。
[4] Touch, J., Wang, Y., Eggert, L. and G. Finn, "A Virtual Internet Architecture", ISI Technical Report ISI-TR-570, Workshop on Future Directions in Network Architecture (FDNA) 2003, March 2003.
[4] Touch，J.，Wang，Y.，Eggert，L.和G.Finn，“虚拟互联网架构”，ISI技术报告ISI-TR-570，网络架构未来方向研讨会（FDNA），2003年3月。
[5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[5] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[6] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[7] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[7] Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[8] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, February 1997.
[8] Hamzeh，K.，“上升隧道管理协议-ATMP”，RFC 2107，1997年2月。
[9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[9] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[10] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Work in Progress, January 2004.
[10] Kaufman，C.，“因特网密钥交换（IKEv2）协议”，正在进行的工作，2004年1月。
[11] Kent, S., "IP Authentication Header", Work in Progress, February 2004.
[11] Kent，S.，“IP认证头”，正在进行的工作，2004年2月。
[12] Kent, S., "IP Encapsulating Security Payload (ESP)", Work in progress, February 2004.
[12] Kent，S.，“IP封装安全有效载荷（ESP）”，正在进行的工作，2004年2月。
[13] Kent, S., "Personal Communication", November 2002.
[13] Kent，S.，“个人交流”，2002年11月。
[14] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[14] Mogul，J.和S.Deering，“MTU发现路径”，RFC191990年11月。
[15] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[15] Lahey，K.，“路径MTU发现的TCP问题”，RFC 29232000年9月。
Appendix A. Encapsulation/Decapsulation Issues
附录A.封装/脱封装问题
There are inconsistencies between the IPIP encapsulation rules specified by IPsec [1] and those specified by MobileIP [2]. The latter specification is standards track, and the IP protocol number of 4 (payload of an IP packet of type 4) is uniquely specified by RFC 2003 according to IANA [2]. The use of IPIP inside an IPsec transport packet can be confused with IPsec tunnel mode, because IPsec does not specify any limits on the types of IP packets that transport mode can secure.
IPsec[1]指定的IPIP封装规则与MobileIP[2]指定的IPIP封装规则不一致。后一个规范是标准跟踪，IP协议编号4（类型4的IP数据包的有效负载）由RFC 2003根据IANA[2]唯一指定。在IPsec传输数据包内使用IPIP可能会与IPsec隧道模式混淆，因为IPsec没有指定传输模式可以保护的IP数据包类型的任何限制。
When an IP packet is encapsulated as payload inside another IP packet, some of the outer header fields can be newly written (and the inner header determines some others [2].) Among these fields is the IP DF (do not fragment) flag. When the inner packet DF flag is clear, the outer packet may copy it or set it; however, when the inner DF flag is set, the outer header must copy it [2]. IPsec defines conflicting rules, where that flag and other similar fields (TOS, etc.) may be copied, cleared, or set as specified by an SA.
当一个IP包被封装为另一个IP包内的有效负载时，可以新写入一些外部报头字段（内部报头确定一些其他字段[2]）。这些字段中有IP DF（不分段）标志。当内包DF标志清除时，外包可以复制或设置；但是，当设置内部DF标志时，外部标头必须复制它[2]。IPsec定义了冲突规则，其中该标志和其他类似字段（TOS等）可以按照SA的指定进行复制、清除或设置。
The IPsec specification indicates that such fields must be controlled, to achieve security. Otherwise, such fields could provide a covert channel between the inner packet header and outer packet header. However, RFC 2003 [2] requires that the outer fields not be cleared when the inner ones are set, to prevent MTU discovery "black holes" [14][15].
IPsec规范指出，为了实现安全性，必须控制这些字段。否则，这些字段可以在内部分组报头和外部分组报头之间提供隐蔽通道。然而，RFC 2003[2]要求在设置内部场时不清除外部场，以防止MTU发现“黑洞”[14][15]。
To avoid a conflict between these rules, and to avoid security weaknesses associated with solely copying the fields, it is recommended that IPsec IPIP encapsulation not permit the clearing of the outer DF flag. When the SA requires clearing the DF flag, and the inner packet DF is set, it is proposed that IPsec drop that packet, rather than violate RFC 2003 processing rules [2]. Similar rules are being developed for TOS and other similar IP header fields, to be included in an update of RFC 2003 [2].
为了避免这些规则之间的冲突，并避免与仅复制字段相关的安全弱点，建议IPsec IPIP封装不允许清除外部DF标志。当SA需要清除DF标志，并且设置了内部数据包DF时，建议IPsec丢弃该数据包，而不是违反RFC 2003处理规则[2]。正在为TOS和其他类似的IP头字段制定类似的规则，这些规则将包含在RFC 2003的更新中[2]。
Another approach to closing the covert channel is always to set the DF flag in the outer header (whether or not it is set in the inner header). Setting the DF flag allows PMTU discovery to operate normally. The details of this approach are discussed in [2].
关闭隐蔽通道的另一种方法是始终在外部标头中设置DF标志（无论是否在内部标头中设置）。设置DF标志允许PMTU发现正常运行。[2]中讨论了该方法的细节。
Given identical keys, a packet created by IPIP tunnel encapsulation combined with IPsec transport mode and an IPsec tunnel mode packet look identical on the wire. Thus, when an IPsec'ed packet arrives that contains an IPIP inner packet, it is not possible to distinguish whether the packet was created using IPsec tunnel mode or IPsec transport mode of an IPIP encapsulated packet. In both cases, the protocol field of the outer header is IPsec (AH or ESP), and the "next header" field for the inner data is 4 (IP). IPsec requires the SA matching a received packet to indicate whether to apply tunnel mode or transport mode.
给定相同的密钥，IPIP隧道封装结合IPsec传输模式创建的数据包和IPsec隧道模式数据包在线路上看起来是相同的。因此，当包含IPIP内部分组的IPsec’ed分组到达时，无法区分该分组是使用IPIP封装分组的IPsec隧道模式还是IPsec传输模式创建的。在这两种情况下，外部头的协议字段都是IPsec（AH或ESP），而内部数据的“下一个头”字段是4（IP）。IPsec要求SA匹配接收到的数据包，以指示是应用隧道模式还是传输模式。
Incoming packet processing must check the SAD before determining whether to decapsulate IPsec packets with inner payload of protocol type 4. If the SAD indicates that a tunnel mode association applies, IPsec must decapsulate the packet. If the SAD indicates that a transport mode association applies, IPsec must not decapsulate the packet. This requires that the SAD indicate one of these two options; wildcard SAD entries ("ANY", or "TUNNEL or TRANSPORT") cannot be supported.
传入数据包处理必须先检查SAD，然后才能确定是否使用协议类型4的内部有效负载解除IPsec数据包的封装。如果SAD指示应用隧道模式关联，则IPsec必须解除数据包的封装。如果SAD指示应用传输模式关联，则IPsec不得解除数据包的封装。这要求SAD指示这两个选项中的一个；不支持通配符SAD条目（“任何”或“隧道或传输”）。
IPsec's use of IPIP encapsulation conflicts with the IPIP standard [2]. This issue is already being resolved in an update to RFC 2003, instead of specifying a non-standard conforming variant of IPIP encapsulation inside IPsec.
IPsec对IPIP封装的使用与IPIP标准冲突[2]。这个问题已经在RFC 2003的更新中得到解决，而不是在IPsec中指定一个不符合标准的IPIP封装变体。
Authors' Addresses
作者地址
Joe Touch USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 US
Joe Touch USC信息科学研究所4676金钟路马里纳德雷，加利福尼亚州，美国90292
Phone: +1 310 822 1511
Fax: +1 310 823 6714
EMail: touch@isi.edu
URI: http://www.isi.edu/touch
Phone: +1 310 822 1511
Fax: +1 310 823 6714
EMail: touch@isi.edu
URI: http://www.isi.edu/touch
Lars Eggert NEC Network Laboratories Kurfuersten-Anlage 36 Heidelberg 69115 DE
Lars Eggert NEC网络实验室Kurfuersten Anlage 36海德堡69115 DE
Phone: +49 6221 90511 43
Fax: +49 6221 90511 55
EMail: lars.eggert@netlab.nec.de
URI: http://www.netlab.nec.de/
Phone: +49 6221 90511 43
Fax: +49 6221 90511 55
EMail: lars.eggert@netlab.nec.de
URI: http://www.netlab.nec.de/
Yu-Shun Wang USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 US
王玉顺南加州大学信息科学研究所4676金钟路马里纳德雷，加利福尼亚州90292美国
Phone: +1 310 822 1511
Fax: +1 310 823 6714
EMail: yushunwa@isi.edu
URI: http://www.isi.edu/yushunwa
Phone: +1 310 822 1511
Fax: +1 310 823 6714
EMail: yushunwa@isi.edu
URI: http://www.isi.edu/yushunwa
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。