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

4.4.1. セキュリティポリシーデータベース (The Security Policy Database, SPD)

SA は、IPsec 境界を通過するトラフィックにセキュリティポリシーを適用するために使用される管理構造です。したがって、SA 処理の本質的な要素は、IP データグラムにどのようなサービスを提供するか、どのような方法で提供するかを指定する基礎となるセキュリティポリシーデータベース (Security Policy Database, SPD) です。データベースの形式とそのインターフェースは、この仕様の範囲外です。ただし、このセクションでは、ユーザーまたはシステム管理者が、ホストによって送受信されるトラフィック、またはセキュリティゲートウェイを通過するトラフィックに IPsec を適用するかどうか、およびどのように適用するかを制御できるようにするために提供する必要がある最小限の管理機能を規定します。SPD または関連するキャッシュは、IPsec 境界を通過するすべてのトラフィック (インバウンドとアウトバウンド) (IPsec で保護されていないトラフィックを含む) の処理中に参照される必要があります。これには IKE などの IPsec 管理トラフィックも含まれます。

SPD 要件​

IPsec 実装は少なくとも 1 つの SPD を持たなければならず (MUST)、IPsec 実装が動作するコンテキストに適している場合は、複数の SPD をサポートできます (MAY)。RFC 2401 で規定されていたような、インターフェースごとに SPD を維持する要件はありません。ただし、実装が複数の SPD をサポートする場合は、アウトバウンドトラフィック処理に適した SPD を選択するために呼び出される明示的な SPD 選択関数を含める必要があります (MUST)。この関数への入力は、アウトバウンドパケットと、SPD 選択関数を実行するために必要な任意のローカルメタデータ (例: パケットが到着したインターフェース) です。関数の出力は SPD 識別子 (SPD-ID) です。

順序付きデータベース​

SPD は順序付きデータベースであり、ファイアウォール、ルーターなどのアクセス制御リスト (Access Control Lists, ACL) またはパケットフィルタの使用と一致しています。順序要件が生じるのは、セレクタの値として (自明でない) 範囲が存在するため、エントリが重複することが多いためです。したがって、ユーザーまたは管理者は、望ましいアクセス制御ポリシーを表現するためにエントリを順序付けできる必要があります (MUST)。セレクタ値にワイルドカードの使用が許可されており、異なるタイプのセレクタが階層的に関連していないため、SPD エントリに一般的な正規の順序を課す方法はありません。

処理の選択: DISCARD、BYPASS、PROTECT​

SPD は、IPsec 保護が提供されるトラフィックと、IPsec をバイパスすることが許可されるトラフィックを区別する必要があります。これは、送信者が適用する IPsec 保護と、受信者に存在する必要がある IPsec 保護の両方に適用されます。任意のアウトバウンドまたはインバウンドデータグラムについて、3 つの処理の選択肢が可能です: DISCARD、BYPASS IPsec、または IPsec を使用した PROTECT。

  • DISCARD: IPsec 境界を (指定された方向に) 通過することが許可されていないトラフィック。
  • BYPASS: IPsec 保護なしで IPsec 境界を越えることが許可されているトラフィック。
  • PROTECT: IPsec 保護が提供されるトラフィック。このようなトラフィックについて、SPD は使用するセキュリティプロトコル、そのモード、セキュリティサービスオプション、および使用する暗号化アルゴリズムを指定する必要があります。

SPD-S、SPD-I、SPD-O​

SPD は論理的に 3 つの部分に分割されます:

  • SPD-S (セキュアトラフィック secure traffic): IPsec 保護の対象となるすべてのトラフィックのエントリが含まれます。
  • SPD-O (アウトバウンド outbound): バイパスまたは破棄されるすべてのアウトバウンドトラフィックのエントリが含まれます。
  • SPD-I (インバウンド inbound): バイパスまたは破棄されるインバウンドトラフィックに適用されます。

これらの 3 つはすべて、キャッシュを容易にするために非相関化できます。IPsec 実装が 1 つの SPD のみをサポートする場合、SPD は 3 つの部分すべてで構成されます。複数の SPD がサポートされている場合、それらの一部は部分的である可能性があります。たとえば、一部の SPD には SPD-I エントリのみが含まれ、インターフェースごとにバイパスされるインバウンドトラフィックを制御します。この分割により、このようなトラフィックについて SPD-S を参照することなく SPD-I を参照できます。

SPD-I は SPD の一部に過ぎないため、SPD-I で検索されたパケットがそこのエントリと一致できない場合、そのパケットは破棄されなければなりません (MUST)。アウトバウンドトラフィックの場合、SPD-S で一致が見つからない場合は、トラフィックをバイパスする必要があるかどうかを確認するために SPD-O をチェックする必要があることに注意してください。同様に、SPD-O が最初にチェックされ、一致が見つからない場合は、SPD-S をチェックする必要があります。順序付けられた非相関化されていない SPD では、SPD-S、SPD-I、および SPD-O のエントリがインターリーブされています。したがって、SPD での検索は 1 回です。

SPD エントリ​

各 SPD エントリは、パケット処理を BYPASS、DISCARD、または PROTECT として指定します。エントリは、1 つ以上のセレクタのリストによってキー付けされます。SPD には、これらのエントリの順序付きリストが含まれています。必要なセレクタタイプはセクション 4.4.1.1 で定義されています。これらのセレクタは、アウトバウンドパケットに応答して、またはピアからの提案に応答して作成される SA の粒度を定義するために使用されます。SPD エントリの詳細な構造はセクション 4.4.1.2 で説明されています。すべての SPD には、他に一致しないものすべてに一致し、それを破棄する名目上の最終エントリが必要です (SHOULD)。

SPD は、ユーザーまたは管理者が次のようにポリシーエントリを指定できるようにする必要があります (MUST):

  • SPD-I: バイパスまたは破棄されるインバウンドトラフィックの場合、エントリは、バイパスまたは破棄されるトラフィックに適用されるセレクタの値で構成されます。

  • SPD-O: バイパスまたは破棄されるアウトバウンドトラフィックの場合、エントリは、バイパスまたは破棄されるトラフィックに適用されるセレクタの値で構成されます。

  • SPD-S: IPsec を使用して保護されるトラフィックの場合、エントリは、AH または ESP を介して保護されるトラフィックに適用されるセレクタの値、これらのセレクタに基づいて SA を作成する方法に関する制御、およびこの保護を実現するために必要なパラメータ (例: アルゴリズム、モードなど) で構成されます。SPD-S エントリには、「パケットから取得」(populate from packet, PFP) フラグなどの情報や、SA ルックアップが SPI に加えてローカルおよびリモート IP アドレスを使用するかどうかを示すビットも含まれることに注意してください。

SPD エントリでの方向性の表現​

IPsec で保護されるトラフィックの場合、SPD エントリ内のローカルアドレスとリモートアドレスおよびポートは、IKE の規則と一致するように、方向性を表すために交換されます。一般に、IPsec が扱うプロトコルには、ローカル/リモート IP アドレスが反転された対称 SA を必要とする特性があります。ただし、ICMP の場合、このような双方向承認要件がないことがよくあります。それにもかかわらず、統一性と簡潔性のために、ICMP の SPD エントリは他のプロトコルと同じ方法で指定されます。また、ICMP、モビリティヘッダー、および非初期フラグメントの場合、これらのパケットにはポートフィールドがないことにも注意してください。

OPAQUE と ANY​

SPD エントリの各セレクタについて、一致を定義するリテラル値に加えて、2 つの特別な値があります: ANY と OPAQUE。

  • ANY: パケットの対応するフィールド内の任意の値に一致するワイルドカード、またはそのフィールドが存在しないか、または不明瞭なパケットに一致します。

  • OPAQUE: 対応するセレクタフィールドがフラグメントに存在しない可能性がある、指定された次層プロトコルには存在しない、または IPsec の事前適用により値が暗号化されている可能性があるため、検査に使用できないことを示します。

ANY 値は OPAQUE 値を包含します。したがって、OPAQUE は、フィールドの任意の許可された値と、フィールドの不在または利用不可能 (暗号化など) のケースを区別する必要がある場合にのみ使用する必要があります。

関連セクション​

に最終更新