ネットワークワーキンググループ
Request for Comments: 2401
廃止: 1825
分類: スタンダードトラック		 S. Kent
BBN Corp
R. Atkinson
@Home Network
1998年11月

インターネットプロトコルのためのセキュリティアーキテクチャ
(Security Architecture for the Internet Protocol)

このメモの位置付け 
この文書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものである。
このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照すること。
このメモの配布に制限はない。
著作権
Copyright (C) The Internet Society (1998). All Rights Reserved.
目次 
1. はじめに
1.1 文書の要旨
1.2 対象とする読者
1.3 関連文書
2. 設計の目的
2.1 目標、目的、要求条件および問題点
2.2 注意および前提
3. システム概要
3.1 IPsec が行うこと
3.2 IPsec の動作
3.3 IPsec の実装場所
4. セキュリティアソシエーション
4.1 定義と範囲
4.2 セキュリティアソシエーションの機能
4.3 セキュリティアソシエーションの結合
4.4 セキュリティアソシエーションデータベース
4.4.1 セキュリティポリシーデータベース（SPD）
4.4.2 セレクタ
4.4.3 セキュリティアソシエーションデータベース（SAD）
4.5 セキュリティアソシエーションの基本的な組み合わせ

4.6 SA と 鍵の管理

4.6.1 マニュアル手法
4.6.2 SA および鍵の自動管理
4.6.3 セキュリティゲートウェイの位置探索
4.7 セキュリティアソシエーションとマルチキャスト
5. IP トラフィック処理
5.1 出力 IP トラフィック処理
5.1.1 SA または SA バンドルの選択と使用
5.1.2 トンネルモードでのヘッダ構成
5.1.2.1 トンネルモードでのヘッダ構成（IPv4）
5.1.2.2 トンネルモードでのヘッダ構成（IPv6）
5.2 入力 IP トラフィック処理
5.2.1 SA または SA バンドルの選択と使用
5.2.2 AH および ESP トンネルの処理方法
6. （IPsec と関連する）ICMP 処理
6.1 PMTU および DF 処理
6.1.1 DF ビット
6.1.2 経路 MTU 探索（PMTU）
6.1.2.1 PMTU の伝播
6.1.2.2 PMTU の計算
6.1.2.3 PMTU 処理のグラニュラリティ
6.1.2.4 PMTU のエージング
7. 監査

8. 情報フローセキュリティをサポートするシステムでの利用

8.1 セキュリティアソシエーションとデータセンシティビティの関係
8.2 センシティビティの一貫性チェック
8.3 セキュリティアソシエーションデータベース用の追加 MLS 属性
8.4 MLS ネットワーキング用の追加入力処理ステップ
8.5 MLS ネットワーキング用の追加出力処理ステップ
8.6 セキュリティゲートウェイ用の追加 MLS 処理
9. 性能に関する問題

10. 準拠に関する要求条件

11. セキュリティに関する考慮事項

12. RFC 1825 との相違点

謝辞

付録 A  用語集

付録 B  PMTU、DF、分割に関する問題についての解釈および議論

B.1 DF ビット
B.2 分割
B.3 経路 MTU 探索
B.3.1 生成元ホストの識別
B.3.2 PMTU の計算
B.3.3 PMTU データのメンテナンスにおけるグラニュラリティ
B.3.4 PMTU データのソケット別メンテナンス
B.3.5 PMTU データのトランスポート層への配送
B.3.6 PMTU データのエージング
付録 C  シーケンススペースウィンドウコードの例

付録 D  ICMP メッセージの分類

参考文献

否認事項

著者の連絡先

著作権表示全文

1. はじめに 
1.1 文書の要旨 
このメモでは、IPsec に準拠するシステムの基本的なアーキテクチャについて定義する。
このアーキテクチャの目標は、IPv4 および IPv6 の両方の環境において、IP 層のトラフィックに様々なセキュリティサービスを提供することである。
この文書では、システムの目標、システムの構成要素、そしてその構成要素がどのように連携するのか、どのように IP 環境へ適用されるのかということについて定義する。
ただし、この文書では、IPsec アーキテクチャのすべての側面を取り上げることはしない。
これに続く別の文書において、NAT 環境における IPsec の利用法や IP マルチキャストのより完全なサポートなど、さらに進んだ機能のより詳細なアーキテクチャについて取り上げる予定である。
以下の IPsec セキュリティアーキテクチャの主要な構成要素について、必要とされる基本的な機能を紹介する。
(a), (c), (d) のプロトコルは、これに追加される別の RFC （別の文書へのポインタは 1.3 章を参照のこと） において定義される。
  1. セキュリティプロトコル -- 認証ヘッダ（Authentication Header（AH））および IP 暗号ペイロード（Encapsulating Security Payload（ESP））
  2. セキュリティアソシエーション -- セキュリティアソシエーションとは何か、その動作、管理方法、関連する処理について
  3. 鍵管理 -- マニュアルおよび自動鍵管理（Internet Key Exchange（IKE））
  4. 認証および暗号化のためのアルゴリズム
この文書では、インターネットにおける総合的なセキュリティアーキテクチャを扱うのではなく、暗号とプロトコルのセキュリティの仕組みの組み合わせによって提供される、IP 層におけるセキュリティのみを扱う。

この文書において、しなければならない (MUST)、してはならない (MUST NOT)、要求される (REQUIRED)、することになる (SHALL)、することはない (SHALL NOT)、する必要がある (SHOULD)、しないほうがよい (SHOULD NOT)、推奨される (RECOMMENDED)、してもよい (MAY)、選択できる (OPTIONAL) のキーワードが使用された場合は、RFC 2119 [Bra97] における定義に沿って解釈されるものとする。

1.2 対象とする読者 
この文書が対象とする読者には、IP セキュリティ技術を実装しようとする者、およびこのシステムの一般的な背景の習得に関心のある者が含まれる。
特に、この技術を将来利用しようとするユーザ（エンドユーザまたはシステム管理者）が対象として含まれる。
知識の背景と語彙のギャップを埋めるために、用語集を付録として付けておく。
この文書では、読者がインターネットプロトコルおよび関連するネットワーク技術、そして一般的なセキュリティ用語とコンセプトに精通していることを前提とする。
1.3 関連文書 
上で説明したように、IPsec の構成要素の一部、およびその相互関係について詳細に定義する文書が他に存在する。
それには、以下に関する RFC が含まれる。
  1. 「IP セキュリティ文書体系（IP Security Document Roadmap）」 [TDG97] -- このシステムで使用される暗号化および認証アルゴリズムを定義する仕様書のためのガイドラインを提供する文書。
  2. セキュリティプロトコル -- 認証ヘッダ（AH）[KA98a] および IP 暗号ペイロード（ESP）[KA98b] プロトコルを定義する RFC。
  3. 認証および暗号化のためのアルゴリズム -- それぞれのアルゴリズムについての個々の RFC。
  4. 自動鍵管理 -- 「Internet Key Exchange (IKE)」 [HC98]、「The Internet Security Association and Key Management Protocol (ISAKMP) [MSST97]、「The OAKLEY Key Determination Protocol」 [Orm97]、そして「The Internet IP Security Domain of Interpretation for ISAKMP」 [Pip98] の RFC。
2. 設計の目的 
2.1 目標、目的、要求条件および問題点 
IPsec は、IPv4 および IPv6 に対して、相互接続可能で高品質な暗号化ベースのセキュリティを提供するように設計されている。
提供されるセキュリティサービスには、アクセス制御、コネクションレスインテグリティ、データ送信元認証、リプレイに対する保護（部分的なシーケンスインテグリティの形式）、機密性（暗号）、そして限定されたトラフィックフロー機密性が含まれる。
これらのサービスは IP 層において提供され、IP とその上位層プロトコルの保護機能を提供する。

これらのサービスの目標は、認証ヘッダ（AH）と IP 暗号ペイロード（ESP）の 2 つのトラフィックセキュリティプロトコルの利用、および暗号鍵管理手法とそのプロトコルの利用によって達成される。
使用される IPsec プロトコルのセット、およびプロトコルの使用法は、ユーザ、アプリケーション、そしてサイト/組織のセキュリティ要件とシステム要件によって決定される。

正確に実装され、使用された場合には、これらの仕組みは、トラフィックの保護にこれらのセキュリティの仕組みを使用しないユーザ、ホスト、およびその他のインターネット構成要素に対して不利な影響を及ぼすものであってはならない。
また、これらの仕組みはアルゴリズムに依存しないように設計されている。
このモジュラー方式により、実装の他の部分へ影響を与えることなく、異なるアルゴリズムのセットを選択することが可能となる。
例えば、必要であれば（小集団を作ることにより）ユーザコミュニティ毎に異なるアルゴリズムのセットを選択する場合があるだろう。

インターネット全体における相互接続性を促進するため、デフォルトのアルゴリズムの標準セットが指定されている。
これらのアルゴリズムを IPsec トラフィック保護プロトコルおよび鍵管理プロトコルと連携して利用することにより、システム開発者およびアプリケーション開発者が、インターネット層における高品質な暗号セキュリティ技術を実装することが可能となる。

2.2 注意および前提 
IPsec プロトコル群とそのデフォルトのアルゴリズムは、インターネットトラフィックに高品質なセキュリティを提供するために設計されている。
しかしながら、これらのプロトコルの利用によって提供されるセキュリティは、プロトコルの実装品質に完全に依存しており、その問題はこの標準セットの範囲外である。
さらに、コンピュータシステムやネットワークのセキュリティは、人的、物理的、手順、危険からの影響や、コンピュータセキュリティ対策などを含む多くの要因からなっている。
このように、IPsec は、総合的なシステムセキュリティアーキテクチャの一部に過ぎないのである。

最後に、IPsec によってもたらされるセキュリティは、IPsec の実装される運用環境の多くの要因に深く依存している。
例えば、OS のセキュリティ上の欠陥、低品質な乱数発生源、ずさんなシステム管理手順や手法などはすべて、IPsec によって提供されるセキュリティを低下させる要因となり得る。
このようないかなる環境上の属性も、IPsec 標準の範囲には含まない。

3. システム概要 
この章では、IPsec の動作、システムの構成要素、そして上で述べたセキュリティサービスを提供するために各構成要素がどのように連携するかということについて概要を述べる。
ここでの目標は、読者が処理とシステムの全体について 「想像」 でき、それが IP 環境にどのように適用されるのかを目にすることができるようにすること、そして各構成要素をより詳細に記述したこの文書の後半部分の周辺状況を提供することである。

IPsec の実装は、ホストまたはセキュリティゲートウェイ環境で動作し、IP トラフィックに対する保護を提供する。
提供される保護は、ユーザまたはシステム管理者によって作成、管理されるセキュリティポリシーデータベース（Security Policy Database（SPD））、または、ユーザまたはシステム管理者が作る制約内で動作するアプリケーションによって定義される要求条件に基づいている。
一般的に、パケットはデータベース（SPD）のエントリにマッチした IP およびトランスポート層ヘッダの情報に従って、3 つの処理モードのうちの 1 つに選択される（4.4.2 章 のセレクタ）。
各パケットは、セレクタによって識別される適用可能なデータベースのポリシーに従って、IPsec セキュリティサービスが適用されるか、そのパケットが破棄されるか、またはそのパケットが IPsec をバイパスされるかのいずれかの処理がされる。

3.1 IPsec が行うこと 
IPsec では、システムに要求されるセキュリティプロトコルを選択させ、サービスに利用するアルゴリズムを決定させ、要求されたサービスの提供に必要な暗号鍵を配備させることによって、IP 層におけるセキュリティサービスを提供する。
IPsec は、ホスト間、セキュリティゲートウェイ間、およびセキュリティゲートウェイとホストの間の 1 つ以上の「経路」の保護に利用できる（「セキュリティゲートウェイ」は、IPsec プロトコルを実装する中間システムを表すものとして、IPsec 文書全体で用いられる。例えば、IPsec を実装するルータやファイアウォールはセキュリティゲートウェイとなる）。

IPsec が提供可能なセキュリティサービスには、アクセス制御、コネクションレスインテグリティ、データ送信元認証、リプレイパケットの拒否（部分的なシーケンスインテグリティの形式）、機密性（暗号）、そして限定されたトラフィックフロー機密性が含まれる。
これらのサービスは IP 層において提供されるため、上位層プロトコル、すなわち、TCP、UDP、ICMP、BGP などでも利用することが可能である。

IPsec DOI はまた、IP 圧縮のネゴシエーション [SMPT98] もサポートする。
これは、IPsec で暗号化が使用された場合に下位プロトコル層による効果的な圧縮が妨げられるという観測が一部動機となっている。

3.2 IPsec の動作 
IPsec はトラフィックセキュリティを提供するために、認証ヘッダ（AH）および暗号ペイロード（ESP）の 2 つのプロトコルを使用する。
各プロトコルの詳細はそれぞれの RFC において定義される [KA98a, KA98b]。 これらのプロトコルは、IPv4 および IPv6 において希望するセキュリティサービスのセットを提供するために、単独でも組み合わせて適用しても良い。
各プロトコルは、2 つの使用モード（トランスポートモードとトンネルモード）をサポートする。
トランスポートモードでは、プロトコルは主に上位層プロトコルの保護を提供し、トンネルモードでは、トンネル IP パケットに対してプロトコルが適用される。
2 つのモードの違いについては、4 章にて説明する。

IPsec はユーザ（またはシステム管理者）に対し、セキュリティサービスが提供されるグラニュラリティの制御を許可する。
例えば、2 つのセキュリティゲートウェイ間のすべてのトラフィックを運ぶ 1 つの暗号化トンネルを作成することもできるし、これらのゲートウェイを越えて通信するホスト間の各 TCP コネクションのために別の暗号化トンネルを作成することもできる。
IPsec の管理は、以下の事項を指定するための機能を持たなければならない。

これらのセキュリティサービスは共有秘密値（暗号鍵）を使用するため、IPsec はこれらの鍵を配備する独立した仕組みのセットに依存する（鍵は認証/インテグリティおよび暗号化サービスに使用される）。
この文書では、鍵のマニュアル配送および自動配送の両方のサポートを要求する。
この文書では、自動鍵管理にある特定の公開鍵ベースのアプローチ（IKE -- [MSST97、Orm97、HC98]）を指定するが、その他の自動鍵配送技術を利用してもよい (MAY)。
例えば、ケルベロスのような KDC ベースのシステムや SKIP のような公開鍵システムを利用することができる。
3.3 IPsec の実装場所 
ホスト上で、または（セキュリティゲートウェイを構築するために）ルータやファイアウォールと連携して IPsec を実装するには、いくつかの方法がある。
一般的な例を以下に示す。
  1. ネイティブ IP 実装と IPsec の統合。
    これには、IP 送信元コードへのアクセスが必要であるが、ホストおよびセキュリティゲートウェイの両方に適用可能である。

  2. 「bump-in-the-stack」（BITS）実装。IPsec をネイティブ IP とローカルネットワークの間の、既存の IP プロトコルスタック実装の下に実装するもの。
    この場合、IP スタックに対する送信元コードアクセスは要求されないため、この実装アプローチは既存システムでの利用に適したものとなっている。
    このアプローチは通常ホスト上で使用される。

  3. 外部暗号化プロセッサの使用は、軍事および一部の商用システムで使用されるネットワークセキュリティシステムの共通設計思想である。
    これはしばしば、「bump-in-the-wire」（BITW）実装と呼ばれる。
    この実装は、ホストまたはゲートウェイ（あるいは両方）へのサービスのために設計される場合がある。
    通常、BITW デバイスには IP アドレスを付与することが可能である。
    これは、単独ホストをサポートする場合は BITS 実装に非常に似ているが、ルータまたはファイアウォールをサポートする場合はセキュリティゲートウェイのように動作しなければならない。
4. セキュリティアソシエーション 
この章では、すべての IPv6 の実装、および AH、ESP、または両方を実装する IPv4 の実装のための、セキュリティアソシエーションの管理に関する要求条件を定義する。
「セキュリティアソシエーション」（SA）の概念は IPsec の基本となるものである。
AH および ESP の両方が SA を使用し、IKE の主要機能によって、セキュリティアソシエーションの確立とメンテナンスがなされる。
AH または ESP のすべての実装は、以下に示すセキュリティアソシエーションの概念をサポートしなければならない (MUST)。
この章の備考では、セキュリティアソシエーションの管理における様々な側面について説明し、SA ポリシー管理、トラフィック処理、SA 管理技術に要求される特長を定義する。
4.1 定義と範囲 
セキュリティアソシエーション（SA）は、それによって運ばれるトラフィックに対してセキュリティサービスを提供する単方向の「コネクション」である。
セキュリティサービスは、AH または ESP のいずれか（両方ではない）を使用することによって SA に提供される。
AH および ESP 保護の両方がトラフィックの流れに対して適用される場合は、そのトラフィックの流れを保護するために複数の SA が生成される。
2 つのホスト間、または 2 つのセキュリティゲートウェイ間の双方向の通信を保護するためには、2 つのセキュリティアソシエーション（それぞれの方向に 1 つづつ）が必要である。

セキュリティアソシエーションは、セキュリティパラメータインデックス（Security Parameter Index（SPI））、IP 宛先アドレス、セキュリティプロトコル（AH または ESP）識別子の 3 つによって一意に識別される。
原則として、宛先アドレスはユニキャストアドレス、IP ブロードキャストアドレス、またはマルチキャストグループアドレスとなる。
ただし、IPsec の SA 管理の仕組みは現在のところ、ユニキャスト SA に対してのみが定義されている。
以下に説明するように、SA の概念は 2 点間の通信の場合において記述するが、1 対 N の場合にも適用可能である。

前に説明したように、2 つのタイプ（トランスポートモードおよびトンネルモード）の SA が定義される。
トランスポートモード SA は、2 つのホスト間のセキュリティアソシエーションである。
IPv4 では、トランスポートモードのセキュリティプロトコルヘッダは、IP ヘッダとすべてのオプションの直後、すべての上位層プロトコル（例えば TCP、UDP など）の直前に現れる。
IPv6 では、セキュリティプロトコルヘッダは、基本 IP ヘッダおよび拡張ヘッダの後に現れるが、宛先オプションの前または後、および上位層プロトコルの前に現れる可能性がある。
ESP の場合、トランスポートモード SA は、上位層プロトコルに対するセキュリティサービスのみを提供し、IP ヘッダや、ESP ヘッダに先行する拡張ヘッダにはサービスは提供されない。
AH の場合、IP ヘッダの選択された部分、拡張ヘッダの選択された部分、および選択されたオプション（IPv4 ヘッダ、IPv6 中継点拡張ヘッダ、または IPv6 宛先拡張ヘッダに含まれる）にも保護が拡張される。
AH のカバー範囲についての詳細は、AH の仕様 [KA98a] を参照のこと。

トンネルモード SA は、基本的に IP トンネルに対して適用される SA である。
セキュリティアソシエーションの終端の一方がセキュリティゲートウェイである場合は、常に、SA はトンネルモードでなければならない (MUST)。
従って、2 つのセキュリティゲートウェイ間の SA は常にトンネルモード SA であり、ホストとセキュリティゲートウェイの間の SA も同様にトンネルモードとなる。
ただし、セキュリティゲートウェイ行きのトラフィックの場合（例えば SNMP コマンド）は、セキュリティゲートウェイはホストとして動作し、トランスポートモードが許可されることに注意すること。
しかしこの場合、セキュリティゲートウェイはゲートウェイとして動作せず、すなわちトラフィックは転送しない。
また、2 つのホスト間でトンネルモードを確立してもよい (MAY)。
IPsec パケットの分割と再構成に関する潜在的問題を回避する必要のため、さらにセキュリティゲートウェイの背後の同じ宛先に対して複数の経路が存在する状況（例えば異なるセキュリティゲートウェイを経由する場合）では、トンネル SA となるセキュリティゲートウェイを含むすべての（通過トラフィック）SA が要求される。

トンネルモード SA には、IPsec 処理の宛先を示す 「外側」 IP ヘッダに加え、（外見上）パケットの最終の宛先を指定する「内側」 IP ヘッダが存在する。
セキュリティプロトコルヘッダは、外側 IP ヘッダの後、および内側 IP ヘッダの前に現れる。
AH がトンネルモードで使用される場合、外側 IP ヘッダの一部に保護が与えられるとともに、トンネルされたすべての IP パケットが保護される（すなわち、すべての内側 IP ヘッダと上位層プロトコルが保護される）。
ESP が使用される場合は、トンネルされたパケットのみが保護され、外側ヘッダは保護されない。

以上まとめると、

  1. ホストはトランスポートモードとトンネルモードの両方をサポートしなければならない (MUST)。
  2. セキュリティゲートウェイはトンネルモードのサポートのみが要求される。
    トランスポートモードをサポートする場合は、それはセキュリティゲートウェイがホストとして動作する場合のみに使用される必要がある（例えばネットワーク管理など）。
4.2 セキュリティアソシエーションの機能 
SA が提供するセキュリティサービスは、選択されたセキュリティプロトコル、SA モード、SA の終端、およびプロトコルでのオプションのサービスの選定に依存する。
例えば、AH は IP データグラムにデータ送信元認証とコネクションレスインテグリティを提供する（以降、単に「認証」と呼ぶことにする）。
認証サービスの「精度」は、AH が使用されるセキュリティアソシエーションのグラニュラリティの機能であり、これについては 4.4.2 章の「セレクタ」で説明する。

AH はまた、サービス妨害攻撃に対抗するために、受信側の選択でリプレイ防御サービス（部分的なシーケンスインテグリティ）を提供する。
機密性が要求されない（あるいは、例えば暗号化の利用に関する政府規制のために機密性が許可されない）場合には、AH が適切なプロトコルとして使用される。
AH はまた、IP ヘッダの選択された部分に対する認証も提供し、これはある時に必要となる場合がある。
例えば、IPv4 オプションまたは IPv6 拡張ヘッダのインテグリティが、送信側と受信側の経路間で保護されなければならない場合に、AH のこのサービスを提供することができる（予測不可能に変化する IP ヘッダの部分を除く）。

ESP はオプションでトラフィックの機密性を提供する。（機密性サービスの強度は、使用する暗号化アルゴリズムに一部依存する。）
ESP は（上で定義したように）オプションで認証も提供する。
認証が ESP SA でネゴシエートされる場合には、受信側が AH リプレイ防御サービスと同じ機能を持つリプレイ防御サービスの適用を選択する場合がある。
ESP が提供する認証の範囲は、AH のものより狭い。
すなわち、ESP ヘッダの「外側にある」 IP ヘッダは保護されない。
上位層プロトコルのみの認証が必要であるならば、ESP 認証を選択することが適切であり、この場合 AH カプセル化 ESP を使用するよりもスペース効率がよい。
ここで、機密性と認証はいずれもオプションであるが、除外することができないことに注意すること。
少なくともどちらか 1 つは選択しなければならない (MUST)。

機密性サービスを選択する場合、2 つのセキュリティゲートウェイ間の ESP（トンネルモード）SA は、部分的なトラフィックフロー機密性を提供することができる。
トンネルモードを使用することによって、内側 IP ヘッダが暗号化され、（最終端の）トラフィックの送信元と宛先の情報が隠される。
さらにパケットサイズを隠すために、 ESP ペイロードでパディングも実行され、トラフィックの外部特性を隠すことができる。
同様のトラフィックフロー機密性サービスは、ダイアルアップ環境でモバイルユーザが動的 IP アドレスを割り当てられ、企業のファイアウォール（セキュリティゲートウェイとして動作）に対して、（トンネルモード）ESP SA を確立する際に提供される場合がある。
ここで、一般的に細かいグラニュラリティの SA は、多くの加入者からトラフィックを運ぶ粗いグラニュラリティの SA に比べ、トラフィック解析に対してより脆弱であることに注意すること。

4.3 セキュリティアソシエーションの結合 
個々の SA 上を転送される IP データグラムには、AH または ESP のいずれか一方（両方ではない）のセキュリティプロトコルによる保護が与えられる。
場合によっては、単独の SA で達成できない特定のトラフィックフローに対して、セキュリティポリシーがサービスの結合を要求することもある。
このような場合、要求されるセキュリティポリシーを実現するために、複数の SA を使用することが必要となるだろう。
ここで、セキュリティポリシーを満足するためにトラフィックを処理しなければならない SA のシーケンスに対して「セキュリティアソシエーションバンドル」または「SA バンドル」という言葉を適用することにする（バンドルを構成する SA は、異なる終端で終了する場合があることに注意すること。例えば、ある SA がモバイルホストとセキュリティゲートウェイの間に存在し、2 番目の入れ子にされた SA はゲートウェイの背後のホストに対して存在することがある）。

セキュリティアソシエーションは 2 つの方法（トランスポート隣接と反復トンネリング）でバンドルされる。

これらの 2 つのアプローチは、結合することも可能である。
例えば、SA バンドルを 1 つのトンネルモード SA と 1 つまたは 2 つのトランスポートモード SA から順番に組み立てることができる（4.5 章 「セキュリティアソシエーションの基本的な組み合わせ」を参照）。
ここで、入れ子にされたトンネルは、どのトンネルの送信元終点も宛先終点も重ならない場合にも起こり得ることに注意すること。
この場合は、入れ子にされたトンネルに対応するバンドルを持つホストまたはセキュリティゲートウェイは存在しないことになる。

トランスポートモード SA でのセキュリティプロトコルの順序は、ただ 1 つだけが適しているようである。
AH は上位層プロトコルと IP ヘッダ（の一部）の両方に適用される。
従って、AH をトランスポートモードで ESP と組み合わせて使用する場合は、AH はESP が出現する前の、IP ヘッダの後の最初のヘッダとして現れる必要がある (SHOULD)。
この場合、AH は ESP の暗号文の出力に対して適用される。
それとは対照的に、トンネルモード SA では、AH と ESP を様々な順序で使用することが想定できる。
IPsec に準拠する実装がサポートしなければならない (MUST)、必須の SA バンドルタイプのセットについては、4.5 章にて説明する。

4.4 セキュリティアソシエーションデータベース 
IPsec の実装における IP トラフィック処理に関連する部分の詳細の多くは、ローカルの問題であり標準化するには適さない。
しかしながら、処理の外部側面については、相互接続性の確保、および IPsec の効率的な利用にとって重要な最小限の管理機能を提供するために標準化されなければならない。
これらの相互接続性と機能上の目標のため、この章ではセキュリティアソシエーションに関連する IP トラフィック処理のための一般モデルについて説明する。
以下に示すモデルは名目上のものであり、準拠する実装はこのモデルで示す詳細に一致させる必要はないが、実装の外部動作はこのモデルの外部から見える特長に対応付けることが可能でなければならない。

このモデルでは、2 つの名目上のデータベース、セキュリティポリシーデータベースとセキュリティアソシエーションデータベースが存在する。
前者は、ホスト、セキュリティゲートウェイ、BITS または BITW IPsec 実装からのすべての入力/出力トラフィックの処理を決定するポリシーを指定する。
後者は、それぞれの（アクティブな）セキュリティアソシエーションに関連するパラメータを含むデータベースである。
この章ではさらに、トラフィックをポリシーすなわち SA （または SA バンドル）に対応付けるためにセキュリティポリシーデータベースが使用する、IP および上位層プロトコルフィールド値のセットであるセレクタの概念についても定義する。

IPsec が有効となる各インタフェースには、セレクタとして使用される多くのフィールドが方向性を持つため、名目上、入力および出力で独立したデータベース（SAD と SPD）が必要とされる。
通常、ホストまたはセキュリティゲートウェイ（SG）のインタフェースは 1 つだけである。
SG は常に少なくとも 2 つのインタフェースを持つが、企業ネットに対する「内部の」インタフェースは通常 IPsec が有効となっていないことから、1 つの SAD ペアと 1 つの SPD ペアのみが必要とされることに注意すること。
その一方、ホストが複数インタフェースを持っていたり、SG が複数の外部インタフェースを持つのであれば、それぞれのインタフェース用に、独立した SAD と SPD のペアを持つ必要がある場合がある。

4.4.1 セキュリティポリシーデータベース（SPD） 
結局、セキュリティアソシエーションは IPsec 環境においてセキュリティポリシーの実行のために使用される管理構造である。
従って、SA 処理の重要な要素は、どのようなサービスをどのような形態で IP データグラムに提供するかを指定する、基本的なセキュリティポリシーデータベース（SPD）である。
データベースとそのインタフェースの形式についてはこの仕様の範囲外である。
しかしながら、この章では、ホストによって送信または受信されるトラフィックや、セキュリティゲートウェイを通過するトラフィックに対する IPsec の適用をユーザやシステム管理者が管理できるようにするために必要な最低限の管理機能について定義する。

非 IPsec トラフィックを含むすべてのトラフィック（入力および出力）の処理中に、SPD を参照しなければならない。
これをサポートするために、SPD は入力と出力で別のエントリを必要とする。
これは、（入力および出力で）別の SPD として考えることができる。
さらに、名目上別の SPD が、IPsec が有効な各インタフェースに対して提供されなければならない。

SPD は、IPsec 保護を受けるトラフィックおよび IPsec のバイパスが許可されるトラフィックを識別しなければならない。
これは、送信側によって適用される IPsec 保護、および受信側に存在しなければならない IPsec 保護に適用される。
すべての出力および入力データグラムに対して、3 つの処理（破棄、IPsec のバイパス、IPsec の適用）が選択できる。
最初の選択は、ホストからの出力、セキュリティゲートウェイの通過、アプリケーションへの配送が全く許可されないトラフィックがあてはまる。
2 番目の選択は、IPsec 保護を加えない状態で通過を許可されるトラフィックがあてはまる。
最後の選択は、IPsec 保護が与えられるトラフィックがあてはまり、この場合 SPD は、そのトラフィックに対して提供するセキュリティサービス、使用するプロトコル、使用するアルゴリズムなどを指定しなければならない。

すべての IPsec の実装は、ユーザやシステム管理者が SPD を管理することのできる管理インタフェースを持っていなければならない (MUST)。
特に、すべての入力または出力パケットは IPsec による処理を受けなければならず、SPD はそれぞれの場合にどのような処理を行うのかを指定しなければならない。
従って、管理インタフェースでは、ユーザ（あるいはシステム管理者）が、システムに出入りするすべてのパケットに適用すべきセキュリティ処理をパケット単位で指定できるようにしなければならない。
（ソケットインタフェースを使用するホスト上での IPsec の実装では、SPD にパケット単位の参照を必要としない場合があるが、効果は同じである）。
SPD の管理インタフェースでは、4.4.2 章で定義されるセレクタと一致するエントリの生成を許可しなければならず (MUST)、さらに、これらのエントリの（全体的な）順序付けをサポートしなければならない (MUST)。
様々なセレクタフィールドでワイルドカードが使用されるため、また、単一の UDP または TCP コネクション上のすべてのパケットが 1 つの SPD エントリにマッチする傾向があるため、この要求条件は SPD の仕様に対して過度なレベルの詳細は強制しないと予想される。
セレクタはステートレスなファイアウォールやフィルタリングルータと類似しており、現時点ではこの方法で管理が可能である。

ホストシステムでは、アプリケーションが作成、使用するトラフィックに適用するセキュリティ処理は、そのアプリケーションに選択させてもよい (MAY)。
（IPsec の実装に対するこの要求のシグナリングの手段については、この標準の範囲外である。）
しかし、ユーザまたはアプリケーションが（デフォルトの）システムポリシーを無効にできるか否かについてシステム管理者が指定できるようにしなければならない (MUST)。
ここで、アプリケーションの要件を満たすために必要な IPsec 処理以上の追加処理をシステムが行う必要がないように、アプリケーションが指定するポリシーはシステム要件を満たす場合があることに注意すること。
管理インタフェースの形式についてはこの文書では指定せず、これはホストとセキュリティゲートウェイで異なる場合がある。
また、ホストでは、ソケットベースと BITS 実装でインタフェースが異なる場合がある。
ただし、すべての IPsec 実装がサポートしなければならない (MUST) SPD 要素の標準セットについてはこの文書で定義する。

SPD にはポリシーエントリの順番リストが含まれる。
各ポリシーエントリは、このポリシーエントリに包含される IP トラフィックのセットを定義する 1 つ以上のセレクタをキーとする。（要求されるセレクタタイプは 4.4.2 章で定義する）。
これらはポリシーまたは SA のグラニュラリティを定義する。
各エントリには、このポリシーにあてはまるトラフィックをバイパスさせるか、破棄するか、IPsec 処理を受けさせるかどうかの指示が含まれる。
IPsec 処理が適用される場合、エントリには、使用する IPsec プロトコル、モード、アルゴリズムをリストした、すべての入れ子要件を含む SA （または SA バンドル）仕様が含まれる。
例えば、エントリはマッチしたすべてのトラフィックに対して、HMAC/SHA-1 を使用するトンネルモードの AH の内側に明示的 IV を持つ 3DES-CBC を使用するトランスポートモードの ESP を入れ子にした保護を要求することがある。
ポリシーエントリは各セレクタに対して、SPD とパケット内の値から、新しいセキュリティアソシエーションデータベース（SAD、4.4.3 章を参照のこと）エントリに対応する値を導き出す方法を以下から指定する（現在のところ、範囲指定は IP アドレスに対してのみサポートされているが、ワイルドカードはすべてのセレクタで表現できることに注意すること）。

  1. パケット自身にある値を使用 -- この場合、ポリシーエントリのセレクタが、このセレクタに対して許可される値の範囲またはワイルドカードを持っていたとしても、その SA の使用は、セレクタに対するこのパケットの値を持つパケットのみに限定される。
  2. ポリシーエントリに関連する値を使用 -- これが単独の値となる場合には、(a) と (b) には違いがない。
    しかし、セレクタに対して許可される値が範囲指定（IP アドレス用）またはワイルドカードであれば、範囲指定の場合には、(b) は SA の生成のトリガーとなったパケットのセレクタ値を持つパケットのみならず、その範囲内のセレクタ値を持つあらゆるパケットにその SA の使用が許可される。
    ワイルドカードの場合には、(b) はこのセレクタに対してどの値を持つパケットにもその SA の使用が許可される。
例えば、許可される送信元アドレスの値がホストの範囲（192.168.2.1 から 192.168.2.10）である SPD エントリを考えてみる。
さらに、送信元アドレスが 192.168.2.3 であるパケットが送られるとする。
SA に対して使用される値は、このセレクタに対するポリシーエントリで示されているセレクタ値のソースによって、以下のサンプル値のいずれかとなる。 
                新しい SAD 
SA で使用される  セレクタ値の
値のソース       例
--------------- ------------
a. パケット      192.168.2.3（1 つのホスト）
b. SPD エントリ  192.168.2.1 から 192.168.2.10（ホストの範囲）
ここで、SPD エントリが許可される送信元アドレスとしてワイルドカード値を持っている場合、SAD セレクタ値はワイルドカード（すべてのホスト）となり得ることに注意すること。
ケース (a) は、同じ SPD エントリにマッチするパケットの間であっても共有を禁止するために使用することができる。

後の 4.4.3 章で説明するように、セレクタには「ワイルドカード」エントリが含まれることがあるため、2 つのエントリに対するセレクタは重複する場合がある。（これは、ルータやパケットフィルタリングファイアウォールで発生する ACL またはフィルタエントリの重複と類似している）。
従って、一貫性のある予測可能な処理を保証するため、最初にマッチしたエントリが常に選択されるように、SPD エントリは順序付けされなければならず (MUST)、さらに SPD は常に同じ順序で検索されなければならない (MUST)。
（SPD エントリに対するトラフィック処理の効果が確実でなければならないことからこの要求条件が必要とされるが、一部のセレクタにワイルドカードの使用が与えられた SPD エントリを規則化する方法は存在しない）。
SPD エントリに対するパケットのマッチングに関しての詳細は、5 章で説明する。

ESP が指定される場合、認証または暗号化のいずれかが省略できる（両方を省略することはできない）ことに注意すること。
従って、認証または暗号化アルゴリズムのための SPD 値を「NULL」に設定することができなければならない (MUST)。
ただし、これらのサービスのうち少なくとも 1 つが選択されなければならない (MUST)。
すなわち、両方のサービスを「NULL」に設定できるようにしてはならない (MUST)。

SPD は特定の SA または SA バンドルへトラフィックを対応付けるために使用することができる。
このため、SPD はセキュリティポリシーに対する参考データベースとして、また既存の SA （または SA バンドル）へのマップとして機能することができる。（前に説明した、バイパスおよび破棄についてのポリシーを取り込むため、これらの機能は本来 IPsec の処理ではないのであるが、SPD はこれらの機能へトラフィックをマッピングする手段も提供しなければならない (MUST)。）
SPD の動作は、入力と出力のトラフィックで異なり、ホストとセキュリティゲートウェイ、BITS、BITW 実装でも異なる場合がある。
5.1 章と 5.2 章では、出力および入力処理のための SPD の使用についてそれぞれ説明する。

指定されたトラフィックに複数の SA をある特定の順序で適用するようにセキュリティポリシーで要求する場合があるため、ポリシーエントリは、順序付けに関する要求条件が存在する場合は、その要求条件を SPD 内に保持しなければならない。
従って、出力または入力パケットが SA の順序に沿って処理されなければならないことを、IPsec 実装が決定できるようにしなければならない。
概念的には、出力処理については、アクティブな SA が存在する SPD エントリから（SAD への）リンクが想定され、各エントリは、単独の SA か、SA バンドルを構成する SA の順序付きリストのどちらかで構成される。
パケットが SPD エントリにマッチし、トラフィックを運ぶために使用できる既存の SA または SA バンドルが存在する時、パケットの処理は SA またはリスト上の SA バンドルエントリによって制御される。
複数の IPsec SA が適用される入力 IPsec パケットについては、宛先アドレス、IPsec プロトコル、そして SPI に基づく検索によって 1 つの SA を識別する必要がある。

SPD は、セキュリティゲートウェイの背後にあるエンティティに出入りする、セキュリティおよび鍵管理トラフィック（例えば ISAKMP）を含む、IPsec システムを通過するすべてのトラフィックのフローを制御するために使用される。
これは、ISAKMP トラフィックが SPD 内で明示的に説明されていなければならず、そうでない場合は破棄されることを意味する。
ここで、セキュリティゲートウェイは、例えば ESP パケットに対して SPD 内に破棄エントリを持ったり、あるいはプロキシ鍵交換を提供するなどの様々な方法によって、暗号化されたパケットの通過を禁止することが可能であることに注意すること。
後者の方法では、トラフィックはセキュリティゲートウェイ内の鍵管理モジュールに内部で送られる。

4.4.2 セレクタ 
SA（または SA バンドル）は、SA に対するトラフィックのセットを定義するために使用されるセレクタに応じて、細かい精製 (fine-grained) または粗い精製 (coarse-grained) となる。
例えば、2 つのホスト間のすべてのトラフィックは、1 つの SA を経由させて運ばれても良く、この場合、そのトラフィックには統一されたセキュリティサービスが与えられる。
これとは別に、ホスト間のトラフィックは、使用されるアプリケーションに応じて（次プロトコルフィールドおよびポートフィールドの定義に従って）、SA によって提供されるセキュリティサービスが異なる複数の SA に分散する場合がある。
同様に、セキュリティゲートウェイ間のすべてのトラフィックは、1 つの SA で運ぶことも可能であり、また、それぞれの通信ホスト間に SA を 1 つずつ割り当てることも可能である。
SA のグラニュラリティ制御を容易にするために、SA 管理用に以下のセレクタパラメータをサポートしなければならない (MUST)。
ここで、ESP ヘッダを持つパケットを受信する場合、例えば、カプセル化セキュリティゲートウェイまたは BITW 実装の場合には、トランスポート層プロトコル、送信元/宛先ポート、名前（存在する場合）は「不透明（OPAQUE）」となる場合があることに注意すること。
すなわち、暗号化または分割のためにアクセス不能となる場合がある。
また、送信元アドレス、宛先アドレスとも、IPv4 または IPv6 のどちらかである必要があることに注意すること。 IPsec 実装によって、セレクタの使用法が決定される。
例えば、スタックに統合されたホスト実装ではソケットインタフェースを使用する場合がある。
新しいコネクションが確立される際に、SPD を調べることができ、SA（または SA バンドル）がソケットに結びつけられる。
従って、そのソケットを経て送られるトラフィックは、SPD/SAD の追加検索の結果を必要としない。
これとは対照的に、BITS、BITW またはセキュリティゲートウェイでの実装は、各パケットを調べ、セレクタに基づいて SPD/SAD 検索を行う必要がある。
セレクタフィールドに対して許可され得る値は、トラフィックフロー、セキュリティアソシエーション、セキュリティポリシーの間で異なる。

SPD および SAD 内で表現できる必要のあるエントリの種類を以下の表にまとめる。
これは、エントリが IPsec スクリーニングに支配されるデータトラフィック内のフィールドとどう関係するのかについて示している。（注釈：送信元アドレス (src address) および宛先アドレス (dst address) に対する「wild」または「wildcard」エントリには、マスク (mask)、範囲 (range) などを含む）。 

フィールド     トラフィック値       SAD エントリ         SPD エントリ
--------      -------------   ----------------   --------------------
src addr      single IP addr  single,range,wild  single,range,wildcard
dst addr      single IP addr  single,range,wild  single,range,wildcard
xpt protocol* xpt protocol    single,wildcard    single,wildcard
src port*     single src port single,wildcard    single,wildcard
dst port*     single dst port single,wildcard    single,wildcard
user id*      single user id  single,wildcard    single,wildcard
sec. labels   single value    single,wildcard    single,wildcard

     * トラフィック値が暗号化されるため、これらのフィールドに対する 
       SAD および SPD エントリは「不透明（OPAQUE）」となり得る。
注釈：原則として、SA または SA バンドルをネゴシエートできない SPD 内のセレクタまたはセレクタ値を持つことが可能である。
例として、リスト上の各アイテムに対して別々の SA を生成する、破棄または列挙リストに対するトラフィックを選択するために使用するセレクタ値が含まれる場合がある。
当面、これについてはこの文書の将来のバージョンに委ねるとし、要求されたセレクタのリストとセレクタ値は SPD と SAD で同じであるとする。
しかし、ネゴシエートできないセレクタ値で SA を生成しているとユーザに誤解させないのであれば、これらのセレクタ値の使用をサポートする管理インタフェースを持ってもよい。
例えば、インタフェースでは、ユーザに値の列挙リストを指定させてもよいが、そのリスト上の各アイテムに対する別々のポリシーと SA を結果的に作り出すことになるだろう。
ベンダーは、顧客が容易に明確かつ簡潔なポリシーの仕様の設定ができるようにするため、このようなインタフェースをサポートする可能性がある。
4.4.3 セキュリティアソシエーションデータベース（SAD） 
IPsec の各実装には、名目上のセキュリティアソシエーションデータベースが存在し、ここでは各エントリに、ある 1 つの SA に関連するパラメータが定義される。
SA はそれぞれ SAD 内にエントリを持つ。
出力処理では、エントリは SPD 内のエントリによって指し示される。
ここで、SPD エントリが、現在そのパケットに対して適切な SA を指し示していない場合には、実装は適切な SA （または SA バンドル）を生成し、SPD エントリを SAD エントリにリンクすることに注意すること（5.1.1 章を参照のこと）。
入力処理では、SAD 内の各エントリは、宛先 IP アドレス、IPsec プロトコルタイプ、および SPI によってインデックスされる。
以下のパラメータが SAD 内の各エントリに関連付けられる。
この記述は MIB を意味しているのではなく、IPsec の実装において SA をサポートするために必要最小限のデータ項目の仕様のみを意味するものである。

入力処理用：SAD 内の SA の検索に使用されるパケットフィールドは以下の通り。

4.4.2 章で定義した各セレクタ用に、SAD 内の SA エントリは、SA が生成された時点でネゴシエートされた値を含まなければならない (MUST)。
送信側では、これらの値は、与えられた SA が出力パケットでの使用に適切であるかどうかを判断するために使用される。
これは、使用できる既存の SA が存在するかどうかをチェックする処理の一部である。
受信側では、これらの値は、入力パケットのセレクタ値が SA の値（間接的に、一致するポリシーの値）と一致することをチェックするために使用される。
これは、受信側で SA がこのパケットに対して適切であったことを確認する処理の一部である。（ICMP メッセージのルールについては 6 章を参照のこと。）
これらのフィールドは、4.4.2 章「セレクタ」で定義するように、特定の値、範囲、ワイルドカード、または「不透明（OPAQUE）」の形式を持つことができる。
ここで、ESP SA では、暗号化アルゴリズムまたは認証アルゴリズムが「NULL」となり得ることに注意すること。
ただし、両方とも「NULL」となってはならない (MUST)。

IPsec 処理で使用される SAD フィールドは以下の通り。

4.5 セキュリティアソシエーションの基本的な組み合わせ 
この章では、IPsec に準拠するホストまたはセキュリティゲートウェイがサポートしなければならない (MUST)、セキュリティアソシエーションの 4 つの組み合わせ例について説明する。
これに追加して、トンネルまたはトランスポートモードでの、AH または ESP の別の組み合わせを実装者の判断でサポートしてもよい (MAY)。
準拠する実装は、これら 4 つの組み合わせを生成し、処理できなければならないが (MUST)、どのような組み合わせでも受信し、処理できる必要がある (SHOULD)。
以下の図と文において、基本的なケースについて説明する。
図の記号の意味は以下の通りである。 
==== = 1 つ以上のセキュリティアソシエーション（AH または ESP、トランスポートまたはトンネル）
---- = コネクティビティ（ラベルが付いていれば、管理境界）
Hx   = ホスト x
SGx  = セキュリティゲートウェイ x
X*   = IPsec をサポートする X
注釈：以下のセキュリティアソシエーションは AH または ESP のどちらかとなり得る。
モード（トンネルまたはトランスポート）は、終点の性質によって決められる。
ホスト間の SA では、モードはトランスポートまたはトンネルのどちらかが可能である。

ケース 1. インターネット（またはイントラネット）を介した 2 つのホスト間において、終点間でのセキュリティを提供する場合。 

 ====================================
 |                                  |
H1* ------ (Inter/Intranet) ------ H2*
ここで、トランスポートまたはトンネルモードのどちらかをホストが選択できることに注意すること。
従って、H1 と H2 間のパケット内のヘッダは、以下のいずれかとなる。 
 トランスポート                  トンネル
-----------------          ---------------------
1. [IP1][AH][upper]        4. [IP2][AH][IP1][upper]
2. [IP1][ESP][upper]       5. [IP2][ESP][IP1][upper]
3. [IP1][AH][ESP][upper]
一般的な入れ子をサポートするための要求条件は存在しないが、トランスポートモードでは、AH および ESP の両方をパケットに適用することができることに注意すること。
この場合、SA 確立の手順では、最初に ESP をパケットに適用し、次に AH を適用することを保証しなければならない (MUST)。
ケース 2. これは、単純な仮想私設網 (Virtual Private Network) のサポートを示す。 
                       ===========================
                       |                         |
  ---------------------|----                  ---|-----------------------
  |                    |   |                  |  |                      |
  |  H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2  |
  |        Intranet)       |                  |          Intranet)      |
  --------------------------                  ---------------------------
          管理境界                                      管理境界
この場合では、トンネルモードのみが要求される。
従って、SG1 と SG2 間のパケット内のヘッダは次のどちらかとなる。 
       トンネル
---------------------
4. [IP2][AH][IP1][upper]
5. [IP2][ESP][IP1][upper]
ケース 3. このケースはケース 1 と 2 の組み合わせであり、送信側ホストと受信側ホストの間に終点間でのセキュリティを追加している。
セキュリティゲートウェイの背後にあるホストのために、セキュリティゲートウェイで IPsec トラフィック（ISAKMP トラフィックを含む）を通過させるように設定可能とする以外に、ホストまたはセキュリティゲートウェイに新しい要求条件が追加されることはない。 
     ===============================================================
     |                                                             |
     |                 =========================                   |
     |                 |                       |                   |
  ---|-----------------|----                ---|-------------------|---
  |  |                 |   |                |  |                   |  |
  | H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* |
  |        Intranet)       |                |          Intranet)      |
  --------------------------                ---------------------------
          管理境界                                    管理境界
ケース 4．これは、リモートホスト（H1）が、ある組織のファイアウォール（SG2）に到達し、サーバーなどのマシン（H2）へアクセスするためにインターネットを利用する状況があてはまる。
このリモートホストは、インターネット上のローカル PPP/ARA サーバー（これは図には存在しない）へダイヤルアップし、インターネットを通過して、自組織のファイアウォール（SG2）に至るモバイルホスト（H1）などにもなり得る。
このケースのサポートについての詳細（H1 による SG2 の位置発見、認証、H2 へのオーソライゼーションの確認方法など）は、4.6.3 章の「セキュリティゲートウェイの位置探索」にて説明する。 
======================================================
|                                                    |
|==============================                      |
||                            |                      |
||                         ---|----------------------|---
||                         |  |                      |  |
H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* |
      ^                    |           Intranet)        |
      |                    ------------------------------
 PPP/ARA サーバーへの            管理境界（オプション）
 ダイヤルアップの場合あり
H1 と SG2 の間にはトンネルモードのみが要求される。
従って、H1 と SG2 間の SA の選択は、ケース 2 での選択のうちのどちらか 1 つとなる。
H1 と H2 の間の SA の選択はケース 1 での選択のうちのどれか 1 つである。

ここで、このケースでは、送信側はトンネルヘッダの前にトランスポートヘッダを適用しなければならない (MUST) ことに注意すること。
従って、IPsec の実装への管理インタフェースは、この IPsec ヘッダの適用の順番を保証するために、SPD と SAD の設定をサポートしなければならない (MUST)。

前に説明したように、これに加えて別の AH と ESP の組み合わせをオプションでサポートできる。
他のオプションの組み合わせの使用により、相互接続性に反する影響が出る場合がある。
4.6 SA と鍵の管理 
IPsec では、マニュアルおよび自動の SA および暗号鍵の管理のサポートを義務付けている。
関連する SA 管理手法は、IPsec プロトコル、すなわち AH と ESP によって提供されるセキュリティサービスの一部に影響を及ぼすが、IPsec プロトコルは、その関連する手法とは大部分独立している。
例えば、AH と ESP で利用できるオプションのリプレイ防御サービスでは、自動 SA 管理が要求される。
さらに、IPsec で使用される鍵配送のグラニュラリティは、提供される認証のグラニュラリティを決定する（4.7 章でのこの問題についての議論も参照のこと）。
一般的に、AH および ESP におけるデータ送信元認証は、認証アルゴリズム（またはこのような秘密情報を生成する鍵管理プロトコル）で使用される秘密情報が、可能性のある複数の送信元の間で共有される範囲によって制限を受ける。

両方のタイプの SA 管理について最低限の要求条件を次に説明する。

4.6.1 マニュアル手法 
最も単純な管理の形態はマニュアル管理であり、他のシステムとの安全な通信に適切な鍵管理情報とセキュリティアソシエーション管理データを、人がそれぞれのシステムで手動で設定するというものである。
マニュアル手法は、小規模で静的な環境では実用的であるが、規模の変化にうまく対応できない。
例えば、ある企業がいくつかの拠点のセキュリティゲートウェイに IPsec を使用することによって、仮想私設網（VPN）を構築することが可能である。
拠点数が少なく、すべてのサイトが単一の管理ドメイン範囲内におさまる場合には、マニュアル管理手法が適しているかもしれない。
この場合、セキュリティゲートウェイは、手動で設定された鍵を使用して組織内の他のサイトとの入出力トラフィックを選択的に保護することが可能だが、他の宛先行きのトラフィックを保護することはできない。
これはまた、選択された通信のみに対して保護が必要な場合に適切であるかもしれない。
組織内に完全に閉じた少数のホストまたはゲートウェイ向けの IPsec の使用に対しても、同様の議論が適用されるだろう。
マニュアル管理手法では、他のオプションも存在するが、静的に設定された対称鍵を使用することが多い。
4.6.2 SA および鍵の自動管理 
IPsec の利用の普及には、インターネット標準でスケーラブルな、自動化された SA 管理プロトコルが必要である。
このサポートには、AH および ESP のリプレイ防御機能の使用を強化することと、例えばユーザ別およびセッション別鍵管理のために、SA の要求に応じた生成に対応できることが要求される。
（ここで、SA を「再鍵付け」するという概念は、新しい SPI での新しい SA の生成、すなわち、自動 SA/鍵管理プロトコルの使用を一般的に意味する処理を実際に含むことに注意すること。）

IPsec で使用するように選択されたデフォルトの自動鍵管理プロトコルは、IPsec 翻訳ドメイン（domain of interpretation）[Pip98] 配下の IKE [MSST97, Orm97, HC98] である。
他の自動 SA 管理プロトコルを使用してもよい (MAY)。

自動 SA/鍵管理プロトコルが使用される場合、このプロトコルの出力は、例えば 1 つの ESP SA 用の複数の鍵の生成に使用されることがある。
これは以下の理由により起こり得る。

鍵管理システムは、それぞれの鍵用に独立したビットストリングを提供してもよいし、すべてのビットが抽出された 1 つのビットストリングを生成してもよい。
1 つのビットストリングが提供される場合、システムの要求される鍵にそのビットストリングをあてはめる部分が、SA の両終端で同じように動作することを保証するように注意する必要がある。
SA のそれぞれの終端における IPsec の実装が同じ鍵に対して同じビットを使用し、システムの部分に関係なくビットストリングを個々の鍵に分割することを保証するために、暗号鍵を最初の（左端、上位）ビットから採り (MUST)、認証鍵を残りのビットから採らなければならない (MUST)。
それぞれの鍵のビット数は、対応するアルゴリズムの仕様が記述されている RFC にて定義される。
複数の暗号鍵または複数の認証鍵を使用する場合、アルゴリズムに提供される 1 つのビットストリングからの選択順序をアルゴリズムの仕様で指定しなければならない。
4.6.3 セキュリティゲートウェイの位置探索 
この章では、適切なセキュリティゲートウェイの存在をホストがいかにして知るか、さらにホストがセキュリティゲートウェイとコンタクトした後、それが正しいセキュリティゲートウェイであることをどのようにして知るかということについて説明する。
要求された情報をどこに保存するかということについての詳細は、ローカルの問題である。

リモートホスト（H1）がサーバーまたはその他のマシン（H2）にアクセスするためにインターネットを使用し、H1 のトラフィックが通過しなければならない、ファイアウォールのようなセキュリティ ゲートウェイ（SG2）が存在する状況を考えてみる。
この状況の例として、インターネットを通って自組織のファイアウォール（SG2）に到達するモバイルホスト（Road Warrior）があてはまる。（4.5 章のケース 4 を参照のこと。）
この状況では、いくつかの問題が起こる。

  1. H1 はどのようにしてセキュリティゲートウェイ SG2 の存在を知る/学習するのか。
  2. H1 はどのようにして SG2 を認証するのか、SG2 が認証された後、SG2 が H2 の代理の権限が与えられていることを H1 がどのように確認するのか。
  3. SG2 はどのようにして H1 を認証するのか、またH1 に H2 と通信する権限を与えられていることをどのように確認するのか。
  4. H1 はどのようにして H2 への代替経路を提供するバックアップゲートウェイについて知る/学習するのか。
これらの問題に対処するために、ホストまたはセキュリティゲートウェイでは、ユーザまたは管理者が、その使用を要求する宛先アドレスのセットに対するセキュリティゲートウェイのアドレスの設定ができるような管理インタフェースを持たなければならない (MUST)。
これには以下の事項を設定する機能が含まれる。 SPD ではまた、セキュリティゲートウェイおよび宛先ホストへの経路に対する、他のどのような IPsec 要求条件をもカバーするようなポリシー情報が設定されると仮定する。

セキュリティゲートウェイの発見/確認の自動化方法の問題については、この文書では扱わないこととする。

4.7 セキュリティアソシエーションとマルチキャスト 
セキュリティアソシエーションの受信側指向とは、ユニキャストトラフィックの場合では、通常、宛先システムによって SPI 値が選択されることを意味する。
宛先システムに SPI 値を選択させることにより、マニュアルで設定されたセキュリティアソシエーションが、自動的に設定（例えば鍵管理プロトコルを経て）されたセキュリティアソシエーションと衝突する可能性、または複数送信元からのセキュリティアソシエーションが互いに衝突する可能性がなくなる。
マルチキャストトラフィックの場合では、マルチキャストグループ単位に複数の宛先システムが存在する。
従って、一部のシステムまたは人々は、それぞれのマルチキャストグループに代わって SPI または SPI 群を選択するために、すべてのマルチキャストグループを調整し、（ここで定義されない仕組みを経て）マルチキャストグループのすべての正規メンバーにグループの IPsec 情報を伝達する必要がある。

対称鍵暗号化アルゴリズムまたは認証アルゴリズムが使用される場合、マルチキャストグループへの複数の送信者は、そのグループへのすべてのトラフィックのために 1 つのセキュリティアソシエーション（それにセキュリティパラメータインデックス）を使用する必要がある (SHOULD)。
このような状況では、受信側は、メッセージがそのマルチキャストグループに対する鍵を保持するシステムから来たということのみを知る。
このような場合、受信側は、一般的にどのシステムがマルチキャストトラフィックを送ったかを認証することは不可能となるだろう。
この他の、より一般的なマルチキャストに関する仕様は後の IPsec 文書に委ねることにする。

この仕様が発行された時点では、マルチキャスト鍵配送のための自動化プロトコルは、十分な標準化が考慮されていなかった。
メンバーが比較的少ないマルチキャストグループでは、マニュアル鍵配送、または、改良された Diffie‐Hellman のような既存のユニキャスト鍵配送アルゴリズムを複数使用した方が現実的である。
大きなグループでは、新しいスケーラブルな手法が必要となるだろう。
この分野での現在の取り組み例として、Group Key Management Protocol (GKMP) [HM97] があげられる。

5. IP トラフィック処理 
4.4.1 章の「セキュリティポリシーデータベース（SPD）」で説明したように、非 IPsec トラフィックを含むすべてのトラフィック（入力および出力）の処理中に、SPD を参照しなければならない。
SPD 内に、当該パケットにあてはまるポリシーが（入力または出力トラフィックのいずれかに対して）発見されない場合は、パケットは破棄されなければならない(MUST)。

注釈：IPsec で使用されるすべての暗号化アルゴリズムは、正規のネットワークバイト順序での入力を期待し（RFC 791 の付録を参照のこと）、正規のネットワークバイト順序の出力を生成する。
IP パケットもまた、ネットワークバイト順序で転送される。

5.1 出力 IP トラフィック処理 
5.1.1 SA または SA バンドルの選択と使用 
セキュリティゲートウェイまたは BITW 実装（および多くの BITS 実装）では、各出力パケットは、そのパケットに要求される処理を決定するために SPD と比較される。
パケットが破棄される場合には、これは監査対象イベントとなる。
トラフィックが IPsec 処理のバイパスを許可される場合には、そのパケットは IPsec 処理が行われている環境での「通常の」処理を通り抜ける。
IPsec 処理が要求される場合には、パケットが既存の SA （または SA バンドル）にマップされるか、そのパケットに対して新しい SA （または SA バンドル）が生成される。
パケットのセレクタが複数のポリシーまたは複数の既存 SA にマッチする可能性があるため、そして、SPD は順序付けされているが、SAD は順序付けされていないため、IPsec は以下のことを行わなければならない (MUST)。
  1. SAD 内の 0 個以上の SA バンドルを指し示す、最初の適切なポリシーの位置を決めるために、SPD 内の出力ポリシーとパケットのセレクタフィールドをつきあわせなければならない。

  2. マッチする最初の SA バンドルの位置を決めるために、(1) で発見された SA バンドルにあるセレクタフィールドとパケットのセレクタフィールドをつきあわせなければならない。
    SA が発見されないか、どれにもあてはまらない場合、適切な SA バンドルを生成し、SPD エントリを SAD エントリにリンクしなければならない。
    鍵管理エンティティが発見されない場合は、パケットをドロップしなければならない。

  3. 要求された IPsec 処理、例えば認証や暗号化を行うために、(2) で発見/作成された SA バンドルを使用しなければならない。
ソケットに基づくホストでの IPsec 実装では、ソケット上を流れるトラフィックに適用される IPsec 処理を決定するために、新しいソケットが生成された際には常に SPD が参照されることになるだろう。

注釈：準拠する実装は、NULL 暗号化アルゴリズムおよび NULL 認証アルゴリズムの両方を使用する ESP SA のインスタンスを許可してはならない (MUST NOT)。
この種の SA をネゴシエートしようとする試みは、監査対象イベントとなる。

5.1.2 トンネルモードのヘッダ構成 
この章では、内側および外側 IP ヘッダ、拡張ヘッダ、そして AH および ESP トンネルのオプションの処理について説明する。
これには、カプセル化（外側） IP ヘッダの構築方法、内側 IP ヘッダ内のフィールドの処理方法、および行うべきその他のアクションが含まれている。
一般的なアイディアは、RFC 2003 「IP Encapsulation with IP」 で使用されているものをもとにモデル化されている。 以下の章の表は、異なるヘッダ/オプションフィールドに対する処理方法を示している（constructed = 外側フィールドにある値は、内側の値とは独立して構成される）。
5.1.2.1 トンネルモードのヘッダ構成（IPv4） 
                     <--    外側ヘッダと内側ヘッダの関係    -->
                     カプセル化器における           カプセル開放器における
IPv4                 外側ヘッダ                    内側ヘッダ
  Header fields:     --------------------         ------------
    version          4 (1)                        no change
    header length    constructed                  no change
    TOS              copied from inner hdr (5)    no change
    total length     constructed                  no change
    ID               constructed                  no change
    flags (DF,MF)    constructed, DF (4)          no change
    fragmt offset    constructed                  no change
    TTL              constructed (2)              decrement (2)
    protocol         AH, ESP, routing hdr         no change
    checksum         constructed                  constructed (2)
    src address      constructed (3)              no change
    dest address     constructed (3)              no change
  Options            never copied                 no change
  1. カプセル化ヘッダ内の IP バージョンは内側ヘッダの値と異なることが可能である。

  2. 内側ヘッダ内の TTL は転送される前にカプセル化器によってデクリメントされ、かつパケットが転送されるのであれば、カプセル開放器によってデクリメントされる（TTL が変化する時にはチェックサムが変化）。

    注釈：TTL のデクリメントは、パケットの転送が行われる際に通常行われるアクションの 1 つである。
    送信ノードは、パケットを転送するのではなく送信するので、カプセル化器と同じノードから送信されるパケットは、TTL のデクリメントは行われない。

  3. 送信元および宛先アドレスは、パケットを転送するためにどの送信元アドレス（ネットワークインタフェース）を使用するかを代わりに決定する宛先アドレスを決定するために使用される SA に依存する。

    注釈：（例えば、カプセル化器が NAT ボックスとして動作している場合）、パケットが送られる環境からカプセル化器を通って到達できるアドレスである限り、原則として、カプセル化 IP 送信元アドレスは、カプセル化器のインタフェースアドレスのどれか、またはカプセル化器の IP アドレスのどれとも異なるアドレスであることができる。
    IPsec が現在のところ、カプセル化 IP ヘッダの送信元アドレスを含む入力処理に関する要求条件を持たないため、これは問題とはならない。
    従って、受信側トンネル終端は、カプセル化 IP ヘッダ内の宛先アドレスを調べる一方、内側（カプセル化） IP ヘッダ内の送信元アドレスを調べるのみである。

  4. 設定によって DF を内側ヘッダ（IPv4 のみ）からコピーするか、クリアまたはセットするかが決定される。

  5. 内側ヘッダが IPv4（プロトコル = 4）であれば、TOS をコピーする。
    内側ヘッダが IPv6（プロトコル = 41）であれば、クラスを TOS にマッピングする。
5.1.2.2 トンネルモードのヘッダ構成（IPv6） 
注釈番号 1-5 については、前の 5.1.2 章を参照のこと。 
                     <--    外側ヘッダと内側ヘッダの関係    -->
                     カプセル化器における           カプセル開放器における
IPv6                 外側ヘッダ                    内側ヘッダ
  Header fields:     --------------------         ------------
    version          6 (1)                        no change
    class            copied or configured (6)     no change
    flow id          copied or configured         no change
    len              constructed                  no change
    next header      AH,ESP,routing hdr           no change
    hop limit        constructed (2)              decrement (2)
    src address      constructed (3)              no change
    dest address     constructed (3)              no change
  Extension headers  never copied                 no change
  1. 内側ヘッダが IPv6（次ヘッダ = 41）であれば、クラスをコピーする。
    内側ヘッダが IPv4（次ヘッダ = 4）であれば、TOS をクラスにマッピングする。
5.2 入力 IP トラフィック処理 
AH または ESP 処理の実行の前に、すべての IP の断片が再構成される。
IPsec 処理を適用する各入力 IP データグラムは、IP 次プロトコルフィールド内の AH または ESP 値（あるいは、IPv6 の場合における拡張ヘッダとしての AH または ESP）の存在によって識別される。

注釈：リプレイ防御サービスの実装時に利用できる、32 パケットウィンドウ用のビットマスクチェックのサンプルコードが付録 C にある。

5.2.1 SA または SA バンドルの選択と使用 
AH または ESP ヘッダには SPI が存在するため、適切な SA への IP データグラムのマッピングは簡略化されている。
ここで、セレクタチェックは外側（トンネル）ヘッダではなく、内側ヘッダで行われることに注意すること。
実行のステップは以下の通りである。
  1. SAD 内の SA を検索するために、パケットの宛先アドレス（外側 IP ヘッダ）、IPsec プロトコル、および SPI を使用する。
    SA の検索に失敗した場合、パケットを破棄し、エラーをログに残すかレポートする。

  2. IPsec 処理、例えば認証や復号化を行うために、(1) で見つけられた SA を使用する。
    このステップには、パケットの（トンネルされた場合は内側ヘッダ）セレクタと、SA 内のセレクタとのマッチングが含まれる。
    ローカルポリシーによって、SA セレクタの詳細（単独の値、リスト、範囲、ワイルドカード）が決定される。
    一般に、パケットの送信元アドレスは SA のセレクタ値と一致しなければならない (MUST)。
    しかしながら、トンネルモード SA で受信された ICMP パケットは、SA に結び付けられたアドレス以外の送信元アドレスを持つことがあるため、この種のパケットはこのチェックの例外として許可される必要がある。
    ICMP パケットの場合、それに封入された問題のあるパケットからのセレクタ（送信元アドレスおよび宛先アドレスとポートがスワップされる必要がある）は、その SA のセレクタに対してチェックされる必要がある。
    ここで、ICMP パケットで運搬される問題のあるパケットのバイト数に制限があったり、暗号化されている場合に、これらのセレクタの一部またはすべてにアクセスできないことがあることに注意すること。
    これについては 6 章を参照のこと。

    このシステム用ではないトランスポートプロトコルヘッダまたは IP ヘッダが現れるまで、すべての IPsec ヘッダに対し (1) と (2) の処理を行う。
    どの SA が使用され、どの順番で適用されたかという情報を保持すること。

  3. そのパケットにあてはまる SPD 内の入力ポリシーを探す。
    これは、例えば SA から SPD へのバックポインタを使用するか、パケットのセレクタ（トンネルされている場合は内側ヘッダ）を SPD 内のポリシーエントリのセレクタとマッチングさせることによって行うことができる。

  4. 要求された IPsec 処理が適用されているかどうかをチェックする。
    すなわち、(1) と (2) で見つかった SA が、(3) で見つかったポリシーによって要求される SA の種類とその順序にマッチすることを確認する。

    注釈：正確な「マッチング」ポリシーは、最初に見つけられた入力ポリシーである必要は必ずしもない。
    (4) のチェックに失敗した場合は、すべてのポリシーエントリのチェックが完了するか、チェックが成功するまで (3) と (4) のステップを繰り返す。

これらのステップの最後では、その結果生じたパケットをトランスポート層に渡すか、そのパケットを転送する。
ここで、これらのステップで処理されたすべての IPsec ヘッダは削除されてしまうことがあるが、この情報、つまり、使用された SA、およびその適用順序は、これに続く IPsec 処理またはファイアウォール処理で必要となることがあることに注意すること。

ここで、セキュリティゲートウェイの場合に、パケットが転送されて、IPsec が有効となっているインタフェースを経由して出ていく場合、追加の IPsec 処理が適用される場合があることに注意すること。

5.2.2 AH および ESP トンネルの処理方法
AH および ESP トンネルでの、内側および外側 IP ヘッダ、拡張ヘッダ、そしてオプションは、5.1 章の表に従って扱われる必要がある。
6. （IPsec と関連する） ICMP 処理 
この章では、ICMP エラーメッセージの処理について主にとりあげる。
例えば Echo/Reply のような他の ICMP トラフィックは別のトラフィックのように扱う必要があり、通常のように SA を使用することによって終点間ベースで保護することが可能である。

AH または ESP によって保護され、ルータによって生成される ICMP エラーメッセージは、トンネルモード SA で処理され、転送される必要がある (SHOULD)。
ローカルポリシーによって、トンネルの宛先の終端ルータが送信元アドレスのチェックをするかどうかが決定される。
ここで、トンネルの生成側の終端ルータが他のルータからの ICMP エラーメッセージを転送している場合には、送信元アドレスのチェックに失敗することに注意すること。
AH または ESP によって保護され、ルータによって生成される ICMP メッセージは、トランスポートモード SA で転送されてはならない (MUST NOT) （例えば、ルータを管理するために使用する Telnet 接続のように、SA がルータに対してホストとして動作するように設定されていない限り）。
ホストによって生成された ICMP メッセージは、メッセージが到着する SA に結び付けられた送信元 IP アドレスセレクタに対してチェックされる必要がある(SHOULD)。
ここで ICMP エラーメッセージの送信元が認証されている場合でも、それによって返された IP ヘッダは無効となり得ることに注意すること。
それに応じて、IP ヘッダ内のセレクタ値もまた、ICMP メッセージを受信した SA のセレクタと一致することを確かめるためにチェックされる必要がある (SHOULD)。

付録 D の表は、ICMP メッセージを、ホストで生成されるもの、ルータで生成されるもの、その両方、未知/未割り当てのものというように分類したものである。
後ろの 2 つのカテゴリに入る ICMP メッセージは、受信側のポリシーによって決定されるものとして扱われる必要がある。

AH または ESP によって保護されていない ICMP メッセージは認証されておらず、それを処理したり、転送したりすることによってサービス妨害を受ける可能性がある。
これは一般に、このようなメッセージを無視することが望ましいということを意味している。
しかしながら、多くのルータ（セキュリティゲートウェイではない）は、経由するトラフィック用に IPsec を実装しないだろうから、このルールに厳密に従うと、多くの ICMP メッセージを破棄することになると予想される。
その結果、一部の重要な IP 機能、例えば経路変更や PMTU 処理が失われることになる。
そのため、ローカルのセキュリティポリシーによって、（ルータ） ICMP トラフィックを受け付けるか、拒否するかを IPsec の実装に対して設定できるようにしなければならない (MUST)。

この章の残りの部分では、ホストおよびセキュリティゲートウェイ上で、PMTU 処理がどのように実行されなければならないか (MUST) ということについて示す。
ここでは、認証された ICMP PMTU メッセージと認証されていない ICMP PMTU メッセージの両方について取り上げている。
ただし、前に説明したように、認証されていない ICMP メッセージはローカルのポリシーに基づいて破棄してもよい(MAY)。

6.1 PMTU / DF 処理 
6.1.1 DF ビット 
システム（ホストまたはゲートウェイ）がカプセル化ヘッダ（ESP トンネルまたは AH トンネル）を追加する場合、システムは、オリジナルのパケットからカプセル化ヘッダへ DF ビットをコピーするオプション（および ICMP PMTU メッセージを処理するオプション）をサポートしなければならない (MUST)。
これは、システムのDF ビットの処理（セット、クリア、カプセル化されたヘッダからのコピー）をインタフェース毎に設定できなければならない (MUST) ことを意味している（その根拠については付録 B を参照のこと）。
6.1.2 経路 MTU 探索 (PMTU) 
この章では、経路 MTU 探索メッセージに対する IPsec の処理について説明する。
ここで、ICMP PMTU は、以下の ICMP メッセージを参照するために使用される。
IPv4（RFC 792）： IPv6（RFC 1885）：
6.1.2.1 PMTU の伝播 
ICMP PMTU メッセージ（IPv4 または IPv6）で返される情報の量は限定されており、PMTU 情報をさらに伝播させるためにどのセレクタが利用できるのかということに影響がでてくる。（この問題については付録 B を参照のこと。）
6.1.2.2 PMTU の計算 
ICMP PMTU から PMTU を計算する際には、IPsec ヘッダ（AH トランスポート、ESP トランスポート、AH/ESP トランスポート、ESP トンネル、AH トンネル）の追加を考慮しなければならない (MUST) 。（実装の問題に関する議論については付録 B を参照のこと。）

注釈：一部の状況では、IPsec ヘッダの追加によって、受け入れられないほど小さい、有効な PMTU （ホストまたはアプリケーションによって見られる）を結果として引き起こすことがあり得る。
この問題を避けるために、実装では、縮小された PMTU を報告しない閾値を下げて設定しても良い。
このような場合、実装は IPsec を適用し、その結果生じたパケットを PMTU に応じて分割する。
これは結果的に、利用可能な帯域幅をより効果的に使用することとなる。

6.1.2.3 PMTU 処理のグラニュラリティ 
ホストでは、ICMP PMTU 処理が実行できるグラニュラリティは、その実装の状況によって異なる。
ホストに関して言えば、PMTU 問題に関連して関心を示す状況として、以下の 3 つが存在する （この話題に関しての詳細については、付録 B を参照のこと）。
  1. ネイティブ IP 実装への IPsec の統合
  2. bump-in-the-stack 実装、この場合 IPsec は既存の TCP/IP プロトコルスタックの実装の「下部」、ネイティブ IP とローカルネットワークドライバの間に実装される。
  3. IPsec 実装なし -- これは、セキュリティゲートウェイが PMTU 情報をホストに送り返す場合に関係するため、ここに含まれている。
(a) の場合のみ、PMTU データは通信アソシエーションと同じグラニュラリティでメンテナンスすることが可能となる。
(b) と (c) では、IP 層は RFC 1191 で定義されているように、PMTU データのみを送信元および宛先 IP アドレス（およびオプションで TOS）のグラニュラリティでメンテナンスすることが可能となる。
複数の通信アソシエーションが同じ送信元アドレスおよび同じ宛先 IP アドレスにマッピングされ、各通信アソシエーションが（例えば、異なる変換、または異なるアルゴリズムを用いるために）異なる量の IPsec ヘッダのオーバーヘッドを持つ可能性があるため、これは重要な相違である。

PMTU 計算の実装および個々の通信アソシエーションのグラニュラリティでの PMTU のサポートは、ローカルの問題である。
ただし、ホストでのソケットベースの IPsec の実装では、ソケット単位で情報をメンテナンスする必要がある (SHOULD)。
bump-in-the-stack システムでは、ICMP PMTU をシステムによって追加されるすべての IPsec ヘッダのオーバーヘッドに対して調整した後、ホストの IP 実装に渡さなければならない (MUST)。
オーバーヘッドの計算は、SPI および返される ICMP PMTU メッセージ中に存在するその他のセレクタ情報の分析によって決定される必要がある (SHOULD)。

6.1.2.4 PMTU のエージング 
IPsec を実装し、PMTU 情報をメンテナンスするすべてのシステム（ホストまたはゲートウェイ）では、セキュリティアソシエーション（トランスポートまたはトンネル）に関連する PMTU は「エージング」されなければならず、PMTU をタイムリに更新し、特に PMTU が必要なものより小さいかどうかを発見するための仕組みを持たなければならない (MUST)。
与えれられた PMTU は、パケットがセキュリティアソシエーションの送信側終端からセキュリティアソシエーションのもう片方の終端に到達し、そして現在の PMTU が大きすぎる場合には ICMP エラーメッセージを伝播し返せるのに十分な長さの時間その場に留まらなければならない。
ここで、入れ子にされたトンネルが存在する場合には、ICMP メッセージをカプセル化器または生成元ホストに戻すために複数のパケットと往復移動時間が必要となる場合があることに注意すること。

システムは、経路 MTU 探索についての文書（RFC 1191の 6.3 章）に記述されているアプローチを使用する必要がある (SHOULD)。
この文書では、PMTU を最初の中継点のデータリンク MTU に定期的にリセットし、必要であれば通常の PMTU 探索処理に PMTU を更新させることが提案されている。
このリセット期間は設定できる必要がある (SHOULD)。

7. 監査 
IPsec を実装するすべてのシステムが監査機能を実装するわけではない。
監査のグラニュラリティについては、ほとんどの部分がローカルの問題である。
しかしながら、いくつかの監査対象イベントが AH および ESP の仕様書内に存在しており、その中では、これらの各イベントに対して、監査ログに含む必要のある (SHOULD) 最低限の情報セットが定義されている。
また、これらの個々のイベントに対するこれ以外の情報を監査ログに含んでもよい (MAY)。
そして、この仕様で明示的に取り上げられていないその他のイベントも監査ログのエントリに含んでもよい (MAY)。
監査対象イベントの検知に応じて、受信側が偽証転送者にすべてのメッセージを転送してしまうような要求条件は存在しない。
これはこのようなアクションを介したサービス妨害を引き起こす可能性があるためである。
8. 情報フローセキュリティをサポートするシステムでの利用 
様々なセンシティビティレベルを持つ情報が単一のネットワーク上を流れる可能性がある。
情報ラベル（例えば、非機密扱い (Unclassified)、企業所有物 (Company Proprietary)、機密 (Secret)）[DoD85, DoD87] はしばしば、このような情報を区別するために使用される。
ラベルの使用により、情報フローセキュリティモデル、例えば Bell-LaPadula モデル [BL73] に沿った情報の選別が促進される。
このようなモデル、そしてそれに対応するサポート技術は、たとえトロイの木馬攻撃を受けた場合でも、重要な情報が許可なく流出するのを防ぐことができるように設計されている。
例えばアクセス制御リストに基づくような従来型の任意アクセス制御 (discretionary access control) （DAC）の仕組みは、一般的に、このようなポリシーをサポートするには十分ではないため、SPD に代表される機能はこの種の環境においては十分ではない。

軍事関連では、このようなモデルをサポートする技術はしばしば、マルチレベルセキュリティ（MLS）と呼ばれる。
コンピュータやネットワークが、情報フローセキュリティポリシーに沿った、ラベル付きデータの分離をサポートする場合、そのコンピュータやネットワークは、しばしば「マルチレベルセキュア」と称される。
このような技術は、軍事関連以外にも幅広く適用可能であるが、この文書では、多くの現存の文献と一致させて、技術を称するために「MLS」という頭字語を使用することにする。

IPsec の仕組みは容易に MLS ネットワーキングをサポートできる。
MLS ネットワーキングでは、強力な強制アクセス制御 (Mandatory Access Controls) （MAC）の利用が要求される。
これは、非特権ユーザまたは非特権プロセスのコントロールや違反を無効とするものである。
この章では、MLS（情報フローセキュリティポリシー）環境における IP セキュリティの仕組みの利用のみに関して述べる。
MLS を提供しないシステムにはこの章の内容は適用されない。

この章で使用する 「センシティビティ情報」 には、実装が定義する階層レベル、カテゴリ、または発表可能な情報が含まれる場合がある。

MLS 環境における強制アクセス制御の決定に沿った強力な認証を提供するために AH を使用することが可能である。
明示的 IP センシティビティ情報（例えば、IPSO [Ken91]）が使用され、機密性がある特定の運用環境において必要であるとされないのであれば、IP ヘッダのセンシティビティラベルと IP ペイロード（ユーザデータを含む）間のバインディングの認証に AH を使用することができる。
これは、IP ヘッダとユーザデータへの情報の認証または暗号バインディングが存在しなくても、センシティビティ情報が信用されることから、ラベル付き IPv4 ネットワークにおける重要な改良となる。
IPv4 ネットワークでは、明示的ラベル付けを使用する場合と使用しない場合がある。
IPv6 では通常、明示的センシティビティ情報を使用する代わりに、IPsec セキュリティアソシエーションの一部であるが各パケットで転送されない暗黙的センシティビティ情報を使用する。
すべての明示的 IP センシティビティ情報は、ESP または AH のどちらか、あるいは両方を使用して認証されなければならない (MUST)。

暗号化は有用であり、すべてのホストが保護された環境内、例えばファイアウォールの背後にあったり、すべての外部接続が遮断されているような場合であっても導入が望ましい。
ESP は、DAC と MAC の両方をサポートし、適切な鍵管理および暗号化アルゴリズムと組み合わせて使用することがで