RFC3948：UDP Encapsulation of IPsec ESP Packets，January 2005
本备忘录的状态
本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（Internet Official Protocol Standards，STD 1）。本备忘录的分发不受限制。
版权声明
版权所有 (C) 互联网协会 (2005)。
梗概
该协议规范定义了在 UDP 数据包内封装和解封装 IP 封装安全载荷 (Encapsulating Security Payload，ESP) 数据包以遍历网络地址转换器的方法。本文档中定义的 ESP 封装可用于 IPv4 和 IPv6 场景。无论何时协商，都将封装与互联网密钥交换 (Internet Key Exchange，IKE) 一起使用。
1、 简介
该协议规范定义了在 UDP 数据包中封装和解封装 ESP 数据包以穿越网络地址转换器 (Network Address Translators，NAT) 的方法（参见 [RFC3715]，第 2.2 节，案例 i）。UDP 端口号与 IKE 流量使用的端口号相同，如 [RFC3947] 中所定义。
选择共享 IKE 和 UDP 封装的 ESP 流量的端口号是因为它提供了更好的扩展性（NAT 中只有一个 NAT 映射；无需发送单独的 IKE keepalive）、更容易配置（仅在防火墙中配置一个端口），更容易实现。
客户端的需求应该决定支持传输模式还是隧道模式（参见 [RFC3715]，第 3 节，“远程办公场景”）。L2TP/IPsec 客户端必须支持 [RFC3193] 中定义的模式。IPsec 隧道模式客户端必须支持隧道模式。
支持此协议规范的 IKE 实现不得对 ESP 数据包使用 ESP SPI 字段零。这样可以确保 IKE 数据包和 ESP 数据包可以相互区分。
如本文档中所定义，ESP 数据包的 UDP 封装是根据 IPv4 报文头编写的。IPv6 报文头不能用作外部报文头和/或内部报文头没有技术原因。
由于 IPsec AH 中对外部 IP 地址的保护本质上与 NAT 不兼容，因此 IPsec AH 被排除在本协议规范的范围之外。该协议还假定 IKE（IKEv1 [RFC2401] 或 IKEv2 [IKEv2]）用于协商 IPsec SA。不支持手动键控。
本文档中的关键词“必须”、“不得”、“需要”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”是解释为 [RFC2119] 中的描述。
2、 数据包格式
2.1、 UDP 封装的 ESP 报文头格式
UDP 报文头是标准的 [RFC0768] 报文头，其中
* 源端口和目标端口必须与 IKE 流量使用的相同，
* IPv4 UDP 校验和应该作为零值传输，并且
* 接收器不得依赖于 UDP 校验和为零值。
ESP 头中的 SPI 字段不得为零值。
2.2、 端口 4500 的 IKE 报文头格式
UDP 报文头是标准的 [RFC0768] 报文头，并按照 [RFC3947] 中的定义使用。本文档未对 IKE 数据包的校验和处理设置任何新要求。
非 ESP 标记是与 ESP 数据包的 SPI 字段对齐的 4 个零值字节。
2.3、 NAT-Keepalive 数据包格式
UDP 报文头是标准的 [RFC0768] 报文头，其中
* 源端口和目标端口必须与第 2.1 节的 UDP-ESP 封装使用的相同，
* IPv4 UDP 校验和应该作为零值传输，并且
* 接收器不得依赖于 UDP 校验和为零值。
发送方必须使用值为 0xFF 的一个八位字节长的有效载荷。接收方应该忽略接收到的 NAT-keepalive 数据包。
3、 封装和解封装过程
3.1、 辅助程序
3.1.1、 隧道模式解封装 NAT 程序
当使用隧道模式传输数据包时（参见 [RFC3715]，第 3 节，标准“模式支持”和“电信场景”），内部 IP 报文头可能包含不适合当前网络的地址。此过程定义了如何将这些地址转换为适合当前网络的地址。
根据本地策略，必须执行以下操作之一：
1. 如果策略中为对端封装的报文定义了有效的源IP地址空间，则根据策略检查内部报文的源IP地址是否有效。
2. 如果已经为远程对端分配了地址，则检查内部数据包中使用的源IP地址是否为分配的IP地址。
3. 对数据包进行 NAT，使其适合在本地网络中传输。
3.1.2、 传输模式解封装 NAT 程序
当使用传输模式传输数据包时，由于传输过程中 IP 报文头部分的变化，包含的 TCP 或 UDP 报文头将具有不正确的校验和。此过程定义了如何修复这些校验和（参见 [RFC3715]，第 2.1 节，情况 b）。
根据本地策略，必须执行以下操作之一：
1、如果ESP头后面的协议头是TCP/UDP头，并且根据[RFC3947]已经收到对端真实的源IP地址和目的IP地址，增量重新计算TCP/UDP校验和：
* 从校验和中减去接收到的数据包中的 IP 源地址。
* 将通过 IKE 收到的真实 IP 源地址添加到校验和（从 NAT-OA 获得）
* 从校验和中减去接收到的数据包中的 IP 目的地址。
* 将通过 IKE 接收到的真实 IP 目标地址添加到校验和（从 NAT-OA 获得）。
注意：如果给定地址（例如，源地址）的接收地址和实际地址相同，则操作取消并且不需要执行。
2. 如果ESP头之后的协议头是TCP/UDP头，则重新计算TCP/UDP头中的校验和字段。
3. 如果 ESP 头之后的协议头是 UDP 头，则将 UDP 头中的校验和字段设置为零。如果 ESP 报文头之后的协议是 TCP 报文头，并且如果有一个选项可以向堆栈标记不需要计算 TCP 校验和，则可以使用该标志。这应该只在传输模式下进行，并且数据包是完整性保护的。必须验证隧道模式 TCP 校验和。（这并不违反 [RFC1122] 中第 4.2.2.7 节的精神，因为发送方正在生成校验和并由接收方验证。该校验和是 IPsec 对数据包执行的完整性。）
此外，一个实现可以修复任何被 NAT 破坏的包含的协议（参见 [RFC3715]，第 2.1 节，案例 g）。
3.2、 传输模式ESP封装
1. 采用普通ESP封装方法。
2. 在所示位置插入格式正确的 UDP 报头。
3. 编辑 IP 报文头中的总长度、协议和报文头校验和（对于 IPv4）字段以匹配生成的 IP 数据包。
3.3、 传输模式 ESP 解封装
1. UDP 报头从数据包中删除。
2. 编辑新 IP 报头中的总长度、协议和报头校验和（对于 IPv4）字段以匹配生成的 IP 数据包。
3. 使用普通的ESP解封装程序。
4. 使用传输模式解封装 NAT 过程。
3.4、 隧道模式ESP封装
1. 采用普通ESP封装方法。
2. 在所示位置插入
格式正确的 UDP 报头。
3. 编辑新 IP 报头中的总长度、协议和报头校验和（对于 IPv4）字段以匹配生成的 IP 数据包。
3.5、 隧道模式 ESP 解封装
1. UDP 报头从数据包中删除。
2. 编辑新 IP 报头中的总长度、协议和报头校验和（对于 IPv4）字段以匹配生成的 IP 数据包。
3. 使用普通的ESP解封装程序。
4. 使用隧道模式解封装NAT程序。
4、 NAT Keepalive程序
发送 NAT-keepalive 数据包的唯一目的是在对等体之间的连接期间保持 NAT 映射处于活动状态（参见 [RFC3715]，第 2.2 节，案例 j）。NAT-keepalive 数据包的接收不得用于检测连接是否有效。
如果对等体之间存在一个或多个阶段 I 或阶段 II SA，或者如果此类 SA 最多在 N 分钟之前存在，则对等体可以发送 NAT 保持连接数据包。N 是本地可配置参数，默认值为 5 分钟。
如果根据 [RFC3947] 检测到需要，并且在 M 秒内没有其他数据包发送到对等体，则对等体应该发送 NAT-keepalive 数据包。M 是本地可配置参数，默认值为 20 秒。
5、 安全考虑
5.1、 隧道模式冲突
实施者被警告说，远程对等体可能会协商在 SGW（security gatewa，安全网关）中重叠的条目，这是一个影响隧道模式的问题（参见 [RFC3715]，第 2.1 节，案例 e）。
因为 SGW 现在会看到两个可能的 SA，它们通向 10.1.2.3，所以它可能会混淆将来自 Suzy 的服务器的数据包发送到哪里。实施者必须设计出防止这种情况发生的方法。
建议 SGW 为 Ari 和 Bob 的笔记本电脑分配本地唯一的 IP 地址（通过使用 IPsec 上的 DHCP 等协议）或使用 NAT 将 Ari 和 Bob 的笔记本电脑源 IP 地址更改为这些本地唯一地址，然后再将数据包转发到 Suzy 的服务器。这涵盖了 [RFC3715] 中第 3 节的“Scaling”标准。
请参阅附录 A。
5.2、 传输方式冲突
另一个类似的问题可能发生在传输模式中，2 个客户端 Ari 和 Bob 在同一个 NAT 后面安全地与同一个服务器通信（参见 [RFC3715]，第 2.1 节，案例 e）。
Cliff 想与同一台服务器畅所欲言。
现在，服务器上的传输 SA 将如下所示：
到 Ari：服务器到 NAT，，UDP encap <4500，Y>
给 Bob：服务器到 NAT，，UDP encap <4500，Z>
Cliff 的流量畅通无阻，因此没有 SA。
<traffic desc> 是协议和端口信息。UDP 封装端口是在 2.1 节的 UDP 封装的 ESP 格式中使用的端口。Y、Z 是 NAT 在 IKE 协商时分配的动态端口。因此，来自 Ari 笔记本电脑的 IKE 流量通过 UDP <4500,4500> 流出。它以 UDP 的形式到达服务器，其中 Y 是动态分配的端口。
如果 与 重叠，那么简单的过滤器查找可能不足以确定必须使用哪个 SA 来发送流量。实现必须处理这种情况，要么通过禁止冲突连接，要么通过其他方式。
现在假设 Cliff 想要以明文方式连接到服务器。这将很难配置，因为服务器已经有一个策略（从服务器到 NAT 的外部地址）来保护 。对于完全不重叠的流量描述，这是可能的。
示例服务器策略可能如下：
到 Ari：服务器到 NAT，所有 UDP，加密
到 Bob：服务器到 NAT，所有 TCP，加密
到 Cliff：服务器到 NAT，所有 ICMP，明文
请注意，此策略还允许 Ari 和 Bob 向服务器发送明文 ICMP。
服务器将 NAT 后面的所有客户端视为相同的 IP 地址，因此原则上不可能为相同的流量描述符设置不同的策略。
服务器上的一个有问题的配置示例如下：
服务器到 NAT、TCP、加密（适用于 Ari 和 Bob）
服务器到 NAT、TCP、铭文（用于 Cliff）
服务器无法执行他的策略，因为行为不端的 Bob 可能会明文发送流量。这与 Cliff 以明文方式发送流量时无法区分。因此，不可能保证来自 NAT 后面的某些客户端的安全性，同时允许来自同一 NAT 后面的不同客户端的明文。但是，如果服务器的安全策略允许这样做，则它可以尽最大努力进行加密：如果来自 NAT 后面的客户端启动安全性，他的连接将受到保护。如果他发送明文，服务器仍将接受该明文。
为了安全保证，服务器上不得允许上述有问题的场景。为了尽力而为安全，可以使用这种情况。
请参阅附录 A。
6、 IAB 考虑
UNSAF [RFC3424] 问题由 IPsec-NAT 兼容性要求文档 [RFC3715] 解决。
7、 致谢
感谢 Tero Kivinen 和 William Dixon，他们为本文档做出了积极贡献。
感谢 Joern Sierwald、Tamir Zegman、Tatu Ylonen 和 Santeri Paavolainen，他们为有关 NAT 穿越的早期文档做出了贡献。
8、 参考文献8.1、 规范参考
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC3947] Kivinen, T., "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
8.2、 参考资料
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001. [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004. [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Work in Progress, October 2004.
附录A、 潜在NAT多客户端解决方案的说明
本附录阐明了同一 NAT 后面的多个客户端同时连接到同一目标 IP 地址的问题的潜在解决方案。
5.1 和 5.2 节说你必须避免这个问题。由于这不是有线协议的问题，而是本地实现的问题，因此这些机制不属于协议规范本身。它们在本附录中列出。
选择一个选项可能取决于一个人使用/支持 IPsec NAT-T 的场景。此列表并非详尽无遗，因此可能存在其他解决方案。我们首先描述解决所有上层协议问题的通用选择。
ESP 传输模式的通用选择：
Tr1) 在 IPsec 解封装之上实现内置的 NAT（network address translatio，网络地址转换）。
Tr2) 在 IPsec 解封装之上实现内置的 NAPT（network address port translatio，网络地址端口转换）。
Tr3) 一旦检测到 NAT，发起方可以决定不请求传输模式，而是可以请求隧道模式 SA。这可能是响应方拒绝传输模式后的重试，或者发起方可能会选择最初提出隧道 SA。这并不比知道是否提出没有 NAT 的传输模式或隧道模式更困难。如果由于某种原因，响应者喜欢或需要隧道模式用于 NAT 穿越，它必须拒绝传输模式的快速模式 SA 提议。
ESP 隧道模式的通用选择：
Tn1) 与 Tr1 相同。
Tn2) 与 Tr2 相同。
Tn3) 如果发起方可以通过其隧道 SA 分配一个地址，而响应方使用 DHCP，则此选项是可能的。发起者最初可以通过 DHCP-IPsec 方法请求内部地址，而不管它是否知道它在 NAT 之后。在响应者的快速模式SA传输模式提议失败后，它可以重新发起DHCP隧道SA的IKE快速模式协商。这发生在发送 NAT-OA 载荷时，或者因为它从 NAT-D 发现发起方位于 NAT 之后，并且其本地配置/策略仅在通过 DHCP-IPsec 分配地址时才接受 NAT 连接。
还有一些实现选择提供有限的互操作性。如果选择了这些选项，实施者应该指定哪些应用程序或协议应该工作。请注意，如下所述，Tr4 和 Tn4 都不能用于 TCP 流量。
ESP 传输模式的有限互操作性选择：
Tr4) 实现对入站和出站 IPsec SA 的上层协议感知，使其不使用源 IP 和源端口作为会话标识符（例如，映射到 IPsec SA 对的 L2TP 会话 ID使用 UDP 源端口或源 IP 地址以获得对等唯一性）。
Tr5) 实现与 IKE 发起的应用集成，以便在 IKE 快速模式 SA 提议被响应方拒绝时重新绑定到不同的源端口；然后它可以重新提出新的 QM 选择器。
ESP 隧道模式的有限互操作性选择：
Tn4) 与 Tr4 相同。
完整的版权声明
版权所有 (C) 互联网协会 (2005)。
本文档受 BCP 78 中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
本文档和其中包含的信息按“原样”提供，贡献者、他/她所代表或赞助的组织（如果有）、互联网社会和互联网工程特别工作组不作任何明示或保证暗示，包括但不限于任何保证，即使用此处的信息不会侵犯任何权利或任何暗示的适销性或特定用途适用性保证。
知识产权
对于可能声称与本文档中描述的技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或者此类权利下的任何许可可能会或可能不会的程度，IETF 不采取任何立场能得到的;也不代表它已作出任何独立努力来确定任何此类权利。有关 IETF 文件中权利的 IETF 程序的信息可以在 BCP 78 和 BCP 79 中找到。
可以获得向 IETF 秘书处披露的知识产权副本和任何许可保证，或试图获得通用许可或本规范的实施者或用户使用此类专有权利的许可的结果来自 IETF 在线 IPR 存储库，网址为 http://www.ietf.org/ipr。
IETF 邀请任何相关方提请其注意任何版权、专利或专利申请，或可能涵盖实施本标准可能需要的技术的其他专有权利。请将信息发送至 IETF ietf-ipr@ietf.org。
致谢
RFC 编辑器功能的资金目前由互联网协会提供。
