3.3. Outbound Packet Processing (出站数据包处理)

在传输模式下, 发送方将下一层协议信息封装在 ESP 头部和 ESP 尾部字段之间, 并保留指定的 IP 头部 (以及在 IPv6 上下文中的任何 IP 扩展头部)。在隧道模式下, 外部和内部 IP 头部/扩展可以以多种方式相互关联。封装过程中外部 IP 头部/扩展的构造在安全架构文档中描述。

3.3.1. Security Association Lookup (安全关联查找)

只有在 IPsec 实现确定数据包与需要 ESP 处理的 SA 关联后, ESP 才会应用于出站数据包。确定对出站流量应用何种 IPsec 处理 (如果有) 的过程在安全架构文档中描述。

3.3.2. Packet Encryption and Integrity Check Value (ICV) Calculation (数据包加密和完整性检查值计算)

在本节中, 由于格式化的影响, 我们总是以应用加密的方式来讨论。这是在理解通过使用 NULL 加密算法 (RFC 2410) 提供 "无机密性" 的情况下完成的。有几种算法选项。

3.3.2.1. Separate Confidentiality and Integrity Algorithms (独立的机密性和完整性算法)

如果使用独立的机密性和完整性算法, 发送方按如下方式进行:

封装 (到 ESP Payload 字段中):
- 对于传输模式 -- 仅原始的下一层协议信息。
- 对于隧道模式 -- 整个原始 IP 数据报。
添加任何必要的填充 -- 可选的 TFC 填充和 (加密) 填充
使用为 SA 指定的密钥, 加密算法和算法模式以及任何所需的密码同步数据对结果进行加密。
- 如果指示了显式密码同步数据 (例如 IV), 则根据算法规范将其输入到加密算法并放置在 Payload 字段中。
- 如果使用隐式密码同步数据, 则根据算法规范构造并输入到加密算法。
- 如果选择了完整性, 则先执行加密, 然后再应用完整性算法, 并且加密不包含 ICV 字段。这种处理顺序有助于接收方在解密数据包之前快速检测和拒绝重放或伪造的数据包, 从而可能减少拒绝服务 (DoS) 攻击的影响。它还允许在接收方并行处理数据包的可能性, 即解密可以与完整性检查并行进行。请注意, 由于 ICV 不受加密保护, 因此必须使用密钥完整性算法来计算 ICV。
对 ESP 数据包减去 ICV 字段进行 ICV 计算。因此, ICV 计算包括 SPI, 序列号, 有效载荷数据, 填充 (如果存在), 填充长度和下一个头部。(请注意, 最后 4 个字段将是密文形式, 因为加密首先执行。) 如果为 SA 启用了 ESN 选项, 则序列号的高 32 位在此计算目的下附加在下一个头部字段之后, 但不进行传输。

对于某些完整性算法, 执行 ICV 计算的字节串必须是算法指定的块大小的倍数。如果 ESP 数据包的长度 (如上所述) 不符合算法的块大小要求, 则必须在 ESP 数据包的末尾附加隐式填充。(如果选择了 ESN, 则在下一个头部字段之后或序列号的高 32 位之后添加此填充。) 块大小 (以及填充的长度) 由完整性算法规范指定。此填充不随数据包一起传输。必须查阅定义完整性算法的文档以确定是否需要如上所述的隐式填充。如果文档未指定对此问题的答案, 则默认假设需要隐式填充 (根据需要使数据包长度与算法的块大小匹配。) 如果需要填充字节但算法未指定填充内容, 则填充八位字节必须具有零值。

3.3.2.2. Combined Confidentiality and Integrity Algorithms (组合的机密性和完整性算法)

如果使用组合的机密性/完整性算法, 发送方按如下方式进行:

封装到 ESP Payload Data 字段中:
- 对于传输模式 -- 仅原始的下一层协议信息。
- 对于隧道模式 -- 整个原始 IP 数据报。
添加任何必要的填充 -- 包括可选的 TFC 填充和 (加密) 填充。
使用为 SA 指定的密钥和组合模式算法以及任何所需的密码同步数据对结果进行加密和完整性保护。
- 如果指示了显式密码同步数据 (例如 IV), 则根据算法规范将其输入到组合模式算法并放置在 Payload 字段中。
- 如果使用隐式密码同步数据, 则根据算法规范构造并输入到加密算法。
- 序列号 (或扩展序列号, 视情况而定) 和 SPI 是算法的输入, 因为它们必须包含在完整性检查计算中。这些值包含在此计算中的方式是所采用的组合模式算法的函数, 因此在本标准中未指定。
- 当使用组合模式算法时, (显式) ICV 字段可以是 ESP 数据包格式的一部分。如果不使用, 则通常会有一个类似的字段作为密文有效载荷的一部分。任何完整性字段的位置, 以及在完整性计算中包含序列号和 SPI 的方式, 必须在定义组合模式算法与 ESP 一起使用的 RFC 中定义。

3.3.3. Sequence Number Generation (序列号生成)

当建立 SA 时, 发送方的计数器初始化为 0。发送方为该 SA 递增序列号 (或 ESN) 计数器, 并将值的低 32 位插入序列号字段。因此, 使用给定 SA 发送的第一个数据包将包含序列号 1。

如果启用了防重放 (默认), 则发送方在将新值插入序列号字段之前检查以确保计数器未循环。换句话说, 如果这样做会导致序列号循环, 则发送方绝对不能在 SA 上发送数据包。尝试传输会导致序列号溢出的数据包是一个可审计事件。此事件的审计日志条目应该包括 SPI 值, 当前日期/时间, 源地址, 目标地址以及 (在 IPv6 中) 明文流 ID。

发送方假定防重放默认启用, 除非接收方另有通知 (参见第 3.4.3 节)。因此, ESP 实现的典型行为要求发送方在序列号 (或 ESN) 循环时或预期此值循环时建立新的 SA。

如果用于计算 ICV 的密钥是手动分发的, 则兼容的实现不应该提供防重放服务。如果用户选择将防重放与手动密钥的 SA 结合使用, 则在更换密钥之前, 必须在本地重启等情况下正确维护发送方的序列号计数器。(参见第 5 节。)

如果禁用防重放 (如上所述), 则发送方不需要监控或重置计数器。但是, 发送方仍然递增计数器, 当它达到最大值时, 计数器回滚到零。(除非在发送方和接收方之间协商了本标准范围之外的防重放机制, 否则建议对多发送方, 多播 SA 采用此行为。)

如果选择了 ESN (参见附录), 则仅在序列号字段中传输序列号的低 32 位, 尽管发送方和接收方都维护完整的 64 位 ESN 计数器。高 32 位以算法/模式特定的方式包含在完整性检查中, 例如当使用单独的完整性算法时, 高 32 位可以在下一个头部字段之后附加。

注意: 如果接收方选择不为 SA 启用防重放, 则接收方不应该在 SA 管理协议中协商 ESN。使用 ESN 会使接收方需要管理防重放窗口 (以确定 ESN 高位的正确值, 该值用于 ICV 计算), 这通常与为 SA 禁用防重放的概念相反。

3.3.4. Fragmentation (分片)

如有必要, 在 IPsec 实现中的 ESP 处理之后执行分片。因此, 传输模式 ESP 仅应用于完整的 IP 数据报 (而不是 IP 分片)。已应用 ESP 的 IP 数据包本身可能会被途中的路由器分片, 并且在接收方的 ESP 处理之前必须重新组装这些分片。在隧道模式下, ESP 应用于 IP 数据包, 该数据包可能是 IP 数据报的分片。例如, 安全网关或 "bump-in-the-stack" 或 "bump-in-the-wire" IPsec 实现 (如安全架构文档中定义) 可能会对此类分片应用隧道模式 ESP。

注意: 对于传输模式 -- 如第 3.1.1 节末尾所述, bump-in-the-stack 和 bump-in-the-wire 实现可能必须首先重新组装由本地 IP 层分片的数据包, 然后应用 IPsec, 然后对生成的数据包进行分片。

注意: 对于 IPv6 -- 对于 bump-in-the-stack 和 bump-in-the-wire 实现, 将需要检查所有扩展头部以确定是否存在分片头部, 从而确定数据包在 IPsec 处理之前需要重新组装。

无论是由 IPsec 实现还是由 IPsec 对等方之间路径上的路由器执行分片, 都会显著降低性能。此外, ESP 接收方接受分片以进行重组的要求会产生拒绝服务漏洞。因此, ESP 实现可以选择不支持分片, 并可以使用 DF 位标记传输的数据包, 以促进路径 MTU (PMTU) 发现。在任何情况下, ESP 实现必须支持生成 ICMP PMTU 消息 (或本地主机实现的等效内部信令), 以最小化分片的可能性。MTU 管理所需的支持细节包含在安全架构文档中。