跳到主要内容

3.3.3. Integrity Check Value Calculation (完整性校验值计算)

AH ICV 计算覆盖:

  • AH 头部之前的 IP 或扩展头部字段, 这些字段在传输过程中是不可变的 (immutable) 或在到达 AH SA 的端点时是可预测的 (predictable)
  • AH 头部 (Next Header, Payload Len, Reserved, SPI, Sequence Number (低 32 位), 以及 ICV (在此计算中设置为零), 以及显式填充字节 (如果有))
  • AH 之后的所有内容都假定在传输过程中是不可变的
  • ESN 的高位 (如果使用), 以及完整性算法所需的任何隐式填充

3.3.3.1. Handling Mutable Fields (处理可变字段)​

如果字段可能在传输过程中被修改, 则为了 ICV 计算的目的, 该字段的值设置为零。如果字段是可变的, 但其在 (IPsec) 接收方的值是可预测的, 则为了 ICV 计算的目的, 将该值插入到字段中。完整性校验值字段也设置为零以准备此计算。请注意, 通过用零替换每个字段的值而不是省略该字段, 为 ICV 计算保留了对齐。此外, 零填充方法确保即使内容未被 ICV 明确覆盖, 在传输过程中也无法更改以这种方式处理的字段的长度。

当创建新的扩展头或 IPv4 选项时, 它将在其自己的 RFC 中定义, 并且应该 (SHOULD) 在 (安全考虑部分) 包含在计算 AH ICV 时应如何处理它的说明。如果 IP (v4 或 v6) 实现遇到它不识别的扩展头, 它将丢弃数据包并发送 ICMP 消息。IPsec 永远不会看到该数据包。如果 IPsec 实现遇到它不识别的 IPv4 选项, 它应该将整个选项清零, 使用选项的第二个字节作为长度。IPv6 选项 (在目标扩展头或逐跳扩展头中) 包含指示可变性的标志, 该标志确定此类选项的适当处理。

3.3.3.1.1. ICV Computation for IPv4 (IPv4 的 ICV 计算)​

3.3.3.1.1.1. Base Header Fields (基本头部字段)​

IPv4 基本头部字段分类如下:

Immutable (不可变):

  • Version
  • Internet Header Length
  • Total Length
  • Identification
  • Protocol (这应该是 AH 的值。)
  • Source Address
  • Destination Address (不使用松散或严格源路由)

Mutable but predictable (可变但可预测):

  • Destination Address (使用松散或严格源路由)

Mutable (可变, 在 ICV 计算之前清零):

  • Differentiated Services Code Point (DSCP) (6 位, 见 RFC 2474 [NBBB98])
  • Explicit Congestion Notification (ECN) (2 位, 见 RFC 3168 [RFB01])
  • Flags
  • Fragment Offset
  • Time to Live (TTL)
  • Header Checksum

DSCP - 路由器可能根据需要重写 DS 字段以提供所需的本地或端到端服务, 因此发送方无法预测其接收时的值。

ECN - 如果路由沿线的路由器遇到拥塞, 这将改变, 因此发送方无法预测其接收时的值。

Flags - 排除此字段是因为中间路由器可能设置 DF 位, 即使源没有选择它。

Fragment Offset - 由于 AH 仅应用于非分片的 IP 数据包, 因此偏移字段必须始终为零, 因此被排除 (即使它是可预测的)。

TTL - 这在路由过程中被路由器作为正常处理过程的一部分进行更改, 因此发送方无法预测其在接收方的值。

Header Checksum - 如果这些其他字段中的任何一个发生变化, 这将改变, 因此发送方无法预测其接收时的值。

3.3.3.1.1.2. Options (选项)​

对于 IPv4 (与 IPv6 不同), 没有将选项标记为在传输过程中可变的机制。因此, IPv4 选项在附录 A 中明确列出, 并分类为不可变, 可变但可预测或可变。对于 IPv4, 整个选项被视为一个单元; 因此, 即使大多数选项中的类型和长度字段在传输过程中是不可变的, 如果选项被分类为可变, 则整个选项在 ICV 计算目的上清零。

3.3.3.1.2. ICV Computation for IPv6 (IPv6 的 ICV 计算)​

3.3.3.1.2.1. Base Header Fields (基本头部字段)​

IPv6 基本头部字段分类如下:

Immutable (不可变):

  • Version
  • Payload Length
  • Next Header
  • Source Address
  • Destination Address (不使用路由扩展头)

Mutable but predictable (可变但可预测):

  • Destination Address (使用路由扩展头)

Mutable (可变, 在 ICV 计算之前清零):

  • DSCP (6 位, 见 RFC2474 [NBBB98])
  • ECN (2 位, 见 RFC3168 [RFB01])
  • Flow Label (*)
  • Hop Limit

(*) AHv1 中描述的流标签是可变的, 在 RFC 2460 [DH98] 中是潜在可变的。为了保持与现有 AH 实现的兼容性, AHv2 中流标签不包含在 ICV 中。

3.3.3.1.2.2. Extension Headers Containing Options (包含选项的扩展头)​

逐跳和目标扩展头中的 IPv6 选项包含一个位, 指示该选项在传输过程中是否可能 (不可预测地) 改变。对于内容可能在途中改变的任何选项, 在计算或验证 ICV 时, 必须将整个 "Option Data" 字段视为零值八位字节。Option Type 和 Opt Data Len 包含在 ICV 计算中。该位指示不可变性的所有选项都包含在 ICV 计算中。有关更多信息, 请参阅 IPv6 规范 [DH98]。

3.3.3.1.2.3. Extension Headers Not Containing Options (不包含选项的扩展头)​

不包含选项的 IPv6 扩展头在附录 A 中明确列出, 并分类为不可变, 可变但可预测或可变。

3.3.3.2. Padding and Extended Sequence Numbers (填充和扩展序列号)​

3.3.3.2.1. ICV Padding (ICV 填充)​

如第 2.6 节所述, 如果需要确保 AH 头部是 32 位 (IPv4) 或 64 位 (IPv6) 的倍数, 则 ICV 字段可能包含显式填充。如果需要填充, 其长度由两个因素决定:

  • ICV 的长度
  • IP 协议版本 (v4 或 v6)

例如, 如果所选算法的输出为 96 位, 则 IPv4 或 IPv6 都不需要填充。但是, 如果由于使用不同的算法而生成不同长度的 ICV, 则可能需要填充, 这取决于长度和 IP 协议版本。填充字段的内容由发送方任意选择。(填充是任意的, 但不需要是随机的以实现安全性。) 这些填充字节包含在 ICV 计算中, 作为载荷长度的一部分计数, 并在 ICV 字段的末尾传输, 以使接收方能够执行 ICV 计算。禁止包含超过满足 IPv4/IPv6 对齐要求所需的最小量的填充。

3.3.3.2.2. Implicit Packet Padding and ESN (隐式数据包填充和 ESN)​

如果为 SA 选择了 ESN 选项, 则必须将 ESN 的高 32 位包含在 ICV 计算中。为了 ICV 计算的目的, 这些位在载荷结束之后以及任何隐式数据包填充之前 (隐式地) 附加。

对于某些完整性算法, 执行 ICV 计算的字节字符串必须是算法指定的块大小的倍数。如果 IP 数据包长度 (包括 AH 和 ESN 的高 32 位, 如果启用) 不匹配算法的块大小要求, 则必须 (MUST) 在 ICV 计算之前将隐式填充附加到数据包的末尾。填充八位字节必须 (MUST) 具有零值。块大小 (以及填充的长度) 由算法规范指定。此填充不与数据包一起传输。必须 (MUST) 查阅定义完整性算法的文档以确定是否需要如上所述的隐式填充。如果文档没有指定对此的答案, 则默认假设需要隐式填充 (根据需要将数据包长度与算法的块大小匹配)。如果需要填充字节但算法没有指定填充内容, 则填充八位字节必须 (MUST) 具有零值。

最后于 更新