8. Backward-Compatibility Considerations (向后兼容性考虑)

8. Backward-Compatibility Considerations (向后兼容性考虑)

ESP 中没有版本号, 也没有机制使 IPsec 对等方能够发现或协商各自正在使用或应该使用的 ESP 版本。本节讨论由此产生的向后兼容性问题。

首先, 如果不使用 ESP v3 中可用的任何新功能, 那么 ESP v2 和 v3 中 ESP 数据包的格式是相同的。如果采用组合模式加密算法 (仅在 ESP v3 中支持的功能), 那么生成的数据包格式可能与 ESP v2 规范不同。然而, 仅实现 ESP v2 的对等方永远不会协商这样的算法, 因为它们被定义为仅在 ESP v3 上下文中使用。

扩展序列号 (ESN) 协商由 IKE v2 支持, 并且已通过 IKE v1 解释域 (DOI) 的 ESN 附录针对 IKE v1 进行了处理。

在新的 ESP (v3) 中, 我们做出两项规定以更好地支持流量流保密性 (TFC):

• IP 数据包结束后的任意填充
• 使用 Next Header = 59 的丢弃约定

第一个功能不应该给接收方造成问题, 因为 IP 总长度字段指示 IP 数据包的结束位置。因此, 在 ESP 处理之后, IP 数据包处理的某个时刻应该删除数据包结束后的任何 TFC 填充字节, 即使 IPsec 软件不删除此类填充。因此, 这是一个 ESP v3 功能, 发送方可以使用它, 无论接收方实现的是 ESP v2 还是 ESP v3。

第二个功能允许发送方在隧道内发送一个任意字节串的有效载荷 (不一定构成格式良好的 IP 数据包), 用于 TFC 目的。当 ESP 数据包中的 Next Header 字段包含值 "59" 时, ESP v2 接收方会做什么是一个开放性问题。当它发现格式不正确的 IP 头时, 它可能会丢弃数据包并记录此事件, 但它肯定不应该崩溃, 因为这种行为会构成相对于从经过身份验证的对等方接收的流量的 DoS 漏洞。因此, 此功能是一种优化, ESP v3 发送方可以使用它, 无论接收方实现的是 ESP v2 还是 ESP v3。