メインコンテンツまでスキップ

4.4.2. セキュリティアソシエーションデータベース (Security Association Database, SAD)

各 IPsec 実装には、名目上のセキュリティアソシエーションデータベース (Security Association Database, SAD) があり、その各エントリは 1 つの SA に関連付けられたパラメータを定義します。各 SA は SAD にエントリを持ちます。

SAD ルックアップメカニズム​

アウトバウンド処理 (Outbound Processing)​

アウトバウンド処理の場合、各 SAD エントリは SPD キャッシュの SPD-S 部分のエントリによって指されます。

インバウンド処理 (Inbound Processing)​

  • ユニキャスト SA の場合：SPI は単独で SA を検索するために使用されるか、IPsec プロトコルタイプと組み合わせて使用されます。
  • IPsec 実装がマルチキャストをサポートする場合：SPI と宛先アドレス、または SPI と宛先アドレスおよび送信元アドレスを使用して SA を検索します。

（インバウンド IPsec データグラムを SA にマッピングするために使用しなければならない (MUST) アルゴリズムの詳細については、セクション 4.1 を参照してください。）

SAD エントリパラメータ​

以下のパラメータは、SAD の各エントリに関連付けられています。AH 認証アルゴリズムなど、特に記載がない限り、すべて存在する必要があります。この説明は MIB であることを意図しているのではなく、IPsec 実装で SA をサポートするために必要な最小限のデータ項目の仕様にすぎません。

セレクタの設定 (Selector Population)​

セクション 4.4.1.1 で定義された各セレクタについて、SAD のインバウンド SA のエントリは、SA が作成された時点で交渉された値で最初に設定されなければなりません (MUST)。（既存の SA に対する SPD 変更の影響に関するガイダンスについては、セクション 4.4.1 の「システム実行中の SPD への変更の処理」の段落を参照してください。）

受信側にとって、これらの値は、インバウンドパケットのヘッダフィールド（IPsec 処理後）が SA に対して交渉されたセレクタ値と一致するかどうかをチェックするために使用されます。したがって、SAD は SA に到着するインバウンドトラフィックのセレクタをチェックするためのキャッシュとして機能します。受信側にとって、これは SA に到着するパケットが SA のポリシーと一致していることを検証する一部です。（ICMP メッセージのルールについては、セクション 6 を参照してください。）

これらのフィールドは、セクション 4.4.1.1「セレクタ」に記載されているように、特定の値、範囲、ANY、または OPAQUE の形式を持つことができます。

SPD 対応関係のない SAD エントリ​

また、SAD が対応する SPD エントリを持たない SA のエントリを持つことができる状況がいくつかあることにも注意してください：

  1. 本文書は SPD が変更されたときに SAD を選択的にクリアすることを義務付けていないため、それらを作成した SPD エントリが変更または削除された場合でも、SAD エントリは残ることがあります。
  2. 手動で鍵付けされた SA が作成された場合、この SA に対応する SAD エントリが存在する可能性がありますが、どの SPD エントリにも対応しません。

マルチキャスト SA サポート​

注意：手動で構成された場合、SAD はマルチキャスト SA をサポートできます。

アウトバウンドマルチキャスト SA (Outbound Multicast SA)​

アウトバウンドマルチキャスト SA はユニキャスト SA と同じ構造を持っています。送信元アドレスは送信者のアドレスであり、宛先アドレスはマルチキャストグループアドレスです。

インバウンドマルチキャスト SA (Inbound Multicast SA)​

インバウンドマルチキャスト SA は、問題のマルチキャスト SA に送信することが許可された各ピアの送信元アドレスで構成する必要があります。マルチキャスト SA の SPI 値は、ユニキャスト SA のように受信者ではなく、マルチキャストグループコントローラによって提供されます。

SAD エントリは、SPD エントリの一部であった複数の個別の IP 送信元アドレスを収容する必要がある場合があるため（ユニキャスト SA の場合）、インバウンドマルチキャスト SA に必要な機能は、IPsec 実装にすでに存在する機能です。ただし、SPD にはマルチキャストエントリを収容するための規定がないため、本文書はマルチキャストインバウンド SA の SAD エントリを作成する自動化された方法を指定していません。インバウンドマルチキャストトラフィックを収容するために、手動で構成された SAD エントリのみを作成できます。

実装ガイダンス：SPD-S から SAD へのリンク​

本文書は、SPD-S エントリが対応する SAD エントリを参照する方法を指定していません。これは実装固有の詳細だからです。ただし、一部の実装（RFC 2401 からの経験に基づく）は、この点で問題があることが知られています。

問題：SPD キャッシュに（リモートトンネルヘッダー IP アドレス、リモート SPI）ペアを単純に格納するだけでは不十分です。このペアは常に単一の SAD エントリを一意に識別するわけではないためです。

非一意性の例：

  • 同じ NAT の背後にある 2 台のホストが同じ SPI 値を選択する可能性があります。
  • ホストに、他のホストが以前使用していた IP アドレスが（DHCP などを介して）割り当てられ、古いホストに関連付けられた SA がデッドピア検出メカニズムを介してまだ削除されていない。

結果：これにより、パケットが誤った SA 経由で送信されるか、鍵管理がペアが一意であることを保証する場合、他の有効な SA の作成が拒否される可能性があります。

推奨事項：実装者は、このような問題を引き起こさない方法で SPD キャッシュと SAD 間のリンクを実装する必要があります。

に最終更新