|
ネットワーク WG Request for Comments： 2401 廃止： 1825 分類： スタンダードトラック |
S. Kent BBN Corp R. Atkinson @Home Network 1998年11月 |
本書は、 インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、 それを改良するための議論や提言を求めるものである。 このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照すること。 このメモの配布に制限はない。
Copyright (C) The Internet Society (1998). All Rights Reserved.
1.1 文書の要旨
1.2 対象とする読者
1.3 関連文書
2.1 目標、目的、要求条件および問題点
2.2 注意および前提
3.1 IPsecが行うこと
3.2 IPsecの動作
3.3 IPsecの実装場所
4.1 定義と範囲
4.2 セキュリティアソシエーションの機能
4.3 セキュリティアソシエーションの結合
4.4 セキュリティアソシエーションデータベース
4.4.1 セキュリティポリシーデータベース(SPD)
4.4.2 セレクタ
4.4.3 セキュリティアソシエーションデータベース(SAD)
4.6.1 マニュアル手法
4.6.2 SAおよび鍵の自動管理
4.6.3 セキュリティゲートウェイの位置探索
5.1.1 SAまたはSAバンドルの選択と使用
5.1.2 トンネルモードでのヘッダ構成
5.1.2.1 トンネルモードでのヘッダ構成(IPv4)
5.1.2.2 トンネルモードでのヘッダ構成(IPv6)
5.2.1 SAまたはSAバンドルの選択と使用
5.2.2 AHおよびESPトンネルの処理方法
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のエージング
8.1 セキュリティアソシエーションとデータセンシティビティの関係
8.2 センシティビティの一貫性チェック
8.3 セキュリティアソシエーションデータベース用の追加MLS属性
8.4 MLSネットワーキング用の追加入力処理ステップ
8.5 MLSネットワーキング用の追加出力処理ステップ
8.6 セキュリティゲートウェイ用の追加MLS処理
補遺 B PMTU、DF、分割に関する問題についての解釈および議論
B.3.1 生成元ホストの識別
B.3.2 PMTUの計算
B.3.3 PMTUデータのメンテナンスにおけるグラニュラリティ
B.3.4 PMTUデータのソケット別メンテナンス
B.3.5 PMTUデータのトランスポート層への配送
B.3.6 PMTUデータのエージング
このメモでは、 IPsecに準拠するシステムの基本的なアーキテクチャについて定義する。 このアーキテクチャの目標は、IPv4およびIPv6の両方の環境において、 IP層のトラフィックに様々なセキュリティサービスを提供することである。 この文書では、システムの目標、システムの構成要素、 そしてその構成要素がどのように連携するのか、 どのようにIP環境へ適用されるのかということについて定義する。 ただし、この文書では、 IPsecアーキテクチャのすべての側面を取り上げることはしない。 これに続く別の文書において、 NAT環境におけるIPsecの利用法やIPマルチキャストのより完全なサポートなど、 さらに進んだ機能のより詳細なアーキテクチャについて取り上げる予定である。 以下のIPsecセキュリティアーキテクチャの主要な構成要素について、 必要とされる基本的な機能を紹介する。 (a), (c), (d)のプロトコルは、 これに追加される別のRFC (別の文書へのポインタは 1.3章を参照のこと) において定義される。
この文書では、 インターネットにおける総合的なセキュリティアーキテクチャを扱うのではなく、 暗号とプロトコルのセキュリティの仕組みの組み合わせによって提供される、 IP層におけるセキュリティのみを扱う。
この文書において、しなければならない(MUST)、 してはならない(MUST NOT)、要求される(REQUIRED)、 することになる(SHALL)、することはない(SHALL NOT)、 する必要がある(SHOULD)、しないほうがよい(SHOULD NOT)、 推奨される(RECOMMENDED)、してもよい(MAY)、 選択できる(OPTIONAL)のキーワードが使用された場合は、 RFC 2119 [Bra97]における定義に沿って解釈されるものとする。
この文書が対象とする読者には、 IPセキュリティ技術を実装しようとする者、 およびこのシステムの一般的な背景の習得に関心のある者が含まれる。 特に、この技術を将来利用しようとするユーザ(エンドユーザまたはシステム管理者)が対象として含まれる。 知識の背景と語彙のギャップを埋めるために、 用語集を付録として付けておく。 この文書では、 読者がインターネットプロトコルおよび関連するネットワーク技術、 そして一般的なセキュリティ用語とコンセプトに精通していることを前提とする。
上で説明したように、IPsecの構成要素の一部、 およびその相互関係について詳細に定義する文書が他に存在する。 それには、以下に関するRFCが含まれる。
IPsecは、IPv4およびIPv6に対して、 相互接続可能で高品質な暗号化ベースのセキュリティを提供するように設計されている。 提供されるセキュリティサービスには、アクセス制御、 コネクションレスインテグリティ、データ生成元認証、 リプレイに対する保護(部分的なシーケンスインテグリティの形式)、 守秘性(暗号)、そして限定されたトラフィックフロー守秘性が含まれる。 これらのサービスはIP層において提供され、 IPとその上位層プロトコルの保護機能を提供する。
これらのサービスの目標は、 認証ヘッダ(AH)とIP暗号ペイロード(ESP)の2つのトラフィックセキュリティプロトコルの利用、 および暗号鍵管理手法とそのプロトコルの利用によって達成される。 使用されるIPsecプロトコルのセット、およびプロトコルの使用法は、 ユーザ、アプリケーション、 そしてサイト/組織のセキュリティ要件とシステム要件によって決定される。
正確に実装され、使用された場合には、これらの仕組みは、 トラフィックの保護にこれらのセキュリティの仕組みを使用しないユーザ、 ホスト、およびその他のインターネット構成要素に対して不利な影響を及ぼすものであってはならない。 また、これらの仕組みはアルゴリズムに依存しないように設計されている。 このモジュラー方式により、実装の他の部分へ影響を与えることなく、 異なるアルゴリズムのセットを選択することが可能となる。 例えば、必要であれば(小集団を作ることにより)ユーザコミュニティ毎に異なるアルゴリズムのセットを選択する場合があるだろう。
インターネット全体における相互接続性を促進するため、 デフォルトのアルゴリズムの標準セットが指定されている。 これらのアルゴリズムをIPsecトラフィック保護プロトコルおよび鍵管理プロトコルと連携して利用することにより、 システム開発者およびアプリケーション開発者が、 インターネット層における高品質な暗号セキュリティ技術を実装することが可能となる。
IPsecプロトコル群とそのデフォルトのアルゴリズムは、 インターネットトラフィックに高品質なセキュリティを提供するために設計されている。 しかしながら、これらのプロトコルの利用によって提供されるセキュリティは、 プロトコルの実装品質に完全に依存しており、 その問題はこの標準セットの範囲外である。 さらに、コンピュータシステムやネットワークのセキュリティは、人的、 物理的、手順、危険からの影響や、 コンピュータセキュリティ対策などを含む多くの要因からなっている。 このように、IPsecは、 総合的なシステムセキュリティアーキテクチャの一部に過ぎないのである。
最後に、IPsecによってもたらされるセキュリティは、 IPsecの実装される運用環境の多くの要因に深く依存している。 例えば、OSのセキュリティ上の欠陥、低品質な乱数発生源、 ずさんなシステム管理手順や手法などはすべて、 IPsecによって提供されるセキュリティを低下させる要因となり得る。 このようないかなる環境上の属性も、IPsec標準の範囲には含まない。
この章では、IPsecの動作、システムの構成要素、 そして上で述べたセキュリティサービスを提供するために各構成要素がどのように連携するかということについて概要を述べる。 ここでの目標は、読者が処理とシステムの全体について「想像」でき、 それがIP環境にどのように適用されるのかを目にすることができるようにすること、 そして各構成要素をより詳細に記述したこの文書の後半部分の周辺状況を提供することである。
IPsecの実装は、ホストまたはセキュリティゲートウェイ環境で動作し、 IPトラフィックに対する保護を提供する。 提供される保護は、ユーザまたはシステム管理者によって作成、 管理されるセキュリティポリシーデータベース(Security Policy Database (SPD))、または、 ユーザまたはシステム管理者が作る制約内で動作するアプリケーションによって定義される要求条件に基づいている。 一般的に、パケットはデータベース(SPD)のエントリにマッチしたIPおよびトランスポート層ヘッダの情報に従って、 3つの処理モードのうちの1つに選択される(4.4.2章のセレクタ)。 各パケットは、 セレクタによって識別される適用可能なデータベースのポリシーに従って、 IPsecセキュリティサービスが適用されるか、そのパケットが破棄されるか、 またはそのパケットがIPsecをバイパスされるかのいずれかの処理がされる。
IPsecでは、システムに要求されるセキュリティプロトコルを選択させ、 サービスに利用するアルゴリズムを決定させ、 要求されたサービスの提供に必要な暗号鍵を配備させることによって、 IP層におけるセキュリティサービスを提供する。 IPsecは、ホスト間、セキュリティゲートウェイ間、 およびセキュリティゲートウェイとホストの間の1つ以上の「経路」の保護に利用できる(「セキュリティゲートウェイ」は、 IPsecプロトコルを実装する中間システムを表すものとして、 IPsec文書全体で用いられる。 例えば、IPsecを実装するルータやファイアウォールはセキュリティゲートウェイとなる)。
IPsecが提供可能なセキュリティサービスには、アクセス制御、 コネクションレスインテグリティ、データ生成元認証、 リプレイパケットの拒否(部分的なシーケンスインテグリティの形式)、 守秘性(暗号)、そして限定されたトラフィックフロー守秘性が含まれる。 これらのサービスはIP層において提供されるため、上位層プロトコル、 すなわち、TCP、UDP、ICMP、BGPなどでも利用することが可能である。
IPsec DOIはまた、IP圧縮のネゴシエーション [SMPT98] もサポートする。 これは、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のような公開鍵システムを利用することができる。
ホスト上で、 または(セキュリティゲートウェイを構築するために)ルータやファイアウォールと連携してIPsecを実装するには、 いくつかの方法がある。 一般的な例を以下に示す。
この章では、すべてのIPv6の実装、およびAH、ESP、 または両方を実装するIPv4の実装のための、 セキュリティアソシエーションの管理に関する要求条件を定義する。 「セキュリティアソシエーション」(SA)の概念はIPsecの基本となるものである。 AHおよびESPの両方がSAを使用し、IKEの主要機能によって、 セキュリティアソシエーションの確立とメンテナンスがなされる。 AHまたはESPのすべての実装は、 以下に示すセキュリティアソシエーションの概念をサポートしなければならない(MUST)。 この章の備考では、 セキュリティアソシエーションの管理における様々な側面について説明し、 SAポリシー管理、トラフィック処理、SA管理技術に要求される特長を定義する。
セキュリティアソシエーション(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が使用される場合は、トンネルされたパケットのみが保護され、 外側ヘッダは保護されない。
以上まとめると、
SAが提供するセキュリティサービスは、選択されたセキュリティプロトコル、 SAモード、SAの終端、 およびプロトコルでのオプションのサービスの選定に依存する。 例えば、AHはIPデータグラムにデータ生成元認証とコネクションレスインテグリティを提供する(以降、 単に「認証」と呼ぶことにする)。 認証サービスの「精度」は、 AHが使用されるセキュリティアソシエーションのグラニュラリティの機能であり、 これについては4.4.2章の「セレクタ」で説明する。
AHはまた、サービス妨害攻撃に対抗するために、 受信側の選択でリプレイ防止サービス(部分的なシーケンスインテグリティ)を提供する。 守秘性が要求されない(あるいは、 例えば暗号化の利用に関する政府規制のために守秘性が許可されない)場合には、 AHが適切なプロトコルとして使用される。 AHはまた、IPヘッダの選択された部分に対する認証も提供し、 これはある時に必要となる場合がある。 例えば、IPv4オプションまたはPv6拡張ヘッダのインテグリティが、 送信側と受信側の経路間で保護されなければならない場合に、 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に比べ、 トラフィック解析に対してより脆弱であることに注意すること。
個々のSA上を転送されるIPデータグラムには、 AHまたはESPのいずれか一方(両方ではない)のセキュリティプロトコルによる保護が与えられる。 場合によっては、 単独のSAで達成できない特定のトラフィックフローに対して、 セキュリティポリシーがサービスの結合を要求することもある。 このような場合、要求されるセキュリティポリシーを実現するために、 複数のSAを使用することが必要となるだろう。ここで、 セキュリティポリシーを満足するためにトラフィックを処理しなければならないSAのシーケンスに対して「セキュリティアソシエーションバンドル」または「SAバンドル」という言葉を適用することにする(バンドルを構成するSAは、 異なる終端で終了する場合があることに注意すること。 例えば、あるSAがモバイルホストとセキュリティゲートウェイの間に存在し、 2番目の入れ子にされたSAはゲートウェイの背後のホストに対して存在することがある)。
セキュリティアソシエーションは2つの方法(トランスポート隣接と反復トンネリング)でバンドルされる。
Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | | -----Security Association 1 (ESP transport)------- | | | -------Security Association 2 (AH transport)----------
反復トンネリングには、3つの基本ケースがあるが、 2と3のケースのみをサポートすればよい。
Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | | -------Security Association 1 (tunnel)---------- | | | | ---------Security Association 2 (tunnel)--------------
Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | ----Security Association 1 (tunnel)---- | | | ---------Security Association 2 (tunnel)-------------
Host 1 --- Security ---- Internet -- Security --- Host 2 | Gwy 1 Gwy 2 | | | | | | --Security Assoc 1 (tunnel)- | | | -----------Security Association 2 (tunnel)-----------
これらの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章にて説明する。
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のペアを持つ必要がある場合がある。
結局、セキュリティアソシエーションは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アドレスに対してのみサポートされているが、 ワイルドカードはすべてのセレクタで表現できることに注意すること)。
例えば、 許可される送信元アドレスの値がホストの範囲(192.168.2.1から192.168.2.10)であるSPDエントリを考えてみる。 さらに、送信元アドレスが192.168.2.3であるパケットが送られるとする。 SAに対して使用される値は、 このセレクタに対するポリシーエントリで示されているセレクタ値のソースによって、 以下のサンプル値のいずれかとなる。
SAで使用される値のソース 新しいSADセレクタ値の例 ------------------------ ----------------------- 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内に破棄エントリを持ったり、 あるいはプロキシ鍵交換を提供するなどの様々な方法によって、 暗号化されたパケットの通過を禁止することが可能であることに注意すること。 後者の方法では、 トラフィックはセキュリティゲートウェイ内の鍵管理モジュールに内部で送られる。
SA(またはSAバンドル)は、 SAに対するトラフィックのセットを定義するために使用されるセレクタに応じて、 細かい精製(fine-grained)または粗い精製(coarse-grained)となる。 例えば、2つのホスト間のすべてのトラフィックは、 1つのSAを経由させて運ばれても良く、この場合、 そのトラフィックには統一されたセキュリティサービスが与えられる。 これとは別に、ホスト間のトラフィックは、 使用されるアプリケーションに応じて(次プロトコルフィールドおよびポートフィールドの定義に従って)、 SAによって提供されるセキュリティサービスが異なる複数のSAに分散する場合がある。 同様に、セキュリティゲートウェイ間のすべてのトラフィックは、 1つのSAで運ぶことも可能であり、また、 それぞれの通信ホスト間にSAを1つずつ割り当てることも可能である。 SAのグラニュラリティ制御を容易にするために、 SA管理用に以下のセレクタパラメータをサポートしなければならない(MUST)。 ここで、ESPヘッダを持つパケットを受信する場合、例えば、 カプセル化セキュリティゲートウェイまたはBITW実装の場合には、 トランスポート層プロトコル、送信元/宛先ポート、 名前(存在する場合)は「不透明(OPAQUE)」となる場合があることに注意すること。 すなわち、暗号化または分割のためにアクセス不能となる場合がある。 また、送信元アドレス、宛先アドレスとも、 IPv4またはIPv6のどちらかである必要があることに注意すること。
注釈：このセレクタのとる値の1つに「不透明(OPAQUE)」がある。
[以下の場合に要求される(REQUIRED)。
ここで、アドレス以外の名前の形式のサポートは、
マニュアル鍵付きSAでは要求されないことに注意すること。
注釈：トランスポートプロトコルの位置を探すために、
システムはパケットヘッダをつないで「プロトコル」または「次ヘッダ」フィールドをチェックする。
これは、トランスポートとして認識されるいずれかのものに到達するまで、
または拡張ヘッダのリスト上にないヘッダに到達するまで、
またはトランスポートプロトコルに不透明(opaque)を与えるESPヘッダに到達するまで行われる。
Next Hdr Transport Layer Derived Port Selector Field
in Packet Protocol in SPD Value in SPD and SAD
-------- --------------- ---------------------------
ESP ESP or ANY ANY (i.e., don't look at it)
-don't care- ANY ANY (i.e., don't look at it)
specific value specific value NOT ANY (i.e., drop packet)
fragment
specific value specific value actual port selector field
not fragment
パケットが分割されている場合、
ポート情報は現在の断片で利用できない場合がある。
その場合は、その断片を破棄する。
ICMP PMTUが最初の断片用に送られる必要があり、
これにポート情報が含まれることになる。
[サポートしてもよい(MAY)]
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を結果的に作り出すことになるだろう。 ベンダーは、 顧客が容易に明確かつ簡潔なポリシーの仕様の設定ができるようにするため、 このようなインタフェースをサポートする可能性がある。
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 フィールドは以下の通り。
注釈：SAの期限が切れた場合の鍵のリフレッシュ処理に関する詳細はローカルの問題である。 ただし、1つの合理的なアプローチは以下の通りである。
注釈：入力SAのプロトコルモードにおいてワイルドカードを使用すると、 受信側(ホストのみ)に複雑な状況を与える場合がある。 この種のSA上のパケットはトンネルまたはトランスポートモードのどちらかで配送されるため、 入力パケットのセキュリティは、 パケットを配送するために使用されるモードに一部依存する。 その結果として、 アプリケーションが所定のパケットのSAのモードを考慮するのであれば、 モードの情報を獲得する仕組みがアプリケーションに必要となる。
この章では、 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の組み合わせをオプションでサポートできる。 他のオプションの組み合わせの使用により、 相互接続性に反する影響が出る場合がある。
IPsecでは、 マニュアルおよび自動のSAおよび暗号鍵の管理のサポートを義務付けている。 関連するSA管理手法は、IPsecプロトコル、 すなわちAHとESPによって提供されるセキュリティサービスの一部に影響を及ぼすが、 IPsecプロトコルは、その関連する手法とは大部分独立している。 例えば、AHとESPで利用できるオプションのリプレイ防止サービスでは、 自動SA管理が要求される。 さらに、IPsecで使用される鍵配送のグラニュラリティは、 提供される認証のグラニュラリティを決定する(4.7章でのこの問題についての議論も参照のこと)。 一般的に、AHおよびESPにおけるデータ生成元認証は、 認証アルゴリズム(またはこのような秘密情報を生成する鍵管理プロトコル)で使用される秘密情報が、 可能性のある複数の送信元の間で共有される範囲によって制限を受ける。
両方のタイプのSA管理について最低限の要求条件を次に説明する。
最も単純な管理の形態はマニュアル管理であり、 他のシステムとの安全な通信に適切な鍵管理情報とセキュリティアソシエーション管理データを、 人がそれぞれのシステムで手動で設定するというものである。 マニュアル手法は、小規模で静的な環境では実用的であるが、 規模の変化にうまく対応できない。 例えば、 ある企業がいくつかの拠点のセキュリティゲートウェイにIPsecを使用することによって、 仮想私設網(VPN)を構築することが可能である。 拠点数が少なく、 すべてのサイトが単一の管理ドメイン範囲内におさまる場合には、 マニュアル管理手法が適しているかもしれない。 この場合、セキュリティゲートウェイは、 手動で設定された鍵を使用して組織内の他のサイトとの入出力トラフィックを選択的に保護することが可能だが、 他の宛先行きのトラフィックを保護することはできない。 これはまた、 選択された通信のみに対して保護が必要な場合に適切であるかもしれない。 組織内に完全に閉じた少数のホストまたはゲートウェイ向けのIPsecの使用に対しても、 同様の議論が適用されるだろう。 マニュアル管理手法では、他のオプションも存在するが、 静的に設定された対称鍵を使用することが多い。
IPsecの利用の普及には、インターネット標準でスケーラブルな、 自動化されたSA管理プロトコルが必要である。 このサポートには、AHおよびESPのリプレイ防止機能の使用を強化することと、 例えばユーザ別およびセッション別鍵管理のために、 SAの要求に応じた生成に対応できることが要求される。 (ここで、SAを「再鍵付け」するという概念は、 新しいSPIでの新しいSAの生成、すなわち、 自動SA/鍵管理プロトコルの使用を一般的に意味する処理を実際に含むことに注意すること。)
IPsecで使用するように選択されたデフォルトの自動鍵管理プロトコルは、 IPsec domein of interpretation [Pip98]配下のIKE [MSST97, Orm97, HC98] である。 他の自動SA管理プロトコルを使用してもよい(MAY)。
自動SA/鍵管理プロトコルが使用される場合、このプロトコルの出力は、 例えば1つのESP SA用の複数の鍵の生成に使用されることがある。 これは以下の理由により起こり得る。
鍵管理システムは、 それぞれの鍵用に独立したビットストリングを提供してもよいし、 すべてのビットが抽出された1つのビットストリングを生成してもよい。
1つのビットストリングが提供される場合、 システムの要求される鍵にそのビットストリングをあてはめる部分が、 SAの両終端で同じように動作することを保証するように注意する必要がある。 SAのそれぞれの終端におけるIPsecの実装が同じ鍵に対して同じビットを使用し、 システムの部分に関係なくビットストリングを個々の鍵に分割することを保証するために、 暗号鍵を最初の(左端、上位)ビットから採り(MUST)、 認証鍵を残りのビットから採らなければならない(MUST)。 それぞれの鍵のビット数は、 対応するアルゴリズムの仕様が記述されているRFCにて定義される。 複数の暗号鍵または複数の認証鍵を使用する場合、 アルゴリズムに提供される1つのビットストリングからの選択順序をアルゴリズムの仕様で指定しなければならない。
この章では、 適切なセキュリティゲートウェイの存在をホストがいかにして知るか、 さらにホストがセキュリティゲートウェイとコンタクトした後、 それが正しいセキュリティゲートウェイであることをどのようにして知るかということについて説明する。 要求された情報をどこに保存するかということについての詳細は、 ローカルの問題である。
リモートホスト(H1)がサーバーまたはその他のマシン(H2)にアクセスするためにインターネットを使用し、 H1のトラフィックが通過しなければならない、 ファイアウォールのようなセキュリティゲートウェイ(SG2)が存在する状況を考えてみる。 この状況の例として、 インターネットを通って自組織のファイアウォール(SG2)に到達するモバイルホスト(Road Warrior)があてはまる。 (4.5章のケース4を参照のこと。) この状況では、いくつかの問題が起こる。
これらの問題に対処するために、 ホストまたはセキュリティゲートウェイでは、ユーザまたは管理者が、 その使用を要求する宛先アドレスのセットに対するセキュリティゲートウェイのアドレスの設定ができるような管理インタフェースを持たなければならない(MUST)。 これには以下の事項を設定する機能が含まれる。
SPDではまた、 セキュリティゲートウェイおよび宛先ホストへの経路に対する、 他のどのようなIPsec要求条件をもカバーするようなポリシー情報が設定されると仮定する。
セキュリティゲートウェイの発見/確認の自動化方法の問題については、 この文書では扱わないこととする。
セキュリティアソシエーションの受信側指向とは、 ユニキャストトラフィックの場合では、通常、 宛先システムによってSPI値が選択されることを意味する。 宛先システムにSPI値を選択させることにより、 マニュアルで設定されたセキュリティアソシエーションが、 自動的に設定(例えば鍵管理プロトコルを経て)されたセキュリティアソシエーションと衝突する可能性、 または複数送信元からのセキュリティアソシエーションが互いに衝突する可能性がなくなる。 マルチキャストトラフィックの場合では、 マルチキャストグループ単位に複数の宛先システムが存在する。 従って、一部のシステムまたは人々は、 それぞれのマルチキャストグループに代わってSPIまたはSPI群を選択するために、 すべてのマルチキャストグループを調整し、 (ここで定義されない仕組みを経て)マルチキャストグループのすべての正規メンバーにグループのIPsec情報を伝達する必要がある。
対称鍵暗号化アルゴリズムまたは認証アルゴリズムが使用される場合、 マルチキャストグループへの複数の送信者は、 そのグループへのすべてのトラフィックのために1つのセキュリティアソシエーション(それにセキュリティパラメータインデックス)を使用する必要がある(SHOULD)。 このような状況では、受信側は、 メッセージがそのマルチキャストグループに対する鍵を保持するシステムから来たということのみを知る。 このような場合、受信側は、 一般的にどのシステムがマルチキャストトラフィックを送ったかを認証することは不可能となるだろう。 この他の、 より一般的なマルチキャストに関する仕様は後のIPsec文書に委ねることにする。
この仕様が発行された時点では、 マルチキャスト鍵配送のための自動化プロトコルは、 十分な標準化が考慮されていなかった。 メンバーが比較的少ないマルチキャストグループでは、 マニュアル鍵配送、または、改良されたDiffie‐Hellmanのような既存のユニキャスト鍵配送アルゴリズムを複数使用した方が現実的である。 大きなグループでは、新しいスケーラブルな手法が必要となるだろう。 この分野での現在の取り組み例として、 Group Key Management Protocol (GKMP) [HM97]があげられる。
4.4.1章の「セキュリティポリシーデータベース(SPD)」で説明したように、 非IPsecトラフィックを含むすべてのトラフィック(入力および出力)の処理中に、 SPDを参照しなければならない。 SPD内に、 当該パケットにあてはまるポリシーが(入力または出力トラフィックのいずれかに対して)発見されない場合は、 パケットは破棄されなければならない(MUST)。
注釈：IPsecで使用されるすべての暗号化アルゴリズムは、 正規のネットワークバイト順序での入力を期待し(RFC 791の付録を参照のこと)、 正規のネットワークバイト順序の出力を生成する。 IPパケットもまた、ネットワークバイト順序で転送される。
セキュリティゲートウェイまたはBITW実装(および多くのBITS実装)では、 各出力パケットは、 そのパケットに要求される処理を決定するためにSPDと比較される。 パケットが破棄される場合には、これは監査対象イベントとなる。 トラフィックがIPsec処理のバイパスを許可される場合には、 そのパケットはIPsec処理が行われている環境での「通常の」処理を通り抜ける。 IPsec処理が要求される場合には、 パケットが既存のSA(またはSAバンドル)にマップされるか、 そのパケットに対して新しいSA(またはSAバンドル)が生成される。 パケットのセレクタが複数のポリシーまたは複数の既存SAにマッチする可能性があるため、 そして、SPDは順序付けされているが、SADは順序付けされていないため、 IPsecは以下のことを行わなければならない(MUST)。
ソケットに基づくホストでのIPsec実装では、 ソケット上を流れるトラフィックに適用されるIPsec処理を決定するために、 新しいソケットが生成された際には常にSPDが参照されることになるだろう。
注釈：準拠する実装は、 NULL暗号化アルゴリズムおよびNULL認証アルゴリズムの両方を使用するESP SAのインスタンスを許可してはならない(MUST NOT)。 この種のSAをネゴシエートしようとする試みは、監査対象イベントとなる。
この章では、内側および外側IPヘッダ、拡張ヘッダ、 そしてAHおよびESPトンネルのオプションの処理について説明する。 これには、カプセル化(外側)IPヘッダの構築方法、 内側IPヘッダ内のフィールドの処理方法、 および行うべきその他のアクションが含まれている。 一般的なアイディアは、RFC 2003 「IP Encapsulation with IP」で使用されているものをもとにモデル化されている。
以下の章の表は、 異なるヘッダ/オプションフィールドに対する処理方法を示している(constructed = 外側フィールドにある値は、内側の値とは独立して構成される)。
<-- 外側ヘッダと内側ヘッダの関係 -->
カプセル化器における カプセル開放器における
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
注釈：TTLのデクリメントは、
パケットの転送が行われる際に通常行われるアクションの1つである。
送信ノードは、パケットを転送するのではなく送信するので、
カプセル化器と同じノードから送信されるパケットは、
TTLのデクリメントは行われない。
注釈：(例えば、カプセル化器がNATボックスとして動作している場合)、
パケットが送られる環境からカプセル化器を通って到達できるアドレスである限り、
原則として、カプセル化IP送信元アドレスは、
カプセル化器のインタフェースアドレスのどれか、
またはカプセル化器のIPアドレスのどれとも異なるアドレスであることができる。
IPsecが現在のところ、
カプセル化IPヘッダの送信元アドレスを含む入力処理に関する要求条件を持たないため、
これは問題とはならない。
従って、受信側トンネル終端は、
カプセル化IPヘッダ内の宛先アドレスを調べる一方、
内側(カプセル化) IPヘッダ内の送信元アドレスを調べるのみである。
注釈番号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
AHまたはESP処理の実行の前に、すべてのIPの断片が再構成される。 IPsec処理を適用する各入力IPデータグラムは、 IP次プロトコルフィールド内のAHまたはESP値(あるいは、 IPv6の場合における拡張ヘッダとしてのAHまたはESP)の存在によって識別される。
注釈：リプレイ防止サービスの実装時に利用できる、 32パケットウィンドウ用のビットマスクチェックのサンプルコードが付録 Cにある。
AHまたはESPヘッダにはSPIが存在するため、 適切なSAへのIPデータグラムのマッピングは簡略化されている。 ここで、セレクタチェックは外側(トンネル)ヘッダではなく、 内側ヘッダで行われることに注意すること。 実行のステップは以下の通りである。
このシステム用ではないトランスポートプロトコルヘッダまたはIPヘッダが現れるまで、
すべてのIPsecヘッダに対し(1)と(2)の処理を行う。
どのSAが使用され、どの順番で適用されたかという情報を保持すること。
注釈：正確な「マッチング」ポリシーは、
最初に見つけられた入力ポリシーである必要は必ずしもない。
(4)のチェックに失敗した場合は、
すべてのポリシーエントリのチェックが完了するか、
チェックが成功するまで(3)と(4)のステップを繰り返す。
これらのステップの最後では、
その結果生じたパケットをトランスポート層に渡すか、
そのパケットを転送する。
ここで、
これらのステップで処理されたすべてのIPsecヘッダは削除されてしまうことがあるが、
この情報、つまり、使用されたSA、およびその適用順序は、
これに続くIPsec処理またはファイアウォール処理で必要となることがあることに注意すること。
ここで、セキュリティゲートウェイの場合に、パケットが転送されて、 IPsecが有効となっているインタフェースを経由して出ていく場合、 追加のIPsec処理が適用される場合があることに注意すること。
AHおよびESPトンネルでの、内側および外側IPヘッダ、拡張ヘッダ、 そしてオプションは、 5.1章の表に従って扱われる必要がある。
この章では、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処理がどのように実行されなければならないかb>(MUST)ということについて示す。 ここでは、認証されたICMP PMTUメッセージと認証されていないICMP PMTUメッセージの両方について取り上げている。 ただし、前に説明したように、 認証されていないICMPメッセージはローカルのポリシーに基づいて破棄してもよい(MAY)。
システム(ホストまたはゲートウェイ)がカプセル化ヘッダ(ESPトンネルまたはAHトンネル)を追加する場合、 システムは、オリジナルのパケットからカプセル化ヘッダへDFビットをコピーするオプション(およびICMP PMTUメッセージを処理するオプション)をサポートしなければならない(MUST)。 これは、システムのDFビットの処理(セット、クリア、 カプセル化されたヘッダからのコピー)をインタフェース毎に設定できなければならない(MUST)ことを意味している(その根拠については付録 Bを参照のこと)。
この章では、経路MTU探索メッセージに対するIPsecの処理について説明する。 ここで、ICMP PMTUは、以下のICMPメッセージを参照するために使用される。
IPv4(RFC 792)：
IPv6(RFC 1885)：
ICMP PMTUメッセージ(IPv4またはIPv6)で返される情報の量は限定されており、 PMTU情報をさらに伝播させるためにどのセレクタが利用できるのかということに影響がでてくる。 (この問題については付録 Bを参照のこと。)
ICMP PMTUからPMTUを計算する際には、 IPsecヘッダ(AHトランスポート、ESPトランスポート、AH/ESPトランスポート、 ESPトンネル、AHトンネル)の追加を考慮しなければならない(MUST)。 (実装の問題に関する議論については付録 Bを参照のこと。)
注釈：一部の状況では、IPsecヘッダの追加によって、 受け入れられないほど小さい、 有効なPMTU(ホストまたはアプリケーションによって見られる)を結果として引き起こすことがあり得る。 この問題を避けるために、実装では、 縮小されたPMTUを報告しない閾値を下げて設定しても良い。 このような場合、実装はIPsecを適用し、 その結果生じたパケットをPMTUに応じて分割する。 これは結果的に、利用可能な帯域幅をより効果的に使用することとなる。
ホストでは、ICMP PMTU処理が実行できるグラニュラリティは、 その実装の状況によって異なる。 ホストに関して言えば、PMTU問題に関連して関心を示す状況として、 以下の3つが存在する (この話題に関しての詳細については、 付録 Bを参照のこと)。
(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)。
IPsecを実装し、 PMTU情報をメンテナンスするすべてのシステム(ホストまたはゲートウェイ)では、 セキュリティアソシエーション(トランスポートまたはトンネル)に関連するPMTUは「エージング」されなければならず、 PMTUをタイムリに更新し、特にPMTUが必要なものより小さいかどうかを発見するための仕組みを持たなければならない(MUST)。 与えれられたPMTUは、 パケットがセキュリティアソシエーションの送信側終端からセキュリティアソシエーションのもう片方の終端に到達し、 そして現在のPMTUが大きすぎる場合にはICMPエラーメッセージを伝播し返せるのに十分な長さの時間その場に留まらなければならない。 ここで、入れ子にされたトンネルが存在する場合には、 ICMPメッセージをカプセル化器または生成元ホストに戻すために複数のパケットと往復移動時間が必要となる場合があることに注意すること。
システムは、経路MTU探索についての文書(RFC 1191の6.3章)に記述されているアプローチを使用する必要がある(SHOULD)。 この文書では、 PMTUを最初の中継点のデータリンクMTUに定期的にリセットし、 必要であれば通常のPMTU探索処理にPMTUを更新させることが提案されている。 このリセット期間は設定できる必要がある(SHOULD)。
IPsecを実装するすべてのシステムが監査機能を実装するわけではない。 監査のグラニュラリティについては、 ほとんどの部分がローカルの問題である。 しかしながら、 いくつかの監査対象イベントがAHおよびESPの仕様書内に存在しており、 その中では、これらの各イベントに対して、 監査ログに含む必要のある(SHOULD)最低限の情報セットが定義されている。 また、 これらの個々のイベントに対するこれ以外の情報を監査ログに含んでもよい(MAY)。 そして、 この仕様で明示的に取り上げられていないその他のイベントも監査ログのエントリに含んでもよい(MAY)。 監査対象イベントの検知に応じて、 受信側が偽証転送者にすべてのメッセージを転送してしまうような要求条件は存在しない。 これはこのようなアクションを介したサービス妨害を引き起こす可能性があるためである。
様々なセンシティビティレベルを持つ情報が単一のネットワーク上を流れる可能性がある。 情報ラベル(例えば、非機密扱い(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)。
暗号ペイロードと認証ヘッダはいずれも、 マルチレベルセキュアネットワークを提供するために、 適切なセキュリティアソシエーションポリシーと組み合わせることができる。
この場合、それぞれのSA(またはSAバンドル)は、一般的に、 センシティビティ情報の1つのインスタンスのみに対して使用される。 例えば、「PROPRIETARY - Internet Engineering」は、 「PROPRIETARY -- Finance」とは異なるSA(またはSAバンドル)と関連付けられなければならない。
MLSの実装(ホストとルータの両方)では、 センシティビティ情報またはセンシティビティ情報の範囲を、 インタフェースまたはプレフィックス付きで設定されているIPアドレスと結び付けてもよい(MAY) (後者は論理インタフェース、 あるいはインタフェースエイリアスと呼ばれることがある)。 このような特性がある場合、 実装はパケットに結び付けられたセンシティビティ情報を、 パケットが到着あるいは出発する予定のインタフェースまたはアドレス/プレフィックスに結び付けられたセンシティビティ情報と比較する必要がある(SHOULD)。 このチェックでは、センシティビティが一致するか、 パケットのセンシティビティがインタフェースまたはアドレス/プレフィックスの範囲に収まるかのどちらであるかを確認する。
このチェックは、 入力と出力の両方の処理において行われる必要がある(SHOULD)。
4.4章では、 2つのセキュリティアソシエーションデータベース(セキュリティポリシーデータベース(SPD)とセキュリティアソシエーションデータベース(SAD))および関連するポリシーセレクタとSA属性について説明した。 MLS ネットワーキングでは、これに追加して以下のセレクタ/属性を導入する。
- センシティビティ情報
8.1章で説明したように、 トラフィックがその重要性とセンシティビティに適した保護レベルを得るように、 センシティビティ情報は適切なアルゴリズムと鍵強度の選択を可能にする。 センシティビティ情報の正確な構文は実装によって定義される。
MLS実装では、入力パケットがIPsec処理を通過した後、 データグラムを上位層プロトコルに配送するか転送するかする前に、 最初に8.2章で定義されたインタフェースまたはアドレス/プレフィックスでパケットのセンシティビティ (そのパケットに対して使用されるSA(またはSAバンドル)によって定義される)をチェックする必要がある(SHOULD)。
MLSシステムは、IPsecで保護されたパケットで受信したデータと、 処理に使用したSAまたはSA群内のセンシティビティ情報の間のバインディングを保持しなければならない(MUST)。 これにより、 データグラムをアプリケーションや転送エンジンに配送する際に、 適切なポリシーを決定することができる。 このバインディングのメンテナンス手段は実装特有である。
IPsecのMLS実装では、 5.1.1章で詳細に説明した通常ステップに追加して、 さらに2つのチェックを行わなければならない(MUST)。 出力セキュリティアソシエーションを発見するためにSPDまたはSADを調べる際に、 MLS実装は、 適切な出力SAまたはSAバンドルを選択するためにデータのセンシティビティを使用しなければならない(MUST)。 2つ目のチェックはパケットを宛先に転送する前に行われるものであり、 8.2章で説明したセンシティビティの一貫性チェックである。
MLSセキュリティゲートウェイは前に説明した入力と出力の処理ルールに従うとともに、 MLS環境におけるパケットの中間保護に特有の追加処理を実行しなければならない(MUST)。
セキュリティゲートウェイは、 そのゲートウェイによって転送されるパケットを生成するMLSシステム用のSAを生成することによって出力プロキシとして動作してもよい(MAY)。 このMLSシステムは転送されるべきパケットに対して明示的にラベル付けをするか、 生成するネットワーク全体がそれに関連するセンシティビティ特性を持つ場合がある。 セキュリティゲートウェイは、転送するトラフィックを保護するために、 AHかESPのどちらか、または両方に対する適切なSAを作成し、 使用しなければならない(MUST)。
同様に、このようなゲートウェイは、 明示的パケットラベリングを使用するか、 宛先ネットワークのセンシティビティ特性に依存しながら、 入力AHまたはESPパケットを適切に受領、処理し、 転送する必要がある(SHOULD)。
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))が存在する。
IPsecを実装するすべてのIPv4システムは、 セキュリティアーキテクチャ文書のすべての要求条件に準拠しなければならない(MUST)。 すべてのIPv6システムは、 セキュリティアーキテクチャ文書のすべての要求条件に準拠しなければならない(MUST)。
この文書の焦点はセキュリティであり、 従ってセキュリティに関する考慮事項はこの仕様書の全体に行き渡っている。
このアーキテクチャ文書は、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の各氏の努力に感謝する。
この章では、 この文書で使用されているいくつかの主要な用語について定義する。 この技術に関連する追加の定義と背景情報は別の文書、 例えば[VK83、 HA94] から提供されている。 この用語集には、 一般的なセキュリティサービスやセキュリティの仕組みについての用語とIPsec特有の用語が含まれる。
システム(ホストまたはゲートウェイ)がカプセル化ヘッダ(例えば、 ESPトンネル)を追加する場合、オリジナルパケット内のDFビットは、 カプセル化ヘッダにコピーすべき/しなければならないのだろうか？
パケットを分割することは、一部の状況では正しいように思える。 例えば、ごく小さいMTUを持つネットワーク、 例えばパケット無線網やモバイルノードへ携帯電話で中継する場合は、 残りの経路用にごく小さなPMTUを伝搬し返すよりもむしろ、 パケットを分割することが適切である場合がある。 その他、分割を要求するPMTU制約に関するフィードバックを後のルータから受けるために、 DFビットをセットすることが適切な場合がある。 これら2つの状況は、 ある特定のネットワーク「リンク」上でパケットを分割するかどうかをシステムに決定できるようにすることを主張していることになる。 すなわち、実装にDFビットをコピーすること (およびICMP PMTUメッセージを処理すること) を可能とすることを求めるが、 それはインタフェース毎に選択させるというオプションとすることである。 つまり、管理者が、ルータでのDFビットの処理 (セット、クリア、カプセル化ヘッダからのコピー) を各インタフェース毎に設定できるようにする必要がある。
注釈：IPsecのbump-in-the-stack実装が、送信元/宛先ポートに基づいて、 異なるIPsecアルゴリズムを適用しようとする場合、 経路MTU調整を適用することは困難となるだろう。
必要であれば、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と同様である。
以下の分析では次の通りに仮定する。
上記の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処理の前に再構成される場合に動作)。
実装における問題点については、注釈において示される。
ネットワーク層において、
IPsecモジュールはパケットからの次のセレクタ --
送信元アドレス、宛先アドレス、次プロトコル、
さらにトランスポート層ヘッダが存在する場合には、
送信元ポートと宛先ポートへアクセスすることになる。
IPsecが名前にアクセスすることは仮定されない。
利用可能なセレクタ情報は、
適切なセキュリティポリシーエントリとセキュリティアソシエーションを理解するのに十分であると仮定する。
注釈：IPsec モジュールはパケットから次のセレクタ -- 送信元アドレス、宛先アドレス、次プロトコル、さらに、 トランスポート層ヘッダが存在する場合には、 送信元ポートおよび宛先ポートにアクセスすることになる。 ユーザIDへはアクセスされない (ホストのみがユーザID情報へアクセスする)。 一部のBump-in-the-stack実装と異なり、 例えば動的に更新されるDNSエントリと連動して動的に割り当てられるIPアドレスを利用する環境が含まれるような場合、 セキュリティゲートウェイはシステム名を提供するためにDNS内の送信元アドレスの検索できる場合がある。 また、ESPヘッダが存在する場合、またはそれが、 分割されたメッセージの最初の断片でない場合には、 トランスポート層の情報へのアクセスは行われない。 利用可能なセレクタ情報は、 適切なセキュリティポリシーエントリとセキュリティアソシエーションを理解するのに十分であると仮定される。
**********************************************************************
以前に説明したように、 「ICMP PMTU」とは経路MTU探索に使用されるICMPメッセージを指す。
B.3.1およびB.3.3 (B.3.2は除く) の図における凡例は以下の通り。
==== = セキュリティアソシエーション(AH または ESP、トランスポートまたはトンネル) ---- = コネクティビティ(または、ラベル付けされる場合、管理境界) .... = 以下の ICMP メッセージ(これ以降 ICMP PMTU と呼ぶことにする)
IPv4：
IPv6 (RFC 1885)：
Hx = ホスト x Rx = ルータ x SGx = セキュリティゲートウェイ x X* = IPsec をサポートする X
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は、
後者のアプローチのみがすべての状況において実行できるため、 セキュリティゲートウェイはこのサポートをオプションで提供しなければならない(MUST)。 ただし、オリジナルパケットからのより多くの情報がICMPメッセージに含まれる場合には、 ICMP/PMTUメッセージを伝播するホストをただちに決定し、 PMTUの保存/更新場所の決定に必要な5つのフィールド(送信元アドレス、 宛先アドレス、送信元ポート、宛先ポート、 トランスポートプロトコル)をシステムに提供するための十分な情報が存在する可能性がある。 このような状況では、セキュリティゲートウェイは、 経路の下のほうからICMP PMTUを受信した場合には、 ただちにICMP PMTUメッセージを生成しなければならない(MUST)。
注釈：次プロトコルフィールドはICMPメッセージに含まれないことがあり、 そしてESP暗号化によって、 セレクタフィールドが暗号化されて隠されてしまう可能性がある。
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からのバックポインタを持つ必要があるだろう。
ホストでは、PMTU ICMP処理が実行可能なグラニュラリティは、 実装状況に応じて異なる。 ホストを見ると、PMTU問題に関して以下の3つの興味ある状況が存在する。
(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ヘッダの最大限の削減となることから、 結果はサブオプティマルとなる可能性がある。
PMTUの計算(B.3.2章)の実装、 および個々の「通信アソシエーション」のグラニュラリティでのPMTUのサポート(B.3.3章)はローカルでの問題である。
しかし、ホストにおけるソケットベースのIPsecの実装は、 ソケット単位で情報をメンテナンスする必要がある(SHOULD)。
bump-in-the-stackシステムは、 このシステムによって追加されるすべてのIPsecヘッダオーバーヘッドに対して調整した後、 ICMP PMTUをホストのIP実装に渡さなければならない(MUST)。
オーバーヘッドの決定は、 返されたICMP PMTUメッセージに存在するSPIやその他のすべてのセレクタ情報の解析によって決定する必要がある(SHOULD)。
更新されたPMTUをトランスポート層へ届けるホストの仕組みは、 RFC 1191(経路MTU探索)で定義されたものから変更されていない。
この話題については、6.1.2.4章に含まれている。
この付録では、 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", ¤t);
result = ChkReplayWindow(current);
printf("%-3s", result ? "OK" : "BAD");
printf(" bits:%08lx last:%lu¥n", bitmap, lastSeq);
}
return 0;
}
以下の表は、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, 1973年 5月. |
| [Bra97] |
Bradner, S., 「RFCにおいて要請の程度を示すために用いるキーワード(Key words for use in RFCs to Indicate Requirement Level)」, BCP 14, RFC 2119, 1997年3月. |
| [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., 1985年12月. |
| [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., 1987年7月31日. |
| [HA94] |
Haller, N., and R. Atkinson, 「インターネット認証について(On Internet Authentication)」, RFC 1704, 1994年10月. |
| [HC98] |
Harkins, D., and D. Carrel, 「IKE：インターネット鍵交換(The Internet Key Exchange (IKE))」, RFC 2409, 1998年11月. |
| [HM97] |
Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, 1997年7月. |
| [ISO] | ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 1992年11月29日. |
| [IB93] |
John Ioannidis and Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of USENIX Security Symposium, Santa Clara, CA, 1993年10月. |
| [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認証ヘッダ(IP Authentication Header)」, RFC 2402, 1998年11月. |
| [KA98b] |
Kent, S., and R. Atkinson, 「IP暗号ペイロード(ESP)(IP Encapsulating Security Payload (ESP))」, RFC 2406, 1998年11月. |
| [Ken91] |
Kent, S., 「米国国防総省 インターネットプロトコルについてのセキュリティオプション(US DoD Security Options for the Internet Protocol)」, RFC 1108, 1991年11月. |
| [MSST97] |
Maughan, D., Schertler, M., Schneider, M., and J. Turner, 「ISAKMP (Internet SAと鍵管理プロトコル)(Internet Security Association and Key Management Protocol (ISAKMP))」, RFC 2408, 1998年11月. |
| [Orm97] |
Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, 1998年11月. |
| [Pip98] |
Piper, D., 「IPsecにおけるISAKMPの解釈(The Internet IP Security Domain of Interpretation for ISAKMP)」, RFC 2407, 1998年11月. |
| [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, 1989年 5月 15日, published in NIST Publication NIST-IR-90-4250, 1990年2月. |
| [SMPT98] |
Shacham, A., Monsour, R., Pereira, R., and M. Thomas,
"IP Payload Compression Protocol (IPComp)", RFC 2393, 1998年8月. |
| [TDG97] |
Thayer, R., Doraswamy, N., and R. Glenn, 「IPSEC文書ロードマップ(IP Security Document Roadmap)」, RFC 2411, 1998年11月. |
| [VK83] | V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, 1983年6月. |
本書において示された見解と仕様は著者によるものであり、 必ずしもその雇い主によるものではない。 著者とその雇い主は、正確／不正確な実装、 およびこの設計の利用から生じるどのような問題への責任も拒否する。
Stephen Kent
BBN Corporation
70 Fawcett Street
Cambridge, MA 02140
USA
電話： +1 (617) 873-3988
EMail： kent＠bbn.com
Randall Atkinson
@Home Network
425 Broadway
Redwood City, CA 94063
USA
電話： +1 (415) 569-5000
EMail： rja＠corp.home.net
翻訳者のアドレス
株式会社 NTTデータ
開発本部
馬場 達也
EMail: babatt＠nttdata.co.jp
Copyright (C) The Internet Society (1998). All Rights Reserved.
本文書とその翻訳は、複製および他に提供することができる。 また、この文書に論評や説明を加えたり、その実装を補助するものは、 上記の著作権表示およびこの節を付加していれば、 全体あるいは一部であっても一切の制約を課されることなく作成、複製、 発表、配布できる。 ただし、この文書自体に対して、 著作権表示やインターネットソサエティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはならない。 インターネット標準化過程で定義されている著作権のための手続きに従って、 インターネット標準を開発するために必要な場合や、 RFCを英語以外の言語に翻訳する必要がある場合はそのかぎりでない。
上記の制限は永続的なものであり、 インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはない。
本文書とここに含まれた情報は「無保証」で提供され、 インターネットソサエティおよびIETFはすべての保証を明示的にも暗黙的にもおこなわない。 その中には、この情報がいかなる権利も侵害していないという保証や、 商用利用および特定目的における適合性への保証が含まれる。