Internet Engineering Task Force (IETF) T. Pauly
Request for Comments: 8229 Apple Inc.
Category: Standards Track S. Touati
ISSN: 2070-1721 Ericsson
R. Mantha
Cisco Systems
August 2017
Internet Engineering Task Force (IETF) T. Pauly
Request for Comments: 8229 Apple Inc.
Category: Standards Track S. Touati
ISSN: 2070-1721 Ericsson
R. Mantha
Cisco Systems
August 2017
TCP Encapsulation of IKE and IPsec Packets
IKE和IPsec数据包的TCP封装
Abstract
摘要
This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP.
本文档描述了一种通过TCP连接传输Internet密钥交换协议（IKE）和IPsec数据包的方法，用于穿越可能阻止通过UDP进行IKE协商的网络中间盒。此方法称为“TCP封装”，包括发送IKE数据包以建立安全关联，以及通过TCP连接封装安全有效负载（ESP）数据包。当无法通过UDP协商IKE时，此方法将用作回退选项。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8229.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8229.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Prior Work and Motivation ..................................4
1.2. Terminology and Notation ...................................5
2. Configuration ...................................................5
3. TCP-Encapsulated Header Formats .................................6
3.1. TCP-Encapsulated IKE Header Format .........................6
3.2. TCP-Encapsulated ESP Header Format .........................7
4. TCP-Encapsulated Stream Prefix ..................................7
5. Applicability ...................................................8
5.1. Recommended Fallback from UDP ..............................8
6. Connection Establishment and Teardown ...........................9
7. Interaction with NAT Detection Payloads ........................11
8. Using MOBIKE with TCP Encapsulation ............................11
9. Using IKE Message Fragmentation with TCP Encapsulation .........12
10. Considerations for Keep-Alives and Dead Peer Detection ........12
11. Middlebox Considerations ......................................12
12. Performance Considerations ....................................13
12.1. TCP-in-TCP ...............................................13
12.2. Added Reliability for Unreliable Protocols ...............14
12.3. Quality-of-Service Markings ..............................14
12.4. Maximum Segment Size .....................................14
12.5. Tunneling ECN in TCP .....................................14
13. Security Considerations .......................................15
14. IANA Considerations ...........................................16
15. References ....................................................16
15.1. Normative References .....................................16
15.2. Informative References ...................................17
1. Introduction ....................................................3
1.1. Prior Work and Motivation ..................................4
1.2. Terminology and Notation ...................................5
2. Configuration ...................................................5
3. TCP-Encapsulated Header Formats .................................6
3.1. TCP-Encapsulated IKE Header Format .........................6
3.2. TCP-Encapsulated ESP Header Format .........................7
4. TCP-Encapsulated Stream Prefix ..................................7
5. Applicability ...................................................8
5.1. Recommended Fallback from UDP ..............................8
6. Connection Establishment and Teardown ...........................9
7. Interaction with NAT Detection Payloads ........................11
8. Using MOBIKE with TCP Encapsulation ............................11
9. Using IKE Message Fragmentation with TCP Encapsulation .........12
10. Considerations for Keep-Alives and Dead Peer Detection ........12
11. Middlebox Considerations ......................................12
12. Performance Considerations ....................................13
12.1. TCP-in-TCP ...............................................13
12.2. Added Reliability for Unreliable Protocols ...............14
12.3. Quality-of-Service Markings ..............................14
12.4. Maximum Segment Size .....................................14
12.5. Tunneling ECN in TCP .....................................14
13. Security Considerations .......................................15
14. IANA Considerations ...........................................16
15. References ....................................................16
15.1. Normative References .....................................16
15.2. Informative References ...................................17
Appendix A. Using TCP Encapsulation with TLS ......................18
Appendix B. Example Exchanges of TCP Encapsulation with TLS .......19
B.1. Establishing an IKE Session ................................19
B.2. Deleting an IKE Session ....................................21
B.3. Re-establishing an IKE Session .............................22
B.4. Using MOBIKE between UDP and TCP Encapsulation .............23
Acknowledgments ...................................................25
Authors' Addresses ................................................25
Appendix A. Using TCP Encapsulation with TLS ......................18
Appendix B. Example Exchanges of TCP Encapsulation with TLS .......19
B.1. Establishing an IKE Session ................................19
B.2. Deleting an IKE Session ....................................21
B.3. Re-establishing an IKE Session .............................22
B.4. Using MOBIKE between UDP and TCP Encapsulation .............23
Acknowledgments ...................................................25
Authors' Addresses ................................................25
The Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] is a protocol for establishing IPsec Security Associations (SAs), using IKE messages over UDP for control traffic, and using Encapsulating Security Payload (ESP) [RFC4303] messages for encrypted data traffic. Many network middleboxes that filter traffic on public hotspots block all UDP traffic, including IKE and IPsec, but allow TCP connections through because they appear to be web traffic. Devices on these networks that need to use IPsec (to access private enterprise networks, to route Voice over IP calls to carrier networks, or because of security policies) are unable to establish IPsec SAs. This document defines a method for encapsulating IKE control messages as well as IPsec data messages within a TCP connection.
Internet密钥交换协议版本2（IKEv2）[RFC7296]是用于建立IPsec安全关联（SAs）的协议，使用UDP上的IKE消息进行控制流量，并使用封装安全有效负载（ESP）[RFC4303]消息进行加密数据流量。许多过滤公共热点上流量的网络中间盒会阻止所有UDP流量，包括IKE和IPsec，但允许TCP连接通过，因为它们看起来是web流量。这些网络上需要使用IPsec（访问私有企业网络、将IP语音呼叫路由到运营商网络或由于安全策略）的设备无法建立IPsec SAs。本文档定义了在TCP连接中封装IKE控制消息以及IPsec数据消息的方法。
Using TCP as a transport for IPsec packets adds a third option to the list of traditional IPsec transports:
使用TCP作为IPsec数据包的传输在传统IPsec传输列表中添加了第三个选项：
1. Direct. Currently, IKE negotiations begin over UDP port 500. If no Network Address Translation (NAT) device is detected between the Initiator and the Responder, then subsequent IKE packets are sent over UDP port 500, and IPsec data packets are sent using ESP.
1. 直接的目前，IKE谈判开始于UDP端口500。如果在发起方和响应方之间未检测到网络地址转换（NAT）设备，则通过UDP端口500发送后续IKE数据包，并使用ESP发送IPsec数据包。
2. UDP Encapsulation [RFC3948]. If a NAT is detected between the Initiator and the Responder, then subsequent IKE packets are sent over UDP port 4500 with four bytes of zero at the start of the UDP payload, and ESP packets are sent out over UDP port 4500. Some peers default to using UDP encapsulation even when no NAT is detected on the path, as some middleboxes do not support IP protocols other than TCP and UDP.
2. UDP封装[RFC3948]。如果在发起方和响应方之间检测到NAT，则随后的IKE数据包通过UDP端口4500发送，UDP有效负载开始处有四个零字节，ESP数据包通过UDP端口4500发送。某些对等点默认使用UDP封装，即使在路径上未检测到NAT，因为某些中间盒不支持TCP和UDP以外的IP协议。
3. TCP Encapsulation. If the other two methods are not available or appropriate, IKE negotiation packets as well as ESP packets can be sent over a single TCP connection to the peer.
3. TCP封装。如果其他两种方法不可用或不合适，IKE协商数据包以及ESP数据包可以通过单个TCP连接发送到对等方。
Direct use of ESP or UDP encapsulation should be preferred by IKE implementations due to performance concerns when using TCP encapsulation (Section 12). Most implementations should use TCP encapsulation only on networks where negotiation over UDP has been attempted without receiving responses from the peer or if a network is known to not support UDP.
由于使用TCP封装时的性能问题，IKE实现应首选直接使用ESP或UDP封装（第12节）。大多数实现应仅在尝试通过UDP进行协商而未收到对等方响应或已知网络不支持UDP的网络上使用TCP封装。
Encapsulating IKE connections within TCP streams is a common approach to solve the problem of UDP packets being blocked by network middleboxes. The specific goals of this document are as follows:
在TCP流中封装IKE连接是解决UDP数据包被网络中间盒阻塞问题的常用方法。本文件的具体目标如下：
o To promote interoperability by defining a standard method of framing IKE and ESP messages within TCP streams.
o 通过定义在TCP流中构建IKE和ESP消息的标准方法来促进互操作性。
o To be compatible with the current IKEv2 standard without requiring modifications or extensions.
o 与当前的IKEv2标准兼容，无需修改或扩展。
o To use IKE over UDP by default to avoid the overhead of other alternatives that always rely on TCP or Transport Layer Security (TLS) [RFC5246].
o 默认情况下通过UDP使用IKE，以避免始终依赖TCP或传输层安全性（TLS）的其他替代方案的开销[RFC5246]。
Some previous alternatives include:
以前的一些备选方案包括：
Cellular Network Access Interworking Wireless LAN (IWLAN) uses IKEv2 to create secure connections to cellular carrier networks for making voice calls and accessing other network services over Wi-Fi networks. 3GPP has recommended that IKEv2 and ESP packets be sent within a TLS connection to be able to establish connections on restrictive networks.
蜂窝网络接入互通无线局域网（IWLAN）使用IKEv2创建到蜂窝运营商网络的安全连接，以便通过Wi-Fi网络进行语音呼叫和访问其他网络服务。3GPP建议在TLS连接内发送IKEv2和ESP分组，以便能够在限制性网络上建立连接。
ISAKMP over TCP Various non-standard extensions to the Internet Security Association and Key Management Protocol (ISAKMP) have been deployed that send IPsec traffic over TCP or TCP-like packets.
ISAKMP over TCP已部署Internet安全关联和密钥管理协议（ISAKMP）的各种非标准扩展，通过TCP或类似TCP的数据包发送IPsec通信。
Secure Sockets Layer (SSL) VPNs Many proprietary VPN solutions use a combination of TLS and IPsec in order to provide reliability. These often run on TCP port 443.
安全套接字层（SSL）VPN许多专有VPN解决方案结合使用TLS和IPsec以提供可靠性。它们通常在TCP端口443上运行。
IKEv2 over TCP IKEv2 over TCP as described in [IKE-over-TCP] is used to avoid UDP fragmentation.
IKEv2 over TCP使用[IKE over TCP]中描述的IKEv2 over TCP避免UDP碎片。
This document distinguishes between the IKE peer that initiates TCP connections to be used for TCP encapsulation and the roles of Initiator and Responder for particular IKE messages. During the course of IKE exchanges, the role of IKE Initiator and Responder may swap for a given SA (as with IKE SA rekeys), while the Initiator of the TCP connection is still responsible for tearing down the TCP connection and re-establishing it if necessary. For this reason, this document will use the term "TCP Originator" to indicate the IKE peer that initiates TCP connections. The peer that receives TCP connections will be referred to as the "TCP Responder". If an IKE SA is rekeyed one or more times, the TCP Originator MUST remain the peer that originally initiated the first IKE SA.
本文档区分了发起TCP连接以用于TCP封装的IKE对等方和特定IKE消息的发起方和响应方角色。在IKE交换过程中，IKE发起方和响应方的角色可以交换给给定的SA（与IKE SA密钥一样），而TCP连接的发起方仍然负责断开TCP连接并在必要时重新建立它。因此，本文档将使用术语“TCP发起人”来表示发起TCP连接的IKE对等方。接收TCP连接的对等方将被称为“TCP响应者”。如果IKE SA被重新设置一次或多次密钥，TCP发起人必须保持最初发起第一个IKE SA的对等方。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
One of the main reasons to use TCP encapsulation is that UDP traffic may be entirely blocked on a network. Because of this, support for TCP encapsulation is not specifically negotiated in the IKE exchange. Instead, support for TCP encapsulation must be pre-configured on both the TCP Originator and the TCP Responder.
使用TCP封装的主要原因之一是UDP通信可能在网络上被完全阻塞。因此，在IKE交换中没有专门协商对TCP封装的支持。相反，必须在TCP发起方和TCP响应方上预先配置对TCP封装的支持。
Implementations MUST support TCP encapsulation on TCP port 4500, which is reserved for IPsec NAT traversal.
实现必须支持TCP端口4500上的TCP封装，该端口保留用于IPsec NAT遍历。
Beyond a flag indicating support for TCP encapsulation, the configuration for each peer can include the following optional parameters:
除了指示支持TCP封装的标志外，每个对等机的配置还可以包括以下可选参数：
o Alternate TCP ports on which the specific TCP Responder listens for incoming connections. Note that the TCP Originator may initiate TCP connections to the TCP Responder from any local port.
o 特定TCP响应程序侦听传入连接的备用TCP端口。请注意，TCP发起人可以从任何本地端口发起到TCP响应程序的TCP连接。
o An extra framing protocol to use on top of TCP to further encapsulate the stream of IKE and IPsec packets. See Appendix A for a detailed discussion.
o 在TCP之上使用的额外帧协议，用于进一步封装IKE和IPsec数据包流。详细讨论见附录A。
Since TCP encapsulation of IKE and IPsec packets adds overhead and has potential performance trade-offs compared to direct or UDP-encapsulated SAs (as described in Section 12), implementations SHOULD prefer ESP direct or UDP-encapsulated SAs over TCP-encapsulated SAs when possible.
由于IKE和IPsec数据包的TCP封装增加了开销，并且与直接或UDP封装的SAs（如第12节所述）相比，具有潜在的性能权衡，因此在可能的情况下，实现应首选ESP直接或UDP封装的SAs而不是TCP封装的SAs。
Like UDP encapsulation, TCP encapsulation uses the first four bytes of a message to differentiate IKE and ESP messages. TCP encapsulation also adds a Length field to define the boundaries of messages within a stream. The message length is sent in a 16-bit field that precedes every message. If the first 32 bits of the message are zeros (a non-ESP marker), then the contents comprise an IKE message. Otherwise, the contents comprise an ESP message. Authentication Header (AH) messages are not supported for TCP encapsulation.
与UDP封装一样，TCP封装使用消息的前四个字节来区分IKE和ESP消息。TCP封装还添加了一个长度字段来定义流中消息的边界。消息长度在每条消息之前的16位字段中发送。如果消息的前32位为零（非ESP标记），则内容包含IKE消息。否则，内容包括ESP消息。TCP封装不支持身份验证标头（AH）消息。
Although a TCP stream may be able to send very long messages, implementations SHOULD limit message lengths to typical UDP datagram ESP payload lengths. The maximum message length is used as the effective MTU for connections that are being encrypted using ESP, so the maximum message length will influence characteristics of inner connections, such as the TCP Maximum Segment Size (MSS).
尽管TCP流可能能够发送很长的消息，但实现应将消息长度限制为典型的UDP数据报ESP有效负载长度。最大消息长度用作使用ESP加密的连接的有效MTU，因此最大消息长度将影响内部连接的特性，例如TCP最大段大小（MSS）。
Note that this method of encapsulation will also work for placing IKE and ESP messages within any protocol that presents a stream abstraction, beyond TCP.
请注意，这种封装方法也适用于将IKE和ESP消息放置在任何呈现流抽象的协议中，而不仅仅是TCP。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Non-ESP Marker |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IKE header [RFC7296] ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Non-ESP Marker |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IKE header [RFC7296] ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
图1
The IKE header is preceded by a 16-bit Length field in network byte order that specifies the length of the IKE message (including the non-ESP marker) within the TCP stream. As with IKE over UDP port 4500, a zeroed 32-bit non-ESP marker is inserted before the start of the IKE header in order to differentiate the traffic from ESP traffic between the same addresses and ports.
IKE头前面是一个16位长度字段，按网络字节顺序排列，该字段指定TCP流中IKE消息（包括非ESP标记）的长度。与UDP端口4500上的IKE一样，在IKE头的开始之前插入一个归零的32位非ESP标记，以区分相同地址和端口之间的通信量与ESP通信量。
o Length (2 octets, unsigned integer) - Length of the IKE packet, including the Length field and non-ESP marker.
o 长度（2个八位字节，无符号整数）—IKE数据包的长度，包括长度字段和非ESP标记。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ESP header [RFC4303] ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ESP header [RFC4303] ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
图2
The ESP header is preceded by a 16-bit Length field in network byte order that specifies the length of the ESP packet within the TCP stream.
ESP头前面是一个16位长度字段，按网络字节顺序排列，指定TCP流中ESP数据包的长度。
The Security Parameter Index (SPI) field [RFC7296] in the ESP header MUST NOT be a zero value.
ESP标头中的安全参数索引（SPI）字段[RFC7296]不得为零值。
o Length (2 octets, unsigned integer) - Length of the ESP packet, including the Length field.
o 长度（2个八位字节，无符号整数）—ESP数据包的长度，包括长度字段。
Each stream of bytes used for IKE and IPsec encapsulation MUST begin with a fixed sequence of six bytes as a magic value, containing the characters "IKETCP" as ASCII values. This value is intended to identify and validate that the TCP connection is being used for TCP encapsulation as defined in this document, to avoid conflicts with the prevalence of previous non-standard protocols that used TCP port 4500. This value is only sent once, by the TCP Originator only, at the beginning of any stream of IKE and ESP messages.
用于IKE和IPsec封装的每个字节流必须以六个字节的固定序列开始，作为一个魔术值，包含字符“IKETCP”作为ASCII值。此值用于识别和验证TCP连接是否用于本文档中定义的TCP封装，以避免与以前使用TCP端口4500的非标准协议的流行发生冲突。此值仅在IKE和ESP消息流开始时由TCP发起人发送一次。
If other framing protocols are used within TCP to further encapsulate or encrypt the stream of IKE and ESP messages, the stream prefix must be at the start of the TCP Originator's IKE and ESP message stream
如果在TCP中使用其他帧协议来进一步封装或加密IKE和ESP消息流，则流前缀必须位于TCP发起人的IKE和ESP消息流的开头
within the added protocol layer (Appendix A). Although some framing protocols do support negotiating inner protocols, the stream prefix should always be used in order for implementations to be as generic as possible and not rely on other framing protocols on top of TCP.
在添加的协议层内（附录A）。尽管某些成帧协议确实支持协商内部协议，但应始终使用流前缀，以便实现尽可能通用，而不依赖于TCP之上的其他成帧协议。
0 1 2 3 4 5
+------+------+------+------+------+------+
| 0x49 | 0x4b | 0x45 | 0x54 | 0x43 | 0x50 |
+------+------+------+------+------+------+
0 1 2 3 4 5
+------+------+------+------+------+------+
| 0x49 | 0x4b | 0x45 | 0x54 | 0x43 | 0x50 |
+------+------+------+------+------+------+
Figure 3
图3
TCP encapsulation is applicable only when it has been configured to be used with specific IKE peers. If a Responder is configured to use TCP encapsulation, it MUST listen on the configured port(s) in case any peers will initiate new IKE sessions. Initiators MAY use TCP encapsulation for any IKE session to a peer that is configured to support TCP encapsulation, although it is recommended that Initiators should only use TCP encapsulation when traffic over UDP is blocked.
TCP封装仅在配置为与特定IKE对等方一起使用时才适用。如果响应程序配置为使用TCP封装，则它必须在配置的端口上侦听，以防任何对等方启动新的IKE会话。发起方可以对配置为支持TCP封装的对等方的任何IKE会话使用TCP封装，但建议发起方仅在UDP上的通信被阻止时使用TCP封装。
Since the support of TCP encapsulation is a configured property, not a negotiated one, it is recommended that if there are multiple IKE endpoints representing a single peer (such as multiple machines with different IP addresses when connecting by Fully Qualified Domain Name, or endpoints used with IKE redirection), all of the endpoints equally support TCP encapsulation.
由于TCP封装的支持是一个配置属性，而不是协商属性，因此建议如果有多个IKE端点代表一个对等点（例如，当通过完全限定的域名连接时，具有不同IP地址的多台计算机，或与IKE重定向一起使用的端点），所有端点都同样支持TCP封装。
If TCP encapsulation is being used for a specific IKE SA, all messages for that IKE SA and its Child SAs MUST be sent over a TCP connection until the SA is deleted or IKEv2 Mobility and Multihoming (MOBIKE) is used to change the SA endpoints and/or the encapsulation protocol. See Section 8 for more details on using MOBIKE to transition between encapsulation modes.
如果TCP封装用于特定IKE SA，则必须通过TCP连接发送该IKE SA及其子SA的所有消息，直到删除SA或使用IKEv2 Mobility and Multihoming（MOBIKE）更改SA端点和/或封装协议。有关使用MOBIKE在封装模式之间转换的更多详细信息，请参见第8节。
Since UDP is the preferred method of transport for IKE messages, implementations that use TCP encapsulation should have an algorithm for deciding when to use TCP after determining that UDP is unusable. If an Initiator implementation has no prior knowledge about the network it is on and the status of UDP on that network, it SHOULD always attempt to negotiate IKE over UDP first. IKEv2 defines how to use retransmission timers with IKE messages and, specifically, IKE_SA_INIT messages [RFC7296]. Generally, this means that the implementation will define a frequency of retransmission and the maximum number of retransmissions allowed before marking the IKE SA
由于UDP是IKE消息的首选传输方法，因此使用TCP封装的实现应该有一个算法，用于在确定UDP不可用后决定何时使用TCP。如果启动器实现事先不知道它所在的网络以及该网络上UDP的状态，则它应该始终尝试首先通过UDP协商IKE。IKEv2定义了如何在IKE消息中使用重传计时器，特别是IKE_SA_INIT消息[RFC7296]。通常，这意味着实现将在标记IKE SA之前定义重传频率和允许的最大重传次数
as failed. An implementation can attempt negotiation over TCP once it has hit the maximum retransmissions over UDP, or slightly before to reduce connection setup delays. It is recommended that the initial message over UDP be retransmitted at least once before falling back to TCP, unless the Initiator knows beforehand that the network is likely to block UDP.
他失败了。一旦实现达到UDP上的最大重传次数，或者稍早一点，就可以尝试通过TCP进行协商，以减少连接设置延迟。建议UDP上的初始消息在返回TCP之前至少重新传输一次，除非启动器事先知道网络可能会阻止UDP。
When the IKE Initiator uses TCP encapsulation, it will initiate a TCP connection to the Responder using the configured TCP port. The first bytes sent on the stream MUST be the stream prefix value (Section 4). After this prefix, encapsulated IKE messages will negotiate the IKE SA and initial Child SA [RFC7296]. After this point, both encapsulated IKE (Figure 1) and ESP (Figure 2) messages will be sent over the TCP connection. The TCP Responder MUST wait for the entire stream prefix to be received on the stream before trying to parse out any IKE or ESP messages. The stream prefix is sent only once, and only by the TCP Originator.
当IKE启动器使用TCP封装时，它将使用配置的TCP端口启动到响应程序的TCP连接。流上发送的第一个字节必须是流前缀值（第4节）。在该前缀之后，封装的IKE消息将协商IKE SA和初始子SA[RFC7296]。在此之后，封装的IKE（图1）和ESP（图2）消息都将通过TCP连接发送。TCP响应程序必须等待在流上接收到整个流前缀，然后才能尝试解析任何IKE或ESP消息。流前缀仅发送一次，并且仅由TCP发起人发送。
In order to close an IKE session, either the Initiator or Responder SHOULD gracefully tear down IKE SAs with DELETE payloads. Once the SA has been deleted, the TCP Originator SHOULD close the TCP connection if it does not intend to use the connection for another IKE session to the TCP Responder. If the connection is left idle and the TCP Responder needs to clean up resources, the TCP Responder MAY close the TCP connection.
为了关闭IKE会话，发起方或响应方都应该使用DELETE有效负载正常地拆除IKE SA。删除SA后，如果TCP发起人不打算将该连接用于与TCP响应者的另一个IKE会话，则应关闭TCP连接。如果连接处于空闲状态，并且TCP响应程序需要清理资源，则TCP响应程序可能会关闭TCP连接。
An unexpected FIN or a TCP Reset on the TCP connection may indicate a loss of connectivity, an attack, or some other error. If a DELETE payload has not been sent, both sides SHOULD maintain the state for their SAs for the standard lifetime or timeout period. The TCP Originator is responsible for re-establishing the TCP connection if it is torn down for any unexpected reason. Since new TCP connections may use different ports due to NAT mappings or local port allocations changing, the TCP Responder MUST allow packets for existing SAs to be received from new source ports.
TCP连接上意外的FIN或TCP重置可能表示连接丢失、攻击或其他错误。如果尚未发送删除有效负载，则双方应在标准生存期或超时期间保持其SA的状态。如果TCP连接因任何意外原因中断，TCP发起人负责重新建立TCP连接。由于NAT映射或本地端口分配发生变化，新TCP连接可能会使用不同的端口，因此TCP响应程序必须允许从新的源端口接收现有SA的数据包。
A peer MUST discard a partially received message due to a broken connection.
由于连接中断，对等方必须放弃部分接收的消息。
Whenever the TCP Originator opens a new TCP connection to be used for an existing IKE SA, it MUST send the stream prefix first, before any IKE or ESP messages. This follows the same behavior as the initial TCP connection.
每当TCP发起人打开新的TCP连接以用于现有IKE SA时，它必须首先发送流前缀，然后再发送任何IKE或ESP消息。这与初始TCP连接的行为相同。
If a TCP connection is being used to resume a previous IKE session, the TCP Responder can recognize the session using either the IKE SPI from an encapsulated IKE message or the ESP SPI from an encapsulated ESP message. If the session had been fully established previously, it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES message if MOBIKE is supported, or an informational message (a keep-alive) otherwise.
如果TCP连接用于恢复以前的IKE会话，TCP响应程序可以使用封装的IKE消息中的IKE SPI或封装的ESP消息中的ESP SPI来识别会话。如果会话之前已完全建立，建议TCP发起人发送更新地址消息（如果支持MOBIKE），否则发送信息消息（保持活动）。
The TCP Responder MUST NOT accept any messages for the existing IKE session on a new incoming connection, unless that connection begins with the stream prefix. If either the TCP Originator or TCP Responder detects corruption on a connection that was started with a valid stream prefix, it SHOULD close the TCP connection. The connection can be determined to be corrupted if there are too many subsequent messages that cannot be parsed as valid IKE messages or ESP messages with known SPIs, or if the authentication check for an ESP message with a known SPI fails. Implementations SHOULD NOT tear down a connection if only a single ESP message has an unknown SPI, since the SPI databases may be momentarily out of sync. If there is instead a syntax issue within an IKE message, an implementation MUST send the INVALID_SYNTAX notify payload and tear down the IKE SA as usual, rather than tearing down the TCP connection directly.
TCP响应程序不得接受新传入连接上现有IKE会话的任何消息，除非该连接以流前缀开头。如果TCP发起方或TCP响应方检测到使用有效流前缀启动的连接损坏，则应关闭TCP连接。如果有太多后续消息无法解析为有效的IKE消息或具有已知SPI的ESP消息，或者具有已知SPI的ESP消息的身份验证检查失败，则可以确定连接已损坏。如果只有一条ESP消息具有未知SPI，则实现不应中断连接，因为SPI数据库可能会暂时不同步。如果IKE消息中出现语法问题，则实现必须发送无效的_语法notify有效负载，并像往常一样断开IKE SA，而不是直接断开TCP连接。
A TCP Originator SHOULD only open one TCP connection per IKE SA, over which it sends all of the corresponding IKE and ESP messages. This helps ensure that any firewall or NAT mappings allocated for the TCP connection apply to all of the traffic associated with the IKE SA equally.
TCP发起人应仅为每个IKE SA打开一个TCP连接，并通过该连接发送所有相应的IKE和ESP消息。这有助于确保为TCP连接分配的任何防火墙或NAT映射平等地应用于与IKE SA关联的所有流量。
Similarly, a TCP Responder SHOULD at any given time send packets for an IKE SA and its Child SAs over only one TCP connection. It SHOULD choose the TCP connection on which it last received a valid and decryptable IKE or ESP message. In order to be considered valid for choosing a TCP connection, an IKE message must be successfully decrypted and authenticated, not be a retransmission of a previously received message, and be within the expected window for IKE message IDs. Similarly, an ESP message must pass authentication checks and be decrypted, and must not be a replay of a previous message.
类似地，TCP响应程序应在任何给定时间仅通过一个TCP连接为IKE SA及其子SA发送数据包。它应该选择上次收到有效且可解密的IKE或ESP消息的TCP连接。为了被认为对选择TCP连接有效，IKE消息必须成功解密和验证，而不是以前接收到的消息的重新传输，并且必须在IKE消息ID的预期窗口内。类似地，ESP消息必须通过身份验证检查并解密，并且不能是以前消息的重播。
Since a connection may be broken and a new connection re-established by the TCP Originator without the TCP Responder being aware, a TCP Responder SHOULD accept receiving IKE and ESP messages on both old and new connections until the old connection is closed by the TCP Originator. A TCP Responder MAY close a TCP connection that it perceives as idle and extraneous (one previously used for IKE and ESP messages that has been replaced by a new connection).
由于TCP发起者可能会在TCP响应者不知道的情况下中断连接并重新建立新连接，因此TCP响应者应接受在旧连接和新连接上接收IKE和ESP消息，直到TCP发起者关闭旧连接。TCP响应程序可以关闭它认为空闲且无关的TCP连接（以前用于IKE和ESP消息的连接已被新连接替换）。
Multiple IKE SAs MUST NOT share a single TCP connection, unless one is a rekey of an existing IKE SA, in which case there will temporarily be two IKE SAs on the same TCP connection.
多个IKE SA不得共享单个TCP连接，除非其中一个是现有IKE SA的密钥更新，在这种情况下，同一TCP连接上将临时有两个IKE SA。
When negotiating over UDP port 500, IKE_SA_INIT packets include NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads to determine if UDP encapsulation of IPsec packets should be used. These payloads contain SHA-1 digests of the SPIs, IP addresses, and ports as defined in [RFC7296]. IKE_SA_INIT packets sent on a TCP connection SHOULD include these payloads with the same content as when sending over UDP and SHOULD use the applicable TCP ports when creating and checking the SHA-1 digests.
通过UDP端口500进行协商时，IKE_SA_INIT数据包包括NAT_检测_源IP和NAT_检测_目的IP有效负载，以确定是否应使用IPsec数据包的UDP封装。这些有效负载包含[RFC7296]中定义的SPI、IP地址和端口的SHA-1摘要。在TCP连接上发送的IKE_SA_INIT数据包应包含这些有效负载，其内容与通过UDP发送时相同，并且在创建和检查SHA-1摘要时应使用适用的TCP端口。
If a NAT is detected due to the SHA-1 digests not matching the expected values, no change should be made for encapsulation of subsequent IKE or ESP packets, since TCP encapsulation inherently supports NAT traversal. Implementations MAY use the information that a NAT is present to influence keep-alive timer values.
如果由于SHA-1摘要与预期值不匹配而检测到NAT，则不应对后续IKE或ESP数据包的封装进行任何更改，因为TCP封装本质上支持NAT遍历。实现可以使用NAT存在的信息来影响保持活动计时器值。
If a NAT is detected, implementations need to handle transport mode TCP and UDP packet checksum fixup as defined for UDP encapsulation in [RFC3948].
如果检测到NAT，则实现需要处理[RFC3948]中为UDP封装定义的传输模式TCP和UDP数据包校验和修正。
When an IKE session that has negotiated MOBIKE [RFC4555] is transitioning between networks, the Initiator of the transition may switch between using TCP encapsulation, UDP encapsulation, or no encapsulation. Implementations that implement both MOBIKE and TCP encapsulation MUST support dynamically enabling and disabling TCP encapsulation as interfaces change.
当协商了MOBIKE[RFC4555]的IKE会话在网络之间转换时，转换的发起方可以在使用TCP封装、UDP封装或不使用封装之间切换。实现MOBIKE和TCP封装的实现必须支持在接口更改时动态启用和禁用TCP封装。
When a MOBIKE-enabled Initiator changes networks, the UPDATE_SA_ADDRESSES notification SHOULD be sent out first over UDP before attempting over TCP. If there is a response to the UPDATE_SA_ADDRESSES notification sent over UDP, then the ESP packets should be sent directly over IP or over UDP port 4500 (depending on if a NAT was detected), regardless of if a connection on a previous network was using TCP encapsulation. Similarly, if the Responder only responds to the UPDATE_SA_ADDRESSES notification over TCP, then the ESP packets should be sent over the TCP connection, regardless of if a connection on a previous network did not use TCP encapsulation.
当启用MOBIKE的启动器更改网络时，在尝试通过TCP之前，应首先通过UDP发送更新地址通知。如果对通过UDP发送的更新地址通知有响应，则ESP数据包应直接通过IP或UDP端口4500发送（取决于是否检测到NAT），而不管以前网络上的连接是否使用TCP封装。类似地，如果响应者仅通过TCP响应UPDATE_SA_ADDRESSES通知，则ESP数据包应通过TCP连接发送，无论以前网络上的连接是否未使用TCP封装。
IKE message fragmentation [RFC7383] is not required when using TCP encapsulation, since a TCP stream already handles the fragmentation of its contents across packets. Since fragmentation is redundant in this case, implementations might choose to not negotiate IKE fragmentation. Even if fragmentation is negotiated, an implementation SHOULD NOT send fragments when going over a TCP connection, although it MUST support receiving fragments.
使用TCP封装时，不需要IKE消息分段[RFC7383]，因为TCP流已经处理其内容在数据包之间的分段。因为在这种情况下碎片是冗余的，所以实现可能选择不协商IKE碎片。即使碎片是协商的，实现在通过TCP连接时也不应该发送碎片，尽管它必须支持接收碎片。
If an implementation supports both MOBIKE and IKE fragmentation, it SHOULD negotiate IKE fragmentation over a TCP-encapsulated session in case the session switches to UDP encapsulation on another network.
如果一个实现同时支持MOBIKE和IKE分段，它应该通过TCP封装的会话协商IKE分段，以防会话切换到另一个网络上的UDP封装。
Encapsulating IKE and IPsec inside of a TCP connection can impact the strategy that implementations use to detect peer liveness and to maintain middlebox port mappings. Peer liveness should be checked using IKE informational packets [RFC7296].
在TCP连接中封装IKE和IPsec可能会影响实现用于检测对等活跃度和维护中间箱端口映射的策略。应使用IKE信息包[RFC7296]检查对等活动性。
In general, TCP port mappings are maintained by NATs longer than UDP port mappings, so IPsec ESP NAT keep-alives [RFC3948] SHOULD NOT be sent when using TCP encapsulation. Any implementation using TCP encapsulation MUST silently drop incoming NAT keep-alive packets and not treat them as errors. NAT keep-alive packets over a TCP-encapsulated IPsec connection will be sent as an ESP message with a one-octet-long payload with the value 0xFF.
通常，TCP端口映射由NAT维护的时间长于UDP端口映射，因此在使用TCP封装时不应发送IPsec ESP NAT保持有效[RFC3948]。任何使用TCP封装的实现都必须静默地丢弃传入的NAT保持活动的数据包，而不是将它们视为错误。通过TCP封装的IPsec连接的NAT保持活动数据包将作为ESP消息发送，有效负载为一个八位字节，值为0xFF。
Note that, depending on the configuration of TCP and TLS on the connection, TCP keep-alives [RFC1122] and TLS keep-alives [RFC6520] may be used. These MUST NOT be used as indications of IKE peer liveness.
注意，根据连接上TCP和TLS的配置，可以使用TCP保持有效[RFC1122]和TLS保持有效[RFC6520]。这些不能用作IKE对等活动的指示。
Many security networking devices, such as firewalls or intrusion prevention systems, network optimization/acceleration devices, and NAT devices, keep the state of sessions that traverse through them.
许多安全网络设备（如防火墙或入侵预防系统、网络优化/加速设备和NAT设备）保持通过它们的会话状态。
These devices commonly track the transport-layer and/or application-layer data to drop traffic that is anomalous or malicious in nature. While many of these devices will be more likely to pass TCP-encapsulated traffic as opposed to UDP-encapsulated traffic, some may still block or interfere with TCP-encapsulated IKE and IPsec traffic.
这些设备通常跟踪传输层和/或应用层数据，以丢弃本质上异常或恶意的流量。虽然这些设备中的许多设备更有可能通过TCP封装的通信量而不是UDP封装的通信量，但有些设备可能仍然会阻止或干扰TCP封装的IKE和IPsec通信量。
A network device that monitors the transport layer will track the state of TCP sessions, such as TCP sequence numbers. TCP encapsulation of IKE should therefore use standard TCP behaviors to avoid being dropped by middleboxes.
监视传输层的网络设备将跟踪TCP会话的状态，例如TCP序列号。因此，IKE的TCP封装应该使用标准的TCP行为来避免被中间盒丢弃。
Several aspects of TCP encapsulation for IKE and IPsec packets may negatively impact the performance of connections within a tunnel-mode IPsec SA. Implementations should be aware of these performance impacts and take these into consideration when determining when to use TCP encapsulation. Implementations SHOULD favor using direct ESP or UDP encapsulation over TCP encapsulation whenever possible.
IKE和IPsec数据包的TCP封装的几个方面可能会对隧道模式IPsec SA内连接的性能产生负面影响。实现应该了解这些性能影响，并在确定何时使用TCP封装时考虑这些影响。在可能的情况下，实现应该倾向于使用直接ESP或UDP封装而不是TCP封装。
If the outer connection between IKE peers is over TCP, inner TCP connections may suffer negative effects from using TCP within TCP. Running TCP within TCP is discouraged, since the TCP algorithms generally assume that they are running over an unreliable datagram layer.
如果IKE对等点之间的外部连接通过TCP，则内部TCP连接可能会因在TCP中使用TCP而受到负面影响。不鼓励在TCP中运行TCP，因为TCP算法通常假定它们在不可靠的数据报层上运行。
If the outer (tunnel) TCP connection experiences packet loss, this loss will be hidden from any inner TCP connections, since the outer connection will retransmit to account for the losses. Since the outer TCP connection will deliver the inner messages in order, any messages after a lost packet may have to wait until the loss is recovered. This means that loss on the outer connection will be interpreted only as delay by inner connections. The burstiness of inner traffic can increase, since a large number of inner packets may be delivered across the tunnel at once. The inner TCP connection may interpret a long period of delay as a transmission problem, triggering a retransmission timeout, which will cause spurious retransmissions. The sending rate of the inner connection may be unnecessarily reduced if the retransmissions are not detected as spurious in time.
如果外部（隧道）TCP连接经历数据包丢失，则该丢失将对任何内部TCP连接隐藏，因为外部连接将重新传输以解释丢失。由于外部TCP连接将按顺序传递内部消息，因此丢失数据包后的任何消息都可能必须等待，直到丢失恢复。这意味着外部连接的丢失将仅被解释为内部连接的延迟。内部流量的突发性可能会增加，因为大量内部数据包可能会一次通过隧道传送。内部TCP连接可能会将长时间延迟解释为传输问题，从而触发重新传输超时，这将导致虚假的重新传输。如果没有及时检测到重传是虚假的，则内部连接的发送速率可能会不必要地降低。
The inner TCP connection's round-trip-time estimation will be affected by the burstiness of the outer TCP connection if there are long delays when packets are retransmitted by the outer TCP connection. This will make the congestion control loop of the inner TCP traffic less reactive, potentially permanently leading to a lower sending rate than the outer TCP would allow for.
如果外部TCP连接重新传输数据包时存在长延迟，则内部TCP连接的往返时间估计将受到外部TCP连接突发性的影响。这将使内部TCP流量的拥塞控制环路反应性降低，可能永久性地导致发送速率低于外部TCP允许的速率。
TCP-in-TCP can also lead to increased buffering, or bufferbloat. This can occur when the window size of the outer TCP connection is reduced and becomes smaller than the window sizes of the inner TCP connections. This can lead to packets backing up in the outer TCP connection's send buffers. In order to limit this effect, the outer TCP connection should have limits on its send buffer size and on the rate at which it reduces its window size.
TCP中的TCP也会导致缓冲增加或缓冲区膨胀。当外部TCP连接的窗口大小减小并小于内部TCP连接的窗口大小时，可能会发生这种情况。这可能导致数据包在外部TCP连接的发送缓冲区中备份。为了限制这种影响，外部TCP连接应该限制其发送缓冲区大小和减少窗口大小的速率。
Note that any negative effects will be shared between all flows going through the outer TCP connection. This is of particular concern for any latency-sensitive or real-time applications using the tunnel. If such traffic is using a TCP-encapsulated IPsec connection, it is recommended that the number of inner connections sharing the tunnel be limited as much as possible.
请注意，任何负面影响都将在通过外部TCP连接的所有流之间共享。对于任何使用隧道的延迟敏感或实时应用程序来说，这一点尤为重要。如果此类通信使用TCP封装的IPsec连接，建议尽可能限制共享隧道的内部连接数。
Since ESP is an unreliable protocol, transmitting ESP packets over a TCP connection will change the fundamental behavior of the packets. Some application-level protocols that prefer packet loss to delay (such as Voice over IP or other real-time protocols) may be negatively impacted if their packets are retransmitted by the TCP connection due to packet loss.
由于ESP是一种不可靠的协议，通过TCP连接传输ESP数据包将改变数据包的基本行为。如果TCP连接因数据包丢失而重新传输数据包，则某些偏爱数据包丢失而非延迟的应用程序级协议（如IP语音或其他实时协议）可能会受到负面影响。
Quality-of-Service (QoS) markings, such as the Differentiated Services Code Point (DSCP) and Traffic Class, should be used with care on TCP connections used for encapsulation. Individual packets SHOULD NOT use different markings than the rest of the connection, since packets with different priorities may be routed differently and cause unnecessary delays in the connection.
在用于封装的TCP连接上，应小心使用服务质量（QoS）标记，如区分服务代码点（DSCP）和流量类别。单个数据包不应使用与连接其余部分不同的标记，因为具有不同优先级的数据包的路由可能不同，并在连接中造成不必要的延迟。
A TCP connection used for IKE encapsulation SHOULD negotiate its MSS in order to avoid unnecessary fragmentation of packets.
用于IKE封装的TCP连接应协商其MSS，以避免不必要的数据包碎片。
Since there is not a one-to-one relationship between outer IP packets and inner ESP/IP messages when using TCP encapsulation, the markings for Explicit Congestion Notification (ECN) [RFC3168] cannot be simply mapped. However, any ECN Congestion Experienced (CE) marking on inner headers should be preserved through the tunnel.
由于在使用TCP封装时，外部IP数据包和内部ESP/IP消息之间没有一对一的关系，因此无法简单地映射显式拥塞通知（ECN）[RFC3168]的标记。但是，内部集管上的任何ECN（CE）标记应通过隧道保留。
Implementations SHOULD follow the ECN compatibility mode for tunnel ingress as described in [RFC6040]. In compatibility mode, the outer tunnel TCP connection marks its packet headers as not ECN-capable. If upon egress, the arriving outer header is marked with CE, the implementation will drop the inner packet, since there is not a distinct inner packet header onto which to translate the ECN markings.
实施应遵循[RFC6040]中所述的隧道入口的ECN兼容模式。在兼容模式下，外部隧道TCP连接将其数据包头标记为不支持ECN。如果在出口时，到达的外部报头用CE标记，则实现将丢弃内部分组，因为不存在将ECN标记转换到其上的不同的内部分组报头。
IKE Responders that support TCP encapsulation may become vulnerable to new Denial-of-Service (DoS) attacks that are specific to TCP, such as SYN-flooding attacks. TCP Responders should be aware of this additional attack surface.
支持TCP封装的IKE响应程序可能容易受到TCP特有的新的拒绝服务（DoS）攻击，例如SYN洪泛攻击。TCP响应者应该知道这个额外的攻击面。
TCP Responders should be careful to ensure that (1) the stream prefix "IKETCP" uniquely identifies incoming streams as streams that use the TCP encapsulation protocol and (2) they are not running any other protocols on the same listening port (to avoid potential conflicts).
TCP响应者应小心确保（1）流前缀“IKETCP”唯一地将传入流标识为使用TCP封装协议的流；（2）它们没有在同一侦听端口上运行任何其他协议（以避免潜在冲突）。
Attackers may be able to disrupt the TCP connection by sending spurious TCP Reset packets. Therefore, implementations SHOULD make sure that IKE session state persists even if the underlying TCP connection is torn down.
攻击者可以通过发送虚假的TCP重置数据包来中断TCP连接。因此，即使底层TCP连接中断，实现也应该确保IKE会话状态保持不变。
If MOBIKE is being used, all of the security considerations outlined for MOBIKE apply [RFC4555].
如果使用MOBIKE，则适用于MOBIKE的所有安全注意事项[RFC4555]。
Similarly to MOBIKE, TCP encapsulation requires a TCP Responder to handle changes to source address and port due to network or connection disruption. The successful delivery of valid IKE or ESP messages over a new TCP connection is used by the TCP Responder to determine where to send subsequent responses. If an attacker is able to send packets on a new TCP connection that pass the validation checks of the TCP Responder, it can influence which path future packets will take. For this reason, the validation of messages on the TCP Responder must include decryption, authentication, and replay checks.
与MOBIKE类似，TCP封装要求TCP响应程序处理由于网络或连接中断而对源地址和端口的更改。TCP响应程序使用通过新TCP连接成功传递有效IKE或ESP消息来确定在何处发送后续响应。如果攻击者能够在通过TCP响应程序验证检查的新TCP连接上发送数据包，则会影响未来数据包将采用的路径。因此，TCP响应程序上消息的验证必须包括解密、身份验证和重播检查。
Since TCP provides reliable, in-order delivery of ESP messages, the ESP anti-replay window size SHOULD be set to 1. See [RFC4303] for a complete description of the ESP anti-replay window. This increases the protection of implementations against replay attacks.
由于TCP提供可靠、有序的ESP消息传递，因此ESP防重播窗口大小应设置为1。有关ESP防重播窗口的完整说明，请参阅[RFC4303]。这增强了实现对重播攻击的保护。
TCP port 4500 is already allocated to IPsec for NAT traversal. This port SHOULD be used for TCP-encapsulated IKE and ESP as described in this document.
TCP端口4500已分配给IPsec用于NAT穿越。如本文档所述，此端口应用于TCP封装的IKE和ESP。
This document updates the reference for TCP port 4500:
本文档更新了TCP端口4500的参考：
Keyword Decimal Description Reference
----------- -------- ------------------- ---------
ipsec-nat-t 4500/tcp IPsec NAT-Traversal RFC 8229
Keyword Decimal Description Reference
----------- -------- ------------------- ---------
ipsec-nat-t 4500/tcp IPsec NAT-Traversal RFC 8229
Figure 4
图4
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, DOI 10.17487/RFC3948, January 2005, <http://www.rfc-editor.org/info/rfc3948>.
[RFC3948]Huttunen，A.，Swander，B.，Volpe，V.，DiBurro，L.，和M.Stenberg，“IPsec ESP数据包的UDP封装”，RFC 3948，DOI 10.17487/RFC3948，2005年1月<http://www.rfc-editor.org/info/rfc3948>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，DOI 10.17487/RFC4303，2005年12月<http://www.rfc-editor.org/info/rfc4303>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <http://www.rfc-editor.org/info/rfc6040>.
[RFC6040]Briscoe，B.，“明确拥塞通知的隧道挖掘”，RFC 6040，DOI 10.17487/RFC6040，2010年11月<http://www.rfc-editor.org/info/rfc6040>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296]Kaufman，C.，Hoffman，P.，Nir，Y.，Eronen，P.，和T.Kivinen，“互联网密钥交换协议版本2（IKEv2）”，STD 79，RFC 7296，DOI 10.17487/RFC72962014年10月<http://www.rfc-editor.org/info/rfc7296>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
[IKE-over-TCP] Nir, Y., "A TCP transport for the Internet Key Exchange", Work in Progress, draft-ietf-ipsecme-ike-tcp-01, December 2012.
[IKE over TCP]Nir，Y.，“互联网密钥交换的TCP传输”，正在进行的工作，草稿-ietf-IPSECM-IKE-TCP-01，2012年12月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，DOI 10.17487/RFC1122，1989年10月<http://www.rfc-editor.org/info/rfc1122>.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, DOI 10.17487/RFC2817, May 2000, <http://www.rfc-editor.org/info/rfc2817>.
[RFC2817]Khare，R.和S.Lawrence，“在HTTP/1.1中升级到TLS”，RFC 2817，DOI 10.17487/RFC2817，2000年5月<http://www.rfc-editor.org/info/rfc2817>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，DOI 10.17487/RFC3168，2001年9月<http://www.rfc-editor.org/info/rfc3168>.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, <http://www.rfc-editor.org/info/rfc4555>.
[RFC4555]Eronen，P.，“IKEv2移动和多址协议（MOBIKE）”，RFC 4555，DOI 10.17487/RFC4555，2006年6月<http://www.rfc-editor.org/info/rfc4555>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, DOI 10.17487/RFC6520, February 2012, <http://www.rfc-editor.org/info/rfc6520>.
[RFC6520]Seggelmann，R.，Tuexen，M.和M.Williams，“传输层安全性（TLS）和数据报传输层安全性（DTLS）心跳扩展”，RFC 6520，DOI 10.17487/RFC6520，2012年2月<http://www.rfc-editor.org/info/rfc6520>.
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/RFC7383, November 2014, <http://www.rfc-editor.org/info/rfc7383>.
[RFC7383]Smyslov，V.，“互联网密钥交换协议版本2（IKEv2）消息碎片”，RFC 7383，DOI 10.17487/RFC7383，2014年11月<http://www.rfc-editor.org/info/rfc7383>.
This section provides recommendations on how to use TLS in addition to TCP encapsulation.
本节提供了关于如何在TCP封装之外使用TLS的建议。
When using TCP encapsulation, implementations may choose to use TLS [RFC5246] on the TCP connection to be able to traverse middleboxes, which may otherwise block the traffic.
当使用TCP封装时，实现可能会选择在TCP连接上使用TLS[RFC5246]，以便能够遍历中间盒，否则可能会阻塞通信。
If a web proxy is applied to the ports used for the TCP connection and TLS is being used, the TCP Originator can send an HTTP CONNECT message to establish an SA through the proxy [RFC2817].
如果将web代理应用于用于TCP连接的端口，并且正在使用TLS，则TCP发起人可以通过代理发送HTTP CONNECT消息以建立SA[RFC2817]。
The use of TLS should be configurable on the peers, and may be used as the default when using TCP encapsulation or may be used as a fallback when basic TCP encapsulation fails. The TCP Responder may expect to read encapsulated IKE and ESP packets directly from the TCP connection, or it may expect to read them from a stream of TLS data packets. The TCP Originator should be pre-configured to use TLS or not when communicating with a given port on the TCP Responder.
TLS的使用应该可以在对等机上配置，并且可以在使用TCP封装时用作默认值，也可以在基本TCP封装失败时用作回退。TCP响应程序可能期望直接从TCP连接读取封装的IKE和ESP数据包，或者期望从TLS数据包流读取它们。当与TCP响应程序上的给定端口通信时，TCP发起人应预先配置为使用TLS或不使用TLS。
When new TCP connections are re-established due to a broken connection, TLS must be renegotiated. TLS session resumption is recommended to improve efficiency in this case.
当由于断开的连接而重新建立新的TCP连接时，必须重新协商TLS。在这种情况下，建议恢复TLS会话以提高效率。
The security of the IKE session is entirely derived from the IKE negotiation and key establishment and not from the TLS session (which in this context is only used for encapsulation purposes); therefore, when TLS is used on the TCP connection, both the TCP Originator and the TCP Responder SHOULD allow the NULL cipher to be selected for performance reasons.
IKE会话的安全性完全来自IKE协商和密钥建立，而不是来自TLS会话（在本文中，TLS会话仅用于封装目的）；因此，当在TCP连接上使用TLS时，出于性能原因，TCP发起方和TCP响应方都应允许选择空密码。
Implementations should be aware that the use of TLS introduces another layer of overhead requiring more bytes to transmit a given IKE and IPsec packet. For this reason, direct ESP, UDP encapsulation, or TCP encapsulation without TLS should be preferred in situations in which TLS is not required in order to traverse middleboxes.
实现应该知道，TLS的使用引入了另一层开销，需要更多字节来传输给定的IKE和IPsec数据包。因此，在不需要TLS的情况下，应首选不带TLS的直接ESP、UDP封装或TCP封装，以便遍历中间盒。
Client Server
---------- ----------
1) -------------------- TCP Connection -------------------
(IP_I:Port_I -> IP_R:Port_R)
TcpSyn ---------->
<---------- TcpSyn,Ack
TcpAck ---------->
Client Server
---------- ----------
1) -------------------- TCP Connection -------------------
(IP_I:Port_I -> IP_R:Port_R)
TcpSyn ---------->
<---------- TcpSyn,Ack
TcpAck ---------->
2) --------------------- TLS Session ---------------------
ClientHello ---------->
ServerHello
Certificate*
ServerKeyExchange*
<---------- ServerHelloDone
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished ---------->
[ChangeCipherSpec]
<---------- Finished
2) --------------------- TLS Session ---------------------
ClientHello ---------->
ServerHello
Certificate*
ServerKeyExchange*
<---------- ServerHelloDone
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished ---------->
[ChangeCipherSpec]
<---------- Finished
3) ---------------------- Stream Prefix --------------------
"IKETCP" ---------->
4) ----------------------- IKE Session ---------------------
Length + Non-ESP Marker ---------->
IKE_SA_INIT
HDR, SAi1, KEi, Ni,
[N(NAT_DETECTION_*_IP)]
<------ Length + Non-ESP Marker
IKE_SA_INIT
HDR, SAr1, KEr, Nr,
[N(NAT_DETECTION_*_IP)]
Length + Non-ESP Marker ---------->
first IKE_AUTH
HDR, SK {IDi, [CERTREQ]
CP(CFG_REQUEST), IDr,
SAi2, TSi, TSr, ...}
<------ Length + Non-ESP Marker
first IKE_AUTH
HDR, SK {IDr, [CERT], AUTH,
EAP, SAr2, TSi, TSr}
3) ---------------------- Stream Prefix --------------------
"IKETCP" ---------->
4) ----------------------- IKE Session ---------------------
Length + Non-ESP Marker ---------->
IKE_SA_INIT
HDR, SAi1, KEi, Ni,
[N(NAT_DETECTION_*_IP)]
<------ Length + Non-ESP Marker
IKE_SA_INIT
HDR, SAr1, KEr, Nr,
[N(NAT_DETECTION_*_IP)]
Length + Non-ESP Marker ---------->
first IKE_AUTH
HDR, SK {IDi, [CERTREQ]
CP(CFG_REQUEST), IDr,
SAi2, TSi, TSr, ...}
<------ Length + Non-ESP Marker
first IKE_AUTH
HDR, SK {IDr, [CERT], AUTH,
EAP, SAr2, TSi, TSr}
Length + Non-ESP Marker ---------->
IKE_AUTH + EAP
repeat 1..N times
<------ Length + Non-ESP Marker
IKE_AUTH + EAP
Length + Non-ESP Marker ---------->
final IKE_AUTH
HDR, SK {AUTH}
<------ Length + Non-ESP Marker
final IKE_AUTH
HDR, SK {AUTH, CP(CFG_REPLY),
SA, TSi, TSr, ...}
-------------- IKE and IPsec SAs Established ------------
Length + ESP Frame ---------->
Length + Non-ESP Marker ---------->
IKE_AUTH + EAP
repeat 1..N times
<------ Length + Non-ESP Marker
IKE_AUTH + EAP
Length + Non-ESP Marker ---------->
final IKE_AUTH
HDR, SK {AUTH}
<------ Length + Non-ESP Marker
final IKE_AUTH
HDR, SK {AUTH, CP(CFG_REPLY),
SA, TSi, TSr, ...}
-------------- IKE and IPsec SAs Established ------------
Length + ESP Frame ---------->
Figure 5
图5
1. The client establishes a TCP connection with the server on port 4500 or on an alternate pre-configured port that the server is listening on.
1. 客户端在端口4500或服务器正在侦听的备用预配置端口上与服务器建立TCP连接。
2. If configured to use TLS, the client initiates a TLS handshake. During the TLS handshake, the server SHOULD NOT request the client's certificate, since authentication is handled as part of IKE negotiation.
2. 如果配置为使用TLS，客户端将启动TLS握手。在TLS握手期间，服务器不应请求客户端的证书，因为身份验证是作为IKE协商的一部分处理的。
3. The client sends the stream prefix for TCP-encapsulated IKE (Section 4) traffic to signal the beginning of IKE negotiation.
3. 客户端发送TCP封装的IKE（第4节）流量的流前缀，以指示IKE协商的开始。
4. The client and server establish an IKE connection. This example shows EAP-based authentication, although any authentication type may be used.
4. 客户端和服务器建立IKE连接。此示例显示了基于EAP的身份验证，尽管可以使用任何身份验证类型。
Client Server
---------- ----------
1) ----------------------- IKE Session ---------------------
Length + Non-ESP Marker ---------->
INFORMATIONAL
HDR, SK {[N,] [D,]
[CP,] ...}
<------ Length + Non-ESP Marker
INFORMATIONAL
HDR, SK {[N,] [D,]
[CP], ...}
Client Server
---------- ----------
1) ----------------------- IKE Session ---------------------
Length + Non-ESP Marker ---------->
INFORMATIONAL
HDR, SK {[N,] [D,]
[CP,] ...}
<------ Length + Non-ESP Marker
INFORMATIONAL
HDR, SK {[N,] [D,]
[CP], ...}
2) --------------------- TLS Session ---------------------
close_notify ---------->
<---------- close_notify
3) -------------------- TCP Connection -------------------
TcpFin ---------->
<---------- Ack
<---------- TcpFin
Ack ---------->
-------------------- IKE SA Deleted -------------------
2) --------------------- TLS Session ---------------------
close_notify ---------->
<---------- close_notify
3) -------------------- TCP Connection -------------------
TcpFin ---------->
<---------- Ack
<---------- TcpFin
Ack ---------->
-------------------- IKE SA Deleted -------------------
Figure 6
图6
1. The client and server exchange informational messages to notify IKE SA deletion.
1. 客户端和服务器交换信息性消息以通知IKE SA删除。
2. The client and server negotiate TLS session deletion using TLS CLOSE_NOTIFY.
2. 客户端和服务器使用TLS CLOSE_NOTIFY协商TLS会话删除。
3. The TCP connection is torn down.
3. TCP连接已断开。
The deletion of the IKE SA should lead to the disposal of the underlying TLS and TCP state.
IKE SA的删除应导致底层TLS和TCP状态的处置。
Client Server
---------- ----------
1) -------------------- TCP Connection -------------------
(IP_I:Port_I -> IP_R:Port_R)
TcpSyn ---------->
<---------- TcpSyn,Ack
TcpAck ---------->
2) --------------------- TLS Session ---------------------
ClientHello ---------->
<---------- ServerHello
[ChangeCipherSpec]
Finished
[ChangeCipherSpec] ---------->
Finished
3) ---------------------- Stream Prefix --------------------
"IKETCP" ---------->
4) <---------------------> IKE/ESP Flow <------------------>
Length + ESP Frame ---------->
Client Server
---------- ----------
1) -------------------- TCP Connection -------------------
(IP_I:Port_I -> IP_R:Port_R)
TcpSyn ---------->
<---------- TcpSyn,Ack
TcpAck ---------->
2) --------------------- TLS Session ---------------------
ClientHello ---------->
<---------- ServerHello
[ChangeCipherSpec]
Finished
[ChangeCipherSpec] ---------->
Finished
3) ---------------------- Stream Prefix --------------------
"IKETCP" ---------->
4) <---------------------> IKE/ESP Flow <------------------>
Length + ESP Frame ---------->
Figure 7
图7
1. If a previous TCP connection was broken (for example, due to a TCP Reset), the client is responsible for re-initiating the TCP connection. The TCP Originator's address and port (IP_I and Port_I) may be different from the previous connection's address and port.
1. 如果以前的TCP连接中断（例如，由于TCP重置），则客户端负责重新启动TCP连接。TCP发起者的地址和端口（IP_I和端口_I）可能与以前连接的地址和端口不同。
2. In the ClientHello TLS message, the client SHOULD send the session ID it received in the previous TLS handshake if available. It is up to the server to perform either an abbreviated handshake or a full handshake based on the session ID match.
2. 在ClientHello TLS消息中，客户机应发送在上一次TLS握手中收到的会话ID（如果可用）。由服务器根据会话ID匹配执行简短握手或完全握手。
3. After TCP and TLS are complete, the client sends the stream prefix for TCP-encapsulated IKE traffic (Section 4).
3. TCP和TLS完成后，客户端发送TCP封装IKE流量的流前缀（第4节）。
4. The IKE and ESP packet flow can resume. If MOBIKE is being used, the Initiator SHOULD send an UPDATE_SA_ADDRESSES message.
4. IKE和ESP数据包流可以恢复。如果正在使用MOBIKE，则启动器应发送更新地址消息。
Client Server
---------- ----------
(IP_I1:UDP500 -> IP_R:UDP500)
1) ----------------- IKE_SA_INIT Exchange -----------------
(IP_I1:UDP4500 -> IP_R:UDP4500)
Non-ESP Marker ----------->
Initial IKE_AUTH
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) }
<----------- Non-ESP Marker
Initial IKE_AUTH
HDR, SK { IDr, CERT, AUTH,
EAP, SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED) }
<------------------ IKE SA Establishment --------------->
Client Server
---------- ----------
(IP_I1:UDP500 -> IP_R:UDP500)
1) ----------------- IKE_SA_INIT Exchange -----------------
(IP_I1:UDP4500 -> IP_R:UDP4500)
Non-ESP Marker ----------->
Initial IKE_AUTH
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) }
<----------- Non-ESP Marker
Initial IKE_AUTH
HDR, SK { IDr, CERT, AUTH,
EAP, SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED) }
<------------------ IKE SA Establishment --------------->
2) ------------ MOBIKE Attempt on New Network --------------
(IP_I2:UDP4500 -> IP_R:UDP4500)
Non-ESP Marker ----------->
INFORMATIONAL
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
2) ------------ MOBIKE Attempt on New Network --------------
(IP_I2:UDP4500 -> IP_R:UDP4500)
Non-ESP Marker ----------->
INFORMATIONAL
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
3) -------------------- TCP Connection -------------------
(IP_I2:Port_I -> IP_R:Port_R)
TcpSyn ----------->
<----------- TcpSyn,Ack
TcpAck ----------->
3) -------------------- TCP Connection -------------------
(IP_I2:Port_I -> IP_R:Port_R)
TcpSyn ----------->
<----------- TcpSyn,Ack
TcpAck ----------->
4) --------------------- TLS Session ---------------------
ClientHello ----------->
ServerHello
Certificate*
ServerKeyExchange*
<----------- ServerHelloDone
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished ----------->
[ChangeCipherSpec]
<----------- Finished
4) --------------------- TLS Session ---------------------
ClientHello ----------->
ServerHello
Certificate*
ServerKeyExchange*
<----------- ServerHelloDone
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished ----------->
[ChangeCipherSpec]
<----------- Finished
5) ---------------------- Stream Prefix --------------------
"IKETCP" ---------->
5) ---------------------- Stream Prefix --------------------
"IKETCP" ---------->
6) ----------------------- IKE Session ---------------------
Length + Non-ESP Marker ----------->
INFORMATIONAL (Same as step 2)
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
6) ----------------------- IKE Session ---------------------
Length + Non-ESP Marker ----------->
INFORMATIONAL (Same as step 2)
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
<------- Length + Non-ESP Marker
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
7) <----------------- IKE/ESP Data Flow ------------------->
<------- Length + Non-ESP Marker
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
7) <----------------- IKE/ESP Data Flow ------------------->
Figure 8
图8
1. During the IKE_SA_INIT exchange, the client and server exchange MOBIKE_SUPPORTED notify payloads to indicate support for MOBIKE.
1. 在IKE_SA_INIT交换期间，客户端和服务器交换MOBIKE_支持的notify payloads表示支持MOBIKE。
2. The client changes its point of attachment to the network and receives a new IP address. The client attempts to re-establish the IKE session using the UPDATE_SA_ADDRESSES notify payload, but the server does not respond because the network blocks UDP traffic.
2. 客户端更改其网络连接点并接收新的IP地址。客户端尝试使用UPDATE_SA_ADDRESSES notify负载重新建立IKE会话，但服务器没有响应，因为网络阻止UDP通信。
3. The client brings up a TCP connection to the server in order to use TCP encapsulation.
3. 客户机启动到服务器的TCP连接以使用TCP封装。
4. The client initiates a TLS handshake with the server.
4. 客户端启动与服务器的TLS握手。
5. The client sends the stream prefix for TCP-encapsulated IKE traffic (Section 4).
5. 客户端为TCP封装的IKE通信发送流前缀（第4节）。
6. The client sends the UPDATE_SA_ADDRESSES notify payload on the TCP-encapsulated connection. Note that this IKE message is the same as the one sent over UDP in step 2; it should have the same message ID and contents.
6. 客户端在TCP封装的连接上发送更新地址通知有效负载。请注意，此IKE消息与步骤2中通过UDP发送的消息相同；它应该具有相同的消息ID和内容。
7. The IKE and ESP packet flow can resume.
7. IKE和ESP数据包流可以恢复。
Acknowledgments
致谢
The authors would like to acknowledge the input and advice of Stuart Cheshire, Delziel Fernandes, Yoav Nir, Christoph Paasch, Yaron Sheffer, David Schinazi, Graham Bartlett, Byju Pularikkal, March Wu, Kingwel Xie, Valery Smyslov, Jun Hu, and Tero Kivinen. Special thanks to Eric Kinnear for his implementation work.
作者要感谢斯图尔特·切希尔、德尔齐尔·费尔南德斯、约阿夫·尼尔、克里斯托夫·帕斯、亚龙·谢弗、大卫·希纳粹主义、格雷厄姆·巴特利特、比丘·普拉里卡尔、吴三月、谢金威尔、瓦莱里·斯米斯洛夫、胡军和泰罗·基维宁的意见和建议。特别感谢Eric Kinnear的实施工作。
Authors' Addresses
作者地址
Tommy Pauly Apple Inc. 1 Infinite Loop Cupertino, California 95014 United States of America
汤米·保利苹果公司，加利福尼亚州库珀蒂诺无限环路1号，美国95014
Email: tpauly@apple.com
Email: tpauly@apple.com
Samy Touati Ericsson 2755 Augustine Santa Clara, California 95054 United States of America
Samy Touati Ericsson 2755奥古斯丁圣克拉拉，加利福尼亚州95054美利坚合众国
Email: samy.touati@ericsson.com
Email: samy.touati@ericsson.com
Ravi Mantha Cisco Systems SEZ, Embassy Tech Village Panathur, Bangalore 560 037 India
印度班加罗尔巴拿马图尔大使馆技术村拉维·曼塔思科系统经济特区560037
Email: ramantha@cisco.com
Email: ramantha@cisco.com