2.6. Next Header (下一首部)

Next Header 是一个强制性的 8 位字段, 用于标识 Payload Data 字段中包含的数据类型, 例如 IPv4 或 IPv6 报文, 或下一层首部和数据。此字段的值从 IANA 网页上定义的 IP 协议号集合中选择, 例如值 4 表示 IPv4, 值 41 表示 IPv6, 值 6 表示 TCP。

为了便于快速生成和丢弃填充流量以支持流量流机密性 (参见第 2.4 节), 协议值 59 (表示 "无下一首部") 必须用于指定 "虚拟" 报文。发送方必须能够生成在下一协议字段中标有此值的虚拟报文, 接收方必须准备好丢弃此类报文, 而不指示错误。虚拟报文中必须存在所有其他 ESP 首部和尾部字段 (SPI, Sequence Number, Padding, Pad Length, Next Header 和 ICV), 但除了此 Next Header 字段外, 载荷的明文部分无需格式良好, 例如 Payload Data 的其余部分可能仅由随机字节组成。虚拟报文被无条件丢弃。

实现应该提供本地管理控制, 以在每个 SA 基础上启用此功能的使用。控制应允许用户指定是否使用此功能, 并提供参数控制; 例如, 控制可能允许管理员生成随机长度或固定长度的虚拟报文。

讨论: 可以以随机间隔插入虚拟报文以掩盖实际流量的缺失。也可以 "塑造" 实际流量以匹配某个分布, 根据分布参数向其添加虚拟流量。与用于 Traffic Flow Security (TFS, 流量流安全) 的报文长度填充设施一样, 最安全的方法是以维持 SA 上恒定速率所需的任何速率生成虚拟报文。如果报文都是相同大小, 那么 SA 呈现恒定比特率数据流的外观, 类似于链路加密在第 1 层或第 2 层提供的内容。然而, 这在许多情况下不太实用, 例如当有多个活动 SA 时, 因为这意味着根据 SA 数量减少站点允许的带宽, 这将损害分组交换的好处。实现应该提供控制, 使本地管理员能够管理用于 TFC 目的的虚拟报文的生成。