2.1. Security Parameters Index (セキュリティパラメータインデックス, SPI)

SPI は受信者が着信パケットがバインドされている SA を識別するために使用する任意の 32 ビット値です。SPI フィールドは必須です。

ユニキャスト SA の場合, SPI は単独で SA を指定するために使用できます。または IPsec プロトコルタイプ (この場合は ESP) と組み合わせて使用できます。ユニキャスト SA の SPI 値は受信者によって生成されるため, この値が単独で SA を識別するのに十分かどうか, または IPsec プロトコル値と組み合わせて使用する必要があるかどうかはローカルの問題です。ユニキャスト SA への着信トラフィックをマッピングするこのメカニズムは, すべての ESP 実装でサポートしなければなりません。

IPsec 実装がマルチキャストをサポートする場合, 着信 IPsec データグラムを SA にマッピングするための以下のアルゴリズムを使用してマルチキャスト SA をサポートしなければなりません。ユニキャストトラフィックのみをサポートする実装は, この逆多重化アルゴリズムを実装する必要はありません。

多くのセキュアマルチキャストアーキテクチャ (例: [RFC3740]) では, 中央の Group Controller/Key Server (グループコントローラー/キーサーバー) がグループセキュリティアソシエーションの SPI を一方的に割り当てます。この SPI 割り当ては, グループを構成する個々のエンドシステムに存在するキー管理 (例: IKE) サブシステムと交渉または調整されません。その結果, グループセキュリティアソシエーションとユニキャストセキュリティアソシエーションが同じ SPI を同時に使用する可能性があります。マルチキャスト対応の IPsec 実装は, SPI 衝突の状況でも着信トラフィックを正しく逆多重化しなければなりません。

Security Association Database (SAD, セキュリティアソシエーションデータベース) [Ken-Arch] の各エントリは, SA ルックアップが SPI に加えて宛先アドレス, または宛先アドレスと送信元アドレスを使用するかどうかを示さなければなりません。マルチキャスト SA の場合, プロトコルフィールドは SA ルックアップに使用されません。各着信 IPsec 保護パケットについて, 実装は "最長" の SA 識別子に一致するエントリを見つけるように SAD の検索を実施しなければなりません。この文脈では, 2 つ以上の SAD エントリが SPI 値に基づいて一致する場合, 宛先アドレス, または宛先アドレスと送信元アドレスの比較 (SAD エントリに示されているように) に基づいても一致するエントリが "最長" の一致です。これは, 次のように SAD 検索の論理的な順序を意味します:

{SPI, 宛先アドレス, 送信元アドレス} の一致について SAD を検索します。SAD エントリが一致する場合, その一致する SAD エントリで着信 ESP パケットを処理します。それ以外の場合は, ステップ 2 に進みます。
{SPI, 宛先アドレス} の一致について SAD を検索します。SAD エントリが一致する場合, その一致する SAD エントリで着信 ESP パケットを処理します。それ以外の場合は, ステップ 3 に進みます。
受信者が AH と ESP に対して単一の SPI 空間を維持することを選択した場合は {SPI} のみの一致について SAD を検索し, それ以外の場合は {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, インターネット割り当て番号機関) によって将来の使用のために予約されています。予約された SPI 値は, 割り当てられた SPI 値の使用が RFC で指定されていない限り, 通常 IANA によって割り当てられません。SPI 値ゼロ (0) はローカルな実装固有の使用のために予約されており, ネットワーク上で送信してはなりません。(たとえば, キー管理実装は, IPsec 実装がキー管理エンティティに新しい SA の確立を要求したが SA がまだ確立されていない期間中に, ゼロの SPI 値を "セキュリティアソシエーションが存在しない" という意味で使用する場合があります。)