2. Authentication Header Format (认证头格式)
紧接在 AH 头部之前的协议头部 (IPv4, IPv6 或 IPv6 Extension) 在其 Protocol (IPv4) 或 Next Header (IPv6, Extension) 字段中必须 (SHALL) 包含值 51 [DH98]。图 1 展示了 AH 的格式。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Integrity Check Value-ICV (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. AH Format
下表涉及组成 AH 的字段 (如图 1 所示), 以及包含在完整性计算中的其他字段, 并说明了哪些字段被 ICV 覆盖以及传输的内容。
| Field | # of bytes | Requ'd [1] | Integ Covers | What is Xmtd |
|---|---|---|---|---|
| IP Header | variable | M | [2] | plain |
| Next Header | 1 | M | Y | plain |
| Payload Len | 1 | M | Y | plain |
| RESERVED | 2 | M | Y | plain |
| SPI | 4 | M | Y | plain |
| Seq# (low-order 32 bits) | 4 | M | Y | plain |
| ICV | variable | M | Y[3] | plain |
| IP datagram [4] | variable | M | Y | plain |
| Seq# (high-order 32 bits) | 4 | if ESN | Y | not xmtd |
| ICV Padding | variable | if need | Y | not xmtd |
[1] - M = mandatory (强制的)
[2] - 有关哪些 IP 头部字段被覆盖的详细信息, 请参阅第 3.3.3 节 "Integrity Check Value Calculation (完整性校验值计算)"。
[3] - 在 ICV 计算之前清零 (计算后将结果 ICV 放置在此处)
[4] - 如果是隧道模式 -> IP 数据报
如果是传输模式 -> 下一个头部和数据
以下小节定义了组成 AH 格式的字段。这里描述的所有字段都是强制的; 即, 它们始终存在于 AH 格式中, 并包含在 Integrity Check Value (完整性校验值, ICV) 计算中 (见第 2.6 节和第 3.3.3 节)。
注意: IPsec 中使用的所有加密算法都期望其输入采用规范的网络字节序 (canonical network byte order) (见 RFC 791 [RFC791] 附录), 并以规范的网络字节序生成其输出。IP 数据包也以网络字节序传输。
AH 不包含版本号, 因此如果存在向后兼容性 (backward compatibility) 的担忧, 则必须 (MUST) 通过在两个 IPsec 对等体之间使用信令机制来解决, 以确保 AH 的兼容版本, 例如, IKE [IKEv2] 或带外配置机制 (out-of-band configuration mechanism)。