ネットワークワーキンググループ
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 -- [MSST97Orm97HC98])を指定するが、その他の自動鍵配送技術を利用してもよい (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 の両方をサポートし、適切な鍵管理および暗号化アルゴリズムと組み合わせて使用することができる。(暗号化および認証アルゴリズムの選択、そして IPsec の実装の保証レベルは、実装が MLS の要求条件を十分に満たすと考えられる環境を決定することになるだろう。)
鍵管理は MAC を提供するためにセンシティビティ情報を活用することができる。
MLS を提供するシステムでの IPsec 実装は、IP ベースの通信に MAC を提供するために IPsec が使用できる必要がある (SHOULD)

8.1 セキュリティアソシエーションとデータセンシティビティの関係 
暗号ペイロードと認証ヘッダはいずれも、マルチレベルセキュアネットワークを提供するために、適切なセキュリティアソシエーションポリシーと組み合わせることができる。

この場合、それぞれの SA (または SA バンドル)は、一般的に、センシティビティ情報の 1 つのインスタンスのみに対して使用される。
例えば、「PROPRIETARY - Internet Engineering」は、「PROPRIETARY -- Finance」とは異なる SA (または SA バンドル)と関連付けられなければならない。

8.2 センシティビティの一貫性チェック 
MLS の実装(ホストとルータの両方)では、センシティビティ情報またはセンシティビティ情報の範囲を、インタフェースまたはプレフィックス付きで設定されている IP アドレスと結び付けてもよい (MAY) (後者は論理インタフェース、あるいはインタフェースエイリアスと呼ばれることがある)。
このような特性がある場合、実装はパケットに結び付けられたセンシティビティ情報を、パケットが到着あるいは出発する予定のインタフェースまたはアドレス/プレフィックスに結び付けられたセンシティビティ情報と比較する必要がある (SHOULD)
このチェックでは、センシティビティが一致するか、パケットのセンシティビティがインタフェースまたはアドレス/プレフィックスの範囲に収まるかのどちらであるかを確認する。

このチェックは、入力と出力の両方の処理において行われる必要がある (SHOULD)

8.3 セキュリティアソシエーションデータベース用の追加 MLS 属性 
4.4 章では、2 つのセキュリティアソシエーションデータベース(セキュリティポリシーデータベース(SPD)とセキュリティアソシエーションデータベース(SAD))および関連するポリシーセレクタと SA 属性について説明した。
MLS ネットワーキングでは、これに追加して以下のセレクタ/属性を導入する。
- センシティビティ情報
8.1 章で説明したように、トラフィックがその重要性とセンシティビティに適した保護レベルを得るように、センシティビティ情報は適切なアルゴリズムと鍵強度の選択を可能にする。
センシティビティ情報の正確な構文は実装によって定義される。
8.4 MLS ネットワーキング用の追加入力処理ステップ 
MLS 実装では、入力パケットが IPsec 処理を通過した後、データグラムを上位層プロトコルに配送するか転送するかする前に、最初に 8.2 章で定義されたインタフェースまたはアドレス/プレフィックスでパケットのセンシティビティ(そのパケットに対して使用される SA (または SA バンドル)によって定義される)をチェックする必要がある (SHOULD)

MLS システムは、IPsec で保護されたパケットで受信したデータと、処理に使用した SA または SA 群内のセンシティビティ情報の間のバインディングを保持しなければならない (MUST)
これにより、データグラムをアプリケーションや転送エンジンに配送する際に、適切なポリシーを決定することができる。
このバインディングのメンテナンス手段は実装特有である。

8.5 MLS ネットワーキング用の追加出力処理ステップ 
IPsec の MLS 実装では、5.1.1 章で詳細に説明した通常ステップに追加して、さらに 2 つのチェックを行わなければならない (MUST)
出力セキュリティアソシエーションを発見するために SPD または SAD を調べる際に、MLS 実装は、適切な出力 SA または SA バンドルを選択するためにデータのセンシティビティを使用しなければならない (MUST)
2 つ目のチェックはパケットを宛先に転送する前に行われるものであり、8.2 章で説明したセンシティビティの一貫性チェックである。
8.6 セキュリティゲートウェイ用の追加 MLS 処理 
MLS セキュリティゲートウェイは前に説明した入力と出力の処理ルールに従うとともに、MLS 環境におけるパケットの中間保護に特有の追加処理を実行しなければならない (MUST)

セキュリティゲートウェイは、そのゲートウェイによって転送されるパケットを生成する MLS システム用の SA を生成することによって出力プロキシとして動作してもよい (MAY)
この MLS システムは転送されるべきパケットに対して明示的にラベル付けをするか、生成するネットワーク全体がそれに関連するセンシティビティ特性を持つ場合がある。
セキュリティゲートウェイは、転送するトラフィックを保護するために、AH か ESP のどちらか、または両方に対する適切な SA を作成し、使用しなければならない (MUST)

同様に、このようなゲートウェイは、明示的パケットラベリングを使用するか、宛先ネットワークのセンシティビティ特性に依存しながら、入力 AH または ESP パケットを適切に受領、処理し、転送する必要がある (SHOULD)

9. 性能に関する事項 
IPsec を使用することによって、これらのプロトコルを実装するホストおよびセキュリティゲートウェイに計算性能コストを課すことになる。
このコストは、IPsec コードやデータ構造に必要なメモリ、インテグリティチェック値や暗号化・復号化の計算、パケット毎に追加される処理に関するものである。
パケット毎の計算コストは、増加する待ち時間と、おそらく、減少するスループットによって示される。
SA・鍵管理プロトコル、特に公開鍵暗号を使用するプロトコルの利用もまた、IPsec を使用する際の計算性能コストに追加される。
これらのアソシエーション毎の計算コストは、アソシエーション確立によって増加する待ち時間に関して示される。
多くのホストでは、ソフトウェアベースの暗号によってスループットが大きく減少することはないと予想されるが、セキュリティゲートウェイや一部のホストでは、ハードウェアが要求される場合がある(ゲートウェイはトラフィックが集まる場所であるため)。

また、IPsec を使用することによって、インターネットの IPsec を実装しない、伝送、スイッチング、経路制御といった構成要素に帯域幅の利用コストを課すことになる。
これは、AH および ESP ヘッダの追加、AH および ESP のトンネリング(2 つ目の IP ヘッダが追加される)によるパケットサイズの増加、鍵管理プロトコルが使用するパケットトラフィックの増加によるものである。
ほとんどの場合、この帯域幅の需要の増加はインターネットに大きな影響を及ぼさないと予想される。
しかしながら、ある状況では、例えばトラフィックを別な方法で圧縮するダイヤルアップリンク上で ESP 暗号化トラフィックを転送する場合などでは、多大な影響が出ることがある。

注釈:最初の SA 確立時のオーバーヘッドは、最初のパケットで感じられるだろう。
この遅延はトランスポート層とアプリケーションに影響を与える可能性がある。
例えば、ISAKMP 交換が完了する前に TCP の SYN を再送信させてしまう可能性がある。
UDP では、先に進めて最初のパケットを超えてデータを送信できるのに対し、TCP では接続が完了するまでは SYN 以外は何も送信すべきではないため、遅延の影響は UDP と TCP では異なるだろう。

注釈:前に説明したように、IP の上の層で圧縮をすることができる。
IETF には、「ペイロードを暗号化するプロトコルによってペイロードが処理される前に、個々のペイロードに対して損失のない圧縮を実現するプロトコルの仕様を作り、この仕様によって、IPsec プロトコルによるペイロードの暗号化に先行して、圧縮処理を実現する」ワーキンググループ(IP Payload Compression Protocol(ippcp))が存在する。

10. 準拠に関する要求事項 
IPsec を実装するすべての IPv4 システムは、セキュリティアーキテクチャ文書のすべての要求条件に準拠しなければならない (MUST)
すべての IPv6 システムは、セキュリティアーキテクチャ文書のすべての要求条件に準拠しなければならない (MUST)
11. セキュリティに関する考慮事項 
この文書の焦点はセキュリティであり、従ってセキュリティに関する考慮事項はこの仕様書の全体に行き渡っている。
12. RFC 1825 との相違点 
このアーキテクチャ文書は、RFC 1825 と比べて、詳細と構成の点で大きく異なっているが基本的な見解は変わらない。
この文書では、準拠する仕様に関する重要な詳細が追加されている。
また、SPD および SAD、そして、SA セレクタの概念について紹介されている。
そして、前版と異なる新バージョンの AH および ESP に合わせている。
サポートされる AH と ESP の組み合わせに特有の要求条件が、PMTU 管理の詳細として新たに追加されている。
謝辞 
この仕様に含まれる概念の多くは、米国政府の SP3 セキュリティプロトコル、ISO/IEC の NLSP、提案された swIPe セキュリティプロトコル [SDNS, ISO, IB93, IBK93]、SNMP セキュリティおよび SNMPv2 セキュリティ向けになされた作業から導出され、影響を受けたものである。

3 年以上(本当はもっと長く感じるが)に渡って、この文書は様々なバージョンと繰り返しを経て発展してきた。
この間、多くの人々が重要なアイディアと熱意を作業と文書の両方に注いでくれた。
レビュー、編集、背景調査、およびコーディネーション作業で多大な貢献をしてくれた Karen Seo に感謝する。
また、IPsec および IPng ワーキンググループのメンバー、特に(アルファベット順で)、Steve Bellovin、Steve Deering、James Hughes、Phil Karn、Frank Kastenholz、Perry Metzger、David Mihelcic、Hilarie Orman、Norman Shulman、William Simpson、Harry Varnis、Nina Yuan の各氏の努力に感謝する。

付録 A -- 用語集 
この章では、この文書で使用されているいくつかの主要な用語について定義する。
この技術に関連する追加の定義と背景情報は別の文書、例えば [VK83HA94] から提供されている。
この用語集には、一般的なセキュリティサービスやセキュリティの仕組みについての用語と IPsec 特有の用語が含まれる。
アクセス制御
アクセス制御とは、無許可の資源利用を防ぐセキュリティサービスであり、無許可の資源利用の回避が含まれる。
IPsec では、アクセスを制御する資源には、以下のものが含まれる。
  • ホストでは、計算サイクルまたはデータ
  • セキュリティゲートウェイでは、ゲートウェイの背後にあるネットワーク、またはネットワークの帯域

リプレイ防御
[後の「インテグリティ」を参照のこと]

認証
この用語は、名目上独立した 2 つのセキュリティサービスである、データ送信元認証とコネクションレスインテグリティの組み合わせを指すために略して使用される。
後のそれぞれのサービスの定義を参照のこと。

可用性
セキュリティサービスとしてみた場合の可用性とは、サービスを妨害または悪化させるような、ネットワークに対する攻撃によって引き起こされるセキュリティに関する問題をさす。
例えば、IPsec では、AH および ESP でリプレイ防御の仕組みを使用した場合、可用性をサポートしていることになる。

機密性
機密性とは、データを無許可の漏洩から保護するセキュリティサービスである。
機密性の主な関心は、ほとんどの場合、アプリケーションレベルのデータの無許可の漏洩であるが、通信の外部特性の漏洩もまた、ある状況では問題となり得る。
トラフィックフロー機密性とは、送信元および宛先アドレス、メッセージ長、通信頻度などを隠すことによって、後者の問題に対処するサービスのことである。
IPsec では、ESP をトンネルモード、特にゲートウェイで使用することにより、あるレベルのトラフィックフロー機密性を提供することができる(後のトラフィック解析も参照のこと)。

暗号化
暗号化とは、機密性を提供するためにデータを理解できる形式(平文)から理解不可能な形式(暗号文)に変換するために使用されるセキュリティの仕組みである。
その変換を逆に辿る処理は、「復号化」と呼ばれる。
「暗号化」という用語はしばしば、総称的に両方の処理を指すものとして使用される。

データ送信元認証
データ送信元認証とは、データの発信源の身元を確認するセキュリティサービスである
このサービスは通常、コネクションレスインテグリティサービスと一緒にされる。

インテグリティ
インテグリティとは、データの修正が検出可能であることを保証するセキュリティサービスである。
アプリケーションの要求条件に合わせるために、インテグリティは様々な形式を持つ。
IPsec は 2 つの形式のインテグリティ(コネクションレスおよび部分的なシーケンスインテグリティの形式)をサポートする。
コネクションレスインテグリティとは、トラフィックの流れの中でのデータグラムの順序を考慮せずに、個々の IP データグラムの修正を検出するサービスである。
IPsec が提供する部分的なシーケンスインテグリティの形式は、リプレイ防御インテグリティを指し、重複した IP データグラムの到着を検出する(限定されたウィンドウの範囲で)。
これは、例えば、紛失したメッセージや再送要求されたメッセージを発見できるようにトラフィックにより厳格な順序条件を強制する、コネクション別インテグリティとは対照的である。
認証サービスとインテグリティサービスはしばしば別々に記述されるが、実際には密接につながっているものであり、ほとんど常に同時に提供される。

セキュリティアソシエーション(SA)
セキュリティを目的に生成された、単一の(一方向の)論理コネクション。
ある SA を通過するすべてのトラフィックは同じセキュリティ処理が適用される。
IPsec では、SA は AH または ESP の使用を通じて実装される、インターネット層の抽象概念である。

セキュリティゲートウェイ
セキュリティゲートウェイは、2 つのネットワークの間の通信インタフェースとして機能する中間システムである。
セキュリティゲートウェイの外側にあるホスト(およびネットワーク)は、信頼されていない(あるいは、あまり信頼されていない)と見なされ、一方、内側にあるネットワークとホストは信頼されている(あるいはより信頼できる)として見なされる。
セキュリティゲートウェイがサービス対象とする内部サブネットとホストは、共通なローカルのセキュリティ管理を共有するという理由によって信頼されていると推測される。(後の 「信頼されているサブネット」を参照のこと。)
IPsec では、セキュリティゲートウェイは、内部ホストに対してサービスを提供するために AH / ESP を実装するポイントであり、内部ホストが IPsec を使用する外部ホストと(直接または他のセキュリティゲートウェイ経由で)通信する際にセキュリティサービスをこれらのホストに提供する。

SPI
「Security Parameters Index」 の頭字語。
宛先アドレス、セキュリティプロトコル、および SPI の組み合わせにより、セキュリティアソシエーション(SA、上記を参照のこと)を一意に識別する。
受信側システムが、受信パケットの処理に使用される SA を選択できるようにするために、AH および ESP プロトコル中で SPI が運ばれる。
SPI は、SA の生成者(通常 SPI を運ぶパケットの受信側)によって定義されるものであり、ローカルな意味しか持たない。
従って、SPI は一般的に隠されたビットストリングと見なされる。
ただし、SA の生成者は、ローカル処理を手助けするために SPI 内のビットを解釈するように選択してもよい。

トラフィック解析
敵に対して有益な情報の推測を目的とした、ネットワークトラフィックフローの解析。
この種の情報としては、伝送頻度、通信中の組織の身元、パケット長、使用されるフロー識別子などがある。[Sch94]

信頼されているサブネットワーク
積極的または消極的攻撃に加わっていないことを相互に信頼する、ホストおよびルータを含むサブネットワーク。
根幹となる通信チャネル(例えば LAN または CAN)が他の手段で攻撃されていないことも想定する。
付録 B -- PMTU、DF、分割に関する問題についての解釈および議論 
B.1 DF ビット 
システム(ホストまたはゲートウェイ)がカプセル化ヘッダ(例えば、ESP トンネル)を追加する場合、オリジナルパケット内の DF ビットは、カプセル化ヘッダにコピーすべき/しなければならないのだろうか?

パケットを分割することは、一部の状況では正しいように思える。
例えば、ごく小さい MTU を持つネットワーク、例えばパケット無線網やモバイルノードへ携帯電話で中継する場合は、残りの経路用にごく小さな PMTU を伝搬し返すよりもむしろ、パケットを分割することが適切である場合がある。
その他、分割を要求する PMTU 制約に関するフィードバックを後のルータから受けるために、DF ビットをセットすることが適切な場合がある。
これら 2 つの状況は、ある特定のネットワーク「リンク」上でパケットを分割するかどうかをシステムに決定できるようにすることを主張していることになる。
すなわち、実装に DF ビットをコピーすること(および ICMP PMTU メッセージを処理すること)を可能とすることを求めるが、それはインタフェース毎に選択させるというオプションとすることである。
つまり、管理者が、ルータでの DF ビットの処理(セット、クリア、カプセル化ヘッダからのコピー)を各インタフェース毎に設定できるようにする必要がある。

注釈:IPsec の bump-in-the-stack 実装が、送信元/宛先ポートに基づいて、異なる IPsec アルゴリズムを適用しようとする場合、経路 MTU 調整を適用することは困難となるだろう。

B.2 分割 
必要であれば、IPsec 実装での IPsec 処理の後に IP の分割が発生する。
従って、トランスポートモード AH または ESP は IP データグラム全体に対してのみ(IP の断片に対してではない)適用される。
AH または ESP が適用された IP パケットは、配送経路上のルータによって分割される場合があり、この結果生じた断片は受信側で IPsec 処理の前に再構成されなければならない (MUST)
トンネルモードでは、IP パケットに対して AH または ESP が適用されるが、この時、この IP パケットのペイロードは分割された IP パケットであっても良い。
例えば、セキュリティゲートウェイ、「bump-in-the-stack」(BITS)、または 「bump-in-the-wire」(BITW)での IPsec 実装では、このような断片に対して、トンネルモード AH を適用してもよい。
ここで、BITS または BITW 実装というのは、トンネルモードが適用される断片をホストの IPsec 実装が受信する場合の例である。
その一方、トランスポートモードが適用される場合には、これらの実装では、IPsec を適用する前に断片を再構成しなければならない (MUST)

注釈:IPsec は常に、カプセル化 IP ヘッダのフィールドが何であるかを理解していなければならない。
これは、IPsec の挿入位置とは独立しており、IPsec の定義に固有のものである。
そのため、IP 実装に統合されないすべての IPsec 実装には、必要な IP ヘッダ(例えば IP2)を構成するためのコードが含まれなければならない。

*********************************************************************

全体的に、上記にて説明した分割/再構成のアプローチは、調査済みのすべてのケースに作用する。

                             AH Xport   AH Tunnel  ESP Xport  ESP Tunnel
Implementation approach      IPv4 IPv6  IPv4 IPv6  IPv4 IPv6  IPv4 IPv6
-----------------------      ---- ----  ---- ----  ---- ----  ---- ----
Hosts (integr w/ IP stack)     Y    Y     Y    Y     Y    Y     Y    Y
Hosts (betw/ IP and drivers)   Y    Y     Y    Y     Y    Y     Y    Y
S. Gwy (integr w/ IP stack)               Y    Y                Y    Y
Outboard crypto processor *
* 暗号プロセッサシステム自身が IP アドレスを持つ場合は、セキュリティゲートウェイのケースに含まれる。
このボックスがホストからのパケットを受信し、IPsec 処理を行う。
これは同じ AH、ESP、およびそれに関連する、セキュリティゲートウェイが扱うべき IPv4/IPv6 トンネル処理を扱うことができる必要がある。
暗号プロセッサシステム自身がアドレスを持たない場合は、IP とネットワークドライバ間に実装される bump-in-the stack と同様である。
以下の分析では次の通りに仮定する。
  1. 所定のシステムのスタックには 1 つの IPsec モジュールのみが存在する。
    IPsec モジュール B からのトランスポートプロトコル、送信元ポート、宛先ポートを(ESP/暗号化を追加して)隠すような IPsec モジュール A は存在しない。
  2. IPsec を実装できる場所は(上記の表に示すように)いくつか存在する。
    1. ネイティブ IP に組み込まれた IPsec 実装を持つホスト。
      実装者はスタックのソースにアクセスする。
    2. bump-in-the-stack 実装を持つホスト。
      IPsec は IP とローカルネットワークドライバの間に実装される。
      スタックのソースへのアクセスは利用できないが、IPsec コードをシステムに取り込むことが可能な、うまく定義されたインタフェースが存在する。
    3. スタックに組み込まれた IPsec 実装を持つ、セキュリティゲートウェイと外部ボード暗号プロセッサ。
  3. 上記のすべてのアプローチがすべてのホストで実現可能であるわけではない。
    しかし、それぞれのアプローチに対して、そのアプローチが実現可能なホストがいくつか存在する。
上記の 3 つのカテゴリのそれぞれに対して、IPv4 および IPv6、AH トランスポートモードおよびトンネルモード、そして ESP トランスポートモードおよびトンネルモードの、合計 24 のケース(3 x 2 x 4)が存在する。

一部のヘッダフィールドとインタフェースフィールドをここで参考としてあげておく。
これはヘッダ順ではないが、その代わり、列間の比較ができるようにあげてある。
(* = AH 認証には含まれない。ESP 認証には、先行するどのヘッダも含まれない。)

                                             IP/Transport Interface
             IPv4            IPv6            (RFC 1122 -- Sec 3.4)
             ----            ----            ----------------------
             Version = 4     Version = 6
             Header Len
             *TOS            Class,Flow Lbl  TOS
             Packet Len      Payload Len     Len
             ID                              ID (optional)
             *Flags                          DF
             *Offset
             *TTL            *Hop Limit      TTL
             Protocol        Next Header
             *Checksum
             Src Address     Src Address     Src Address
             Dst Address     Dst Address     Dst Address
             Options?        Options?        Opt

             ? = AH には Option-Type と Option-Length は含まれるが、
                 Option-Data は含まれない場合がある。
20 のケースそれぞれについての結果を以下に示す("works" = 出力 IPsec 処理の後に分割され、入力 IPsec 処理の前に再構成される場合に動作)。
実装における問題点については、注釈において示される。
  1. ホスト(IP スタックに統合)
    • AH-トランスポート --> (IP1 - AH - トランスポート - データ)
      • IPv4 -- works
      • IPv6 -- works
    • AH-トンネル --> (IP2 - AH - IP1 - トランスポート - データ)
      • IPv4 -- works
      • IPv6 -- works
    • ESP-トランスポート --> (IP1 - ESP ヘッダ - トランスポート - データ - ESP トレイラー)
      • IPv4 -- works
      • IPv6 -- works
    • ESP-トンネル --> (IP2 - ESP ヘッダ - IP1 - トランスポート - データ - ESP トレイラー)
      • IPv4 -- works
      • IPv6 -- works

  2. ホスト(bump-in-the-stack) -- IPsec を IP 層とネットワークドライバの間に挿入。
    この場合、IPsec モジュールは、分割と再構成のために以下のいずれか 1 つを実行しなければならない。
    • 分割/再構成作業をそれ自身で行い、ネットワーク層との間でやり取りされるパケットを直接送受信する。
      AH または ESP のトランスポートモードでは、これは問題ない。
      AH または ESP のトンネルモードにおいて、トンネルの終端が最終の宛先の場合には、これは問題ない。
      しかし、AH または ESP のトンネルモードで、トンネルの終端が最終の宛先ではなく、送信元ホストがマルチホームである場合、IPsec モジュールは、パケットを適切なネットワークインタフェースに導くために必要な情報(LAN インタフェースと次中継ゲートウェイ)を得ることができないため、このアプローチはサブオプティマルルーティングとなり得る。
      これは、インタフェースと次中継ゲートウェイが最終の宛先とトンネルの終端に対して同一であれば問題ではない。
      しかしこれらが異なると、IPsec はトンネルの終端に対する LAN インタフェースと次中継ゲートウェイを知る必要が出てくる。
      (注釈:トンネルの終I端(セキュリティゲートウェイ)は、最終の宛先への通常の経路上に存在する可能性が極めて高い。しかし、宛先への経路は複数存在することもあり得る。例えば、ファイアウォールを 2 つ持つ組織にホストが存在する場合である。さらに、使用される経路には、普段あまり選ばれないファイアウォールが存在することがあり得る)。
      または、
    • 超過 IP ヘッダが最終的にプリペンドとなり、IPsec モジュールが IPsec 処理された断片をチェックし、それをそのまま放置しなければならない場合に、IPsec 処理されたパケットを IP 層に返す。
      または、
    • IP 層が適切な IP ヘッダを再生成するように、IP 層にパケットの内容を渡す。
    ネットワーク層において、IPsec モジュールはパケットからの次のセレクタ -- 送信元アドレス、宛先アドレス、次プロトコル、さらにトランスポート層ヘッダが存在する場合には、送信元ポートと宛先ポートへアクセスすることになる。
    IPsec が名前にアクセスすることは仮定されない。
    利用可能なセレクタ情報は、適切なセキュリティポリシーエントリとセキュリティアソシエーションを理解するのに十分であると仮定する。
    • AH-トランスポート --> (IP1 - AH - トランスポート - データ)
      • IPv4 -- works
      • IPv6 -- works
    • AH-トンネル --> (IP2 - AH - IP1 - トランスポート - データ)
      • IPv4 -- works
      • IPv6 -- works
    • ESP-トランスポート --> (IP1 - ESP ヘッダ - トランスポート - データ - ESP トレイラー)
      • IPv4 -- works
      • IPv6 -- works
    • ESP-トンネル --> (IP2 - ESP ヘッダ - IP1 - トランスポート - データ - ESP トレイラー)
      • IPv4 -- works
      • IPv6 -- works
  3. セキュリティゲートウェイ -- IPsec を IP スタックに統合

    注釈:IPsec モジュールはパケットから次のセレクタ -- 送信元アドレス、宛先アドレス、次プロトコル、さらに、トランスポート層ヘッダが存在する場合には、送信元ポートおよび宛先ポートにアクセスすることになる。
    ユーザ ID へはアクセスされない(ホストのみがユーザ ID 情報へアクセスする)。
    一部の Bump-in-the-stack 実装と異なり、例えば動的に更新される DNS エントリと連動して動的に割り当てられる IP アドレスを利用する環境が含まれるような場合、セキュリティゲートウェイはシステム名を提供するために DNS 内の送信元アドレスの検索できる場合がある。
    また、ESP ヘッダが存在する場合、またはそれが、分割されたメッセージの最初の断片でない場合には、トランスポート層の情報へのアクセスは行われない。
    利用可能なセレクタ情報は、適切なセキュリティポリシーエントリとセキュリティアソシエーションを理解するのに十分であると仮定される。

    • AH-トンネル --> (IP2 - AH - IP1 - トランスポート - データ)
      • IPv4 -- works
      • IPv6 -- works
    • ESP-トンネル --> (IP2 - ESP ヘッダ - IP1 - トランスポート - データ - ESP トレイラー)
      • IPv4 -- works
      • IPv6 -- works
**********************************************************************
B.3 経路 MTU 探索 
以前に説明したように、「ICMP PMTU」とは経路 MTU 探索に使用される ICMP メッセージを指す。

B.3.1 および B.3.3B.3.2 は除く)の図における凡例は以下の通り。

==== = セキュリティアソシエーション(AH または ESP、トランスポートまたはトンネル)
---- = コネクティビティ(または、ラベル付けされる場合、管理境界)
.... = 以下の ICMP メッセージ(これ以降 ICMP PMTU と呼ぶことにする)
IPv4: IPv6 (RFC 1885):
Hx   = ホスト x
Rx   = ルータ x
SGx  = セキュリティゲートウェイ x
X*   = IPsec をサポートする X
B.3.1 生成元ホストの識別 
ICMP メッセージで返される情報量は限定されているため、PMTU 情報をさらに伝播させる目的で、セキュリティアソシエーション、送信元ホストなどを識別するためにどのセレクタが利用できるかに影響が出てくる。

簡単に言えば、ICMP メッセージは「違反」パケットからの以下の情報を含まなければならない。

- IPv4 (RFC 792) -- IP ヘッダに加えて最低 64 ビット分
従って、IPv4 では、ICMP PMTU は最初の(最も外側の)セキュリティアソシエーションのみを識別する。
これは、ICMP PMTU が、AH または ESP からの最初の SPI のみが得られる、「違反」パケットの IP ヘッダの後の 64 ビット分のみを含むためである。
IPv6 では、おそらく ICMP PMTU は IP ヘッダ内のすべての SPI とセレクタを提供することになるが、(トランスポートヘッダの)送信元/宛先ポート、またはカプセル化されたプロトコル(TCP、UDP など)までは提供しないだろう。
さらに、ESP が使用される場合、トランスポートポートとプロトコルセレクタが暗号化される場合がある。

以下のセキュリティゲートウェイトンネルの図を見て頂きたい(至る所で説明しているように、セキュリティゲートウェイはトランスポートモードを使用しない)

     H1   ===================           H3
       \  |                 |          /
   H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5
       /  ^        |                   \
     H2   |........|                    H4
ホスト H0、H1、H2 と ホスト H3、H4、H5 の間のすべてのトラフィックは、SG2 に対しての 1 つの SA を使用するという SG1 のセキュリティポリシーを考える。
さらに、H0 が H5 に対してデータパケットを送信し、その結果 R1 が ICMP PMTU メッセージを SG1 へ送信することを考える。
もし、PMTU メッセージが SPI のみを持つのであれば、SG1 は SA を検索し、可能性のあるホストのリスト(H0、H1、H2、ワイルドカード)を割り出すことができるが、H0 が ICMP PMTU メッセージを引き起こしたトラフィックを送信したことを SG1 が理解する方法はない。
      original        after IPsec     ICMP
      packet          processing      packet
      --------        -----------     ------
                                      IP-3 header (S = R1, D = SG1)
                                      ICMP header (includes PMTU)
                      IP-2 header     IP-2 header (S = SG1, D = SG2)
                      ESP header      minimum of 64 bits of ESP hdr (*)
      IP-1 header     IP-1 header
      TCP header      TCP header
      TCP data        TCP data
                      ESP trailer

      (*) The 64 bits will include enough of the ESP (or AH) header to

          include the SPI.
              - ESP -- SPI (32 bits), Seq number (32 bits)
              - AH -- Next header (8 bits), Payload Len (8 bits),
                Reserved (16 bits), SPI (32 bits)
ICMP メッセージで返される情報量の制限は、(ICMP PMTU をどこに伝播させるかを知るために)パケットの生成元ホストを識別する際に問題がでる。
ICMP メッセージが 64 ビットの IPsec ヘッダしか含まない(IPv4 での最低限度)のであれば、IPsec セレクタ(例えば、送信元および宛先アドレス、次プロトコル、送信元および宛先ポートなど)は失われることになる。
しかし、ICMP エラーメッセージはそれでも、SG1 に対して SPI、PMTU 情報、そして、関連するセキュリティアソシエーションに対する送信元および宛先ゲートウェイを提供することになる。

宛先セキュリティゲートウェイと SPI は、可能性のある生成元ホストのセットを順に定義していくセキュリティアソシエーションを一意に定義する。
この点において、SG1は、

  1. 可能性のあるすべての生成元ホストに対し、PMTU 情報を送信することができる。
    これは、ホストのリストがワイルドカードの場合、または多くの/ほとんどのホストが SG1 に対して送信してしない場合はうまく動作しない。
    しかし、SPI /宛先/その他が 1 つまたは少数のホストにマッピングされるのであればうまく動作する可能性がある。
  2. SPI /その他と共に PMTU を保存し、対応するセキュリティアソシエーションで、生成元ホストから次のパケットが到着するまで待つことができる。
    パケットが PMTU より大きい場合には、そのパケットをドロップし、新しいパケットと更新された PMTU で ICMP PMTU メッセージを生成し、その生じた問題についての ICMP メッセージを生成元ホストに送信する。
    これにより、生成元ホストへの通知が遅れることになるが、(a) における問題を回避することができる。
後者のアプローチのみがすべての状況において実行できるため、セキュリティゲートウェイはこのサポートをオプションで提供しなければならない (MUST)
ただし、オリジナルパケットからのより多くの情報が ICMP メッセージに含まれる場合には、ICMP/PMTU メッセージを伝播するホストをただちに決定し、PMTU の保存/更新場所の決定に必要な 5 つのフィールド(送信元アドレス、宛先アドレス、送信元ポート、宛先ポート、トランスポートプロトコル)をシステムに提供するための十分な情報が存在する可能性がある。
このような状況では、セキュリティゲートウェイは、経路の下のほうから ICMP PMTU を受信した場合には、ただちに ICMP PMTU メッセージを生成しなければならない (MUST)
注釈:次プロトコルフィールドは ICMP メッセージに含まれないことがあり、そして ESP 暗号化によって、セレクタフィールドが暗号化されて隠されてしまう可能性がある。
B.3.2 PMTU の計算 
ICMP PMTU から PMTU を計算するには、H1 によるあらゆる IPsec ヘッダ(AH / ESP トランスポート、または ESP / AH トンネル)の追加を考慮しなければならない。
1 つのホスト内において、複数のアプリケーションが SPI を共有する可能性があり、セキュリティアソシエーションの入れ子が発生する可能性がある(サポートしなければならない (MUST) 組み合わせについては 4.5 章のセキュリティアソシエーションの基本的な組み合わせを参照のこと)。
以下の図はホスト間のセキュリティアソシエーションの例を示している(ホストのうちの 1 つから見た場合)。
(ESPx または AHx = トランスポートモード)
           Socket 1 -------------------------|
                                             |
           Socket 2 (ESPx/SPI-A) ---------- AHx (SPI-B) -- Internet
SPI-B ヘマッピングされる各ソケットに対する PMTU を計算するために、SPI-B に到達する 2 つの経路 -- Socket 1 と Socket 2/SPI-A への SPI-B からのバックポインタを持つ必要があるだろう。
B.3.3 PMTU データのメンテナンスにおけるグラニュラリティ 
ホストでは、PMTU ICMP 処理が実行可能なグラニュラリティは、実装状況に応じて異なる。
ホストを見ると、PMTU 問題に関して以下の 3 つの興味ある状況が存在する。
  1. ネイティブ IP 実装への IPsec の統合。
  2. 「bump-in-the-stack」(BITS)実装。
    IPsec がネイティブ IP とローカルネットワークの間の、既存の IP プロトコルスタック実装の下に実装される。
  3. IPsec 実装なし -- これはセキュリティゲートウェイが PMTU 情報をホストに送信し返す場合に関連するため含まれる。
(a) の場合のみ、PMTU データは通信アソシエーションと同じグラニュラリティでメンテナンスすることが可能である。
その他の場合には、IP 層は RFC 1191 で定義されている通り、送信元および宛先 IP アドレス(およびオプションで TOS/クラス)のグラニュラリティで PMTU データをメンテナンスすることになる。
これは、複数の通信アソシエーションが同じ送信元と宛先 IP アドレスにマップされる場合や、それぞれの通信アソシエーションが(例えば、異なる変換や異なるアルゴリズムの利用によって)異なる量の IPsec ヘッダオーバーヘッドを持つ場合があるため、重要な相違となる。
これを以下の例で説明する。

ケース (a) と (b) において、以下の状況を考えてみる。
H1 が H2 へ送信する際に、R1 から R2 に送信されるパケットがその間のネットワークホップの PMTU を超過する。

                 ==================================
                 |                                |
                H1* --- R1 ----- R2 ---- R3 ---- H2*
                 ^       |
                 |.......|
R1 が加入者トラフィックを分割しないように設定されている場合、R1 は H1 に対して適切な PMTU を持つ ICMP PMTU メッセージを送信する。
H1 での処理は実装状況に応じて異なる。
(a) (ネイティブ IP)の場合、セキュリティサービスはソケットまたはそれと同等のものにバインドされる。
ここで H1 における IP/IPsec の実装は、関連するソケットに対して PMTU を保存/更新できる。
(b) の場合、H1 の IP 層は PMTU を保存/更新可能であるが、前に説明したように、送信元および宛先アドレス、そして、おそらく TOS/クラスのグラニュラリティでのみ行われる。
そのため、与えられた送信元/宛先/TOS/クラスに対する PMTU は、与えられた送信元および宛先の間のすべての通信アソシエーションに対して使用される IPsec ヘッダの最大限の削減となることから、結果はサブオプティマルとなる可能性がある。

(c) の場合には、IPsec 処理を行うためにセキュリティゲートウェイが存在しなければならない。
そのため、以下の状況を持つと想定する。
H1 が H2 へ送信する際に、SG1 から R に送信されるパケットがその間のネットワークホップの PMTU を超過する。

                         ================
                         |              |
                H1 ---- SG1* --- R --- SG2* ---- H2
                 ^       |
                 |.......|
上記の (b) のケースで説明したように、H1 の IP 層は PMTU を保存/更新可能であるが、送信元および宛先アドレス、そして、おそらく TOS/クラスのグラニュラリティでのみ行われる。
そのため、与えられた送信元/宛先/TOS/クラスに対する PMTU は、与えられた送信元および宛先の間のすべての通信アソシエーションに対して使用される IPsec ヘッダの最大限の削減となることから、結果はサブオプティマルとなる可能性がある。
B.3.4 PMTU データのソケット別メンテナンス 
PMTU の計算(B.3.2 章)の実装、および個々の「通信アソシエーション」のグラニュラリティでの PMTU のサポート(B.3.3 章)はローカルでの問題である。
しかし、ホストにおけるソケットベースの IPsec の実装は、ソケット単位で情報をメンテナンスする必要がある (SHOULD)
bump-in-the-stack システムは、このシステムによって追加されるすべての IPsec ヘッダオーバーヘッドに対して調整した後、ICMP PMTU をホストの IP 実装に渡さなければならない (MUST)
オーバーヘッドの決定は、返された ICMP PMTU メッセージに存在する SPI やその他のすべてのセレクタ情報の解析によって決定する必要がある (SHOULD)
B.3.5 PMTU データのトランスポート層への配送 
更新された PMTU をトランスポート層へ届けるホストの仕組みは、RFC 1191 (経路 MTU 探索)で定義されたものから変更されていない。
B.3.6 PMTU データのエージング 
この話題については、6.1.2.4 章に含まれている。
付録 C -- シーケンススペースウィンドウコードの例 
この付録では、32 パケットウィンドウのビットマスクチェックを実装するルーチンを紹介しておく。
これは、James Hughes 氏(jim_hughes@stortek.com)と Harry Varnis 氏(hgv@anubis.network.com)によって提供されたものであり、実装の例となることを意図して載せたものである。
ここで、このコードはリプレイのチェックとウィンドウの更新の両方を行うことに注意すること。
従って以下のアルゴリズムは、パケットが認証された後のみ呼び出される必要がある。
実装時には、ICV を計算する前にリプレイのチェックを行うようにするために、コードを分割することを考慮してもよい。
パケットがリプレイしていない場合、コードは ICV を計算し、(悪いパケットを破棄し)、そしてパケットが OK であれば、ウィンドウを更新する。
#include <stdio.h>
#include <stdlib.h>
typedef unsigned long u_long;

enum {
    ReplayWindowSize = 32
};

u_long bitmap = 0;                 /* session state - must be 32 bits */
u_long lastSeq = 0;                     /* session state */

/* Returns 0 if packet disallowed, 1 if packet permitted */
int ChkReplayWindow(u_long seq);

int ChkReplayWindow(u_long seq) {
    u_long diff;

    if (seq == 0) return 0;             /* first == 0 or wrapped */
    if (seq > lastSeq) {                /* new larger sequence number */
        diff = seq - lastSeq;
        if (diff < ReplayWindowSize) {  /* In window */
            bitmap <<= diff;
            bitmap |= 1;                /* set bit for this packet */
        } else bitmap = 1;          /* This packet has a "way larger" */
        lastSeq = seq;
        return 1;                       /* larger is good */
    }
    diff = lastSeq - seq;
    if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */
    if (bitmap & ((u_long)1 << diff)) return 0; /* already seen */
    bitmap |= ((u_long)1 << diff);              /* mark as seen */
    return 1;                           /* out of order but good */
}

char string_buffer[512];


#define STRING_BUFFER_SIZE sizeof(string_buffer)

int main() {
    int result;
    u_long last, current, bits;

    printf("Input initial state (bits in hex, last msgnum):\n");
    if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0);
    sscanf(string_buffer, "%lx %lu", &bits, &last);
    if (last != 0)
    bits |= 1;
    bitmap = bits;
    lastSeq = last;
    printf("bits:%08lx last:%lu\n", bitmap, lastSeq);
    printf("Input value to test (current):\n");

    while (1) {
        if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break;
        sscanf(string_buffer, "%lu", &current);
        result = ChkReplayWindow(current);
        printf("%-3s", result ? "OK" : "BAD");
        printf(" bits:%08lx last:%lu\n", bitmap, lastSeq);
    }
    return 0;
}
付録 D -- ICMP メッセージの分類 
以下の表は、ICMP メッセージの特長を、ホスト生成、ルータ生成、両方、未割り当て/未知として分類したものである。
最初のセットが IPv4 であり、2 番目のセットが IPv6 である。
                                IPv4

Type    Name/Codes                                             Reference
========================================================================
HOST GENERATED:
  3     Destination Unreachable
         2  Protocol Unreachable                               [RFC792]
         3  Port Unreachable                                   [RFC792]
         8  Source Host Isolated                               [RFC792]
        14  Host Precedence Violation                          [RFC1812]
 10     Router Selection                                       [RFC1256]




Type    Name/Codes                                             Reference
========================================================================
ROUTER GENERATED:
  3     Destination Unreachable
         0  Net Unreachable                                    [RFC792]
         4  Fragmentation Needed, Don't Fragment was Set       [RFC792]
         5  Source Route Failed                                [RFC792]
         6  Destination Network Unknown                        [RFC792]
         7  Destination Host Unknown                           [RFC792]
         9  Comm. w/Dest. Net. is Administratively Prohibited  [RFC792]
        11  Destination Network Unreachable for Type of Service[RFC792]
  5     Redirect
         0  Redirect Datagram for the Network (or subnet)      [RFC792]
         2  Redirect Datagram for the Type of Service & Network[RFC792]
  9     Router Advertisement                                   [RFC1256]
 18     Address Mask Reply                                     [RFC950]



                                IPv4
Type    Name/Codes                                             Reference
========================================================================
BOTH ROUTER AND HOST GENERATED:
  0     Echo Reply                                             [RFC792]
  3     Destination Unreachable
         1  Host Unreachable                                   [RFC792]
        10  Comm. w/Dest. Host is Administratively Prohibited  [RFC792]
        12  Destination Host Unreachable for Type of Service   [RFC792]
        13  Communication Administratively Prohibited          [RFC1812]
        15  Precedence cutoff in effect                        [RFC1812]
  4     Source Quench                                          [RFC792]
  5     Redirect
         1  Redirect Datagram for the Host                     [RFC792]
         3  Redirect Datagram for the Type of Service and Host [RFC792]
  6     Alternate Host Address                                 [JBP]
  8     Echo                                                   [RFC792]
 11     Time Exceeded                                          [RFC792]
 12     Parameter Problem                              [RFC792,RFC1108]
 13     Timestamp                                              [RFC792]
 14     Timestamp Reply                                        [RFC792]
 15     Information Request                                    [RFC792]
 16     Information Reply                                      [RFC792]
 17     Address Mask Request                                   [RFC950]
 30     Traceroute                                             [RFC1393]
 31     Datagram Conversion Error                              [RFC1475]
 32     Mobile Host Redirect                                   [Johnson]
 39     SKIP                                                   [Markson]
 40     Photuris                                               [Simpson]




Type    Name/Codes                                             Reference
========================================================================
UNASSIGNED TYPE OR UNKNOWN GENERATOR:
  1     Unassigned                                             [JBP]
  2     Unassigned                                             [JBP]
  7     Unassigned                                             [JBP]
 19     Reserved (for Security)                                [Solo]
 20-29  Reserved (for Robustness Experiment)                   [ZSu]
 33     IPv6 Where-Are-You                                     [Simpson]
 34     IPv6 I-Am-Here                                         [Simpson]
 35     Mobile Registration Request                            [Simpson]
 36     Mobile Registration Reply                              [Simpson]
 37     Domain Name Request                                    [Simpson]
 38     Domain Name Reply                                      [Simpson]
 41-255 Reserved                                               [JBP]


                                IPv6

Type    Name/Codes                                             Reference
========================================================================
HOST GENERATED:
  1     Destination Unreachable                                [RFC 1885]
         4  Port Unreachable




Type    Name/Codes                                             Reference
========================================================================
ROUTER GENERATED:
  1     Destination Unreachable                                [RFC1885]
         0  No Route to Destination
         1  Comm. w/Destination is Administratively Prohibited
         2  Not a Neighbor
         3  Address Unreachable
  2     Packet Too Big                                         [RFC1885]
         0
  3     Time Exceeded                                          [RFC1885]
         0  Hop Limit Exceeded in Transit
         1  Fragment reassembly time exceeded




Type    Name/Codes                                             Reference
========================================================================
BOTH ROUTER AND HOST GENERATED:
  4     Parameter Problem                                      [RFC1885]
         0  Erroneous Header Field Encountered
         1  Unrecognized Next Header Type Encountered
         2  Unrecognized IPv6 Option Encountered
参考文献 
[BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: Mathematical Foundations and Model", Technical Report M74-244, The MITRE Corporation, Bedford, MA, May 1973.

[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.

[DoD85] US National Computer Security Center, "Department of Defense Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, US Department of Defense, Ft. Meade, MD., December 1985.

[DoD87] US National Computer Security Center, "Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria", NCSC-TG-005, Version 1, US Department of Defense, Ft. Meade, MD., 31 July 1987.

[HA94] Haller, N., and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.

[HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.

[HM97] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997.

[ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992.

[IB93] John Ioannidis and Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of USENIX Security Symposium, Santa Clara, CA, October 1993.

[IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio

[KA98a] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.

[KA98b] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.

[Ken91] Kent, S., "US DoD Security Options for the Internet Protocol", RFC 1108, November 1991.

[MSST97] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.

[Orm97] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.

[Pip98] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.

[Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John Wiley & Sons, New York, NY, 1994.

[SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, published in NIST Publication NIST-IR-90-4250, February 1990.

[SMPT98] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393, August 1998.

[TDG97] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.

[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.

否認事項 
この文書において示された見解と仕様は著者によるものであり、必ずしもその雇い主によるものではない。
著者とその雇い主は、正確/不正確な実装、およびこの設計の利用から生じるどのような問題への責任も拒否する。
著者の連絡先 
Stephen Kent
BBN Corporation
70 Fawcett Street
Cambridge, MA 02140
USA

Phone: +1 (617) 873-3988
EMail: kent@bbn.com
 

Randall Atkinson
@Home Network
425 Broadway
Redwood City, CA 94063
USA

Phone: +1 (415) 569-5000
EMail: rja@corp.home.net
 

翻訳者

東京都中央区新川1-21-2 茅場町タワー
株式会社 NTTデータ
技術開発本部
馬場 達也

EMail: babatt@nttdata.co.jp

著作権表示全文 
Copyright (C) The Internet Society (1998). All Rights Reserved.

本文書とその翻訳は、複製および他に提供することができる。
また、この文書に論評や説明を加えたり、その実装を補助するものは、上記の著作権表示およびこの節を付加していれば、全体あるいは一部であっても一切の制約を課されることなく作成、複製、発表、配布できる。
ただし、この文書自体に対して、著作権表示やインターネットソサエティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはならない。
インターネット標準化過程で定義されている著作権のための手続きに従って、インターネット標準を開発するために必要な場合や、RFC を英語以外の言語に翻訳する必要がある場合はそのかぎりでない。

上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはない。

本文書とここに含まれた情報は「無保証」で提供され、インターネットソサエティおよび IETF はすべての保証を明示的にも暗黙的にもおこなわない。
その中には、この情報がいかなる権利も侵害していないという保証や、商用利用および特定目的における適合性への保証が含まれる。