IKE和IPsec数据包的TCP封装

RFC 8229：TCP Encapsulation of IKE and IPsec Packets，August 2017
梗概
本文档描述了一种通过TCP连接传输Internet密钥交换协议（Internet Key Exchange，IKE）和IPsec数据包的方法，用于穿越可能阻止通过UDP进行IKE协商的网络中间设备。这种方法称为“TCP封装”，涉及通过TCP连接发送用于建立安全关联的IKE数据包和封装安全载荷（Encapsulating Security Payload，ESP）数据包。此方法旨在用作无法通过UDP协商IKE时的后备选项。
本备忘录的状态
这是一份互联网标准跟踪文档。
本文档是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已接受公众审查，并已被互联网工程指导小组（IESG）批准发布。有关互联网标准的更多信息，请参阅RFC 7841第2节。

有关本文档当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8229。
版权声明
版权所有（c）2017 IETF Trust和文档作者。版权所有。
本文档受本文档发布之日生效的BCP 78和IETF Trust与IETF文件相关的法律规定（http://trustee.ietf.org/license-info）的约束。请仔细阅读这些文件，因为它们描述了您与本文件相关的权利和限制。从本文档中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并且在提供时不提供简化BSD许可证中所述的保证。
1、简介
Internet密钥交换协议版本2（Internet Key Exchange Protocol version 2，IKEv2）[RFC7296]是一种用于建立IPsec安全关联（Security Associations，SA）、使用UDP上的IKE消息来控制流量以及使用封装安全载荷（ESP）[RFC4303]消息来加密数据流量的协议。许多过滤公共热点流量的网络中间件会阻止所有UDP流量，包括IKE和IPsec，但允许TCP连接通过，因为它们看起来是Web流量。这些网络上需要使用IPsec（访问私有企业网络、将IP语音呼叫路由到运营商网络或由于安全策略）的设备无法建立IPsec SA。本文档定义了一种在TCP连接内封装IKE控制消息以及IPsec数据消息的方法。
使用TCP作为IPsec数据包的传输为传统IPsec传输列表添加了第三个选项：

1. Direct。目前，IKE协商通过UDP端口500开始。如果在发起方和响应方之间未检测到网络地址转换（Network Address Translation，NAT）设备，则后续IKE数据包将通过UDP端口500发送，并使用ESP发送IPsec数据包。
2. UDP封装[RFC3948]。如果在发起方和响应方之间检测到NAT，则后续IKE数据包将通过UDP端口4500发送，并在UDP有效负载开头处包含四个字节的零，并且ESP数据包将通过UDP端口4500发送出去。即使在路径上未检测到NAT，某些对等方也会默认使用UDP封装，因为某些中间设备不支持除TCP和UDP之外的IP协议。
3. TCP封装。如果其他两种方法不可用或不合适，则可以通过单个TCP连接将IKE协商数据包以及ESP数据包发送到对等方。
   由于使用TCP封装时的性能问题，IKE实现应首选直接使用ESP或UDP封装（第12节）。大多数实现应仅在已尝试通过UDP进行协商而未收到来自对等方的响应或已知网络不支持UDP的网络上使用TCP封装。
   1.1、之前的工作和动机
   将IKE连接封装在TCP流中是解决UDP数据包被网络中间件阻塞问题的常用方法。本文件的具体目标如下：

• 通过定义在TCP流中构建IKE和ESP消息的标准方法来促进互操作性。
• 与当前IKEv2标准兼容，无需修改或扩展。
• 默认情况下使用基于UDP的IKE，以避免始终依赖TCP或传输层安全性（Transport Layer Security，TLS）[RFC5246]的其他替代方案的开销。
  之前的一些替代方案包括：
  蜂窝网络接入互通无线LAN（Interworking Wireless LAN，IWLAN）使用IKEv2创建与蜂窝运营商网络的安全连接，以便通过Wi-Fi网络进行语音呼叫和访问其他网络服务。3GPP建议在TLS连接内发送IKEv2和ESP数据包，以便能够在限制性网络上建立连接。
  TCP上的ISAKMP已部署互联网安全关联和密钥管理协议（Internet Security Association and Key Management Protocol，ISAKMP）的各种非标准扩展，通过TCP或类似TCP的数据包发送IPsec流量。
  安全套接字层（Secure Sockets Layer，SSL）VPN许多专有VPN解决方案结合使用TLS和IPsec来提供可靠性。它们通常在TCP端口443上运行。
  TCP上的IKEv2如[IKE-over-TCP]中所述，TCP上的IKEv2用于避免UDP分片。
  1.2、术语和符号
  本文档区分了发起用于TCP封装的TCP连接的IKE对等体以及特定IKE消息的发起者和响应者的角色。在IKE交换过程中，IKE发起者和响应者的角色可能会交换给定的SA（与IKE SA重新生成密钥一样），而TCP连接的发起者仍然负责拆除TCP连接并在必要时重新建立它。因此，本文档将使用术语“TCP发起者”来指示发起TCP连接的IKE对等体。接收TCP连接的对等方将被称为“TCP响应方”。如果IKE SA被重新生成密钥一次或多次，则TCP发起者必须仍然是最初发起第一个IKE SA的对等体。
  本文档中的关键字“必须”、“不得”、“必需”、“应”、“不应”、“应该”、“不应该”、“推荐”、“不推荐”、“可以”和“可选”当且仅当它们出现在所有内容中时，应按照BCP 14[RFC2119][RFC8174]中的描述进行解释。
  2、配置
  使用TCP封装的主要原因之一是UDP流量可能在网络上被完全阻止。因此，在IKE交换中并未专门协商对TCP封装的支持。相反，必须在TCP发起方和TCP响应方上预先配置对TCP封装的支持。
  实现必须支持TCP端口4500上的TCP封装，该端口是为IPsec NAT穿越保留的。
  除了指示支持TCP封装的标志之外，每个对等点的配置还可以包括以下可选参数：
• 特定TCP响应程序侦听传入连接的备用TCP端口。请注意，TCP发起者可以从任何本地端口发起到TCP响应者的TCP连接。
• 在TCP之上使用的额外成帧协议，以进一步封装IKE和IPsec数据包流。详细讨论请参见附录A。
  由于与直接或UDP封装的SA（如第12节中所述）相比，IKE和IPsec数据包的TCP封装增加了开销，并且具有潜在的性能权衡，因此在可能的情况下，实现应该优先选择ESP直接或UDP封装的SA，而不是TCP封装的SA。
  3、TCP封装的报文头格式
  与UDP封装一样，TCP封装使用消息的前四个字节来区分IKE和ESP消息。TCP封装还添加了一个长度字段来定义流中消息的边界。消息长度在每条消息之前的16位字段中发送。如果消息的前32位为零（非ESP标记），则内容包含IKE消息。否则，内容包括ESP消息。TCP封装不支持身份验证报文头（Authentication Header，AH）消息。
  尽管TCP流可能能够发送非常长的消息，但实现应该将消息长度限制为典型的UDP数据报ESP有效负载长度。最大消息长度用作使用ESP加密的连接的有效MTU，因此最大消息长度会影响内部连接的特性，例如TCP最大分片大小（Maximum Segment Size，MSS）。
  请注意，这种封装方法也适用于将IKE和ESP消息放置在TCP之外的任何呈现流抽象的协议中。
  3.1、TCP封装的IKE报文头格式

图1
IKE报文头前面有一个按网络字节顺序排列的16位长度字段，用于指定TCP流中IKE消息（包括非ESP标记）的长度。与UDP端口4500上的IKE一样，在IKE报文头开始之前插入归零的32位非ESP标记，以便区分相同地址和端口之间的流量与ESP流量。

• Length：长度（2个八位字节，无符号整数）- IKE数据包的长度，包括长度字段和非ESP标记。
  3.2、TCP封装的ESP报文头格式

图2
ESP报文头前面有一个按网络字节顺序排列的16位长度字段，用于指定TCP流中ESP数据包的长度。
ESP报文头中的安全参数索引（Security Parameter Index，SPI）字段[RFC7296]不得为零值。

• Length：长度（2个八位字节，无符号整数）- ESP数据包的长度，包括长度字段。
  4、TCP封装的流前缀
  用于IKE和IPsec封装的每个字节流必须以固定的六个字节序列作为魔术值开始，其中包含字符“IKETCP”作为ASCII值。该值旨在识别和验证TCP连接是否用于本文档中定义的TCP封装，以避免与使用TCP端口4500的先前非标准协议发生冲突。该值仅由TCP发起者在任何IKE和ESP消息流开始时发送一次。
  如果在TCP内使用其他成帧协议来进一步封装或加密IKE和ESP消息流，则流前缀必须位于TCP发起者的IKE和ESP消息流的开头
  在添加的协议层内（附录A）。尽管某些成帧协议确实支持协商内部协议，但应始终使用流前缀，以便实现尽可能通用，并且不依赖于TCP之上的其他成帧协议。

图3
5、适用性
TCP封装仅在配置为与特定IKE对等体一起使用时才适用。如果响应方配置为使用TCP封装，则它必须侦听配置的端口，以防任何对等方发起新的IKE会话。发起者可以对与配置为支持TCP封装的对等方的任何IKE会话使用TCP封装，但建议发起者仅在UDP上的流量被阻止时才使用TCP封装。
由于TCP封装的支持是一项配置的属性，而不是协商的属性，因此建议如果有多个IKE端点代表单个对等方（例如通过完全限定域名连接时具有不同IP地址的多台计算机，或者使用IKE重定向的端点），则所有端点均同等地支持TCP封装。
如果TCP封装用于特定IKE SA，则该IKE SA及其子SA的所有消息都必须通过TCP连接发送，直到删除SA或使用IKEv2移动性和多宿主（MOBIKE）更改SA端点和/或封装协议。有关使用MOBIKE在封装模式之间转换的更多详细信息，请参阅第8节。
5.1、建议从UDP回退
由于UDP是IKE消息的首选传输方法，因此使用TCP封装的实现应该有一个算法，用于在确定UDP不可用后决定何时使用TCP。如果发起方实现事先不了解其所在的网络以及该网络上UDP的状态，则它应该始终首先尝试通过UDP协商IKE。IKEv2定义了如何将重传计时器与IKE消息一起使用，特别是IKE_SA_INIT消息[RFC7296]。通常这意味着实现将定义重传频率以及在将 IKE SA 标记为失败之前允许的最大重传次数。一旦达到UDP上的最大重传次数，或者稍微提前一点，实现就可以尝试通过TCP进行协商，以减少连接建立延迟。建议在回退到TCP之前至少重传一次通过UDP的初始消息，除非发起方事先知道网络可能会阻止UDP。
6、连接建立和拆除
当IKE Initiator使用TCP封装时，它将使用配置的TCP端口发起到Responder的TCP连接。在流上发送的第一个字节必须是流前缀值（第4节）。在此前缀之后，封装的IKE消息将协商IKE SA和初始子SA[RFC7296]。此后，封装的IKE（图1）和ESP（图2）消息都将通过TCP连接发送。TCP响应方必须等待流上接收到整个流前缀，然后再尝试解析任何IKE或ESP消息。流前缀仅发送一次，并且仅由TCP发起者发送。
为了关闭IKE会话，发起方或响应方应该使用DELETE有效负载优雅地拆除IKE SA。一旦SA被删除，如果TCP发起者不打算将该连接用于与TCP响应者的另一个IKE会话，则它应该关闭该TCP连接。如果连接处于空闲状态并且TCP响应者需要清理资源，则TCP响应者可以关闭TCP连接。
TCP连接上的意外FIN或TCP重置可能表示连接丢失、攻击或某些其他错误。如果未发送DELETE有效负载，双方都应在标准生存期或超时期限内维持其SA的状态。如果由于任何意外原因而断开TCP连接，则TCP发起者负责重新建立TCP连接。由于新的TCP连接可能由于NAT映射或本地端口分配更改而使用不同的端口，因此TCP响应方必须允许从新的源端口接收现有SA的数据包。
由于连接中断，对等方必须丢弃部分接收到的消息。
每当TCP发起者打开一个新的TCP连接用于现有IKE SA时，它必须在任何IKE或ESP消息之前首先发送流前缀。这遵循与初始TCP连接相同的行为。
如果使用TCP连接来恢复先前的IKE会话，则TCP响应程序可以使用来自封装的IKE消息的IKE SPI或来自封装的ESP消息的ESP SPI来识别该会话。如果先前已完全建立会话，则建议TCP发起方在支持MOBIKE的情况下发送UPDATE_SA_ADDRESSES消息，否则发送信息性消息（保持活动状态）。
TCP响应方不得在新传入连接上接受现有IKE会话的任何消息，除非该连接以流前缀开头。如果TCP发起者或TCP响应者检测到以有效流前缀启动的连接损坏，则它应该关闭TCP连接。如果有太多后续消息无法解析为有效的IKE消息或具有已知SPI的ESP消息，或者如果对具有已知SPI的ESP消息的身份验证检查失败，则可以确定连接已损坏。如果只有单个ESP消息具有未知的SPI，则实现不应断开连接，因为SPI数据库可能会暂时不同步。如果IKE消息中存在语法问题，则实现必须发送INVALID_SYNTAX通知负载并照常拆除IKE SA，而不是直接拆除TCP连接。
TCP发起者应该只为每个IKE SA打开一个TCP连接，通过该连接发送所有相应的IKE和ESP消息。这有助于确保为TCP连接分配的任何防火墙或NAT映射同样适用于与IKE SA关联的所有流量。
类似地，TCP响应者应该在任何给定时间仅通过一个TCP连接发送IKE SA及其子SA的数据包。它应该选择上次接收有效且可解密的IKE或ESP消息的TCP连接。为了被认为对于选择TCP连接有效，IKE消息必须成功解密和验证，而不是先前接收到的消息的重传，并且位于IKE消息ID的预期窗口内。同样，ESP消息必须通过身份验证检查并解密，并且不能是先前消息的重放。
由于TCP发起者可能会在TCP响应者不知情的情况下断开连接并重新建立新连接，因此TCP响应者应该接受在旧连接和新连接上接收IKE和ESP消息，直到TCP发起者关闭旧连接。TCP响应者可以关闭它认为空闲和无关的TCP连接（以前用于IKE和ESP消息的连接已被新连接替换）。
多个IKE SA不得共享单个TCP连接，除非其中一个是现有IKE SA的密钥更新，在这种情况下，同一TCP连接上将暂时有两个IKE SA。
7、与NAT检测有效负载的交互
通过UDP端口500进行协商时，IKE_SA_INIT数据包包含NAT_DETECTION_SOURCE_IP和NAT_DETECTION_DESTINATION_IP负载，以确定是否应使用IPsec数据包的UDP封装。这些有效负载包含[RFC7296]中定义的SPI、IP地址和端口的SHA-1摘要。在TCP连接上发送的IKE_SA_INIT数据包应包含这些有效负载，其内容与通过UDP发送时相同，并且在创建和检查SHA-1摘要时应使用适用的TCP端口。
如果由于SHA-1摘要与预期值不匹配而检测到NAT，则不应对后续IKE或ESP数据包的封装进行任何更改，因为TCP封装本质上支持NAT穿越。实现可以使用NAT存在的信息来影响保持活动定时器值。
如果检测到NAT，实现需要处理传输模式TCP和UDP数据包校验和修复，如[RFC3948]中为UDP封装定义的那样。
8、使用TCP封装的MOBIKE
当已协商MOBIKE[RFC4555]的IKE会话在网络之间转换时，转换的发起者可以在使用TCP封装、UDP封装或不封装之间切换。同时实现MOBIKE和TCP封装的实现必须支持在接口更改时动态启用和禁用TCP封装。
当启用MOBIKE的发起方更改网络时，应首先通过UDP发送UPDATE_SA_ADDRESSES通知，然后再尝试通过TCP。如果对通过UDP发送的UPDATE_SA_ADDRESSES通知有响应，则应直接通过IP或UDP端口4500（取决于是否检测到NAT）发送ESP数据包，无论先前网络上的连接是否使用TCP封装。同样，如果响应方仅通过TCP响应UPDATE_SA_ADDRESSES通知，则应通过TCP连接发送ESP数据包，无论先前网络上的连接是否未使用TCP封装。
9、将IKE消息分片与TCP封装结合使用
使用TCP封装时不需要IKE消息分片[RFC7383]，因为TCP流已经处理了跨数据包的内容分片。由于在这种情况下分片是多余的，因此实现可能会选择不协商IKE分片。即使分片经过协商，实现在通过TCP连接时也不应该发送分片，尽管它必须支持接收分片。
如果实现同时支持MOBIKE和IKE分片，则它应该在TCP封装会话上协商IKE分片，以防会话切换到另一个网络上的UDP封装。
10、保持活动和死亡对等点检测的注意事项
将IKE和IPsec封装在TCP连接内可能会影响实现中用于检测对等活动和维护中间设备端口映射的策略。应使用IKE信息包[RFC7296]检查对等体的活跃性。
一般来说，TCP端口映射由NAT维护的时间比UDP端口映射的时间长，因此在使用TCP封装时不应发送IPsec ESP NAT keep-alives[RFC3948]。任何使用TCP封装的实现都必须默默地丢弃传入的NAT保持活动数据包，并且不将它们视为错误。TCP封装的IPsec连接上的NAT保持活动数据包将作为ESP消息发送，其负载为1个八位字节，负载值为0xFF。
请注意，根据连接上TCP和TLS的配置，可以使用TCP keep-alives[RFC1122]和TLS keep-alives[RFC6520]。这些不得用作IKE对等体活跃度的指示。
11、中间设备注意事项
许多安全网络设备（例如防火墙或入侵防御系统、网络优化/加速设备和NAT设备）都会保留穿过它们的会话的状态。
这些设备通常跟踪传输层和/或应用层数据以丢弃本质上异常或恶意的流量。虽然其中许多设备更有可能传递TCP封装的流量（而不是UDP封装的流量），但有些设备可能仍会阻止或干扰TCP封装的IKE和IPsec流量。
监视传输层的网络设备将跟踪TCP会话的状态，例如TCP序列号。因此，IKE的TCP封装应使用标准TCP行为，以避免被中间设备丢弃。
12、性能考虑
IKE和IPsec数据包的TCP封装的几个方面可能会对隧道模式IPsec SA内的连接性能产生负面影响。实现应了解这些性能影响，并在确定何时使用TCP封装时将其考虑在内。只要有可能，实现应该优先使用直接ESP或UDP封装而不是TCP封装。
12.1、TCP-in-TCP
如果IKE对等体之间的外部连接通过TCP，则内部TCP连接可能会因在TCP内使用TCP而遭受负面影响。不鼓励在TCP内运行TCP，因为TCP算法通常假设它们在不可靠的数据报层上运行。
如果外部（隧道）TCP连接遇到数据包丢失，则任何内部TCP连接都会隐藏此丢失，因为外部连接将重新传输以解决丢失问题。由于外部TCP连接将按顺序传递内部消息，因此丢失数据包后的任何消息可能必须等待，直到丢失恢复。这意味着外部连接上的损耗将仅被解释为内部连接的延迟。内部流量的突发性可能会增加，因为大量内部数据包可能会同时通过隧道传送。内部TCP连接可能会将长时间的延迟解释为传输问题，触发重传超时，从而导致虚假重传。如果没有及时检测到重传是虚假的，则内部连接的发送速率可能会不必要地降低。
如果外部TCP连接重传数据包时存在较长的延迟，则内部TCP连接的往返时间估计将受到外部TCP连接的突发性的影响。这将使内部TCP流量的拥塞控制循环反应性降低，可能永久导致发送速率低于外部TCP允许的发送速率。
TCP-in-TCP还可能导致缓冲增加或缓冲区膨胀。当外部TCP连接的窗口大小减小并变得小于内部TCP连接的窗口大小时，可能会发生这种情况。这可能会导致数据包在外部TCP连接的发送缓冲区中备份。为了限制这种影响，外部TCP连接应该限制其发送缓冲区大小以及减少窗口大小的速率。
请注意，任何负面影响都将在经过外部TCP连接的所有流之间共享。对于任何使用隧道的延迟敏感或实时应用程序来说，这一点尤其值得关注。如果此类流量使用TCP封装的IPsec连接，建议尽可能限制共享隧道的内部连接数量。
12.2、为不可靠的协议增加可靠性
由于ESP是不可靠的协议，因此通过TCP连接传输ESP数据包将改变数据包的基本行为。一些更喜欢丢包而不是延迟的应用程序级协议（例如IP语音或其他实时协议）如果由于丢包而由TCP连接重新传输其数据包，则可能会受到负面影响。
12.3、服务质量标记
在用于封装的TCP连接上应谨慎使用服务质量（Quality-of-Service，QoS）标记，例如差分服务代码点（Differentiated Services Code Point，DSCP）和流量类别。各个数据包不应使用与连接的其余部分不同的标记，因为具有不同优先级的数据包可能会以不同的方式路由并导致连接中不必要的延迟。
12.4、最大分片尺寸
用于IKE封装的TCP连接应该协商其MSS，以避免不必要的数据包分片。
12.5、TCP中的隧道ECN
由于使用TCP封装时外部IP数据包和内部ESP/IP消息之间不存在一对一的关系，因此无法简单地映射显式拥塞通知（Explicit Congestion Notification，ECN）[RFC3168]的标记。然而，内部报文头上的任何ECN拥塞经历（Congestion Experienced，CE）标记都应通过隧道保留。
实现应该遵循[RFC6040]中描述的隧道入口的ECN兼容模式。在兼容模式下，外部隧道TCP连接将其数据包报文头标记为不支持ECN。如果在出口时，到达的外部报文头被标记为CE，则实现将丢弃内部数据包，因为没有明确的内部数据包报文头可将ECN标记转换到其上。
13、安全考虑
支持TCP封装的IKE响应程序可能容易受到TCP特有的新拒绝服务（Denial-of-Service，DoS）攻击，例如SYN洪泛攻击。TCP响应者应该意识到这个额外的攻击面。
TCP响应程序应小心确保（1）流前缀“IKETCP”唯一地将传入流标识为使用TCP封装协议的流，并且（2）它们不在同一侦听端口上运行任何其他协议（以避免潜在的冲突）。
攻击者可能能够通过发送虚假的TCP重置数据包来中断TCP连接。因此，实现应该确保IKE会话状态持续存在，即使底层TCP连接被断开。
如果使用MOBIKE，则适用于MOBIKE概述的所有安全注意事项[RFC4555]。
与MOBIKE类似，TCP封装需要TCP响应程序来处理由于网络或连接中断而导致的源地址和端口的更改。TCP响应程序使用通过新TCP连接成功传送有效IKE或ESP消息来确定将后续响应发送到何处。如果攻击者能够在通过TCP响应程序验证检查的新TCP连接上发送数据包，则它可以影响未来数据包将采用的路径。因此，TCP响应程序上的消息验证必须包括解密、身份验证和重放检查。
由于TCP提供可靠、按顺序的ESP消息传递，因此ESP抗重播窗口大小应设置为1。有关ESP抗重播窗口的完整描述，请参阅[RFC4303]。这增强了对重放攻击实施的保护。
14、IANA考虑因素
TCP端口4500已分配给IPsec用于NAT穿越。此端口应该用于TCP封装的IKE和ESP，如本文档中所述。
本文档更新了TCP端口4500的参考：

图4
15、参考文献
15.1、规范性参考文献
[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.
[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.
[RFC4303]Kent, S., “IP Encapsulating Security Payload (ESP)”, RFC 4303, DOI 10.17487/RFC4303, December 2005, 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.
[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.
[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.
15.2、参考资料
[IKE-over-TCP]Nir, Y., “A TCP transport for the Internet Key Exchange”, Work in Progress, draft-ietf-ipsecme-ike-tcp-01, December 2012.
[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.
[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.
[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.
[RFC4555]Eronen, P., “IKEv2 Mobility and Multihoming Protocol (MOBIKE)”, RFC 4555, DOI 10.17487/RFC4555, June 2006, 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.
[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.
[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.
附录A、使用带有TLS的TCP封装
本节提供有关如何使用TCP封装和TLS的建议。
当使用TCP封装时，实现可以选择在TCP连接上使用TLS[RFC5246]，以便能够遍历中间设备，否则可能会阻塞流量。
如果将Web代理应用于用于TCP连接的端口并且正在使用TLS，则TCP发起者可以发送HTTP CONNECT消息以通过代理建立SA[RFC2817]。
TLS的使用应该可以在对等点上进行配置，并且可以在使用TCP封装时用作默认设置，也可以在基本TCP封装失败时用作后备。TCP响应者可能期望直接从TCP连接读取封装的IKE和ESP数据包，或者可能期望从TLS数据包流中读取它们。TCP发起方应预先配置为在与TCP响应方上的给定端口通信时使用或不使用TLS。
当由于连接断开而重新建立新的TCP连接时，必须重新协商TLS。在这种情况下，建议使用TLS会话恢复来提高效率。
IKE会话的安全性完全源自IKE协商和密钥建立，而不是源自TLS会话（在本上下文中，TLS会话仅用于封装目的）；因此，当在TCP连接上使用TLS时，出于性能原因，TCP发起方和TCP响应方都应该允许选择NULL密码。
实现应该意识到，TLS的使用引入了另一层开销，需要更多字节来传输给定的IKE和IPsec数据包。因此，在不需要TLS穿越中间设备的情况下，应首选直接ESP、UDP封装或不带TLS的TCP封装。
附录B、TCP封装与TLS的交换示例
B.1、建立IKE会话

图5

1. 客户端在端口4500或服务器正在侦听的备用预配置端口上与服务器建立TCP连接。
2. 如果配置为使用TLS，客户端将发起TLS握手。在TLS握手期间，服务器不应请求客户端的证书，因为身份验证是作为IKE协商的一部分进行处理的。
3. 客户端发送TCP封装的IKE（第4节）流量的流前缀，以表示IKE协商开始。
4. 客户端与服务器建立IKE连接。此示例显示基于EAP的身份验证，但可以使用任何身份验证类型。
   B.2、删除IKE会话

图6

1. 客户端和服务器交换信息消息以通知IKE SA删除。
2. 客户端和服务器使用TLS CLOSE_NOTIFY协商TLS会话删除。
3. TCP连接断开。
   IKE SA的删除应导致底层TLS和TCP状态的处置。
   B.3、重新建立IKE会话

图7

1. 如果之前的TCP连接断开（例如，由于TCP重置），则客户端负责重新发起TCP连接。TCP发起者的地址和端口（IP_I和Port_I）可能与先前连接的地址和端口不同。
2. 在ClientHello TLS消息中，客户端应该发送在先前TLS握手中收到的会话ID（如果可用）。服务器根据会话ID匹配来执行简短握手或完整握手。
3. TCP和TLS完成后，客户端发送TCP封装的IKE流量的流前缀（第4节）。
4. IKE和ESP数据包流可以恢复。如果正在使用MOBIKE，发起方应该发送一条UPDATE_SA_ADDRESSES消息。
   B.4、在UDP和TCP封装之间使用MOBIKE

图8

1. 在IKE_SA_INIT交换期间，客户端和服务器交换MOBIKE_SUPPORTED通知有效负载以指示对MOBIKE的支持。
2. 客户端更改其网络连接点并接收新的IP地址。客户端尝试使用UPDATE_SA_ADDRESSES通知有效负载重新建立IKE会话，但服务器未响应，因为网络阻止UDP流量。
3. 客户端建立到服务器的TCP连接以使用TCP封装。
4. 客户端发起与服务器的TLS握手。
5. 客户端发送TCP封装的IKE流量的流前缀（第4节）。
6. 客户端在TCP封装的连接上发送UPDATE_SA_ADDRESSES通知负载。请注意，此IKE消息与步骤2中通过UDP发送的消息相同；它应该具有相同的消息ID和内容。
7. IKE和ESP数据包流可以恢复。
   致谢
   作者谨此感谢Stuart Cheshire、Delziel Fernandes、Yoav Nir、Christoph Paasch、Yaron Sheffer、David Schinazi、Graham Bartlett、Byju Pularikkal、March Wu、Kingwel Xie、Valery Smyslov、Jun Hu和Tero Kivinen的意见和建议。特别感谢Eric Kinnear的实施工作。