2. Encapsulating Security Payload Packet Format (封装安全载荷报文格式)
紧邻 ESP 首部之前的 (外层) 协议首部 (IPv4, IPv6 或扩展) 必须在其 Protocol (IPv4) 或 Next Header (IPv6, Extension) 字段中包含值 50 (参见 IANA 网页 http://www.iana.org/assignments/protocol-numbers)。图 1 展示了 ESP 报文的顶层格式。报文以两个 4 字节字段 (Security Parameters Index (SPI, 安全参数索引) 和 Sequence Number (序列号)) 开始。这些字段之后是 Payload Data (载荷数据), 它具有依赖于加密算法和模式选择以及 TFC 填充使用的子结构, 这将在后面更详细地讨论。Payload Data 之后是 Padding (填充) 和 Pad Length (填充长度) 字段, 以及 Next Header (下一首部) 字段。可选的 Integrity Check Value (ICV, 完整性校验值) 字段完成报文。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图 1. ESP 报文的顶层格式
* 如果 Payload 字段中包含加密同步数据, 例如 Initialization Vector (IV, 初始化向量, 参见第 2.3 节), 通常其本身不被加密, 尽管它经常被称为密文的一部分。
(传输的) ESP 尾部由 Padding, Pad Length 和 Next Header 字段组成。额外的隐式 ESP 尾部数据 (不被传输) 被包含在完整性计算中, 如下所述。
如果选择了完整性服务, 完整性计算包含 SPI, Sequence Number, Payload Data 和 ESP 尾部 (显式和隐式)。
如果选择了机密性服务, 密文由 Payload Data (除了可能包含的任何加密同步数据) 和 (显式) ESP 尾部组成。
如上所述, Payload Data 可能具有子结构。需要显式 Initialization Vector (IV) 的加密算法, 例如 Cipher Block Chaining (CBC, 密码块链接) 模式, 通常在要保护的 Payload Data 前面加上该值。一些算法模式将加密和完整性组合到单个操作中; 本文档将此类算法模式称为 "combined mode algorithms (组合模式算法)"。对组合模式算法的适应要求算法明确描述用于传递完整性数据的载荷子结构。
一些组合模式算法仅为加密的数据提供完整性, 而其他算法可以为一些未加密传输的额外数据提供完整性。因为 SPI 和 Sequence Number 字段作为完整性服务的一部分需要完整性, 并且它们没有被加密, 所以必须确保无论采用何种组合算法模式, 只要选择了服务, 它们就能获得完整性保护。
当采用任何组合模式算法时, 算法本身应该返回解密的明文和完整性检查的通过/失败指示。对于组合模式算法, 通常在 ESP 报文末尾出现的 ICV (当选择完整性时) 可以省略。当省略 ICV 并选择完整性时, 组合模式算法有责任在 Payload Data 中编码一个等效于 ICV 的方法来验证报文的完整性。
如果组合模式算法仅为加密的数据提供完整性, 则有必要将 SPI 和 Sequence Number 复制为 Payload Data 的一部分。
最后, 在 Payload Data 之后和 ESP 尾部之前插入填充以实现流量流机密性的新规定。图 2 展示了 Payload Data 的这种子结构。(注意: 此图显示线上的比特。因此, 即使使用扩展序列号, 也只传输 Sequence Number 的 32 位 (参见第 2.2.1 节)。)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| IV (optional) | ^ p
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| Rest of Payload Data (variable) | | y
~ ~ | l
| | | o
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| | TFC Padding * (optional, variable) | v d
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图 2. Payload Data 的子结构
* 如果使用隧道模式, 则 IPsec 实现可以在 Payload Data 之后和 Padding (0-255 字节) 字段之前添加 Traffic Flow Confidentiality (TFC, 流量流机密性) 填充 (参见第 2.4 节)。
如果采用组合算法模式, 图 1 和图 2 中显示的显式 ICV 可以省略 (参见下面的第 3.3.2.2 节)。因为算法和模式在建立 SA 时是固定的, 所以给定 SA 的 ESP 报文的详细格式 (包括 Payload Data 子结构) 对于 SA 上的所有流量都是固定的。
下表引用前面图中的字段, 并说明几类算法选项 (每类具有不同的处理模型) 如何影响上述字段。处理细节在后面的章节中描述。
表 1. 分离的加密和完整性算法
| 字段 | 字节数 | 要求 [1] | 加密覆盖范围 | 完整性覆盖范围 | 传输内容 |
|---|---|---|---|---|---|
| SPI | 4 | M | Y | plain | |
| Seq# (低位) | 4 | M | Y | plain | |
| IV | variable | O | Y | plain | |
| IP datagram [2] | variable | M or D | Y | Y | cipher[3] |
| TFC padding [4] | variable | O | Y | Y | cipher[3] |
| Padding | 0-255 | M | Y | Y | cipher[3] |
| Pad Length | 1 | M | Y | Y | cipher[3] |
| Next Header | 1 | M | Y | Y | cipher[3] |
| Seq# (高位) | 4 | if ESN [5] | Y | not xmtd | |
| ICV Padding | variable | if need | Y | not xmtd | |
| ICV | variable | M [6] | plain |
[1] M = 强制; O = 可选; D = 虚拟
[2] 如果隧道模式 -> IP 数据报; 如果传输模式 -> 下一首部和数据
[3] 如果选择了加密则为密文
[4] 仅当载荷指定其 "实际" 长度时才能使用
[5] 参见第 2.2.1 节
[6] 如果使用单独的完整性算法则为强制
表 2. 组合模式算法
| 字段 | 字节数 | 要求 [1] | 加密覆盖范围 | 完整性覆盖范围 | 传输内容 |
|---|---|---|---|---|---|
| SPI | 4 | M | plain | ||
| Seq# (低位) | 4 | M | plain | ||
| IV | variable | O | Y | plain | |
| IP datagram [2] | variable | M or D | Y | Y | cipher |
| TFC padding [3] | variable | O | Y | Y | cipher |
| Padding | 0-255 | M | Y | Y | cipher |
| Pad Length | 1 | M | Y | Y | cipher |
| Next Header | 1 | M | Y | Y | cipher |
| Seq# (高位) | 4 | if ESN [4] | Y | [5] | |
| ICV Padding | variable | if need | Y | [5] | |
| ICV | variable | O [6] | plain |
[1] M = 强制; O = 可选; D = 虚拟
[2] 如果隧道模式 -> IP 数据报; 如果传输模式 -> 下一首部和数据
[3] 仅当载荷指定其 "实际" 长度时才能使用
[4] 参见第 2.2.1 节
[5] 算法选择决定是否传输这些内容, 但在任何情况下, 结果对 ESP 都是不可见的
[6] 算法规范决定此字段是否存在
以下小节描述首部格式中的字段。"Optional (可选)" 表示如果未选择该选项则省略该字段, 即它既不存在于传输的报文中, 也不存在于为计算 ICV 而格式化的报文中 (参见第 2.7 节)。是否选择选项是作为 Security Association (SA, 安全关联) 建立的一部分确定的。因此, 给定 SA 的 ESP 报文格式在 SA 的持续时间内是固定的。相反, "mandatory (强制)" 字段始终存在于 ESP 报文格式中, 对于所有 SA。
注意: IPsec 中使用的所有加密算法都期望其输入为规范网络字节序 (参见 RFC 791 [Pos81] 的附录) 并以规范网络字节序生成其输出。IP 报文也以网络字节序传输。
ESP 不包含版本号, 因此如果存在向后兼容性的问题, 必须通过在两个 IPsec 对等体之间使用信令机制来确保 ESP 的兼容版本 (例如 Internet Key Exchange (IKEv2) [Kau05]) 或带外配置机制来解决。