1. Introduction (はじめに)
1. Introduction
この文書は, 読者が "Security Architecture for the Internet Protocol" [Ken-Arch] で説明されている用語と概念に精通していることを前提としています。以下, セキュリティアーキテクチャ文書と呼びます。特に, 読者は Encapsulating Security Payload (カプセル化セキュリティペイロード, ESP) と IP Authentication Header (IP 認証ヘッダー, AH) によって提供されるセキュリティサービスの定義, Security Associations (セキュリティアソシエーション) の概念, ESP を AH と組み合わせて使用する方法, および ESP と AH で利用可能なさまざまな鍵管理オプションに精通している必要があります。
キーワード MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, および OPTIONAL は, この文書に出現する場合, RFC 2119 [Bra97] で説明されているように解釈されるものとします。
Encapsulating Security Payload (ESP) ヘッダーは, IPv4 と IPv6 [DH98] で複数のセキュリティサービスを組み合わせて提供するように設計されています。ESP は単独で適用することも, AH [Ken-AH] と組み合わせて使用することも, ネストされた方法で使用することもできます (セキュリティアーキテクチャ文書 [Ken-Arch] を参照)。セキュリティサービスは, 通信する一対のホスト間, 通信する一対のセキュリティゲートウェイ間, またはセキュリティゲートウェイとホスト間で提供できます。さまざまなネットワーク環境で ESP と AH を使用する方法の詳細については, セキュリティアーキテクチャ文書 [Ken-Arch] を参照してください。
ESP ヘッダーは, IP ヘッダーの後, 次のレイヤープロトコルヘッダーの前 (トランスポートモード) または カプセル化された IP ヘッダーの前 (トンネルモード) に挿入されます。これらのモードについては, 以下でより詳しく説明します。
ESP は, 機密性, データ送信元認証, コネクションレス完全性, アンチリプレイサービス (部分的なシーケンス完全性の一形態), および (限定的な) トラフィックフロー機密性を提供するために使用できます。提供されるサービスのセットは, Security Association (SA) 確立時に選択されたオプションと, ネットワークトポロジー内の実装の場所に依存します。
ESP では, 機密性のために暗号化のみを使用することが許可されています。ただし, 一般的に, これは受動的な攻撃者に対してのみ防御を提供することに注意する必要があります。その上に強力な完全性メカニズム (ESP 内または AH を介して個別に提供されるもの) なしで暗号化を使用すると, 一部の形式の能動的攻撃に対して機密性サービスが安全でなくなる可能性があります [Bel96, Kra01]。さらに, 暗号化の前に適用される基礎的な完全性サービス (AH など) は, 必ずしも暗号化のみの機密性を能動的な攻撃者から保護するものではありません [Kra01]。ESP が暗号化のみの SA を許可するのは, これがかなり優れたパフォーマンスを提供し, 依然として十分なセキュリティを提供する可能性があるためです。たとえば, 上位層で認証/完全性保護が独立して提供される場合などです。ただし, この標準では, ESP 実装が暗号化のみのサービスを提供することを要求していません。
データ送信元認証とコネクションレス完全性は共同サービスであり, 以下では総称して "integrity" (完全性) と呼びます。(この用語が使用されるのは, パケット単位で実行される計算がコネクションレス完全性を直接提供するためです。データ送信元認証は, 完全性を検証するために使用される鍵を IPsec ピアの ID にバインドすることによって間接的に提供されます。通常, このバインディングは, 共有対称鍵の使用によって実現されます。) 完全性のみの ESP は, サービス選択オプションとして提供されなければなりません。たとえば, SA 管理プロトコルで交渉可能でなければならず, 管理インターフェースを介して設定可能でなければなりません。完全性のみの ESP は, 多くのコンテキストで AH の魅力的な代替手段です。たとえば, 多くの実装で処理が高速で, パイプライン処理に適しているためです。
機密性と完全性は独立して提供できますが, ESP は通常, 両方のサービスを使用します。つまり, パケットは機密性と完全性の両方に関して保護されます。したがって, これらのサービスに関連する ESP セキュリティサービスの組み合わせには, 3 つの可能性があります:
- confidentiality-only (機密性のみ) (サポートされてもよい)
- integrity only (完全性のみ) (サポートされなければならない)
- confidentiality and integrity (機密性と完全性) (サポートされなければならない)
アンチリプレイサービスは, その SA に対して完全性サービスが選択されている場合にのみ, SA に対して選択できます。このサービスの選択は, 受信者の裁量のみに委ねられているため, 交渉する必要はありません。ただし, 相互運用可能な方法で拡張シーケンス番号機能を使用するために, ESP は SA 管理プロトコルがこの機能を交渉できることを要求します (以下のセクション 2.2.1 を参照)。
トラフィックフロー機密性 (TFC) サービスは, 通常, ESP が通信相手の最終的な送信元アドレスと宛先アドレスを隠す方法で使用されている場合にのみ有効です。たとえば, セキュリティゲートウェイ間のトンネルモードで, IPsec ピア間に十分なトラフィックが流れている場合 (自然に発生するか, マスキングトラフィックの生成の結果として) にのみ, 特定の個々の加入者トラフィックフローの特性を隠すことができます。(ESP は, Onion Routing [Syverson] などの上位層 TFC システムの一部として使用される場合がありますが, そのようなシステムはこの標準の範囲外です。) ESP に存在する新しい TFC 機能は, 後方互換性のある方法で, ダミートラフィックの効率的な生成と破棄, および実際のトラフィックのより良いパディングを容易にします。
セクション 7 では, この文書と RFC 2406 の違いについて簡単にレビューします。