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

4.1. 定義と範囲 (Definition and Scope)

SA は、それが伝送するトラフィックにセキュリティサービスを提供する単方向 (simplex) の「接続」です。セキュリティサービスは、AH または ESP のいずれかを使用して SA に提供されますが、両方を同時に使用することはできません。AH と ESP の両方の保護をトラフィックストリームに適用する場合は、2 つの SA を作成して調整し、セキュリティプロトコルの反復適用によって保護を実現する必要があります。IPsec 対応の 2 つのシステム間の典型的な双方向通信を保護するには、SA のペア (各方向に 1 つ) が必要です。IKE は、この一般的な使用要件を認識して、明示的に SA ペアを作成します。

SA 識別​

ユニキャストトラフィックを伝送するために使用される SA の場合、セキュリティパラメータインデックス (Security Parameters Index, SPI) 単独で SA を指定するのに十分です。(SPI の情報については、付録 A および AH と ESP の仕様 [Ken05b, Ken05a] を参照してください。)ただし、ローカルな問題として、実装は SA 識別のために SPI を IPsec プロトコルタイプ (AH または ESP) と組み合わせて使用することを選択できます。IPsec 実装がマルチキャストをサポートする場合、インバウンド IPsec データグラムを SA にマッピングするための以下のアルゴリズムを使用して、マルチキャスト SA をサポートしなければなりません (MUST)。ユニキャストトラフィックのみをサポートする実装は、この逆多重化アルゴリズムを実装する必要はありません。

マルチキャスト SA の考慮事項​

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

SA データベース (SA Database, SAD)(セクション 4.4.2) の各エントリは、SA ルックアップが SPI に加えて、宛先 IP アドレス、または宛先と送信元 IP アドレスを使用するかどうかを示す必要があります。マルチキャスト SA の場合、プロトコルフィールドは SA ルックアップに使用されません。インバウンドの IPsec 保護されたパケットごとに、実装は SAD を検索して、「最長」SA 識別子に一致するエントリを見つける必要があります。この文脈では、2 つ以上の SAD エントリが SPI 値に基づいて一致する場合、宛先アドレス、または宛先と送信元アドレス (SAD エントリに示されているとおり) にも基づいて一致するエントリが「最長」一致です。これは、SAD 検索の論理的な順序を次のように意味します:

  1. SPI、宛先アドレス、および送信元アドレスの組み合わせで SAD を検索します。 SAD エントリが一致する場合、その一致する SAD エントリでインバウンドパケットを処理します。それ以外の場合は、ステップ 2 に進みます。

  2. SPI と宛先アドレスの両方で SAD を検索します。 SAD エントリが一致する場合、その一致する SAD エントリでインバウンドパケットを処理します。それ以外の場合は、ステップ 3 に進みます。

  3. SPI のみで SAD を検索します (受信者が AH と ESP に対して単一の SPI 空間を維持することを選択した場合)、それ以外の場合は SPI とプロトコルの両方で検索します。SAD エントリが一致する場合、その一致する SAD エントリでインバウンドパケットを処理します。それ以外の場合は、パケットを破棄し、監査可能なイベントを記録します。

実際には、実装はこの検索を高速化するために任意の方法 (またはまったく方法を使用しない) を選択できますが、その外部から見える動作は、上記の順序で SAD を検索したのと機能的に同等でなければなりません (MUST)。たとえば、ソフトウェアベースの実装は、SPI によってハッシュテーブルにインデックスを付けることができます。各ハッシュテーブルバケットのリンクリスト内の SAD エントリは、最長の SA 識別子を持つ SAD エントリがそのリンクリストの最初にくるようにソートされた状態を維持できます。最短の SA 識別子を持つ SAD エントリは、リンクリストの最後のエントリになるようにソートできます。ハードウェアベースの実装は、一般的に利用可能な三値連想メモリ (Ternary Content-Addressable Memory, TCAM) 機能を使用して、本質的に最長一致検索を実行できる場合があります。

インバウンド IPsec トラフィックを SA にマッピングするために送信元と宛先のアドレスマッチングが必要かどうかの指示は、手動 SA 構成の副作用として設定されるか、SA 管理プロトコル (例: IKE またはグループ解釈ドメイン (Group Domain of Interpretation, GDOI) [RFC3547]) を使用した交渉によって設定されなければなりません (MUST)。通常、ソース固有マルチキャスト (Source-Specific Multicast, SSM) [HC03] グループは、SPI、宛先マルチキャストアドレス、および送信元アドレスで構成される 3 タプル SA 識別子を使用します。任意ソースマルチキャスト (Any-Source Multicast) グループ SA は、識別子として SPI と宛先マルチキャストアドレスのみを必要とします。

QoS と複数の SA​

異なるクラスのトラフィック (差分化サービスコードポイント (Differentiated Services Code Point, DSCP) ビット [NiBlBaBL98], [Gro02] によって区別される) が同じ SA で送信され、受信者が AH と ESP の両方で利用可能なオプションのアンチリプレイ機能を使用している場合、この機能が使用するウィンドウメカニズムにより、優先度の低いパケットが不適切に破棄される可能性があります。したがって、送信者は、サービス品質 (Quality of Service, QoS) を適切にサポートするために、異なるクラスのトラフィック (ただし同じセレクタ値を持つ) を異なる SA に配置すべきです (SHOULD)。これを許可するために、IPsec 実装は、特定の送信者と受信者の間で、同じセレクタを持つ複数の SA の確立と維持を許可しなければなりません (MUST)。QoS をサポートするためのこれらの並列 SA 間でのトラフィックの分散は、送信者によってローカルで決定され、IKE によって交渉されません。受信者は、異なる SA からのパケットを偏見なく処理しなければなりません (MUST)。これらの要件は、トランスポートモードとトンネルモードの SA の両方に適用されます。トンネルモード SA の場合、問題の DSCP 値は内部 IP ヘッダーに表示されます。トランスポートモードでは、DSCP 値は経路上で変更される可能性がありますが、この値は SA 選択に使用されず、SA/パケット検証の一部としてチェックされてはならない (MUST NOT) ため、IPsec 処理に関して問題を引き起こすべきではありません。ただし、SA でパケットの大幅な並べ替えが発生した場合、例えば経路上での DSCP 値の変更の結果として、これはアンチリプレイメカニズムの適用により受信者によるパケット破棄をトリガーする可能性があります。

議論: DSCP [NiBlBaBL98, Gro02] と明示的輻輳通知 (Explicit Congestion Notification, ECN) [RaFlBl01] フィールドは、このアーキテクチャで使用される用語「セレクタ」ではありませんが、送信者は特定の (セットの) DSCP 値を持つパケットを適切な SA に誘導するメカニズムを必要とします。このメカニズムは「分類器 (classifier)」と呼ばれる場合があります。

トランスポートモード vs トンネルモード​

上記のように、2 つのタイプの SA が定義されています: トランスポートモードとトンネルモード。IKE は SA のペアを作成するため、簡素化のために、ペア内の両方の SA が同じモード、トランスポートモードまたはトンネルモードであることを要求することを選択します。

トランスポートモード SA​

トランスポートモード SA は、エンドツーエンドのセキュリティサービスを提供するために一対のホスト間で通常使用される SA です。パス上の 2 つの中間システム間でセキュリティが必要な場合 (IPsec のエンドツーエンド使用に対して)、トランスポートモードはセキュリティゲートウェイ間、またはセキュリティゲートウェイとホスト間で使用される場合があります (MAY)。トランスポートモードがセキュリティゲートウェイ間またはセキュリティゲートウェイとホスト間で使用される場合、トランスポートモードは、トランスポートモード SA 上での IP 内トンネリング (例: IP-in-IP [Per96] または汎用ルーティングカプセル化 (Generic Routing Encapsulation, GRE) トンネリング [FaLiHaMeTr00] または動的ルーティング [ToEgWa04]) をサポートするために使用される場合があります。明確にするために、中間システム (例: セキュリティゲートウェイ) によるトランスポートモードの使用は、送信元アドレス (アウトバウンドパケットの場合) または宛先アドレス (インバウンドパケットの場合) が中間システム自体に属するアドレスであるパケットに適用される場合にのみ許可されます。IPsec の重要な部分であるアクセス制御機能は、この文脈では大幅に制限されます。これは、この方法で使用されるトランスポートモード SA を通過するパケットのエンドツーエンドヘッダーに適用できないためです。したがって、この方法でトランスポートモードを使用することは、特定の文脈で採用する前に慎重に評価する必要があります。

IPv4 では、トランスポートモードセキュリティプロトコルヘッダーは、IP ヘッダーとオプションの直後、および次層プロトコル (例: TCP または UDP) の前に表示されます。IPv6 では、セキュリティプロトコルヘッダーは、基本 IP ヘッダーと選択された拡張ヘッダーの後に表示されますが、宛先オプションの前または後に表示される場合があります。次層プロトコル (例: TCP、UDP、ストリーム制御伝送プロトコル (Stream Control Transmission Protocol, SCTP)) の前に表示されなければなりません (MUST)。ESP の場合、トランスポートモード SA はこれらの次層プロトコルにのみセキュリティサービスを提供し、IP ヘッダーや ESP ヘッダーの前の拡張ヘッダーには提供しません。AH の場合、保護はその前の IP ヘッダーの選択された部分、拡張ヘッダーの選択された部分、および選択されたオプション (IPv4 ヘッダー、IPv6 ホップバイホップ拡張ヘッダー、または IPv6 宛先拡張ヘッダーに含まれる) にも拡張されます。AH が提供するカバレッジの詳細については、AH 仕様 [Ken05b] を参照してください。

トンネルモード SA​

トンネルモード SA は、本質的に IP トンネルに適用される SA であり、アクセス制御はトンネル内のトラフィックのヘッダーに適用されます。2 つのホストは、相互にトンネルモード SA を確立できます (MAY)。以下の 2 つの例外を除いて、セキュリティアソシエーションのいずれかの端がセキュリティゲートウェイである場合は常に、SA はトンネルモードでなければなりません (MUST)。したがって、2 つのセキュリティゲートウェイ間の SA は通常トンネルモード SA であり、ホストとセキュリティゲートウェイ間の SA も同様です。以下の 2 つが例外です。

  • トラフィックがセキュリティゲートウェイ宛ての場合、 例えば簡易ネットワーク管理プロトコル (Simple Network Management Protocol, SNMP) コマンドの場合、セキュリティゲートウェイはホストとして動作し、トランスポートモードが許可されます。この場合、SA はセキュリティゲートウェイ内のホスト (管理) 機能で終了するため、異なる扱いに値します。

  • 上記のように、 セキュリティゲートウェイは、パス上の 2 つの中間システム間の IP トラフィックにセキュリティを提供するために、トランスポートモード SA をサポートできます (MAY)。例えば、ホストとセキュリティゲートウェイ間、または 2 つのセキュリティゲートウェイ間です。

セキュリティゲートウェイが関与する SA にトンネルモードを使用する理由はいくつかあります。たとえば、セキュリティゲートウェイの背後にある同じ宛先への複数のパス (例: 異なるセキュリティゲートウェイ経由) がある場合、IPsec パケットが SA を交渉したセキュリティゲートウェイに送信されることが重要です。同様に、経路上でフラグメント化される可能性のあるパケットは、暗号処理の前に再構成するために、すべてのフラグメントが同じ IPsec インスタンスに配信される必要があります。また、フラグメントが IPsec によって処理されて送信され、その後経路上でフラグメント化される場合、IPsec 前後のパケット形式のフラグメント化状態データを保持するために内部ヘッダーと外部ヘッダーが存在することが重要です。したがって、SA のいずれかの端がセキュリティゲートウェイである場合にトンネルモードを使用する理由はいくつかあります。(IP-in-IP トンネルをトランスポートモードと組み合わせて使用することも、これらのフラグメント化の問題に対処できます。ただし、この構成では、IPsec がトラフィックにアクセス制御ポリシーを適用する能力が制限されます。)

注意: AH と ESP は、フラグメントである IPv4 パケットにトランスポートモードを使用して適用することはできません。このような場合は、トンネルモードのみを使用できます。IPv6 の場合、トランスポートモード SA で平文フラグメントを伝送することは実行可能です。ただし、簡素化のために、この制限は IPv6 パケットにも適用されます。IPsec バリアの保護側での平文フラグメントの処理の詳細については、セクション 7 を参照してください。

トンネルモード SA の場合、IPsec 処理の送信元と宛先を指定する「外部」IP ヘッダーと、パケットの (見かけ上の) 最終的な送信元と宛先を指定する「内部」IP ヘッダーがあります。セキュリティプロトコルヘッダーは、外部 IP ヘッダーの後、内部 IP ヘッダーの前に表示されます。トンネルモードで AH が使用される場合、外部 IP ヘッダーの部分が保護される (上記のとおり) とともに、トンネル化されたすべての IP パケット (つまり、すべての内部 IP ヘッダーと次層プロトコル) も保護されます。ESP が使用される場合、保護はトンネル化されたパケットにのみ提供され、外部ヘッダーには提供されません。

実装要件​

要約すると、

a) ホストの IPsec 実装は、トランスポートモードとトンネルモードの両方をサポートしなければなりません (MUST)。 これは、ホストのネイティブ、BITS、および BITW 実装のすべてに当てはまります。

b) セキュリティゲートウェイは、トンネルモードをサポートしなければならず (MUST)、トランスポートモードをサポートできます (MAY)。 トランスポートモードをサポートする場合、それはセキュリティゲートウェイがホストとして動作している場合 (例: ネットワーク管理) にのみ使用されるべきです。または、パス上の 2 つの中間システム間でセキュリティを提供する場合です。

に最終更新