同时接收多个spi_IP 安全与 IPsec 协议的 RFC 一瞥：数据接收中的 SPI

无论是ESP还是AH协议，IPsec 协议首部中都携带有 SPI 字段，安全参数索引。

SPI 一般在 SA 协商期间由接收方指定，发送方在发送数据包时，将流量对应的 SA 所持有的 SPI 写入安全协议的首部。接收方提取首部中的 SPI，用于为该流量查找合适的 SA。

RFC 4301： Security Architecture for IP，IPsec 的主要 RFC 文件讨论了接收过程中 SPI 的应用。

For an SA used to carry unicast traffic, the Security Parameters Index (SPI) by itself suffices to specify an SA. .

对于承载单播流量的 SA，仅通过 SPI 就可以对应到唯一的 SA。

However, as a local matter, an implementation may choose to use the SPI in conjunction with the IPsec protocol type (AH or ESP) for SA identification.

部分实现中需要使用 SPI 和协议类型（AH/ESP）来共同确定 SA。笔者的看法是在这些实现中，不同协议类型的 SA 可能使用同样的 SPI。比如对不同协议类型的 SA 分开管理，ESP /AH 协议的 SA 有单独的管理单元，两者可能分配相同的 SPI。但 SPI 是一项本地参数，分配管理由接收方决定。在上述实现中，接收方可以通过协议类型区分相同的 SA，所以是可行的。

那么对于多播流量呢？

In many secure multicast architectures, e.g., [RFC3740], a central Group Controller/Key Server unilaterally assigns the Group Security Association's (GSA's) SPI.
This SPI assignment is not negotiated or coordinated with the key management (e.g., IKE) subsystems that reside in the individual end systems that constitute the group.

在许多多播架构中，多播组的组控制器/密钥管理单元单方面地指定 Group SA 的 SPI。而不会与多播组内的节点进行协商。

Consequently, it is possible that a GSA and a unicast SA can simultaneously use the same SPI.
A multicast-capable IPsec implementation MUST correctly de-multiplex inbound traffic even in the context of SPI collisions.

这样一来对于多播组内的节点来说，组播模式下由组管理器分配的组 SPI 就有可能同单播模式下协商的某个 SPI 相同。

所以，对于支持多播模式的节点，多播模式 SA 的 SPI 可能同某个单播模式 SA 的 SPI 冲突，因此不能够仅通过 SPI 唯一确定 SA。必须有能力在 SPI 冲突的情况下，通过其他信息对应到正确的 SA，比如目的，源 IP 地址。

支持多播模式的 SA 查找

Each entry in the SA Database (SAD) (Section 4.4.2) must indicate whether the SA lookup makes use of the destination IP address, or the destination and source IP addresses, in addition to the SPI.
For multicast SAs, the protocol field is not employed for SA lookups. For each inbound, IPsec-protected packet, an implementation must conduct its search of the SAD such that it finds the entry that matches the "longest" SA identifier.

对于支持多播模式的节点，安全关联数据库中的表项必须标明除使用 SPI 用于查找之外，还需要目的地址或者需要源以及目的地址用于安全关联查找。

如果安全关联表项中只指定了目的地址，那么源地址可以是任意值，实现中可以使用通配符来表示源地址。

In this context, if two or more SAD entries match based on the SPI value, then the entry that also matches based on destination address, or destination and source address (as indicated in the SAD entry) is the "longest" match.

安全关联查找遵循最长匹配原则。如果两个表项的 SPI 相同，其中一项匹配目的地址，另一项目的、源地址均匹配，选取后者，因为后者更加匹配。最长匹配需要遵循下述的顺序

1. Search the SAD for a match on the combination of SPI,
destination address, and source address. If an SAD entry
matches, then process the inbound packet with that
matching SAD entry. Otherwise, proceed to step 2.
2. Search the SAD for a match on both SPI and destination address.
If the SAD entry matches, then process the inbound packet
with that matching SAD entry. Otherwise, proceed to step 3.
3. Search the SAD for a match on only SPI if the receiver has
chosen to maintain a single SPI space for AH and ESP, and on
both SPI and protocol, otherwise. If an SAD entry matches,
then process the inbound packet with that matching SAD entry.
Otherwise, discard the packet and log an auditable event.

1. 选取 SPI， 目的、源地址均匹配的表项，否则转向 2 。
2. 选取 SPI，目的地址均匹配的表项，否则转向 3 。
3. 选取 SPI 匹配的表项，如果还没找到则丢包并向上层报告。

实现建议

In practice, an implementation may choose any method (or none at all) to accelerate this search, although its externally visible behavior MUST be functionally equivalent to having searched the SAD in the above order. For example, a software-based implementation could index into a hash table by the SPI. The SAD entries in each hash table bucket's linked list could be kept sorted to have those SAD entries with the longest SA identifiers first in that linked list. Those SAD entries having the shortest SA identifiers could be sorted so that they are the last entries in the linked list.

RFC 指出具体实现需要在逻辑上遵循上述顺序，但不必在实现中严格按照这个顺序。

RFC 给出了一个最长匹配的软件实现建议。软件上使用哈希查找表管理和查找 SA 表项。哈希查找表使用 SPI 作为索引，当两个或者多个 SA 的 SPI 相同，即发生哈希冲突时，使用链表法解决冲突。将 SPI 相同的表项，按照最长匹配的顺序用链表组织起来，查找按顺序进行。比如同时指定源、目的地址的 SA 表项将排在只指定目的地址，或者什么地址都未指定的 SA 表项之前。

笔者的想法

对于同时支持单播以及多播的应用，需要同时具备查找单播和多播流量的能力。两者可以使用统一的方法来查找，比如软件中的哈希查找表。哈希查找表通过 SPI 作为索引查找 SA，只有在两个或者多个 SA 的 SPI 相同的情况下，才进行多播 SA 的查找。但两者的查找也可以分开，首先通过 IP 地址区分出两者，基于多播流量目的地址使用 D 类多播地址，使用不同的方法查找。

单播数据可以使用复杂度更低的方法查找，这样在以单播流量为主的网络中就能够加速单播SA 的查找过程。