跳到主要内容

3.4. Inbound Packet Processing (入站数据包处理)

3.4. Inbound Packet Processing (入站数据包处理)​

3.4.1. Reassembly (重组)​

如果需要, 在 ESP 处理之前执行重组。如果提供给 ESP 处理的数据包看起来是 IP 分片, 即 OFFSET 字段非零或 MORE FRAGMENTS 标志已设置, 则接收方必须 (MUST) 丢弃该数据包; 这是一个可审计事件。此事件的审计日志条目应该 (SHOULD) 包括 SPI 值, 接收日期/时间, Source Address (源地址), Destination Address (目的地址), Sequence Number (序列号) 以及 (在 IPv6 中) Flow ID (流 ID)。

注意: 对于数据包重组, 当前的 IPv4 规范不要求 (does NOT require) 将 OFFSET 字段清零或清除 MORE FRAGMENTS 标志。为了使重组的数据包能够被 IPsec 处理 (而不是作为明显的分片被丢弃), IP 代码必须 (MUST) 在重组数据包后执行这两项操作。

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

在接收到包含 ESP 头部的数据包时, 接收方通过在 SAD 中查找来确定适当的 (单向) SA。对于单播 SA, 此确定基于 SPI 或 SPI 加协议字段, 如第 2.1 节所述。如果实现支持多播流量, 则查找中还使用目的地址 (除了 SPI 之外), 并且还可以使用源地址, 如第 2.1 节所述。(此过程在 Security Architecture 文档中有更详细的描述。) SA 的 SAD 条目还指示是否将检查 Sequence Number 字段, 该 SA 是否使用 32 位或 64 位序列号, 以及 (显式) ICV 字段是否应该存在 (如果是, 其大小)。此外, SAD 条目将指定用于解密和 ICV 计算 (如果适用) 的算法和密钥。

如果该数据包不存在有效的 Security Association, 则接收方必须 (MUST) 丢弃该数据包; 这是一个可审计事件。此事件的审计日志条目应该 (SHOULD) 包括 SPI 值, 接收日期/时间, Source Address (源地址), Destination Address (目的地址), Sequence Number (序列号) 以及 (在 IPv6 中) 明文 Flow ID (流 ID)。

(请注意, SA 管理流量, 例如 IKE 数据包, 不需要基于 SPI 进行处理, 即可以例如基于 Next Protocol 和 Port 字段单独解复用此流量。)

3.4.3. Sequence Number Verification (序列号验证)​

所有 ESP 实现必须 (MUST) 支持防重放服务, 尽管接收方可以在每个 SA 的基础上启用或禁用其使用。除非还为 SA 启用了 ESP 完整性服务, 否则绝对不能 (MUST NOT) 启用此服务, 因为否则 Sequence Number 字段没有得到完整性保护。防重放适用于单播以及多播 SA。但是, 本标准未指定为多发送方 SA (单播或多播) 提供防重放的机制。在没有协商 (或手动配置) 此类 SA 的防重放机制的情况下, 建议通过协商或手动配置禁用发送方和接收方对该 SA 序列号的检查, 如下所述。

如果接收方未为 SA 启用防重放, 则不对 Sequence Number 执行入站检查。然而, 从发送方的角度来看, 默认假定接收方启用了防重放。为了避免发送方执行不必要的序列号监控和 SA 设置 (参见第 3.3.3 节), 如果使用了 SA 建立协议, 则如果接收方不会提供防重放保护, 则接收方应该 (SHOULD) 在 SA 建立期间通知发送方。

如果接收方为此 SA 启用了防重放服务, 则在建立 SA 时, 该 SA 的接收数据包计数器必须 (MUST) 初始化为零。对于每个接收的数据包, 接收方必须 (MUST) 验证该数据包包含的 Sequence Number 不与此 SA 生命周期内接收的任何其他数据包的 Sequence Number 重复。这应该 (SHOULD) 是在数据包与 SA 匹配后应用于该数据包的第一个 ESP 检查, 以加快拒绝重复数据包的速度。

ESP 允许对数据包序列号进行两阶段验证。当 ESP 实现 (通常是其加密模块部分) 无法以与到不受保护网络的接口相同的速率执行解密和/或完整性检查时, 此功能非常重要。如果实现能够进行此类 "线速" 操作, 则无需执行下面描述的初步验证阶段。

初步的 Sequence Number 检查利用 ESP 头部中的 Sequence Number 值进行, 并在完整性检查和解密之前执行。如果此初步检查失败, 则丢弃该数据包, 从而避免接收方需要进行任何加密操作。如果初步检查成功, 则接收方此时还不能修改其本地计数器, 因为此时尚未验证 Sequence Number 的完整性。

通过使用滑动接收窗口拒绝重复项。窗口的实现方式是本地问题, 但以下文本描述了实现必须 (MUST) 展现的功能。

窗口的 "右" 边缘表示在此 SA 上接收的最高的、已验证的 Sequence Number 值。包含低于窗口 "左" 边缘的序列号的数据包被拒绝。落在窗口内的数据包会根据窗口内已接收数据包的列表进行检查。如果为 SA 选择了 ESN 选项, 则仅显式传输序列号的低 32 位, 但接收方在检查接收的 Sequence Number 与接收窗口时, 使用为指定 SA (从其本地计数器) 使用高 32 位计算的完整序列号。在构造完整序列号时, 如果数据包中携带的低 32 位的值低于接收方序列号的低 32 位, 则接收方假定高 32 位已递增, 移动到新的序列号子空间。(此算法适应单个 SA 的接收间隙大至 2^32-1 个数据包。如果发生更大的间隙, 可以采用额外的启发式检查来重新同步接收方序列号计数器, 如附录中所述。)

如果接收的数据包落在窗口内且不是重复的, 或者如果数据包在窗口的右侧, 并且如果采用独立的完整性算法, 则接收方继续进行完整性验证。如果采用组合模式算法, 则完整性检查与解密一起执行。在任何一种情况下, 如果完整性检查失败, 则接收方必须 (MUST) 丢弃接收的 IP 数据报作为无效; 这是一个可审计事件。此事件的审计日志条目应该 (SHOULD) 包括 SPI 值, 接收日期/时间, Source Address (源地址), Destination Address (目的地址), Sequence Number (序列号) 以及 (在 IPv6 中) Flow ID (流 ID)。仅当完整性验证成功时才更新接收窗口。(如果正在使用组合模式算法, 则完整性保护的 Sequence Number 也必须 (MUST) 与用于防重放保护的 Sequence Number 匹配。)

当使用 32 位序列号时, 必须 (MUST) 支持至少 32 个数据包的最小窗口大小; 优选 64 的窗口大小, 并且应该 (SHOULD) 作为默认值使用。接收方可以 (MAY) 选择另一个窗口大小 (大于最小值)。(接收方不会 (does NOT) 通知发送方窗口大小。) 对于更高速的环境, 应该增加接收窗口大小, 而不管保证问题如何。本标准未指定超高速 (例如, 多吉比特/秒) 设备的最小和推荐接收窗口大小的值。

3.4.4. Integrity Check Value Verification (完整性校验值验证)​

与出站处理一样, 入站处理有几个选项, 基于所采用算法的功能。

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

如果采用独立的机密性和完整性算法, 则处理按以下方式进行:

  1. 如果选择了完整性, 则接收方使用指定的完整性算法在 ESP 数据包减去 ICV 上计算 ICV, 并验证它与数据包中携带的 ICV 相同。计算的详细信息如下所述。

    如果计算的 ICV 和接收的 ICV 匹配, 则数据报有效, 并被接受。如果测试失败, 则接收方必须 (MUST) 丢弃接收的 IP 数据报作为无效; 这是一个可审计事件。日志数据应该 (SHOULD) 包括 SPI 值, 接收日期/时间, Source Address (源地址), Destination Address (目的地址), Sequence Number (序列号) 以及 (对于 IPv6) 明文 Flow ID (流 ID)。

    实现注意:

    实现可以使用任何一组步骤, 只要结果与以下一组步骤相同即可。首先删除并保存 ICV 字段。接下来检查 ESP 数据包减去 ICV 字段的总长度。如果基于完整性算法的块大小需要隐式填充, 则在 ESP 数据包的末尾 (紧接 Next Header 字段之后) 附加零填充字节, 或者如果选择了 ESN, 则在序列号的高 32 位之后附加。执行 ICV 计算, 并使用算法规范定义的比较规则将结果与保存的值进行比较。

  2. 接收方使用 SA 指示的密钥、加密算法、算法模式和加密同步数据 (如果有) 解密 ESP Payload Data, Padding, Pad Length 和 Next Header。如第 3.3.2 节所述, 我们在这里以始终应用加密的方式进行讨论, 因为有格式化的影响。这样做是基于这样的理解, 即通过使用 NULL 加密算法 (RFC 2410) 提供 "无机密性"。

    • 如果指示了显式加密同步数据, 例如 IV, 则根据算法规范从 Payload 字段中获取它并输入到解密算法。

    • 如果指示了隐式加密同步数据, 则根据算法规范构造 IV 的本地版本并输入到解密算法。

  3. 接收方按照加密算法规范中的规定处理任何 Padding。如果采用了默认填充方案 (参见第 2.4 节), 则接收方应该 (SHOULD) 在将解密数据传递到下一层之前删除填充之前检查 Padding 字段。

  4. 接收方检查 Next Header 字段。如果值为 "59" (no next header, 无下一个头部), 则丢弃 (虚拟) 数据包而不做进一步处理。

  5. 接收方从以下内容重构原始 IP 数据报:

    • 对于传输模式 -- 外部 IP 头部加上 ESP Payload 字段中的原始下一层协议信息
    • 对于隧道模式 -- ESP Payload 字段中的整个 IP 数据报。

    重构原始数据报的确切步骤取决于模式 (传输或隧道), 并在 Security Architecture 文档中描述。至少, 在 IPv6 上下文中, 接收方应该 (SHOULD) 确保解密的数据是 8 字节对齐的, 以便于由 Next Header 字段标识的协议进行处理。此处理 "丢弃" 为流量流机密性添加的任何 (可选) TFC 填充。(如果存在, 这将在 IP 数据报 (或传输层帧) 之后和 Padding 字段之前插入 (参见第 2.4 节)。)

如果完整性检查和加密并行执行, 则必须 (MUST) 在将解密的数据包传递以进行进一步处理之前完成完整性检查。这种处理顺序有助于接收方在解密数据包之前快速检测和拒绝重放或虚假数据包, 从而可能减少拒绝服务攻击的影响。

注意: 如果接收方并行执行解密和完整性检查, 则必须注意避免与数据包访问和解密数据包提取有关的可能竞争条件。

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

如果采用组合机密性和完整性算法, 则接收方按以下方式进行:

  1. 使用 SA 指示的密钥、算法、算法模式和加密同步数据 (如果有) 解密并完整性检查 ESP Payload Data, Padding, Pad Length 和 Next Header。ESP 头部中的 SPI 和 (接收方) 数据包计数器值 (根据第 3.4.3 节中描述的处理进行调整) 是此算法的输入, 因为它们是完整性检查所需的。

    • 如果指示了显式加密同步数据, 例如 IV, 则根据算法规范从 Payload 字段中获取它并输入到解密算法。

    • 如果指示了隐式加密同步数据, 例如 IV, 则根据算法规范构造 IV 的本地版本并输入到解密算法。

  2. 如果组合模式算法执行的完整性检查失败, 则接收方必须 (MUST) 丢弃接收的 IP 数据报作为无效; 这是一个可审计事件。日志数据应该 (SHOULD) 包括 SPI 值, 接收日期/时间, Source Address (源地址), Destination Address (目的地址), Sequence Number (序列号) 以及 (在 IPv6 中) 明文 Flow ID (流 ID)。

  3. 如果算法尚未这样做, 则按照加密算法规范中的规定处理任何 Padding。

  4. 接收方检查 Next Header 字段。如果值为 "59" (no next header, 无下一个头部), 则丢弃 (虚拟) 数据包而不做进一步处理。

  5. 从 ESP Payload Data 字段中提取原始 IP 数据报 (隧道模式) 或传输层帧 (传输模式)。这隐式地丢弃为流量流机密性添加的任何 (可选) 填充。(如果存在, TFC 填充将在 IP 数据报 (或传输层帧) 之后和 (加密) Padding 字段之前插入 (参见第 2.4 节)。)

最后于 更新