無論是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.
- 選取 SPI， 目的、源位址均比對的表項，否則轉向 2 。
- 選取 SPI，目的位址均比對的表項，否則轉向 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 的查找過程。