1. Introduction (はじめに)

本文書は, 読者が "Security Architecture for the Internet Protocol" [Ken-Arch] (以下, セキュリティアーキテクチャ文書と呼びます) で説明されている用語と概念に精通していることを前提としています。特に, 読者は, Encapsulating Security Payload (ESP) [Ken-ESP] とIP認証ヘッダー (AH) が提供するセキュリティサービスの定義, セキュリティアソシエーション (Security Associations) の概念, 認証ヘッダー (AH) と組み合わせてESPを使用する方法, およびESPとAHで利用可能な異なる鍵管理オプションについて精通している必要があります。

本文書に記載されているキーワードMUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, およびOPTIONALは, RFC 2119 [Bra97] に記載されているとおりに解釈されるものとします。

IP認証ヘッダー (AH) は, IPデータグラム (以下, 単に「完全性」と呼びます) にコネクションレス完全性とデータ発信元認証を提供し, リプレイ攻撃に対する保護を提供するために使用されます。この後者のオプションサービスは, セキュリティアソシエーション (SA) が確立されるときに, 受信者によって選択される場合があります。(プロトコルのデフォルトでは, 送信者がアンチリプレイに使用されるシーケンス番号をインクリメントする必要がありますが, このサービスは受信者がシーケンス番号をチェックする場合にのみ有効です。) ただし, 相互運用可能な方法で拡張シーケンス番号機能を利用するには, AHはSA管理プロトコルに対して, この新機能をネゴシエートできる要件を課します (以下のセクション2.5.1を参照してください)。

AHは, 次レベルプロトコルデータだけでなく, 可能な限り多くのIPヘッダーに対して認証を提供します。ただし, 一部のIPヘッダーフィールドは転送中に変更される可能性があり, パケットが受信者に到達したときのこれらのフィールドの値は, 送信者によって予測できない場合があります。このようなフィールドの値は, AHによって保護することはできません。したがって, AHによってIPヘッダーに提供される保護は断片的です。(付録Aを参照してください。)

AHは, 単独で, IPカプセル化セキュリティペイロード (ESP) [Ken-ESP] と組み合わせて, またはネストされた方法で適用される場合があります (セキュリティアーキテクチャ文書 [Ken-Arch] を参照してください)。セキュリティサービスは, 通信ホストのペア間, 通信セキュリティゲートウェイのペア間, またはセキュリティゲートウェイとホスト間で提供できます。ESPは, 同じアンチリプレイサービスと同様の完全性サービスを提供するために使用される場合があり, 機密性 (暗号化) サービスも提供します。ESPとAHによって提供される完全性の主な違いは, カバレッジの範囲です。具体的には, ESPは, これらのフィールドがESPによってカプセル化されていない限り (例: トンネルモードの使用による), IPヘッダーフィールドを保護しません。さまざまなネットワーク環境でAHとESPを使用する方法の詳細については, セキュリティアーキテクチャ文書 [Ken-Arch] を参照してください。

セクション7は, 本文書とRFC 2402 [RFC2402] との相違点の簡単なレビューを提供します。