2.1. Security Parameters Index (安全参数索引, SPI)

SPI 是一个任意的 32 位值, 接收方使用它来识别传入报文所绑定的 SA。SPI 字段是强制性的。

对于单播 SA, SPI 可以单独用于指定 SA, 或者可以与 IPsec 协议类型 (在本例中为 ESP) 结合使用。由于 SPI 值是由接收方为单播 SA 生成的, 因此该值是否足以单独识别 SA, 或者是否必须与 IPsec 协议值结合使用, 这是一个本地问题。所有 ESP 实现必须支持将入站流量映射到单播 SA 的这种机制。

如果 IPsec 实现支持组播, 则它必须使用以下算法支持组播 SA, 以将入站 IPsec 数据报映射到 SA。仅支持单播流量的实现无需实现此解复用算法。

在许多安全组播架构中 (例如 [RFC3740]), 中央 Group Controller/Key Server (组控制器/密钥服务器) 单方面分配组安全关联的 SPI。此 SPI 分配不与驻留在组成该组的各个终端系统中的密钥管理 (例如 IKE) 子系统协商或协调。因此, 组安全关联和单播安全关联可能同时使用相同的 SPI。支持组播的 IPsec 实现必须正确地解复用入站流量, 即使在 SPI 冲突的情况下。

Security Association Database (SAD, 安全关联数据库) [Ken-Arch] 中的每个条目必须指示 SA 查找除了使用 SPI 之外, 是否还使用目标地址或目标和源 IP 地址。对于组播 SA, 协议字段不用于 SA 查找。对于每个入站的受 IPsec 保护的报文, 实现必须进行 SAD 搜索, 以便找到与 "最长" SA 标识符匹配的条目。在这种情况下, 如果两个或更多 SAD 条目基于 SPI 值匹配, 那么还基于目标地址或目标和源地址比较 (如 SAD 条目中所示) 匹配的条目是 "最长" 匹配。这意味着 SAD 搜索的逻辑顺序如下:

在 SAD 中搜索与 {SPI, 目标地址, 源地址} 匹配的条目。如果 SAD 条目匹配, 则使用该匹配的 SAD 条目处理入站 ESP 报文。否则, 进行步骤 2。
在 SAD 中搜索与 {SPI, 目标地址} 匹配的条目。如果 SAD 条目匹配, 则使用该匹配的 SAD 条目处理入站 ESP 报文。否则, 进行步骤 3。
如果接收方选择为 AH 和 ESP 维护单个 SPI 空间, 则在 SAD 中仅搜索与 {SPI} 匹配的条目, 否则搜索 {SPI, protocol}。如果 SAD 条目匹配, 则使用该匹配的 SAD 条目处理入站 ESP 报文。否则, 丢弃报文并记录可审计事件。

实际上, 实现可以选择任何方法来加速此搜索, 尽管其外部可见行为必须在功能上等同于按上述顺序搜索 SAD。例如, 基于软件的实现可以通过 SPI 索引到哈希表中。每个哈希表桶的链表中的 SAD 条目保持排序, 以使具有最长 SA 标识符的 SAD 条目首先出现在该链表中。具有最短 SA 标识符的 SAD 条目被排序为链表中的最后条目。基于硬件的实现可能能够使用常用的 Ternary Content-Addressable Memory (TCAM, 三态内容可寻址存储器) 功能本质上实现最长匹配搜索。

是否需要源和目标地址匹配以将入站 IPsec 流量映射到 SA 的指示必须作为手动 SA 配置的副作用设置, 或通过使用 SA 管理协议 (例如 IKE 或 Group Domain of Interpretation (GDOI) [RFC3547]) 协商设置。通常, Source-Specific Multicast (SSM, 源特定组播) [HC03] 组使用由 SPI, 目标组播地址和源地址组成的 3 元组 SA 标识符。Any-Source Multicast (任意源组播) 组 SA 仅需要 SPI 和目标组播地址作为标识符。

范围 1 到 255 的 SPI 值集由 Internet Assigned Numbers Authority (IANA, 互联网号码分配机构) 保留供将来使用; 除非在 RFC 中指定了分配的 SPI 值的使用, 否则 IANA 通常不会分配保留的 SPI 值。SPI 值零 (0) 保留用于本地特定于实现的使用, 绝对不能在线路上发送。(例如, 密钥管理实现可能在 IPsec 实现请求其密钥管理实体建立新 SA 但 SA 尚未建立的期间使用零 SPI 值表示 "不存在安全关联"。)