[要約] 要約：RFC 3884は、動的ルーティングにおけるIPsecトランスポートモードの使用に関するガイドラインを提供しています。 目的：このRFCの目的は、IPsecトランスポートモードを使用して動的ルーティングを実装する際のベストプラクティスを定義し、セキュリティとパフォーマンスの向上を促進することです。
Network Working Group J. Touch
Request for Comments: 3884 ISI
Category: Informational L. Eggert
NEC
Y. Wang
ISI
September 2004
Use of IPsec Transport Mode for Dynamic Routing
動的ルーティングのためのIPSEC輸送モードの使用
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
IESG Note
IESGノート
This document is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this document for any purpose, and in particular notes that it has not had IETF review for such things as security, congestion control or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment.
このドキュメントは、インターネット標準のレベルの候補ではありません。IETFは、あらゆる目的のためにこのドキュメントのフィットネスに関する知識を放棄します。特に、セキュリティ、混雑制御、展開プロトコルとの不適切な相互作用などのIETFレビューはなかったことに注意してください。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。
Abstract
概要
IPsec can secure the links of a multihop network to protect communication between trusted components, e.g., for a secure virtual network (VN), overlay, or virtual private network (VPN). Virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside VNs because IP routing depends on references to interfaces and next-hop IP addresses. The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts. An alternative to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec transport mode, which we call IIPtran. IPIP encapsulation occurs as a separate initial step, as the result of a forwarding lookup of the VN packet. IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database (SAD) match on the tunnel header. IIPtran supports dynamic routing inside the VN without changes to the current IPsec architecture. IIPtran demonstrates how to configure any compliant IPsec implementation to avoid the aforementioned conflicts. IIPtran is also compared to several alternative mechanisms for VN routing and their respective impact on IPsec, routing, policy enforcement, and interactions with the Internet Key Exchange (IKE).
IPSECは、マルチホップネットワークのリンクを保護して、たとえば安全な仮想ネットワーク（VN）、オーバーレイ、または仮想プライベートネットワーク（VPN）の信頼できるコンポーネント間の通信を保護できます。IPSECトンネルモードによって確立された仮想リンクは、IPルーティングはインターフェイスと次元IPアドレスへの参照に依存するため、VNS内のルーティングと転送と競合する可能性があります。IPSECトンネルモードの仕様はこの問題について曖昧であるため、競合を避けるために、準拠した実装でさえ信頼できません。トンネルモードに代わるものは、IIPTRANと呼ばれるIPSECトランスポートモードとともに非IPIP IPIPカプセル化を使用します。IPIPカプセル化は、VNパケットの転送検索の結果として、別の初期ステップとして発生します。IPSECトランスポートモードは、トンネルヘッダーのセキュリティアソシエーションデータベース（SAD）マッチを介して決定されたSAを使用して、結果の（トンネル付き）IPパケットを処理します。IIPTRANは、現在のIPSECアーキテクチャを変更せずにVN内の動的ルーティングをサポートしています。IIPTRANは、前述の競合を回避するために、準拠したIPSEC実装を構成する方法を示します。IIPTRANは、VNルーティングのいくつかの代替メカニズムと、IPSEC、ルーティング、ポリシー執行、およびインターネットキーエクスチェンジ（IKE）との相互作用へのそれぞれの影響とも比較されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Document History . . . . . . . . . . . . . . . . . . . . 3
2. Problem Description. . . . . . . . . . . . . . . . . . . . . . 4
2.1. IPsec Overview . . . . . . . . . . . . . . . . . . . . . 5
2.2. Forwarding Example . . . . . . . . . . . . . . . . . . . 6
2.3. Problem 1: Forwarding Issues . . . . . . . . . . . . . . 7
2.4. Problem 2: Source Address Selection . . . . . . . . . . 8
3. IIPtran: IPIP Tunnel Devices + IPsec Transport Mode . . . . . 9
3.1. IIPtran Details . . . . . . . . . . . . . . . . . . . . 10
3.2. Solving Problem 1: Forwarding Issues . . . . . . . . . . 11
3.3. Solving Problem 2: Source Address Selection . . . . . . 12
4. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Other Proposed Solutions . . . . . . . . . . . . . . . . 12
4.1.1. Alternative 1: IPsec with Interface SAs. . . . . 13
4.1.2. Alternative 2: IPsec with Initial
Forwarding Lookup. . . . . . . . . . . . . . . . 13
4.1.3. Alternative 3: IPsec with Integrated
Forwarding . . . . . . . . . . . . . . . . . . . 14
4.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. VN Routing Support and Complexity . . . . . . . 14
4.2.2. Impact on the IPsec Architecture . . . . . . . . 15
4.2.3. Policy Enforcement and Selectors . . . . . . . . 16
4.2.4. IKE Impact . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Summary and Recommendations . . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 21
A. Encapsulation/Decapsulation Issues . . . . . . . . . . . . . . 22
A.1. Encapsulation Issues . . . . . . . . . . . . . . . . . . 22
A.2. Decapsulation Issues . . . . . . . . . . . . . . . . . . 23
A.3. Appendix Summary . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
The IP security architecture (IPsec) consists of two modes, transport mode and tunnel mode [1]. Transport mode is allowed between two end hosts only; tunnel mode is required when at least one of the endpoints is a "security gateway" (intermediate system that implements IPsec functionality, e.g., a router.)
IPセキュリティアーキテクチャ（IPSEC）は、輸送モードとトンネルモードの2つのモードで構成されています[1]。輸送モードは、2つのエンドホスト間でのみ許可されます。エンドポイントの少なくとも1つが「セキュリティゲートウェイ」（IPSEC機能を実装する中間システム、例えばルーターなど）の場合、トンネルモードが必要です。
IPsec can be used to secure the links of a virtual network (VN), creating a secure VN. In a secure VN, trusted routers inside the network dynamically forward packets in the clear (internally), and exchange the packets on secure tunnels, where paths may traverse multiple tunnels. Contrast this to the conventional 'virtual private network' (VPN), which often assumes that paths tend to traverse one secure tunnel to resources in a secure core. A general secure VN allows this secure core to be distributed, composed of trusted or privately-managed resources anywhere in the network.
IPSECを使用して、仮想ネットワーク（VN）のリンクを保護し、安全なVNを作成できます。安全なVNでは、ネットワーク内の信頼できるルーターがクリア（内部的に）で動的にパケットを動的に転送し、パスが複数のトンネルを通過する可能性のある安全なトンネルでパケットを交換します。これを従来の「仮想プライベートネットワーク」（VPN）とは対照的です。これは、パスが安全なコアのリソースに1つの安全なトンネルを横断する傾向があることを想定していることがよくあります。一般的な安全なVNを使用すると、ネットワーク内のどこでも信頼できるまたは個人管理されたリソースで構成される、この安全なコアを分散させることができます。
This document addresses the use of IPsec to secure the links of a multihop, distributed VN. It describes how virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside the VN, due to the IP routing dependence on references to interfaces and next-hop IP addresses.
このドキュメントでは、IPSECの使用に対処し、マルチホップの分散VNのリンクを保護します。IPSECトンネルモードによって確立された仮想リンクが、インターフェイスと次元IPアドレスへの参照にIPルーティング依存性により、VN内のルーティングと転送と競合する方法を説明します。
This document proposes a solution called IIPtran that separates the step of IP tunnel encapsulation from IPsec processing. The solution combines a subset of the current IPsec architecture with other Internet standards to arrive at an interoperable equivalent that is both simpler and has a modular specification.
このドキュメントでは、IPトンネルのカプセル化のステップをIPSEC処理から分離するIiptranと呼ばれるソリューションを提案します。このソリューションは、現在のIPSECアーキテクチャのサブセットを他のインターネット標準と組み合わせて、よりシンプルでモジュラー仕様を備えた相互運用可能な同等物に到達します。
Later sections of this document compare IIPtran to other proposals for dynamic routing inside VPNs, focusing on the impact the different proposals have on the overall IPsec architecture, routing protocols, security policy enforcement, and the Internet Key Exchange (IKE) [9][10]. An appendix addresses IP tunnel processing issues in IPsec related to IPIP encapsulation and decapsulation.
このドキュメントの後のセクションは、IIPTRANをVPN内の動的ルーティングの他の提案と比較し、さまざまな提案がIPSECアーキテクチャ全体、ルーティングプロトコル、セキュリティポリシーの執行、およびインターネットキーエクスチェンジ（IKE）[9] [10に与える影響に焦点を当てています。]。付録は、IPIPのカプセル化と脱カプセル化に関連するIPSECのIPトンネル処理の問題に対応しています。
This document assumes familiarity with other Internet standards [1][2], notably with terminology and numerous acronyms therein.
このドキュメントは、他のインターネット標準[1] [2]に精通していることを想定しています。
This document was first issued as an Internet Draft on March 10, 2000, entitled "Use of IPSEC Transport Mode for Virtual Networks," and was first presented in the IPsec WG at the 47th IETF in Adelaide in March 2000. It was subsequently revised and presented to the PPVPN WG at the 51st IETF in London in August 2001, to the IPsec WG at the 52nd IETF in Salt Lake City in December 2001, and to both the IPsec and PPVPN WGs at the 53rd IETF in Minneapolis in March 2002. Version 04 of this draft was submitted for publication as an Informational RFC based on suggestions by the IPsec WG in June 2002, and was under IESG review from then until version 07 was approved for publication in June 2004. During that time, it was substantively revised according to feedback from the IESG regarding interactions with the IPsec specification (RFC 2401 [1]) and other protocols, with regard to security and compatibility issues.
このドキュメントは、2000年3月10日に「仮想ネットワークのIPSEC輸送モードの使用」というタイトルのインターネットドラフトとして最初に発行され、2000年3月にアデレードの第47 IETFでIPSEC WGで最初に発表されました。その後、改訂され、改訂され、2001年8月にロンドンの第51 IETFでPPVPN WGに、2001年12月にソルトレイクシティの第52 IETFでのIPSEC WGに、2002年3月のミネアポリスの53番目のIETFでのIPSECとPPVPN WGSの両方に提示されました。このドラフトの04は、2002年6月のIPSEC WGによる提案に基づいて情報RFCとして公開され、2004年6月にバージョン07が承認されるまでIESGレビューを受けていました。その間、それは実質的に修正されました。セキュリティと互換性の問題に関するIPSEC仕様（RFC 2401 [1]）およびその他のプロトコルとの相互作用に関するIESGからのフィードバック。
Virtual networks connect subsets of resources of an underlying base network, and present the result as a virtual network layer to upper-layer protocols. Similar to a real network, virtual networks consist of virtual hosts (packet sources and sinks) and virtual routers (packet transits), both of which can have a number of network interfaces, and links, which connect multiple network interfaces together. Virtual links (also called tunnels, especially when point-to-point) are one-hop links in the VN topology, but are either direct links or paths (sequences of connected links) in the underlying base network.
仮想ネットワークは、基礎となるベースネットワークのリソースのサブセットを接続し、結果を上層層プロトコルの仮想ネットワークレイヤーとして提示します。実際のネットワークと同様に、仮想ネットワークは、仮想ホスト（パケットソースとシンク）と仮想ルーター（パケットトランジット）で構成されます。仮想リンク（特にポイントツーポイントの場合、トンネルとも呼ばれます）は、VNトポロジのワンホップリンクですが、基礎となるベースネットワークの直接リンクまたはパス（接続リンクのシーケンス）のいずれかです。
Base network hosts and routers can be part of multiple virtual networks at the same time, and their role in the base network does not need to coincide with their role in a virtual network (i.e., base network hosts may act as VN routers or hosts, as may base network routers).
ベースネットワークホストとルーターは同時に複数の仮想ネットワークの一部になります。ベースネットワークでの役割は、仮想ネットワークでの役割と一致する必要はありません（つまり、ベースネットワークホストはVNルーターまたはホストとして機能する場合があります。ベースネットワークルーターと同様）。
It is important to note that this definition of a VN is more general than some other definitions, where the VN participation of end systems is limited. Some proposals only allow end systems to be part of a single VN, or even only allow them to be part of the VN and not the base network, substituting the VN for the Internet. The definition above explicitly allows hosts and routers to participate in multiple, parallel VNs, and allows layered VNs (VN inside VN).
VNのこの定義は、最終システムのVN参加が制限されている他の定義よりも一般的であることに注意することが重要です。一部の提案では、最終システムのみが単一のVNの一部であるか、またはインターネットのVNを代用するベースネットワークではなく、VNの一部であることさえ許可することさえできます。上記の定義により、ホストとルーターが複数の並列VNSに参加することを明示的に許可し、層状のVN（VN内のVN）を許可します。
It can be useful for a VN to secure its virtual links [3][4], resulting in a VPN. This is not equivalent to end-to-end security, but can be useful when end hosts do not support secure communication themselves. It can provide an additional level of hop-by-hop network security to secure routing in the VPN and isolate the traffic of different VPNs.
VNが仮想リンク[3] [4]を保護するために役立ち、VPNになります。これはエンドツーエンドのセキュリティと同等ではありませんが、エンドホストが安全な通信自体をサポートしない場合に役立ちます。VPNのルーティングを保護し、異なるVPNのトラフィックを隔離するための追加レベルのホップバイホップネットワークセキュリティを提供できます。
The topology of an IPsec VPN commonly consists of IPsec tunnel mode virtual links, as required by the IPsec architecture when the communicating peers are gateway pairs, or a host and a gateway [1]. However, this current required use of IPsec tunnel mode can be incompatible with dynamic routing [3].
IPSEC VPNのトポロジーは、一般に、通信ピアがゲートウェイペア、またはホストとゲートウェイである場合にIPSECアーキテクチャで要求されるIPSECトンネルモード仮想リンクで構成されています[1]。ただし、この電流が必要なIPSECトンネルモードの使用は、動的ルーティングと互換性がない場合があります[3]。
The next section provides a short overview on IPsec transport and tunnel mode processing, as far as it is relevant for the understanding of the problem scenarios that follow. The following sections discuss routing problems in detail, based on a common example.
次のセクションでは、以下の問題シナリオの理解に関連する限り、IPSECトランスポートおよびトンネルモードの処理に関する簡単な概要を説明します。次のセクションでは、一般的な例に基づいて、ルーティングの問題について詳しく説明します。
There are two modes of IPsec, transport mode and tunnel mode [1]. Transport mode secures portions of the existing IP header and the payload data of the packet, and inserts an IPsec header between the IP header and the payload; tunnel mode adds an additional IP header before performing similar operations. This section gives a short overview of the relevant processing steps for both modes.
IPSECには2つのモード、トランスポートモード、トンネルモードがあります[1]。トランスポートモードは、既存のIPヘッダーとパケットのペイロードデータの部分を確保し、IPヘッダーとペイロードの間にIPSECヘッダーを挿入します。トンネルモードは、同様の操作を実行する前に追加のIPヘッダーを追加します。このセクションでは、両方のモードの関連する処理手順の簡単な概要を説明します。
In transport mode, IPsec inserts a security protocol header into outgoing IP packets between the original IP header and the packet payload (Figure 1) [5][6][11][12]. The contents of the IPsec header are based on the result of a "security association" (SA) lookup that uses the contents of the original packet header (Figure 1, arrow) as well as its payload (especially transport layer headers) to locate an SA in the security association database (SAD).
トランスポートモードでは、IPSECは、元のIPヘッダーとパケットペイロード（図1）[5] [6] [11] [12]の間の発信IPパケットにセキュリティプロトコルヘッダーを挿入します。IPSECヘッダーの内容は、元のパケットヘッダーの内容（図1、矢印）とそのペイロード（特に輸送層ヘッダー）を使用する「セキュリティ協会」（SA）ルックアップの結果に基づいています。セキュリティ協会データベースのSA（SAD）。
Original Outbound Packet Outbound Packet (IPsec Transport Mode)
+-----------+---------+ +-----------+==============+---------+
| IP Header | Payload | | IP Header | IPsec Header | Payload |
+-----------+---------+ +-----------+==============+---------+
| ^
| |
+-------------+
SA Lookup
Figure 1: Outbound Packet Construction under IPsec Transport Mode
図1：IPSECトランスポートモードでのアウトバウンドパケット構造
When receiving packets secured with IPsec transport mode, a similar SA lookup occurs based on the IP and IPsec headers, followed by a verification step after IPsec processing that checks the contents of the packet and its payload against the respective SA. The verification step is similar to firewall processing.
IPSECトランスポートモードで固定されたパケットを受信すると、IPおよびIPSECヘッダーに基づいて同様のSAルックアップが発生し、その後、パケットの内容とそれぞれのSAに対するペイロードをチェックするIPSEC処理後の検証ステップが続きます。検証ステップは、ファイアウォール処理に似ています。
When using tunnel mode, IPsec prepends an IPsec header and an additional IP header to the outgoing IP packet (Figure 2). In essence, the original packet becomes the payload of another IP packet, which IPsec then secures. This has been described [1] as "a tunnel mode SA is essentially a [transport mode] SA applied to an IP tunnel." However, there are significant differences between the two, as described in the remainder of this section.
トンネルモードを使用する場合、IPSECはIPSECヘッダーと発信IPパケットへの追加のIPヘッダーをプレイエンドします（図2）。本質的に、元のパケットは別のIPパケットのペイロードになり、IPSECが保護します。これは[1]が「トンネルモードSAは、本質的にIPトンネルに適用される[輸送モード] SAです」と説明されています。ただし、このセクションの残りの部分で説明されているように、2つの間には大きな違いがあります。
In IPsec tunnel mode, the IP header of the original outbound packet together with its payload (especially transport headers) determines the IPsec SA, as for transport mode. However, a tunnel mode SA also contains encapsulation information, including the source and destination IP addresses for the outer tunnel IP header, which is also based on the original outbound packet header and its payload (Figure 2, arrows).
IPSECトンネルモードでは、元のアウトバウンドパケットのIPヘッダーとそのペイロード（特にトランスポートヘッダー）が、輸送モードのようにIPSEC SAを決定します。ただし、トンネルモードSAには、元のアウトバウンドパケットヘッダーとそのペイロードにも基づいた外側トンネルIPヘッダーのソースおよび宛先IPアドレスを含むカプセル化情報も含まれています（図2、矢印）。
Outbound Packet (IPsec Tunnel Mode)
+==================+==============+-----------------+---------+
| Tunnel IP Header | IPsec Header | Orig. IP Header | Payload |
+==================+==============+-----------------+---------+
^ ^ | |
| | | |
| +--------------+ |
| SA Lookup |
| |
+---------------------------------+
IP Encapsulation
Figure 2: Outbound Packet Construction under IPsec Tunnel Mode
図2：IPSECトンネルモードでのアウトバウンドパケット構造
When receiving packets secured with tunnel mode IPsec, an SA lookup occurs based on the contents of the IPsec header and the outer IP header. Next, the packet is decrypted or authenticated based on its IPsec header and the SA, followed by a verification step that checks the contents of the original packet and its payload (especially the inner IP header and transport headers) against the respective SA.
トンネルモードIPSECで固定されたパケットを受信すると、IPSECヘッダーと外部IPヘッダーの内容に基づいてSAルックアップが発生します。次に、パケットは、IPSECヘッダーとSAに基づいて復号化または認証され、その後、それぞれのSAに対して元のパケットとそのペイロード（特に内部IPヘッダーとトランスポートヘッダー）をチェックする検証ステップが続きます。
Consider a VPN topology with virtual links established by IPsec tunnel mode SAs, as would be required for compliance with [1]. Such hop-by-hop security can be useful, for example, to secure VN routing, and when legacy end systems do not support end-to-end IPsec themselves.
[1]のコンプライアンスに必要なIPSECトンネルモードSASによって確立された仮想リンクを使用したVPNトポロジを考えてみましょう。このようなホップバイホップセキュリティは、たとえばVNルーティングを保護するために、およびレガシーエンドシステムがエンドツーエンドのIPSEC自体をサポートしない場合に役立ちます。
Virtual routers in a VN need to forward packets the same way regular Internet routers do: based on the destination IP address and the forwarding table. These two determine the next hop IP address the packet should be forwarded to (additional header fields and inner headers can be used, e.g., in policy routing.)
VNの仮想ルーターは、通常のインターネットルーターが行うのと同じように、宛先IPアドレスと転送テーブルに基づいて、パケットを転送する必要があります。これら2つは、パケットを転送する必要がある次のホップIPアドレスを決定します（追加のヘッダーフィールドと内側ヘッダーを使用できます。たとえば、ポリシールーティングで使用できます。
In Figure 3, traffic arrives at gateway A on virtual link 1, having come from any of the virtual hosts upstream of that virtual link. There are two outgoing virtual links for this incoming traffic: out link 3 going to the VPN next-hop gateway B, and out link 4 going to the VPN next-hop gateway C.
図3では、その仮想リンクの上流の仮想ホストのいずれかから来た仮想リンク1のゲートウェイAにトラフィックが到着します。この着信トラフィックには2つの発信仮想リンクがあります。AUTリンク3 VPN Next-Hop Gateway Bに移動し、VPN Next-Hop Gateway Cに行くリンク4
For this example, assume the incoming traffic is from a single VPN source X, going to a single VPN destination Y. Ellipses (...) represent multiple virtual links in Figure 3.
この例では、着信トラフィックが単一のVPNソースXからであると仮定し、単一のVPN宛先Y. ellipses（...）が図3の複数の仮想リンクを表しています。
B ---...---
/ \
/ 3 \
/ \
X ---...--- A D ---...--- Y
1 2 \ /
\ 4 /
\ /
C ---...---
Figure 3: Topology of a Virtual Network
図3：仮想ネットワークのトポロジ
Two problems arise; one is forwarding of VN traffic over IPsec tunnel mode links, the other is source address selection on VN end systems.
2つの問題が発生します。1つは、IPSECトンネルモードリンクを介したVNトラフィックの転送、もう1つはVN Endシステムのソースアドレス選択です。
Assume a packet from source X to destination Y arrives on link 2 at gateway A. Gateway A now needs to both forward and encrypt the packet to make progress to the next hop gateway inside the VPN.
ソースXから宛先YへのパケットがGateway Aのリンク2に到着すると仮定します。GatewayAは、VPN内の次のホップゲートウェイに進行するために、パケットを転送および暗号化する必要があります。
Dynamically routed gateways forward packets based on a forwarding table managed by a routing daemon that exchanges connectivity information with directly connected peers by communicating on its local interfaces. Entries in the forwarding table map destination IP addresses to the IP address of a next-hop gateway and an associated outbound interface.
ローカルインターフェイスで通信することにより、接続されたピアと接続された情報を交換するルーティングデーモンによって管理された転送テーブルに基づいて、動的にルーティングされたゲートウェイフォワードパケット。転送テーブルのエントリは、次のホップゲートウェイのIPアドレスと関連するアウトバウンドインターフェイスのIPアドレスへの宛先IPアドレスをマップします。
The problem is that an intermediate router needs to pick a next hop gateway for a transit packet based on its destination IP address and the contents of the forwarding table. However, the IPsec architecture does not define if and how tunnel mode SAs are represented in the forwarding table.
問題は、中間ルーターが、宛先IPアドレスと転送テーブルの内容に基づいて、トランジットパケットの次のホップゲートウェイを選択する必要があることです。ただし、IPSECアーキテクチャは、転送テーブルでトンネルモードSASが表現されるかどうか、どのように表現されるかを定義していません。
The problem occurs when A tries to decide how to forward the packet X->Y. In a regular IP network, this decision depends on a forwarding lookup on destination address Y, which indicates the IP address of the next-hop gateway and an associated outbound interface. In the case of a VN, forwarding lookups occur on virtual destination addresses. For the forwarding lookup on such a virtual destination address to succeed, routes through virtual interfaces (tunnels) must exist in the forwarding table.
問題は、パケットx-> yを転送する方法を決定しようとすると発生します。通常のIPネットワークでは、この決定は宛先アドレスYの転送検索に依存します。これは、next-HopゲートウェイのIPアドレスと関連するアウトバウンドインターフェイスを示します。VNの場合、仮想宛先アドレスで転送ルックアップが発生します。このような仮想宛先アドレスの転送検索を成功させるには、仮想インターフェイス（トンネル）を通るルートを転送テーブルに存在する必要があります。
There are two common implementation scenarios for tunnel mode SAs: One is based on firewall-like packet matching operations where tunnel mode SAs are not virtual interfaces, another is tunnel-based, and treats a tunnel mode SA as a virtual interface. The current IPsec architecture does not mandate one or the other.
トンネルモードSASには2つの一般的な実装シナリオがあります。1つは、トンネルモードSASが仮想インターフェイスではなく、トンネルベースであり、トンネルモードSAを仮想インターフェイスとして扱うファイアウォールのようなパケットマッチング操作に基づいています。現在のIPSECアーキテクチャは、どちらかを義務付けていません。
Under the first approach, the presence of IPsec tunnel mode SAs is invisible to the IP forwarding mechanism. The lookup uses matching rules in the SA lookup process, closer to firewall matching than traditional IP forwarding lookups, and independent from existing IP forwarding tables. The SA lookup determines which virtual link the packet will be forwarded over, because the tunnel mode SA includes encapsulation information. This lookup and the subsequent tunnel mode processing both ignore the contents of the existing IP forwarding table, whether static or dynamic routing are used. This type of tunnel mode processing is thus incompatible with dynamically routed VPNs.
最初のアプローチでは、IPSECトンネルモードSASの存在は、IP転送メカニズムには見えません。Lookupは、SAルックアッププロセスで一致するルールを使用し、従来のIP転送ルックアップよりもファイアウォールマッチングに近い、既存のIP転送テーブルから独立しています。SAルックアップは、トンネルモードSAにカプセル化情報が含まれているため、パケットが転送される仮想リンクを決定します。このルックアップとその後のトンネルモードの処理は、静的または動的ルーティングが使用されるかどうかにかかわらず、既存のIP転送テーブルの内容を無視します。したがって、このタイプのトンネルモード処理は、動的にルーティングされたVPNと互換性がありません。
The second approach - requiring tunnel mode SAs to be interfaces - can be compatible with dynamically routed VPNs (see Section 4) depending on how it is implemented; however, IIPtran (see Section 3) has the additional benefit of greatly simplifying the IPsec architecture and related specifications, and of being compatible with all IPsec specification compliant implementations.
2番目のアプローチ - トンネルモードSASをインターフェイスにする必要があります - は、実装方法に応じて動的にルーティングされたVPNS（セクション4を参照）と互換性があります。ただし、IIPTRAN（セクション3を参照）には、IPSECアーキテクチャと関連する仕様を大幅に簡素化し、すべてのIPSEC仕様に準拠した実装と互換性があるという追加の利点があります。
A second issue is source address selection at the source host. When an application sends traffic to another host, the host must choose an IP source address for the IP packets before transmission.
2番目の問題は、ソースホストでのソースアドレス選択です。アプリケーションがトラフィックを別のホストに送信する場合、ホストは送信前にIPパケットのIPソースアドレスを選択する必要があります。
When an end system is connected to multiple networks, it must set the source address properly to receive return traffic over the correct network. When a node participates in a virtual network, it is always connected to two networks, the base network and the VN (more if it connects to at least two VNs.) The IPsec specification currently does not define how tunnel mode SAs integrate with source address selection.
エンドシステムが複数のネットワークに接続されている場合、正しいネットワーク上のリターントラフィックを受信するためにソースアドレスを適切に設定する必要があります。ノードが仮想ネットワークに参加する場合、常に2つのネットワーク、ベースネットワークとVN（少なくとも2つのVNに接続する場合はさらに）に接続されています。IPSEC仕様は現在、トンネルモードSASがソースアドレスと統合する方法を定義していません。選択。
For example, when communication occurs over a virtual network, the source address must lie inside the VN. When X sends to Y (Figure 3), the source address must be the IP address of X's local end of tunnel 1. If host A, which has multiple interfaces inside the VN, sends to Y, the source address must be the IP address of the local end of either tunnel 3 or 4.
たとえば、仮想ネットワークを介して通信が発生した場合、ソースアドレスはVN内にある必要があります。xがyに送信する場合（図3）、ソースアドレスはxのトンネルのローカルエンドのIPアドレスでなければなりません。VN内に複数のインターフェイスがあるホストAがyに送信される場合、ソースアドレスはIPアドレスでなければなりません。トンネル3または4のローカルエンドの。
Most applications do not bind to a specific source IP address, and instead let the host pick one for their traffic [7]. Rules for source address selection that depend heavily on the notions of interfaces and routes.
ほとんどのアプリケーションは特定のソースIPアドレスにバインドせず、代わりにホストにトラフィック用に1つを選択させます[7]。インターフェイスとルートの概念に大きく依存するソースアドレス選択のルール。
According to [7], the IP source address of an outbound packet should: (1) for directly connected networks derive from the corresponding interface, or (2) derive from existing dynamic or static route entries to the destination, or finally (3) derive from the interface attached to a default gateway.
[7]によれば、アウトバウンドパケットのIPソースアドレスは次のとおりです。（1）対応するインターフェイスから直接接続されたネットワークの場合、または（2）既存の動的または静的ルートエントリから宛先または最終的に（3）デフォルトゲートウェイに接続されたインターフェイスから派生します。
Because IPsec tunnel mode SAs are not required to be interfaces, rules (1) and (2) may not return a usable source address for a given packet. Consequently, VN packets will use the IP address of the local interface connecting to a default gateway as their source address. Often, a default gateway for a host provides connectivity in the base network underlying the VN. The outgoing packet will thus have a source address in the base network, and a destination address in the VN.
IPSECトンネルモードSASはインターフェイスである必要はないため、ルール（1）および（2）は、特定のパケットの使用可能なソースアドレスを返すことはできません。その結果、VNパケットは、デフォルトゲートウェイに接続するローカルインターフェイスのIPアドレスをソースアドレスとして使用します。多くの場合、ホストのデフォルトゲートウェイは、VNの基礎となるベースネットワークで接続を提供します。したがって、発信パケットには、ベースネットワークにソースアドレスがあり、VNには宛先アドレスがあります。
This can result in numerous problems, including applications that fail to operate at all, firewalls and admission control failures, and may even lead to compromised security. Consider two cases, one with IPsec tunnels configured with no wildcard tunnel addresses, the other using certain wildcards. In both cases, an application whose source address is set by RFC 1122 [7] rules may send packets (e.g.) with the source address of that host's base network (via the default route) and a destination address of the remote tunnel endpoint.
これにより、動作がまったく動作できないアプリケーション、ファイアウォール、入場制御の失敗など、多くの問題が発生する可能性があり、セキュリティの侵害につながる可能性があります。2つのケースを考えてみましょう。1つはワイルドカードトンネルアドレスなしで構成されたIPSECトンネルを使用し、もう1つは特定のワイルドカードを使用しています。どちらの場合も、RFC 1122 [7]ルールによってソースアドレスが設定されているアプリケーションは、そのホストのベースネットワークのソースアドレス（デフォルトルート経由）とリモートトンネルエンドポイントの宛先アドレスを使用してパケット（例えば）を送信する場合があります。
This section introduces a solution - called IIPtran - for the two issues identified above. IIPtran replaces IPsec tunnel mode with a combination of IPIP tunnel interfaces that support forwarding and source address selection (as per RFC 2003 [2]), followed by IPsec transport mode on the encapsulated packet.
このセクションでは、上記の2つの問題について、Iiptranと呼ばれるソリューションを紹介します。IIPTRANは、IPSECトンネルモードを、転送およびソースアドレスの選択をサポートするIPIPトンネルインターフェイスの組み合わせ（RFC 2003 [2]）に置き、その後、カプセル化されたパケットにIPSECトランスポートモードが続きます。
The IPsec architecture [1] defines the appropriate use of IPsec transport mode and IPsec tunnel mode (host-to-host communication for the former, and all transit communication for the latter). IIPtran appears to violate this requirement, because it uses IPsec transport mode for transit communication.
IPSECアーキテクチャ[1]は、IPSECトランスポートモードとIPSECトンネルモード（前者のホスト間通信、および後者のすべてのトランジット通信）の適切な使用を定義しています。IIPTRANは、トランジット通信にIPSECトランスポートモードを使用しているため、この要件に違反しているようです。
However, for an IPIP tunnel between security gateways, the gateways themselves source or sink base network traffic when tunneling - they act as hosts in the base network. Thus, IPsec transport mode is also appropriate, if not required, for encapsulated traffic, according to [1].
ただし、セキュリティゲートウェイ間のIPIPトンネルの場合、ゲートウェイ自体がトンネル時にベースネットワークトラフィックをソースまたはシンクします - それらはベースネットワークでホストとして機能します。したがって、[1]によると、カプセル化されたトラフィックには、IPSECトランスポートモードも必要ではないにしても適切です。
As a result, replacing IPsec tunnel mode with IPIP tunnel devices and IPsec transport mode is consistent with the existing architecture. Furthermore, this does not compromise the end-to-end use of IPsec, either inside a VPN or in the base network; it only adds IPsec protection to secure virtual links.
その結果、IPSECトンネルモードをIPIPトンネルデバイスとIPSECトランスポートモードに置き換えることは、既存のアーキテクチャと一致しています。さらに、これは、VPN内またはベースネットワーク内で、IPSECのエンドツーエンドの使用を妥協するものではありません。仮想リンクを保護するためにIPSEC保護を追加するだけです。
The next sections will give a short overview of IPIP encapsulation, and show it combines with IPsec transport mode processing. This section will then discuss how IIPtran addresses each of the problems identified above.
次のセクションでは、IPIPのカプセル化の簡単な概要を示し、IPSECトランスポートモードの処理と組み合わせることを示します。次に、このセクションでは、Iiptranが上記の各問題にどのように対処するかについて説明します。
IIPtran uses IPIP tunnels (as defined in RFC 2003 [2]), followed by IPsec transport mode on the encapsulated packet.
IIPTRANは、IPIPトンネル（RFC 2003 [2]で定義されている）を使用し、その後、カプセル化されたパケットにIPSECトランスポートモードが続きます。
RFC 2003 [2] uniquely specifies IPIP encapsulation (placing an IP packet as payload inside another IP packet.) Originally developed for MobileIP, it has often been adopted when virtual topologies were required. Examples include virtual (overlay) networks to support emerging protocols such as IP Multicast, IPv6, and Mobile IP itself, as well as systems that provide private networks over the Internet (X-Bone [3] and PPVPN).
RFC 2003 [2] IPIPカプセル化（IPパケットを別のIPパケット内にペイロードとして配置する）を一意に指定します。もともとMobileIP用に開発されたため、仮想トポロジが必要なときに採用されることがよくあります。例には、IPマルチキャスト、IPv6、モバイルIP自体などの新しいプロトコルをサポートする仮想（オーバーレイ）ネットワーク、およびインターネット上でプライベートネットワークを提供するシステム（X-Bone [3]およびPPVPN）が含まれます。
IPIP outbound packet processing, as specified by RFC 2003 [2], tunnels an existing IP packet by prepending it with another IP header (Figure 4.)
RFC 2003 [2]で指定されているIPIPアウトバウンドパケット処理は、別のIPヘッダーで準備することにより、既存のIPパケットをトンネルします（図4.）
Outbound Packet (IPIP Tunnel)
+==================+-----------------+---------+
| Tunnel IP Header | Orig. IP Header | Payload |
+==================+-----------------+---------+
^ |
| |
+------------------+
IPIP Encapsulation
Figure 4: Outbound Packet Construction for IPIP Tunnel
図4：IPIPトンネルのアウトバウンドパケット構造
IIPtran performs this IPIP processing as a first step, followed by IPsec transport mode processing on the resulting IPIP packet (Figure 5.)
IIPTRANは、このIPIP処理を最初のステップとして実行し、その後、結果のIPIPパケットでIPSECトランスポートモードの処理が続きます（図5）
Outbound Packet (IPIP Tunnel + IPsec Transport Mode)
+==================+==============+-----------------+---------+
| Tunnel IP Header | IPsec Header | Orig. IP Header | Payload |
+==================+==============+-----------------+---------+
^ | ^ |
| | | |
| +---------------+ |
| SA Lookup |
| |
+----------------------------------+
IPIP Encapsulation
Figure 5: Outbound Packet Construction for IPIP Tunnel with IPsec Transport Mode
図5：IPSEC輸送モードを備えたIPIPトンネルのアウトバウンドパケット構造
A key difference between Figure 2 and Figure 5 is that in the proposed solution, the IPsec header is based on the outer IP header, whereas under IPsec tunnel mode processing, the IPsec header depends on the contents of the inner IP header and payload (see Section 2.1).
図2と図5の重要な違いは、提案されたソリューションでは、IPSECヘッダーが外側のIPヘッダーに基づいているのに対し、IPSECトンネルモード処理では、IPSECヘッダーは内的IPヘッダーとペイロードの内容に依存します（参照セクション2.1）。
However, the resulting VPN packet (Figure 5) on the wire cannot be distinguished from a VPN packet generated by IPsec tunnel mode processing (Figure 2); and the two methods inter-operate, given appropriate configurations on both ends [3].
ただし、ワイヤ上の結果のVPNパケット（図5）は、IPSECトンネルモード処理によって生成されたVPNパケットと区別することはできません（図2）。両端に適切な構成を与えられた2つの方法は操作します[3]。
A detailed discussion of the differences between IIPtran, IPsec tunnel mode, and other proposed mechanisms follows in Section 4. The remainder of this section will describe how IIPtran combines IPIP tunnel devices with IPsec transport mode to solve the problems identified in Section 2.
IIPTRAN、IPSECトンネルモード、およびその他の提案されたメカニズムの違いについての詳細な議論は、セクション4に記載されています。このセクションの残りの部分では、IIPTRANがIPIPトンネルデバイスとIPSECトランスポートモードを組み合わせてセクション2で特定した問題を解決する方法について説明します。
Section 2.3 described how IP forwarding over IPsec tunnel mode SAs breaks, because tunnel mode SAs are not required to be network interfaces. IIPtran uses RFC 2003 IPIP tunnels [2] to establish the topology of the virtual network. RFC 2003 [2] requires that IPIP tunnels can be routed to, and have configurable addresses. Thus, they can be references in node's routing table (supporting static routing), as well as used by dynamic routing daemons for local communication of reachability information.
セクション2.3は、トンネルモードSASがネットワークインターフェイスである必要がないため、IPSECトンネルモード上のIP転送がどのように壊れるかについて説明します。IIPTRANは、RFC 2003 IPIPトンネル[2]を使用して、仮想ネットワークのトポロジを確立します。RFC 2003 [2]では、IPIPトンネルをルーティングし、構成可能なアドレスを持つことが必要です。したがって、それらはノードのルーティングテーブル（静的ルーティングをサポート）に参照することができ、到達可能性情報のローカル通信のために動的ルーティングデーモンで使用されます。
RFC 2003 [2] addressed the issue of inserting an IPsec header between the two IP headers that are a result of IPIP encapsulation. IIPtran provides further details on this configuration, and demonstrates how it enables dynamic routing in a virtual network.
RFC 2003 [2]は、IPIPカプセル化の結果である2つのIPヘッダー間にIPSECヘッダーを挿入する問題に対処しました。IIPTRANは、この構成の詳細を提供し、仮想ネットワークでの動的ルーティングをどのように可能にするかを示します。
It is important to note that the RFC 2003 IPIP tunnels [2] already provide a complete virtual network that can support static or dynamic routing. The proposed solution of using IPIP tunnel with IPsec transport mode decouples IPsec processing from routing and forwarding. IIPtran's use of IPsec is limited to securing the links of the VN (creating a VPN), because IPsec (rightly) lacks internal support for routing and forwarding.
RFC 2003 IPIPトンネル[2]は、静的または動的ルーティングをサポートできる完全な仮想ネットワークをすでに提供していることに注意することが重要です。IPSECトランスポートモードでIPIPトンネルを使用するという提案されたソリューションは、ルーティングと転送からIPSEC処理を分離します。IIPTRANのIPSECの使用は、IPSEC（正しく）ルーティングと転送の内部サポートがないため、VNのリンク（VPNの作成）を確保することに限定されています。
Section 2.4 gave an overview of IP source address selection and its dependence on interfaces and routes.
セクション2.4では、IPソースアドレスの選択とインターフェイスとルートへの依存の概要について説明しました。
Using RFC 2003 IPIP tunnel devices [2] for VN links, instead of IPsec tunnel mode SAs, allows existing multihoming solutions for source address selection [1] to solve source address selection in this context as well. As indicated in Section 2.4, according to [1], the IP source address of an outbound packet is determined by the outbound interface, which is in turn determined by existing forwarding mechanism. Because IPIP tunnels are full-fledged interfaces with associated routes (as in Section 3.2 of [2]), the routes and address selection as specified in [1] can also operate as desired in the context of VN links.
IPSECトンネルモードSASの代わりに、VNリンクにRFC 2003 IPIPトンネルデバイス[2]を使用すると、ソースアドレス選択のための既存のマルチホームソリューション[1]がこのコンテキストでのソースアドレスの選択を解決できます。セクション2.4に示されているように、[1]によれば、アウトバウンドパケットのIPソースアドレスは、アウトバウンドインターフェイスによって決定され、既存の転送メカニズムによって決定されます。IPIPトンネルは、[1]で指定されているルートとアドレスの選択を関連付けたルートを持つ本格的なインターフェイスであるため、VNリンクのコンテキストでは目的のように動作することもできます。
The previous sections described problems when IPsec tunnel mode provides VPN links, and proposed a solution. This section introduces a number of proposed alternatives, and compares their effect on the IPsec architecture, routing, and policy enforcement, among others, to IIPtran.
以前のセクションでは、IPSECトンネルモードがVPNリンクを提供する場合の問題について説明し、ソリューションを提案しました。このセクションでは、提案されている多くの代替案を紹介し、IPSECアーキテクチャ、ルーティング、および政策執行などの影響をIIPTRANと比較します。
This section gives a brief overview of a number of alternative proposals that aim at establishing support for dynamic routing for IPsec-secured VNs. The following section then compares these proposals in detail.
このセクションでは、IPSECが配置されたVNSの動的ルーティングのサポートを確立することを目的とする多くの代替提案の概要を説明します。次のセクションでは、これらの提案を詳細に比較します。
Although some of the alternatives also address the issues identified above, IIPtran alone also significantly simplifies and modularizes the IPsec architecture.
代替案のいくつかは、上記の問題にも対処していますが、IiptranだけでもIPSECアーキテクチャを大幅に簡素化およびモジュール化します。
In the first alternative, each IPsec tunnel mode SA is required to act as a full-fledged network interface. This SA interface acts as the outbound interface of the virtual destination's forwarding table entry. IPsec dynamically updates the SA interface configuration in response to SAD changes, e.g., caused by IKE negotiation.
最初の代替案では、各IPSECトンネルモードSAは、本格的なネットワークインターフェイスとして機能するために必要です。このSAインターフェイスは、仮想宛先の転送テーブルエントリのアウトバウンドインターフェイスとして機能します。IPSECは、IKEの交渉によって引き起こされる悲しい変更に応じて、SAインターフェイス構成を動的に更新します。
This approach supports dynamic routing and existing source address selection rules, but requires extensions to the IPsec architecture that define tunnel mode SA interfaces and their associated management procedures.
このアプローチは、動的ルーティングと既存のソースアドレス選択ルールをサポートしますが、トンネルモードSAインターフェイスとそれに関連する管理手順を定義するIPSECアーキテクチャの拡張が必要です。
It would necessitate recapitulating the definition of the entirety of RFC 2003 IPIP encapsulation [2], including the association of tunnels with interfaces, inside IPsec. This defeats the modular architecture of the Internet, and violates the specification of type 4 IP in IP packets as being uniquely defined by a single Internet standard (it is already standardized by [2]).
IPSEC内のトンネルとインターフェースとの関連性を含む、RFC 2003 IPIPカプセル化[2]の全体の定義を要約する必要があります。これは、インターネットのモジュラーアーキテクチャを打ち負かし、単一のインターネット標準によって一意に定義されているとして、IPパケットのタイプ4 IPの仕様に違反します（既に[2]によって標準化されています）。
This solution also requires augmenting the IPsec specification to mandate an implementation detail, one that may be difficult to resolve with other IPsec designs, notably the BITS (bump-in-the-stack) alternative. Although the current IPsec specification is ambiguous and allows this implementation, an implementation-independent design is preferable.
また、このソリューションでは、実装の詳細を義務付けるためにIPSEC仕様を拡張する必要があります。これは、他のIPSECデザイン、特にBITS（Bumbin-in-the-Stack）の代替案で解決するのが難しい場合があります。現在のIPSEC仕様は曖昧であり、この実装を可能にしますが、実装に依存しない設計が望ましいです。
A second alternative is the addition of an extra forwarding lookup before IPsec tunnel mode processing. This forwarding lookup will return a "virtual interface" identifier, which indicates how to route the packet [13]. Due to a lack of concrete documentation of this alternative at this time, proposed for an update pending to RFC 2401 [1], two variants are presumed possible:
2番目の選択肢は、IPSECトンネルモード処理の前に追加の転送検索を追加することです。この転送ルックアップは、パケットをルーティングする方法を示す「仮想インターフェイス」識別子を返します[13]。RFC 2401 [1]の保留中の更新のために提案されたこの代替案の具体的な文書が不足しているため、2つのバリアントが可能であると推定されます。
In the first scenario, the extra forwarding lookup indicates the outbound interface of the final encapsulated tunnel mode packet, i.e., usually a physical interface in the base network. The tunnel mode SA lookup following the forwarding lookup will occur in the per-interface SAD associated with the respective virtual interface.
最初のシナリオでは、追加の転送ルックアップは、最終的なカプセル化されたトンネルモードパケットのアウトバウンドインターフェイス、つまりベースネットワークの物理インターフェイスを示します。転送の検索後のトンネルモードSAルックアップは、それぞれの仮想インターフェイスに関連付けられたインターフェイスごとのSADで発生します。
In the second scenario, the extra forwarding lookup returns an outbound tunnel SA interface. This solution seems to be equivalent to the one described above (Section 4.1.1), i.e., all tunnel mode SAs must be interfaces, and is not discussed separately below.
2番目のシナリオでは、追加の転送ルックアップがアウトバウンドトンネルSAインターフェイスを返します。このソリューションは、上記のソリューション（セクション4.1.1）と同等であると思われます。つまり、すべてのトンネルモードSASはインターフェースでなければならず、以下で個別に説明するものではありません。
In the third alternative, the routing protocols and forwarding mechanisms are modified to consult both the routing tables and SADs to make forwarding decision. To prevent IPsec processing from interfering with routing, forwarding table lookup must precede SAD lookup.
3番目の代替案では、ルーティングプロトコルと転送メカニズムが変更され、ルーティングテーブルとSADの両方を参照して転送決定を行います。IPSEC処理がルーティングに干渉するのを防ぐには、転送テーブルの検索が悲しい検索に先行する必要があります。
This approach supports dynamic routing, but requires changes to routing mechanisms such that SAD contents are included in the route exchanges. It is unclear how transport-layer selectors would affect this approach.
このアプローチは動的ルーティングをサポートしますが、ルーティングメカニズムの変更が必要なため、Route交換には悲しい内容が含まれています。輸送層セレクターがこのアプローチにどのように影響するかは不明です。
This section compares the three different alternatives and IIPtran according to a number of evaluation criteria, such as support for VN forwarding, or impact on the IPsec architecture.
このセクションでは、VN転送のサポートやIPSECアーキテクチャへの影響など、多くの評価基準に従って、3つの異なる代替案とIiptranを比較します。
This section investigates whether the three alternatives and IIPtran support VN routing, especially dynamic routing based on existing IP routing protocols.
このセクションでは、3つの代替案とIIPTRANがVNルーティング、特に既存のIPルーティングプロトコルに基づいた動的ルーティングをサポートするかどうかを調査します。
Both IIPtran (IPIP tunnels + transport mode) and alternative 1 (per-SA interfaces) establish VN links as full-fledged devices that can be referred to in the routing table, as well as used for local communication by dynamic routing protocols. They both support static and dynamic VN routing.
IIPTRAN（IPIP Tunnels Transport Mode）とAlternative 1（PERSAインターフェイス）の両方が、ルーティングテーブルで参照できる本格的なデバイスとしてVNリンクを確立し、動的ルーティングプロトコルによるローカル通信に使用します。どちらも静的および動的VNルーティングをサポートしています。
However, because the current IPsec architecture does not require tunnel mode SAs to behave similarly to interfaces (some implementers chose alternative 1, but it is not mandated by the specification), alternative 1 requires extensions to the current IPsec architecture that define the exact behavior of tunnel mode SAs. The proposed solution does not require any such changes to IPsec, and for tunnels RFC 2003 already specifies those requirements [2]. Furthermore, addition of those requirements would be redundant and potentially conflict with RFC 2003 [2].
ただし、現在のIPSECアーキテクチャでは、トンネルモードSASがインターフェイスと同様に動作する必要がないため（一部の実装者は代替1を選択しますが、仕様によって義務付けられていません）、代替1には現在のIPSECアーキテクチャの拡張が必要です。トンネルモードSAS。提案されたソリューションは、IPSECにそのような変更を必要としません。TunnelsRFC2003については、これらの要件をすでに指定しています[2]。さらに、これらの要件の追加は冗長であり、RFC 2003と潜在的に矛盾します[2]。
Alternative 3 supports dynamic VN routing, but requires modifying routing protocols and forwarding lookup mechanisms to act or synchronize based on SAD entries. This requires substantial changes to routing software and forwarding mechanisms in all participating nodes to interface to the internals of IPsec; this would require revising a large number of current Internet standards. It is also not clear how tunnel mode SAs that specify port selectors would operate under this scheme, since IP routing has no dependence on transport-layer fields.
代替3は動的なVNルーティングをサポートしますが、ルーティングプロトコルを変更し、SADエントリに基づいて行動または同期するための検索メカニズムを転送する必要があります。これには、IPSECの内部にインターフェイスするために、すべての参加ノードのルーティングソフトウェアと転送メカニズムを大幅に変更する必要があります。これには、多数の現在のインターネット標準を改訂する必要があります。また、IPルーティングには輸送層フィールドに依存していないため、ポートセレクターを指定するトンネルモードSASがこのスキームで動作する方法も明確ではありません。
Alternative 2 does not support dynamic VN routing. The additional forwarding lookup before IPsec processing is irrelevant, because IPsec tunnel mode SAs are not represented as interfaces, and thus invisible to IP routing protocols.
代替2は、動的なVNルーティングをサポートしません。IPSECトンネルモードSASはインターフェイスとして表されず、IPルーティングプロトコルには見えないため、IPSEC処理前の追加の転送検索は無関係です。
Additionally, the forwarding lookup suggested for alternative 2 is not compatible with a weak ES model described in [1], which requires both an outbound interface indicator as well as the IP address of the next-hop gateway. For example, multiple tunnels can use the same outgoing interface and thus same SAD. The forwarding lookup would return only the interface; lacking the next-hop gateway, the correct SAD entry cannot be determined. Given the next-hop gateway would not help, because the SAD is not indexed by tunnel mode SA encapsulation destination IP address.
さらに、代替2について提案された転送検索は、[1]で説明されている弱いESモデルと互換性がありません。これには、アウトバウンドインターフェイスインジケーターとNext-HOPゲートウェイのIPアドレスの両方が必要です。たとえば、複数のトンネルは同じ発信インターフェイスを使用する可能性があるため、同じ悲しいことです。転送検索はインターフェイスのみを返します。次のホップゲートウェイがないため、正しい悲しいエントリを決定することはできません。SadはトンネルモードSAカプセル化の宛先IPアドレスによってインデックス化されていないため、Next-Hop Gatewayが役に立たないことを考えると。
Because alternative 2 fails to support VN routing, it will not be discussed in the remainder of this section.
Alternative 2はVNルーティングをサポートできないため、このセクションの残りの部分では議論されません。
IIPtran recognizes that encapsulation is already a property of interface processing, and thus relies on IPIP tunnel devices to handle the IPIP encapsulation for VN links. Tunnel mode IPsec thus becomes unnecessary and can potentially be removed from the IPsec architecture, greatly simplifying the specification.
IIPTRANは、カプセル化がすでにインターフェイス処理の特性であることを認識しているため、VNリンクのIPIPカプセル化を処理するためにIPIPトンネルデバイスに依存しています。したがって、トンネルモードIPSECは不要になり、IPSECアーキテクチャから削除される可能性があり、仕様を大幅に簡素化できます。
Alternative 1 requires SAs to be represented as full-fledged interfaces, for the purpose of routing. SAD changes must furthermore dynamically update the configuration of these SA interfaces. The IPsec architecture thus needs extensions that define the operation of interfaces and their interactions with the forwarding table and routes.
代替1では、ルーティングを目的として、SASを本格的なインターフェイスとして表現する必要があります。さらに、悲しい変更は、これらのSAインターフェイスの構成を動的に更新する必要があります。したがって、IPSECアーキテクチャには、インターフェイスの動作と転送テーブルとルートとの相互作用を定義する拡張機能が必要です。
Additionally, RFC 2401 [1] describes per-interface SADs as a component of IPsec. When tunnel mode SAs themselves act as interfaces, the function of per-interface SADs needs clarification as follows:
さらに、RFC 2401 [1]は、インターフェイスごとのSADSをIPSECのコンポーネントとして説明しています。トンネルモード自体がインターフェイスとして機能する場合、インターフェイスごとのSADSの機能には次のように説明が必要です。
First, each tunnel interface SAD must contain exactly one IPsec tunnel mode SA. Transport mode SAs are prohibited, because they would not result in IP encapsulation (the encapsulation header is part of the tunnel mode SA, a transport mode SA would not cause encapsulation), and thus lead to processing loops. Multiple tunnel mode SAs are prohibited, because dynamic routing algorithms construct topology information based on per-interface communication. Merging different virtual links (tunnels) into a single SA interface can cause routing events on one virtual link to apply incorrectly to other links sharing an SA interface.
まず、各トンネルインターフェイスSADには、1つのIPSECトンネルモードSAを正確に含める必要があります。トランスポートモードSASは禁止されています。これは、IPカプセル化につながらないためです（カプセル化ヘッダーはトンネルモードSAの一部であり、輸送モードSAがカプセル化を引き起こさないため）。動的ルーティングアルゴリズムがインターフェイスごとの通信に基づいてトポロジ情報を構築するため、複数のトンネルモードSASが禁止されています。異なる仮想リンク（トンネル）を単一のSAインターフェイスにマージすると、1つの仮想リンクでルーティングイベントが発生し、SAインターフェイスを共有する他のリンクに誤って適用できます。
Second, only the SAD of physical interfaces may contain IPsec transport mode SAs; otherwise, the current issues with VN routing remain unsolved.
第二に、物理的なインターフェイスの悲しいだけがIPSECトランスポートモードSASを含むことができます。それ以外の場合、VNルーティングに関する現在の問題は未解決のままです。
In summary, these restrictions cause the SADs of SA interfaces to contain only tunnel mode SAs, and the SADs of regular interfaces to contain only transport mode SAs. Thus, tunnel encapsulation essentially becomes a unique property of the interface, and not IPsec.
要約すると、これらの制限により、SAインターフェイスの悲しみがトンネルモードSASのみを封じ込め、通常のインターフェイスが輸送モードSAのみを封じ込めることが含まれます。したがって、トンネルのカプセル化は、本質的にIPSECではなくインターフェイスの一意のプロパティになります。
IIPtran already recognizes this property. Consequently, it uses IPIP tunnels directly, and combines them with transport mode processing. By eliminating the use of tunnel mode, it removes the need for additional constraints on the contents of per-interface SAs.
Iiptranはすでにこのプロパティを認識しています。その結果、IPIPトンネルを直接使用し、それらを輸送モード処理と組み合わせます。トンネルモードの使用を排除することにより、インターフェイスごとのSASの内容に対する追加の制約が必要になります。
On receiving a packet, both IPsec tunnel mode and IIPtran decrypt and/or authenticate the packet with the same techniques. IPsec tunnel mode decapsulates and decrypts the packet in a single step, followed by a policy check of the inner packet and its payload against the respective IPsec tunnel mode SA. IIPtran uses IPsec transport mode to decrypt and verify the incoming packet, then passes the decrypted IPIP packet on to RFC 2003 IPIP processing [2]. At that point, IIPtran can support selector checks on both the header and its payload using firewall mechanisms, similar to IPsec tunnel mode processing.
パケットを受信すると、IPSECトンネルモードとIIPTRANの両方が同じ手法でパケットを解読および/または認証します。IPSECトンネルモードは、パケットを1つのステップで脱カプセル化して解読し、その後、内側のパケットとそのペイロードのポリシーチェックがそれぞれのIPSECトンネルモードSAに対するペイロードを行います。IIPTRANは、IPSECトランスポートモードを使用して、着信パケットを復号化および検証し、RFC 2003 IPIP処理[2]に復号化されたIPIPパケットを渡します。その時点で、IIPTRANは、IPSECトンネルモード処理と同様に、ファイアウォールメカニズムを使用して、ヘッダーとそのペイロードの両方のセレクターチェックをサポートできます。
The primary difference between the two is that IPsec tunnel mode does not require a separate processing step for validating packets; once IPsec accepts them during the policy check during decapsulation, they are accepted. IIPtran requires additional processing on the decapsulated packets, to validate whether they conform to their respective IPsec policy.
2つの主な違いは、IPSECトンネルモードでは、パケットを検証するための個別の処理ステップを必要としないことです。IPSECが脱カプセル化中のポリシーチェック中にそれらを受け入れると、それらは受け入れられます。IIPTRANは、脱カプセル化パケットで追加の処理を必要とし、それぞれのIPSECポリシーに適合するかどうかを検証します。
As noted in Section 5.2 of the IPsec architecture document [1], IPsec processing should retain information about what SAs matched a given packet, for subsequent IPsec or firewall processing. To allow for complex accept policies, it should be possible to reconstruct the format of the original packet at the time it first entered a machine based on saved processing context at any time during inbound processing. IIPtran accepts incoming VN packets only if they have arrived over a specific IPIP tunnel that was secured with IPsec transport mode, but as a separate step following IPIP decapsulation.
IPSECアーキテクチャドキュメント[1]のセクション5.2で述べたように、IPSEC処理は、後続のIPSECまたはファイアウォール処理のために、SASが特定のパケットと一致するものに関する情報を保持する必要があります。複雑な受け入れポリシーを許可するには、インバウンド処理中にいつでも保存された処理コンテキストに基づいてマシンを最初に入力したときに、元のパケットの形式を再構築することができるはずです。IIPTRANは、IPSECトランスポートモードで固定された特定のIPIPトンネルに到着した場合にのみ、着信VNパケットを受け入れますが、IPIPの脱カプセル化後の別のステップとして受け入れます。
Note that IPsec tunnel mode and IIPtran are interoperable [3]. Experiments have verified this interoperability, notably because there are no differences in the resulting packets on the wire, given appropriate keys.
IPSECトンネルモードとIIPTRANは相互運用可能であることに注意してください[3]。特に、適切なキーを与えられたワイヤー上のパケットに違いがないため、実験によりこの相互運用性が検証されました。
When looking up an SA for a given packet, IPsec allows selectors to match on the contents of the IP header and transport headers. IIPtran using existing IPsec cannot support transport header matches, because SA lookup occurs before decapsulation. A small extension to IPsec can address this issue in a modular way.
特定のパケットのSAを検索するとき、IPSECを使用すると、セレクターがIPヘッダーとトランスポートヘッダーの内容を一致させることができます。既存のIPSECを使用したiiptranは、脱カプセル化の前にSAルックアップが発生するため、トランスポートヘッダーマッチをサポートできません。IPSECの小さな拡張機能は、この問題にモジュール式の方法で対処できます。
RFC 2401 [1] explicitly recognizes that the transport layer header may be nested several headers deep inside the packet, and allows a system to (quote) "chain through the packet headers checking the 'Protocol' or 'Next Header' field until it encounters either one it recognizes as a transport protocol, or until it reaches one that isn't on its list of extension headers, or until it encounters an ESP header that renders the transport protocol opaque."
RFC 2401 [1]は、輸送層ヘッダーがパケットの奥深くにあるいくつかのヘッダーがいくつかのヘッダーにネストされている可能性があることを明示的に認識し、遭遇するまで「プロトコル」または「次のヘッダー」フィールドをチェックするパケットヘッダーを介してシステムを（引用）することができます。輸送プロトコルとして認識されるもの、または拡張ヘッダーのリストに載っていないものに達するまで、または輸送プロトコル不透明をレンダリングするESPヘッダーに遭遇するまで。」
With IIPtran, the SA lookup starts on the outer (tunnel) header, and selectors including port number information must thus traverse the inner IP header (and possibly other headers) before they can match on the transport headers. IIPtran thus requires that IP be a known IPsec "extension header." This recognizes that with IPIP encapsulation, IP VNs use the base IP network as a link layer. Although this small extension to IPsec is not explicitly required, it is already implied.
IIPTRANを使用すると、SAルックアップは外側（トンネル）ヘッダーで開始され、ポート番号情報を含むセレクターは、トランスポートヘッダーで一致する前に、内側のIPヘッダー（および場合によっては他のヘッダー）を通過する必要があります。したがって、IIPTRANは、IPが既知のIPSEC「拡張ヘッダー」であることを要求しています。これは、IPIPカプセル化では、IP VNSがベースIPネットワークをリンクレイヤーとして使用することを認識しています。IPSECのこの小さな拡張は明示的に必要ではありませんが、すでに暗示されています。
Recognizing IP as a valid transport layer over IP also allows selectors to match on the contents of the inner ("transport") IP header. Thus, IPsec selectors under IIPtran can express the same set of policies as conventional IPsec tunnel mode.
IPをIP上の有効なトランスポートレイヤーとして認識することで、セレクターは内側（「輸送」）IPヘッダーの内容を一致させることができます。したがって、IIPTRANの下のIPSECセレクターは、従来のIPSECトンネルモードと同じポリシーセットを表現できます。
Note that in both cases, these policy enforcement rules violate layering by looking at information other than the outermost header. This is consistent with IPsec's current use of port-based selectors. The next section discusses that selectors may not be useful for virtual networks.
どちらの場合も、これらの政策執行規則は、最も外側のヘッダー以外の情報を調べることにより、階層化に違反していることに注意してください。これは、IPSECの現在のポートベースのセレクターの使用と一致しています。次のセクションでは、セレクターが仮想ネットワークに役立たない可能性があることについて説明します。
For secure VN links established via IPsec tunnel mode SAs, the selectors for the inner (VN) source and destination IP addresses often need to be wildcarded to support dynamic routing in a VN. Thus, the limitation described in 4.2.3.1 (without the proposed extension) may not be important in a VN scenario.
IPSECトンネルモードSASを介して確立された安全なVNリンクの場合、内側（VN）ソースおよび宛先IPアドレスのセレクターは、VNでの動的ルーティングをサポートするためにワイルドカードを使用する必要があることがよくあります。したがって、4.2.3.1（提案された延長なし）で説明されている制限は、VNシナリオでは重要ではないかもしれません。
Consider a four-node VN with nodes A, B, C, and N (Figure 6). Consider the case where N is either a new node joining an existing VPN, or an existing node that had been disconnected and was just rediscovered via dynamic routing.
ノードA、B、C、およびNを備えた4ノードVNを考えてみましょう（図6）。nが既存のVPNを結合する新しいノード、または切断された既存のノードであり、動的ルーティングを介して再発見された場合を考慮してください。
In this example, A has IPsec tunnel mode SAs to B and C. If the selectors for the virtual source and destination IP addresses for those SAs are not wildcards, the SA needs to be dynamically modified to permit packets from N to pass over the tunnels to B and C. This becomes quickly impractical as VPN sizes grow.
この例では、AはIpsecトンネルモードSASをBおよびCに持っています。これらのSASの仮想ソースおよび宛先IPアドレスのセレクターがワイルドカードではない場合、SAはNからパケットがトンネルを通過することを許可するために動的に変更する必要がありますBとCに、VPNサイズが成長するにつれてこれはすぐに非現実的になります。
B
/
/
/
N ------ A
\
\
\
C
Figure 6: Topology of a Virtual Network
図6：仮想ネットワークのトポロジ
Thus, IPsec selectors appear much less useful in a VPN scenario than expected. A consequence might be that IIPtran - even without extensions to support the full expressiveness of tunnel mode SA selectors as described above - can still support the majority of VPN scenarios.
したがって、IPSECセレクターは、VPNシナリオでは予想よりもはるかに有用ではないようです。その結果、上記のようにトンネルモードSAセレクターの完全な表現力をサポートする拡張機能がなくても、VPNシナリオの大部分をサポートできる可能性があります。
One purpose of selectors matching on transport header content is policy routing. Different SAs can apply to different applications, resulting in different apparent virtual topologies. IIPtran supports policy routing in a more modular way, by having existing policy routing implementations forward traffic over multiple, parallel VNs. IIPtran supports arbitrary IP-based policy routing schemes, while policies are limited by the expressiveness of IPsec's selectors in the former case.
トランスポートヘッダーコンテンツで一致するセレクターの1つの目的は、ポリシールーティングです。さまざまなSASが異なるアプリケーションに適用できるため、異なる見かけの仮想トポロジが発生します。IIPTRANは、既存のポリシールーティングの実装を複数の並列VNSで転送することにより、よりモジュール式の方法でポリシールーティングをサポートしています。IIPTRANは、任意のIPベースのポリシールーティングスキームをサポートしますが、ポリシーは前者の場合のIPSECのセレクターの表現力によって制限されています。
The Internet Key Exchange (IKE) [9][10] is a protocol to negotiate IPsec keys between end systems dynamically and securely. It is not a strictly required component of IPsec in the sense that two hosts can communicate using IPsec without having used IKE to negotiate keys (through manually keyed SAs, for example). Despite its name, IKE also acts as a tunnel management protocol (when IPsec tunnel mode SAs are configured), and negotiates security policies between the peers.
Internet Key Exchange（IKE）[9] [10]は、エンドシステム間のIPSECキーを動的および安全にネゴシエートするプロトコルです。IKESを使用してキーをネゴシエートすることなくIPSECを使用して通信できるという意味で、IPSECの厳密に必要なコンポーネントではありません（たとえば、手動でキー付きSASを介して）。その名前にもかかわらず、IKEはトンネル管理プロトコルとしても機能し（IPSECトンネルモードSASが設定されている場合）、ピア間のセキュリティポリシーを交渉します。
Alternatives 1 and 3 use existing IKE without changes.
代替案1および3は、変更なしで既存のIKEを使用します。
One possible approach to use IKE with IIPtran is to negotiate a tunnel mode SA, and then treat it as a transport mode SA against an IPIP tunnel when communicating with conventional peers. For policies that do not specify selectors based on transport-layer information, this establishes interoperability.
IIPTRANでIKEを使用する可能性のあるアプローチの1つは、トンネルモードSAと交渉し、従来のピアと通信するときにIPIPトンネルに対して輸送モードSAとして扱うことです。輸送層情報に基づいてセレクターを指定しないポリシーの場合、これにより相互運用性が確立されます。
However, since IIPtran eliminates IPsec tunnel mode, it could also simplify IKE, by limiting it to its original purpose of key exchange. A new tunnel management protocol (e.g., ATMP [8]) would set up IPIP tunnels, use an as of yet unspecified second protocol to negotiate security policy, and then use IKE to exchange keys for use with the policy.
ただし、IIPTRANはIPSECトンネルモードを排除するため、IKEを単純化する可能性もあります。新しいトンネル管理プロトコル（例：ATMP [8]）は、IPIPトンネルをセットアップし、まだ特定されていない2番目のプロトコルを使用してセキュリティポリシーを交渉し、IKEを使用してポリシーで使用するキーを交換します。
Current IKE operation would become a modular composition of separate protocols, similar to how IIPtran modularizes IPsec by combining existing Internet standards. For example, a VPN link creation could follow these steps: (1) IKE negotiation in the base network to secure (2) a subsequent tunnel management exchange [8] in the base network, followed by (3) IKE exchanges over the established tunnel to create a secure VPN link.
現在のIKE操作は、既存のインターネット標準を組み合わせてIIPTRANがIPSECをモジュール化する方法と同様に、個別のプロトコルのモジュラー構成になります。たとえば、VPNリンクの作成は次の手順に従うことができます。（1）ベースネットワークでのIKEの交渉は、（2）ベースネットワークでその後のトンネル管理交換[8]を保護し、続いて（3）IKEが確立されたトンネルを介して交換します。安全なVPNリンクを作成します。
This document addresses security considerations throughout, as they are a primary concern of proposed uses of IPsec.
このドキュメントは、IPSECの提案された用途の主な関心事であるため、セキュリティに関する考慮事項について説明します。
The primary purpose of this document is to extend the use of IPsec to dynamically routed VPNs, which will extend the use of IPsec and, it is hoped, increase the security of VPN infrastructures using existing protocols.
このドキュメントの主な目的は、IPSECの使用を動的にルーティングしたVPNSに拡張することです。これにより、IPSECの使用が拡張され、既存のプロトコルを使用してVPNインフラストラクチャのセキュリティが増加することが期待されます。
This document presents a mechanism consistent with the current use of IPsec which supports dynamic routing inside a virtual network that uses IPsec to secure its links. It illustrates how current use of IPsec tunnel mode can fail to support dynamic VN routing (depending on the implementation), and compares IIPtran with several different alternatives. It finds that IIPtran, a composite of a subset of IPsec (i.e., transport mode) together with existing standard IPIP encapsulation, results in an interoperable, standards-conforming equivalent that is both simpler and modular.
このドキュメントは、IPSECを使用してリンクを保護する仮想ネットワーク内の動的ルーティングをサポートするIPSECの現在の使用と一致するメカニズムを示しています。IPSECトンネルモードの現在の使用が動的VNルーティングをサポートできないことを示しており（実装に応じて）、IIPTRANをいくつかの異なる代替案と比較します。IIPTRANは、IPSECのサブセット（つまり、トランスポートモード）と既存の標準のIPIPカプセル化の複合であり、よりシンプルでモジュラーの両方の相互運用可能な標準構成の同等物をもたらすことがわかります。
The authors would like to thank the members of the X-Bone and DynaBone projects at USC/ISI for their contributions to the ideas behind this document, notably (current) Greg Finn and (past) Amy Hughes, Steve Hotz and Anindo Banerjea.
著者は、USC/ISIのX-BoneおよびDynaboneプロジェクトのメンバーに、このドキュメントの背後にあるアイデア、特に（現在の）グレッグフィンと（過去）エイミーヒューズ、スティーブホッツ、アニンドバネジアへの貢献について感謝したいと思います。
The authors would also like to thank Jun-ichiro (itojun) Hagino and the KAME project for bringing IKE implications of this proposal to our attention, as well as implementing the mechanisms in this document in the KAME IPv6/IPsec network stack. Members of several IETF WGs (especially IPsec: Stephen Kent, PPVPN: Eric Vyncke, Paul Knight, various members of MobileIP) provided valuable input on the details of IPsec processing in earlier revisions of this document.
著者はまた、この提案のIKEの影響を私たちの注意に導き、KAME IPv6/IPSECネットワークスタックのこのドキュメントのメカニズムを実装してくれたJun-Ichiro（Itojun）HaginoとKame Projectに感謝したいと思います。いくつかのIETF WGSのメンバー（特にIPSEC：Stephen Kent、PPVPN：Eric Vyncke、Paul Knight、MobileIPのさまざまなメンバー）は、このドキュメントの以前の改訂におけるIPSEC処理の詳細に関する貴重な入力を提供しました。
Effort sponsored by the Defense Advanced Research Projects Agency (DARPA) and Air Force Research Laboratory, Air Force Materiel Command, USAF, under agreements number F30602-98-1-0200 entitled "X-Bone" and number F30602-01-2-0529 entitled "DynaBone".
防衛先進研究プロジェクト局（DARPA）および空軍研究所、USAFの空軍材料研究所、「X-Bone」および番号F30602-01-2-0529というタイトルの契約番号F30602-98-1-0200が後援する努力「dynabone」と題されています。
[1] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[1] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[2] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[2] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[3] Touch, J., "Dynamic Internet overlay deployment and management using the X-Bone", Computer Networks Vol. 36, No. 2-3, July 2001.
[3] Touch、J。、「X-Boneを使用したダイナミックインターネットオーバーレイの展開と管理」、Computer Networks Vol。36、No。2-3、2001年7月。
[4] Touch, J., Wang, Y., Eggert, L. and G. Finn, "A Virtual Internet Architecture", ISI Technical Report ISI-TR-570, Workshop on Future Directions in Network Architecture (FDNA) 2003, March 2003.
[4] Touch、J.、Wang、Y.、Eggert、L。and G. Finn、「仮想インターネットアーキテクチャ」、ISIテクニカルレポートISI-570、2003年3月、ネットワークアーキテクチャ（FDNA）2003年の将来の方向性に関するワークショップ。
[5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[5] Kent、S。およびR. Atkinson、「IP Authentication Header」、RFC 2402、1998年11月。
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[6] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[7] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[7] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[8] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, February 1997.
[8] Hamzeh、K。、「Ascend Tunnel Management Protocol -ATMP」、RFC 2107、1997年2月。
[9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[9] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[10] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Work in Progress, January 2004.
[10] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、2004年1月、進行中の作業。
[11] Kent, S., "IP Authentication Header", Work in Progress, February 2004.
[11] Kent、S。、「IP Authentication Header」、Work in Progress、2004年2月。
[12] Kent, S., "IP Encapsulating Security Payload (ESP)", Work in progress, February 2004.
[12] Kent、S。、「セキュリティペイロードをカプセル化するIP（ESP）」、2004年2月、進行中の作業。
[13] Kent, S., "Personal Communication", November 2002.
[13] ケント、S。、「個人的なコミュニケーション」、2002年11月。
[14] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[14] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[15] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[15] Lahey、K。、「Path MTU DiscoveryのTCP問題」、RFC 2923、2000年9月。
Appendix A. Encapsulation/Decapsulation Issues
付録A. カプセル化/脱カプセル化の問題
There are inconsistencies between the IPIP encapsulation rules specified by IPsec [1] and those specified by MobileIP [2]. The latter specification is standards track, and the IP protocol number of 4 (payload of an IP packet of type 4) is uniquely specified by RFC 2003 according to IANA [2]. The use of IPIP inside an IPsec transport packet can be confused with IPsec tunnel mode, because IPsec does not specify any limits on the types of IP packets that transport mode can secure.
IPSEC [1]によって指定されたIPIPカプセル化ルールとMobileIP [2]によって指定されたものとの間には不一致があります。後者の仕様は標準トラックであり、IPプロトコル番号4（タイプ4のIPパケットのペイロード）は、IANA [2]によるとRFC 2003によって一意に指定されています。IPSECトランスポートパケット内でのIPIPの使用は、IPSECトンネルモードと混同する可能性があります。これは、IPSECでは、トランスポートモードが確保できるIPパケットの種類に制限を指定していないためです。
When an IP packet is encapsulated as payload inside another IP packet, some of the outer header fields can be newly written (and the inner header determines some others [2].) Among these fields is the IP DF (do not fragment) flag. When the inner packet DF flag is clear, the outer packet may copy it or set it; however, when the inner DF flag is set, the outer header must copy it [2]. IPsec defines conflicting rules, where that flag and other similar fields (TOS, etc.) may be copied, cleared, or set as specified by an SA.
IPパケットが別のIPパケット内のペイロードとしてカプセル化されると、外側のヘッダーフィールドの一部を新たに記述できます（および内側のヘッダーは他のいくつかを決定します[2]）。内側のパケットDFフラグがクリアされると、外側のパケットがコピーまたは設定する場合があります。ただし、内側のDFフラグが設定されている場合、外側のヘッダーはコピーする必要があります[2]。IPSECは、そのフラグやその他の同様のフィールド（TOSなど）がSAによって指定されているようにコピー、クリア、または設定される可能性がある矛盾するルールを定義します。
The IPsec specification indicates that such fields must be controlled, to achieve security. Otherwise, such fields could provide a covert channel between the inner packet header and outer packet header. However, RFC 2003 [2] requires that the outer fields not be cleared when the inner ones are set, to prevent MTU discovery "black holes" [14][15].
IPSEC仕様は、セキュリティを達成するために、そのようなフィールドを制御する必要があることを示しています。それ以外の場合、そのようなフィールドは、内側のパケットヘッダーと外側のパケットヘッダーの間に秘密のチャネルを提供できます。ただし、RFC 2003 [2]では、MTUの発見「ブラックホール」[14] [15]を防ぐために、内側のフィールドが設定されているときに外側のフィールドをクリアしないことが必要です。
To avoid a conflict between these rules, and to avoid security weaknesses associated with solely copying the fields, it is recommended that IPsec IPIP encapsulation not permit the clearing of the outer DF flag. When the SA requires clearing the DF flag, and the inner packet DF is set, it is proposed that IPsec drop that packet, rather than violate RFC 2003 processing rules [2]. Similar rules are being developed for TOS and other similar IP header fields, to be included in an update of RFC 2003 [2].
これらのルール間の競合を回避し、フィールドのみのコピーに関連するセキュリティの弱点を回避するために、IPSEC IPIPのカプセル化は外部DFフラグのクリアを許可しないことをお勧めします。SAがDFフラグをクリアする必要があり、内側のパケットDFが設定されると、IPSECがRFC 2003処理ルールに違反するのではなく、そのパケットをドロップすることが提案されています[2]。RFC 2003 [2]の更新に含まれるために、TOSおよびその他の同様のIPヘッダーフィールド向けに同様のルールが開発されています。
Another approach to closing the covert channel is always to set the DF flag in the outer header (whether or not it is set in the inner header). Setting the DF flag allows PMTU discovery to operate normally. The details of this approach are discussed in [2].
秘密のチャネルを閉じるもう1つのアプローチは、常に外側のヘッダーにDFフラグを設定することです（内側のヘッダーに設定されているかどうか）。DFフラグを設定することで、PMTUの発見が正常に動作できます。このアプローチの詳細については、[2]で説明しています。
Given identical keys, a packet created by IPIP tunnel encapsulation combined with IPsec transport mode and an IPsec tunnel mode packet look identical on the wire. Thus, when an IPsec'ed packet arrives that contains an IPIP inner packet, it is not possible to distinguish whether the packet was created using IPsec tunnel mode or IPsec transport mode of an IPIP encapsulated packet. In both cases, the protocol field of the outer header is IPsec (AH or ESP), and the "next header" field for the inner data is 4 (IP). IPsec requires the SA matching a received packet to indicate whether to apply tunnel mode or transport mode.
同一のキーが与えられた場合、IPIPトンネルのカプセル化によって作成されたパケットは、IPSECトランスポートモードとワイヤー上で同じように見えるIPSECトンネルモードパケットを組み合わせています。したがって、IPIPインナーパケットを含むIPSECのパケットが到着すると、IPIPカプセル化されたパケットのIPSECトンネルモードを使用してPacketが作成されたのか、IPSEC輸送モードを使用して作成されたかを区別することはできません。どちらの場合も、外側ヘッダーのプロトコルフィールドはIPSEC（AHまたはESP）であり、内部データの「次のヘッダー」フィールドは4（IP）です。IPSECでは、トンネルモードを適用するか輸送モードを適用するかを示すために、受信したパケットを一致させるSAが必要です。
Incoming packet processing must check the SAD before determining whether to decapsulate IPsec packets with inner payload of protocol type 4. If the SAD indicates that a tunnel mode association applies, IPsec must decapsulate the packet. If the SAD indicates that a transport mode association applies, IPsec must not decapsulate the packet. This requires that the SAD indicate one of these two options; wildcard SAD entries ("ANY", or "TUNNEL or TRANSPORT") cannot be supported.
着信パケット処理は、プロトコルタイプ4の内部ペイロードでIPSECパケットを脱カプセル化するかどうかを判断する前に、SADを確認する必要があります。SADが輸送モードの関連付けが適用されることを示している場合、IPSECはパケットを脱カプセル化してはなりません。これには、SADがこれら2つのオプションのいずれかを示していることが必要です。ワイルドカードの悲しいエントリ（「任意」、または「トンネルまたは輸送」）をサポートできません。
IPsec's use of IPIP encapsulation conflicts with the IPIP standard [2]. This issue is already being resolved in an update to RFC 2003, instead of specifying a non-standard conforming variant of IPIP encapsulation inside IPsec.
IPSECのIPIPカプセル化の使用は、IPIP標準と矛盾しています[2]。この問題は、IPSEC内のIPIPカプセル化の非標準的な適合バリアントを指定する代わりに、RFC 2003の更新ですでに解決されています。
Authors' Addresses
著者のアドレス
Joe Touch USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 US
Joe Touch USC Information Sciences Institute 4676 Admiralty Way Marina Del Rey、CA 90292 US
Phone: +1 310 822 1511
Fax: +1 310 823 6714
EMail: touch@isi.edu
URI: http://www.isi.edu/touch
Lars Eggert NEC Network Laboratories Kurfuersten-Anlage 36 Heidelberg 69115 DE
Lars Eggert Nec Network Laboratories Kurfuersten-Anlage 36 Heidelberg 69115 de
Phone: +49 6221 90511 43
Fax: +49 6221 90511 55
EMail: lars.eggert@netlab.nec.de
URI: http://www.netlab.nec.de/
Yu-Shun Wang USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 US
Yu-Shun Wang USC Information Sciences Institute 4676 Admiralty Way Marina Del Rey、CA 90292 US
Phone: +1 310 822 1511
Fax: +1 310 823 6714
EMail: yushunwa@isi.edu
URI: http://www.isi.edu/yushunwa
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。