ネットワーク・ワーキンググループ 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 章を参照のこと) において定義される。 a. セキュリティ・プロトコル -- 認証ヘッダ (Authentication Header (AH) ) および IP 暗号ペイロード (Encapsulating Security Payload (ESP) ) b. セキュリティ・アソシエーション -- セキュリティ・アソシエーシ ョンとは何か、その動作、管理方法、関連する処理について c. 鍵管理 -- マニュアルおよび自動鍵管理 (Internet Key Exchange (IKE) ) d. 認証および暗号化のためのアルゴリズム この文書では、インターネットにおける総合的なセキュリティ・アーキテ クチャを扱うのではなく、暗号とプロトコルのセキュリティの仕組みの組 み合わせによって提供される、IP 層におけるセキュリティのみを扱う。 この文書において、しなければならない (MUST)、してはならない (MUST NOT)、要求される (REQUIRED)、することになる (SHALL)、することはな い (SHALL NOT)、する必要がある (SHOULD)、しないほうがよい (SHOULD NOT)、推奨される (RECOMMENDED)、してもよい (MAY)、選択できる (OPTIONAL) のキーワードが使用された場合は、RFC 2119 [Bra97] におけ る定義に沿って解釈されるものとする。 1.2 対象とする読者 この文書が対象とする読者には、IP セキュリティ技術を実装しようとす る者、およびこのシステムの一般的な背景の習得に関心のある者が含まれ る。 特に、この技術を将来利用しようとするユーザ (エンドユーザまたはシス テム管理者) が対象として含まれる。 知識の背景と語彙のギャップを埋めるために、用語集を付録として付けて おく。 この文書では、読者がインターネットプロトコルおよび関連するネットワ ーク技術、そして一般的なセキュリティ用語とコンセプトに精通している ことを前提とする。 1.3 関連文書 上で説明したように、IPsec の構成要素の一部、およびその相互関係につ いて詳細に定義する文書が他に存在する。 それには、以下に関する RFC が含まれる。 a. 「IP セキュリティ文書体系 (IP Security Document Roadmap) 」 [ TDG97] -- このシステムで使用される暗号化および認証アルゴリズ ムを定義する仕様書のためのガイドラインを提供する文書。 b. セキュリティ・プロトコル -- 認証ヘッダ (AH) [KA98a] および IP 暗号ペイロード (ESP) [KA98b] プロトコルを定義する RFC。 c. 認証および暗号化のためのアルゴリズム -- それぞれのアルゴリズ ムについての個々の RFC。 d. 自動鍵管理 -- 「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]。 * IP 認証ヘッダ (AH) [KA98a] はコネクションレス・インテグ リティ、データ生成元認証、そしてオプションでリプレイ防止 サービスを提供する。 * 暗号ペイロード (ESP) プロトコル [KA98b] は機密性 (暗号 化)、限定されたトラヒックフロー機密性を提供する。 さらに、コネクションレス・インテグリティ、データ生成元認 証、リプレイ防止サービスも提供する場合がある。 (ESP が呼び出される場合は、常にこれらのセキュリティ・サ ービスの 1 つ、またはセットが適用されなければならな い)。 * AH および ESP は、暗号鍵の配送およびこれらのセキュリテ ィ・プロトコルに関連するトラヒックフローの管理に基づいた アクセス制御の伝達手段である。 これらのプロトコルは、IPv4 および IPv6 において希望するセキュリテ ィ・サービスのセットを提供するために、単独でも組み合わせて適用して も良い。 各プロトコルは、2 つの使用モード (トランスポートモードとトンネルモ ード) をサポートする。 トランスポートモードでは、プロトコルは主に上位層プロトコルの保護を 提供し、トンネルモードでは、トンネル IP パケットに対してプロトコル が適用される。 2 つのモードの違いについては、4 章にて説明する。 IPsec はユーザ (またはシステム管理者) に対し、セキュリティ・サービ スが提供されるグラニュラリティの制御を許可する。 例えば、2 つのセキュリティ・ゲートウェイ間のすべてのトラヒックを運 ぶ 1 つの暗号化トンネルを作成することもできるし、これらのゲートウ ェイを越えて通信するホスト間の各 TCP コネクションのために別の暗号 化トンネルを作成することもできる。 IPsec の管理は、以下の事項を指定するための機能を持たなければならな い。 * 使用するセキュリティ・サービスとその組み合わせ * 与えられたセキュリティ保護が適用されるグラニュラリティ * 暗号ベースのセキュリティを実現するために使用されるアルゴリズ ム これらのセキュリティ・サービスは共有秘密値 (暗号鍵) を使用するた め、IPsec はこれらの鍵を配備する独立した仕組みのセットに依存する (鍵は認証/インテグリティおよび暗号化サービスに使用される)。 この文書では、鍵のマニュアル配送および自動配送の両方のサポートを要 求する。 この文書では、自動鍵管理にある特定の公開鍵ベースのアプローチ (IKE -- [MSST97、Orm97、HC98]) を指定するが、その他の自動鍵配送技術を利 用してもよい (MAY)。 例えば、ケルベロスのような KDC ベースのシステムや SKIP のような公 開鍵システムを利用することができる。 3.3 IPsec の実装場所 ホスト上で、または (セキュリティ・ゲートウェイを構築するために) ル ータやファイアウォールと連携して IPsec を実装するには、いくつかの 方法がある。 一般的な例を以下に示す。 a. ネイティブ IP 実装と IPsec の統合。 これには、IP 送信元コードへのアクセスが必要であるが、ホストお よびセキュリティ・ゲートウェイの両方に適用可能である。 b. 「bump-in-the-stack」 (BITS) 実装。IPsec をネイティブ IP とロ ーカル・ネットワークの間の、既存の IP プロトコルスタック実装 の下に実装するもの。 この場合、IP スタックに対する送信元コードアクセスは要求されな いため、この実装アプローチは既存システムでの利用に適したもの となっている。 このアプローチは通常ホスト上で使用される。 c. 外部暗号化プロセッサの使用は、軍事および一部の商用システムで 使用されるネットワークセキュリティシステムの共通設計思想であ る。 これはしばしば、「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 が使用される場合は、トンネルされたパケットのみが保護され、外側 ヘッダは保護されない。 以上まとめると、 a. ホストはトランスポートモードとトンネルモードの両方をサポート しなければならない (MUST)。 b. セキュリティ・ゲートウェイはトンネルモードのサポートのみが要 求される。 トランスポートモードをサポートする場合は、それはセキュリテ ィ・ゲートウェイがホストとして動作する場合のみに使用される必 要がある (例えばネットワーク管理など)。 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 つの方法 (トランスポート隣接と 反復トンネリング) でバンドルされる。 * トランスポート隣接とは、トンネリングを行わずに、同じ IP デー タグラムに 1 つ以上のセキュリティ・プロトコルを適用することを 指す。 このアプローチによる AH と ESP の結合は、1 つのレベルの組み合 わせのみを考慮している。 処理は (最終の) 宛先の 1 つの IPsec インスタンスで実行される ため、さらなる入れ子によって利点が生まれることはない (各プロ トコルが十分に強力なアルゴリズムを使用すると想定)。 Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | | -----Security Association 1 (ESP transport) ------ | | | -------Security Association 2 (AH transport) --------- * 反復トンネリングとは、IP トンネリングを通った複数層のセキュリ ティ・プロトコルを適用することを指す。 このアプローチは、それぞれのトンネルが経路上の異なる IPsec サ イトで開始または終了できるため、複数レベルの入れ子を許可して いる。 途中のセキュリティ・ゲートウェイでは、それが適切な SPD エント リを通して指定可能であれば、ISAKMP トラヒックに対して特別な処 理を行う必要はない (4.5 章のケース 3 を参照のこと)。 反復トンネリングには、3 つの基本ケースがあるが、2 と 3 のケー スのみをサポートすればよい。 1. SA の両方の終点が同じ -- Host 1 が両方とも同じものを指 定、すなわち、AH の内側に AH を、または ESP の内側に ESP を指定する可能性はあまりないが、内側および外側のトンネル が、それぞれ AH あるいは ESP のいずれかとなり得る。 Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | | -------Security Association 1 (tunnel) ----------- | | | ---------Security Association 2 (tunnel) ------------- 2. SA の片方の終点が同じ -- 内側および外側のトンネルが、AH または ESP のいずれかとなり得る。 Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | ----Security Association 1 (tunnel) ---- | | | ---------Security Association 2 (tunnel) ------------ 3. どちらの終点も同じでない -- 内側および外側のトンネルが AH または ESP のいずれかとなり得る。 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 章にて説明する。 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 アドレスに対してのみサポートされてい るが、ワイルドカードはすべてのセレクタで表現できることに注意するこ と)。 a. パケット自身にある値を使用 -- この場合、ポリシー・エントリの セレクタが、このセレクタに対して許可される値の範囲またはワイ ルドカードを持っていたとしても、その SA の使用は、セレクタに 対するこのパケットの値を持つパケットのみに限定される。 b. ポリシー・エントリに関連する値を使用 -- これが単独の値となる 場合には、 (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 のどちら かである必要があることに注意すること。 * 宛先 IP アドレス (IPv4 または IPv6) :これは、 1 つの IP アド レス (ユニキャスト、エニーキャスト、ブロードキャスト (IPv4 の み)、またはマルチキャストグループ)、アドレスの範囲 (上限値 と下限値 (これも含む) )、アドレス+マスク、またはワイルドカ ード・アドレスとなる。 最後の 3 つは、同じ SA を共有する複数の宛先システムをサポート するために使用される (例えばセキュリティ・ゲートウェイの背後 にあるシステム)。 ここで、このセレクタは、SA を一意に識別するために使用される < 宛先 IP アドレス, IPsec プロトコル, SPI> の組の中の「宛先 IP アドレス」フィールドとは概念的に異なることに注意すること。 トンネルされたパケットがトンネルの終端に到達した時に、その SPI、宛先アドレス、プロトコルが SAD 内のこのパケットに対する SA を検索するために使用される。 この宛先アドレスはカプセル化 IP ヘッダからもってくる。 一度パケットがトンネル SA に従って処理され、トンネルを抜け出 せば、そのセレクタは入力用 SPD 内で 「検索」 される。 入力用 SPD は宛先アドレスというセレクタを持つ。 この IP 宛先アドレスは内側 (カプセル化された) IP ヘッダに存 在するものである。 トランスポートモードで送られたパケットの場合には、IP ヘッダは 1 つだけであり、このあいまいさは存在しない。 [すべての実装において要求される (REQUIRED) ] * 送信元 IP アドレス (群) (IPv4 または IPv6) :これは、 1 つの IP アドレス (ユニキャスト、エニーキャスト、ブロードキャスト (IPv4 のみ)、またはマルチキャストグループ)、アドレスの範囲 (上限値と下限値 (これも含む) )、アドレス+マスク、またはワ イルドカード・アドレスとなる。 最後の 3 つは、同じ SA を共有する複数の送信元システムをサポー トするために使用される (例えばセキュリティ・ゲートウェイの背 後にあるシステム、またはマルチホーム・ホストのシステム)。 [すべての実装において要求される (REQUIRED) ] * 名前:2 つのケースがある (これらの名前の形式は IPsec DOI でサ ポートされることに注意すること)。 1. ユーザ ID a. 正式なユーザ名の文字列 (DNS)、例えば mozart@foo.bar.com b. X.500 識別名、例えば、C = US, SP = MA, O = GTE Internetworking, CN = Stephen T. Kent. 2. システム名 (ホスト、セキュリティ・ゲートウェイ等) a. 正式な DNS 名、例えば、foo.bar.com b. X.500 識別名 c. X.500 一般名 注釈:このセレクタのとる値の 1 つに「不透明 (OPAQUE) 」があ る。 [以下の場合に要求される (REQUIRED)。ここで、アドレス以外の名 前の形式のサポートは、マニュアル鍵付き SA では要求されないこ とに注意すること。 o ユーザ ID + ネイティブホスト実装 + 1 ユーザのみを持つホストとして動作する BITW および BITS 実装 + セキュリティ・ゲートウェイでの入力処理用の実装 o システム名 -- すべての実装] * データセンシティビティレベル: (IPSO/CIPSO ラベル) [ 8 章に従って情報フローセキュリティを提供するすべてのシステ ムにおいて要求され (REQUIRED)、その他のすべてのシステムにおい て選択できる (OPTIONAL)。] * トランスポート層プロトコル:IPv4の「プロトコル (Protocol) 」ま たは IPv6の「次ヘッダ (Next Header) 」フィールドから得られる。 これは個々のプロトコル番号である。 例えば経路制御ヘッダ (Routing Header)、AH、ESP、分割ヘッダ (Fragmentation Header)、宛先オプション (Destination Options)、中継点オプション (Hop-by-hop options) などの IP 拡 張ヘッダが存在するために、これらのパケットフィールドにはトラ ンスポートプロトコルが含まれない場合がある。 ここで、トランスポートプロトコルは ESP ヘッダを持つパケットを 受信する場合に利用できないことがあるため、「不透明 (OPAQUE) 」をサポートする必要がある (SHOULD) ことに注意する こと。 [すべての実装において要求される (REQUIRED) ] 注釈:トランスポートプロトコルの位置を探すために、システムは パケットヘッダをつないで「プロトコル」または「次ヘッダ」フィ ールドをチェックする。 これは、トランスポートとして認識されるいずれかのものに到達す るまで、または拡張ヘッダのリスト上にないヘッダに到達するま で、またはトランスポートプロトコルに不透明 (opaque) を与える ESP ヘッダに到達するまで行われる。 * 送信元および宛先 (例えば TCP/UDP) ポート:これらは個々の UDP または TCP ポート値、あるいはワイルドカードポートの場合があ る。 (次プロトコル (Next Protocol) フィールド、および送信元ま たは宛先ポート・フィールド (送信元または宛先アドレス・フィー ルドと組み合わせて) を SA セレクタとして使用することは、しば しば「セッション別鍵管理」と呼ばれる。) ここで、送信元および宛先ポートは、ESP ヘッダを持つパケットを 受信する場合は利用できないことがあるため、「不透明 (OPAQUE) 」をサポートする必要がある (SHOULD) ことに注意する こと。 パケットの「次ヘッダ (Next Header) 」値、SPD、そして SPD およ び SAD に対して導き出されたポートセレクタ値 (derived Port Selecter value) との間の関係を以下の表にまとめる。 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 を結果的 に作り出すことになるだろう。 ベンダーは、顧客が容易に明確かつ簡潔なポリシーの仕様の設定ができる ようにするため、このようなインタフェースをサポートする可能性があ る。 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 の検索に使用されるパケットフィールドは以下 の通り。 * 外側ヘッダの宛先 IP アドレス:IPv4 または IPv6 宛先アドレス。 [すべての実装に要求される (REQUIRED) ] * IPsec プロトコル:AH または ESP、このデータベース内の SA 検索 の際のインデックスとして使用される。 この SA のトラヒックに適用される IPsec プロトコルを指定。 [すべての実装に要求される (REQUIRED) ] * SPI:同じ宛先で終了し、同じ IPsec プロトコルを使用している、 異なる SA を区別するために使用される 32 ビットの値。 [すべての実装に要求される (REQUIRED) ] 4.4.2 章で定義した各セレクタ用に、SAD 内の SA エントリは、SA が生 成された時点でネゴシエートされた値を含まなければならない (MUST)。 送信側では、これらの値は、与えられた SA が出力パケットでの使用に適 切であるかどうかを判断するために使用される。 これは、使用できる既存の SA が存在するかどうかをチェックする処理の 一部である。 受信側では、これらの値は、入力パケットのセレクタ値が SA の値 (間接 的に、一致するポリシーの値) と一致することをチェックするために使用 される。 これは、受信側で SA がこのパケットに対して適切であったことを確認す る処理の一部である。 (ICMP メッセージのルールについては 6 章を参照 のこと。) これらのフィールドは、4.4.2 章「セレクタ」で定義するように、特定の 値、範囲、ワイルドカード、または「不透明 (OPAQUE) 」の形式を持つこ とができる。 ここで、ESP SA では、暗号化アルゴリズムまたは認証アルゴリズムが 「NULL」となり得ることに注意すること。 ただし、両方とも「NULL」となってはならない (MUST)。 IPsec 処理で使用される SAD フィールドは以下の通り。 * シーケンス番号カウンタ:AH または ESP ヘッダ内のシーケンス番 号フィールドの生成に使用する 32 ビットの値。 [すべての実装に要求されるが、出力トラヒックのみに使用される (REQUIRED)。] * シーケンス・カウンタ・オーバーフロー:シーケンス番号カウンタ のオーバーフローによる監査対象イベントの生成、および SA 上の 追加パケットの転送の回避が必要かどうかを示すフラグ。 [すべての実装に要求されるが、出力トラヒックのみに使用される (REQUIRED)。] * リプレイ防止ウィンドウ:入力 AH または ESP パケットがリプレイ されているかどうかを検査するために使用される 32 ビットのカウ ンタとビットマップ (またはそれ相当のもの) [すべての実装に要求されるが、入力トラヒックのみに使用される (REQUIRED)。注釈:受信側によってリプレイ防止が無効にされてい る場合、例えばマニュアル鍵付 SA の場合、リプレイ防止ウィンド ウは使用されない。] * AH 認証アルゴリズム、鍵など。 [AH の実装に要求される (REQUIRED) ] * ESP 暗号化アルゴリズム、鍵、IV モード、IV など。 [ESP の実装に要求される (REQUIRED) ] * ESP 認証アルゴリズム、鍵など。 認証サービスが使用されない場合、このフィールドは NULL とな る。 [ESP の実装に要求される (REQUIRED) ] * このセキュリティ・アソシエーションの有効期間:SA を新しい SA (および新しい SPI ) と置き換えるか、または破棄しなければなら ない時間間隔、および置き換えと破棄のどちらのアクションを行う べきかの指示。 これは時間またはバイト・カウント、あるいは両方同時に使用して 表現してもよく、この場合、最初に期限切れとなる有効期間が優先 される。 準拠する実装は、両方の形式の有効期間をサポートしなければなら ず (MUST)、さらに両方の形式の同時使用をサポートしなければなら ない。 時間の形式を使用し、IKE で SA の確立に X.509 証明書を使用する 場合、SA の有効期間は、証明書の有効期間、および IKE 交換で SA 用に使用される CRL の NextIssueDate の制約を受けなければなら ない。 開始者と応答者の両方が、この形式による SA の有効期間の制約の 責任を持つ。 [すべての実装に要求される (REQUIRED) ] 注釈:SA の期限が切れた場合の鍵のリフレッシュ処理に関する詳細 はローカルの問題である。 ただし、1 つの合理的なアプローチは以下の通りである。 a. バイト・カウントを使用する場合には、実装は IPsec アルゴ リズムが適用されるパケットのバイト数をカウントする必要が ある (SHOULD)。 ESP では、これは暗号化アルゴリズム (NULL 暗号化を含む) であり、AH では、これは認証アルゴリズムである。 これにはパディングに使用されるバイト数なども含まれる。 ここで、実装は、SA の各終点のカウンタが、例えば、パケッ トロスや、SA の各終点での実装が同じ方法で処理を行わない ために起こる同期から抜け出せるようにしておく必要があるこ とに注意すること (SHOULD)。 b. 2 つの種類の有効期間を持つ必要がある (SHOULD) -- 実装 に、SA の置き換えのセットアップなどのアクションの開始を 警告するソフト有効期間と、現在の SA が終了した時のハード 有効期間。 c. SA 有効期間中にパケットの全体が届かなかった場合は、その パケットを破棄する必要がある (SHOULD)。 * IPsec プロトコルモード:トンネル、トランスポート、またはワイ ルドカード。 AH または ESP のどのモードを、この SA 上のトラヒックに適用す るかを示す。 ここで、このフィールドが SA の送信側終端で「ワイルドカード」 である場合、アプリケーションが IPsec の実装に対してモードを指 定しなければならないことに注意すること。 このワイルドカードの使用によって、トンネルモードのトラヒック とトランスポートモードのトラヒックに同じ SA を使用すること が、パケット単位で、例えば異なるソケット毎に許可されることに なる。 受信側は、パケットの IPsec ヘッダを適切に処理するためにモード を知る必要はない。 [文章中で明示的に定義しない限り、以下の通りに要求される (REQUIRED) : - ホストでの実装では、すべてのモードをサポートしなければ ならない - ゲートウェイでの実装では、トンネルモードをサポートしな ければならない] 注釈:入力 SA のプロトコルモードにおいてワイルドカードを使用 すると、受信側 (ホストのみ) に複雑な状況を与える場合がある。 この種の SA 上のパケットはトンネルまたはトランスポートモード のどちらかで配送されるため、入力パケットのセキュリティは、パ ケットを配送するために使用されるモードに一部依存する。 その結果として、アプリケーションが所定のパケットの SA のモー ドを考慮するのであれば、モードの情報を獲得する仕組みがアプリ ケーションに必要となる。 * 経路 MTU:観測されるすべての経路 MTU およびエージング変数。 6.1.2.4 章を参照のこと。 [すべての実装に要求されるが、出力トラヒックのみに使用される (REQUIRED) ] 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 domein of interpretation [Pip98] 配下の IKE [MSST97, Orm97, HC98] である。 他の自動 SA 管理プロトコルを使用してもよい (MAY)。 自動 SA/鍵管理プロトコルが使用される場合、このプロトコルの出力は、 例えば 1 つの ESP SA 用の複数の鍵の生成に使用されることがある。 これは以下の理由により起こり得る。 * 暗号化アルゴリズムが複数の鍵を使用する (例えば、トリプル DES など) * 認証アルゴリズムが複数の鍵を使用する * 暗号化アルゴリズムと認証アルゴリズムの両方が使用される 鍵管理システムは、それぞれの鍵用に独立したビット・ストリングを提供 してもよいし、すべてのビットが抽出された 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」 で使用 されているものをもとにモデル化されている。 * 外側 IP ヘッダの送信元アドレスと宛先アドレスは、トンネルの 「終端」 (カプセル化する側とカプセル化を解く側) を識別する。 内側 IP ヘッダの送信元アドレスと宛先アドレスは、それぞれ、 (このトンネルから見た)、データグラムのオリジナルの送信者と 受信者をそれぞれ識別する (カプセル化された送信元 IP アドレス に関する詳細は、5.1.2.1 章の表の後にある注を参照のこと)。 * 内側 IP ヘッダは、後で説明する TTL のデクリメントを行う場合以 外には変更されず、トンネルの出口に配送されるまではそのままの 状態であり続ける。 * IP オプションまたは内側ヘッダ内の拡張ヘッダは、カプセル化デー タグラムをトンネルで配送する間に変更されない。 * 必要であれば、IP 認証ヘッダなどのプロトコルヘッダが、外側 IP ヘッダと内側 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 6. 内側ヘッダが 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) : * タイプ = 3 (終点到達不能) * コード = 4 (分割必要かつ DF セット) * ICMP ヘッダの第 2 ワードの下位 16 ビット内の次中継 点 MTU (RFC 792 で「未使用」のラベル付き)、上位 16 ビットはゼロがセット IPv6 (RFC 1885) : * タイプ = 2 (パケット過大) * コード = 0 (分割必要) * ICMP6 メッセージの 32 ビットの MTU フィールド内の次 中継点 MTU 6.1.2.1 PMTU の伝播 ICMP PMTU メッセージ (IPv4 または IPv6) で返される情報の量は限定さ れており、PMTU 情報をさらに伝播させるためにどのセレクタが利用でき るのかということに影響がでてくる。 (この問題については付録 B を参 照のこと。) * IPsec ヘッダのうちの 64 ビット分を含む PMTU メッセージ -- ICMP PMTU メッセージが IPsec ヘッダのうちの 64 ビット分 (IPv4 での最小値) のみを含む場合、セキュリティ・ゲートウェイは SPI/SA 毎に以下のオプションをサポートしなければならない (MUST)。 a. 生成元ホストが確定できれば (または、可能性のある生成元が 管理可能な数にまで絞り込めれば)、生成元である可能性のあ るすべてのホストに PM 情報を送る。 b. 生成元ホストが確定できなければ、PMTU を SA とともに保存 し、当該セキュリティ・アソシエーションにおいて生成元ホス トからの次のパケットが到着するまで待つ。 パケットが PMTU より大きい場合はパケットを破棄し、更新さ れた PMTU で新しいパケットとして ICMP PMTU メッセージを 構成し、その問題に関する ICMP メッセージを生成元ホストに 送る。 続いて到着するメッセージのために PMTU 情報を保持し続ける (6.1.2.4 章の「PMTU エージング」 を参照のこと)。 * IPsec ヘッダのうちの 64 ビットより多くの部分を持つ PMTU メッ セージ -- ICMP メッセージがより多くのオリジナルのパケットの情 報を含む場合には、ICMP/PMTU メッセージを伝播するホストをただ ちに決定し、PMTU の保存または更新場所を決定するために必要な 5 つのフィールド (送信元アドレス、宛先アドレス、送信元ポート、 宛先ポート、トランスポート・プロトコル) をシステムに提供する のに十分な不透明でない情報が存在する可能性がある。 このような状況では、セキュリティ・ゲートウェイは、さらに経路 を下ったところから ICMP PMTU を受信した際にただちに ICMP PMTU メッセージを生成しなければならない (MUST)。 * PMTU のトランスポート層への配送 -- 更新された PMTU をトランス ポート層に伝えるホストの仕組みは、RFC 1191 (経路 MTU 探索) に定義されている通りであり、変更されない。 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 を 参照のこと)。 a. ネイティブ IP 実装への IPsec の統合 b. bump-in-the-stack 実装、この場合 IPsec は既存の TCP/IP プロト コル・スタックの実装の「下部」、ネイティブ IP とローカル・ネ ットワークドライバの間に実装される。 c. 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 -- 用語集 この章では、この文書で使用されているいくつかの主要な用語について定 義する。 この技術に関連する追加の定義と背景情報は別の文書、例えば [VK83、 HA94] から提供されている。 この用語集には、一般的なセキュリティ・サービスやセキュリティの仕組 みについての用語と IPsec 特有の用語が含まれる。 アクセス制御 アクセス制御とは、無許可の資源利用を防ぐセキュリティ・サービ スであり、無許可の資源利用の回避が含まれる。 IPsec では、アクセスを制御する資源には、以下のものが含まれ る。 o ホストでは、計算サイクルまたはデータ o セキュリティ・ゲートウェイでは、ゲートウェイの背後にある ネットワーク、またはネットワークの帯域 リプレイ防止 [後の「インテグリティ」を参照のこと] 認証 この用語は、名目上独立した 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-トンネル --> IP2 - AH - IP1 - トランスポート - データ * ESP-トンネル --> IP2 - ESP ヘッダ - IP1 - トランスポート - デ ータ - ESP トレイラー ********************************************************************* 全体的に、上記にて説明した分割/再構成のアプローチは、調査済みのす べてのケースに作用する。 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 を実装できる場所は (上記の表に示すように) いくつか存在 する。 a. ネイティブ IP に組み込まれた IPsec 実装を持つホスト。 実装者はスタックのソースにアクセスする。 b. bump-in-the-stack 実装を持つホスト。 IPsec は IP とローカル・ネットワーク ドライバの間に実装 される。 スタックのソースへのアクセスは利用できないが、IPsec コー ドをシステムに取り込むことが可能な、うまく定義されたイン タフェースが存在する。 c. スタックに組み込まれた 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 処理の前に再構成される場合に 動作)。 実装における問題点については、注釈において示される。 a. ホスト (IP スタックに統合) o AH-トランスポート --> (IP1 - AH - トランスポート - デー タ) + IPv4 -- works + IPv6 -- works o AH-トンネル --> (IP2 - AH - IP1 - トランスポート - デー タ) + IPv4 -- works + IPv6 -- works o ESP-トランスポート --> (IP1 - ESP ヘッダ - トランスポー ト - データ - ESP トレイラー) + IPv4 -- works + IPv6 -- works o ESP-トンネル --> (IP2 - ESP ヘッダ - IP1 - トランスポー ト - データ - ESP トレイラー) + IPv4 -- works + IPv6 -- works b. ホスト (bump-in-the-stack) -- IPsec を IP 層とネットワークド ライバの間に挿入。 この場合、IPsec モジュールは、分割と再構成のために以下のいず れか 1 つを実行しなければならない。 o 分割/再構成作業をそれ自身で行い、ネットワーク層との間で やり取りされるパケットを直接送受信する。 AH または ESP のトランスポートモードでは、これは問題な い。 AH または ESP のトンネルモードにおいて、トンネルの終端が 最終の宛先の場合には、これは問題ない。 しかし、AH または ESP のトンネルモードで、トンネルの終端 が最終の宛先ではなく、送信元ホストがマルチホームである場 合、IPsec モジュールは、パケットを適切なネットワーク・イ ンタフェースに導くために必要な情報 (LAN インタフェースと 次中継ゲートウェイ) を得ることができないため、このアプロ ーチはサブ・オプティマル・ルーティングとなり得る。 これは、インタフェースと次中継ゲートウェイが最終の宛先と トンネルの終端に対して同一であれば問題ではない。 しかしこれらが異なると、IPsec はトンネルの終端に対する LAN インタフェースと次中継ゲートウェイを知る必要が出てく る。 (注釈:トンネルの終I端 (セキュリティ・ゲートウェイ) は、最終の宛先への通常の経路上に存在する可能性が極めて高 い。しかし、宛先への経路は複数存在することもあり得る。例 えば、ファイアウォールを 2 つ持つ組織にホストが存在する 場合である。さらに、使用される経路には、普段あまり選ばれ ないファイアウォールが存在することがあり得る)。 または、 o 超過 IP ヘッダが最終的にプリペンドとなり、IPsec モジュー ルが IPsec 処理された断片をチェックし、それをそのまま放 置しなければならない場合に、IPsec 処理されたパケットを IP 層に返す。 または、 o IP 層が適切な IP ヘッダを再生成するように、IP 層にパケッ トの内容を渡す。 ネットワーク層において、IPsec モジュールはパケットからの次の セレクタ -- 送信元アドレス、宛先アドレス、次プロトコル、さら にトランスポート層ヘッダが存在する場合には、送信元ポートと宛 先ポートへアクセスすることになる。 IPsec が名前にアクセスすることは仮定されない。 利用可能なセレクタ情報は、適切なセキュリティ・ポリシー・エン トリとセキュリティ・アソシエーションを理解するのに十分である と仮定する。 o AH-トランスポート --> (IP1 - AH - トランスポート - デー タ) + IPv4 -- works + IPv6 -- works o AH-トンネル --> (IP2 - AH - IP1 - トランスポート - デー タ) + IPv4 -- works + IPv6 -- works o ESP-トランスポート --> (IP1 - ESP ヘッダ - トランスポー ト - データ - ESP トレイラー) + IPv4 -- works + IPv6 -- works o ESP-トンネル --> (IP2 - ESP ヘッダ - IP1 - トランスポー ト - データ - ESP トレイラー) + IPv4 -- works + IPv6 -- works c. セキュリティ・ゲートウェイ -- IPsec を IP スタックに統合 注釈:IPsec モジュールはパケットから次のセレクタ -- 送信元ア ドレス、宛先アドレス、次プロトコル、さらに、トランスポート層 ヘッダが存在する場合には、送信元ポートおよび宛先ポートにアク セスすることになる。 ユーザ ID へはアクセスされない (ホストのみがユーザ ID 情報へ アクセスする)。 一部の Bump-in-the-stack 実装と異なり、例えば動的に更新される DNS エントリと連動して動的に割り当てられる IP アドレスを利用 する環境が含まれるような場合、セキュリティ・ゲートウェイはシ ステム名を提供するために DNS 内の送信元アドレスの検索できる場 合がある。 また、ESP ヘッダが存在する場合、またはそれが、分割されたメッ セージの最初の断片でない場合には、トランスポート層の情報への アクセスは行われない。 利用可能なセレクタ情報は、適切なセキュリティ・ポリシー・エン トリとセキュリティ・アソシエーションを理解するのに十分である と仮定される。 o AH-トンネル --> (IP2 - AH - IP1 - トランスポート - デー タ) + IPv4 -- works + IPv6 -- works o ESP-トンネル --> (IP2 - ESP ヘッダ - IP1 - トランスポー ト - データ - ESP トレイラー) + IPv4 -- works + IPv6 -- works ********************************************************************** B.3 経路 MTU 探索 以前に説明したように、「ICMP PMTU」とは経路 MTU 探索に使用される ICMP メッセージを指す。 B.3.1 および B.3.3 (B.3.2 は除く) の図における凡例は以下の通り。 ==== = セキュリティ・アソシエーション (AH または ESP、トランスポートまたはトンネル) ---- = コネクティビティ (または、ラベル付けされる場合、管理境界) .... = 以下の ICMP メッセージ (これ以降 ICMP PMTU と呼ぶことにする) IPv4: * タイプ = 3 (終点到達不能) * コード = 4 (分割必要、DF セット) * ICMP ヘッダ (RFC 792での未使用のラベル付き) の第 2 ワードの下位 16 ビットにおける次中継点 MTU、上位 16 ビットはゼロにセット IPv6 (RFC 1885) : * タイプ = 2 (パケット過大) * コード = 0 (分割必要、DF セット) * ICMP6 の 32 ビット MTU フィールドにおける次中継点 MTU 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は、 a. 可能性のあるすべての生成元ホストに対し、PMTU 情報を送信するこ とができる。 これは、ホストのリストがワイルドカードの場合、または多くの/ほ とんどのホストが SG1 に対して送信してしない場合はうまく動作し ない。 しかし、SPI /宛先/その他が 1 つまたは少数のホストにマッピング されるのであればうまく動作する可能性がある。 b. 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 つの興味ある状況が存在す る。 a. ネイティブ IP 実装への IPsec の統合。 b. 「bump-in-the-stack」 (BITS) 実装。 IPsec がネイティブ IP とローカル・ネットワークの間の、既存の IP プロトコル・スタック実装の下に実装される。 c. 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 #include 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; } 付録 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: baba@rd.nttdata.co.jp 著作権表示全文 Copyright (C) The Internet Society (1998). All Rights Reserved. 本文書とその翻訳は、複製および他に提供することができる。 また、この文書に論評や説明を加えたり、その実装を補助するものは、上 記の著作権表示およびこの節を付加していれば、全体あるいは一部であっ ても一切の制約を課されることなく作成、複製、発表、配布できる。 ただし、この文書自体に対して、著作権表示やインターネット・ソサエテ ィもしくは他のインターネット関連団体への参照を取り除くなどの変更を 加えてはならない。 インターネット標準化過程で定義されている著作権のための手続きに従っ て、インターネット標準を開発するために必要な場合や、RFC を英語以外 の言語に翻訳する必要がある場合はそのかぎりでない。 上記の制限は永続的なものであり、インターネット・ソサエティもしくは その継承者や譲渡者によって取り消されることはない。 本文書とここに含まれた情報は「無保証」で提供され、インターネット・ ソサエティおよび IETF はすべての保証を明示的にも暗黙的にもおこなわ ない。 その中には、この情報がいかなる権利も侵害していないという保証や、商 用利用および特定目的における適合性への保証が含まれる。