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
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）インターネット協会（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.
この文書はインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のために、それはセキュリティ、輻輳制御または展開されたプロトコルとの不適切な相互作用のようなもののためにIETFのレビューを受けていない特定のノートに、このドキュメントのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。
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）のために、例えば、信頼されたコンポーネント間の通信を保護するために、マルチホップネットワークのリンクを確保することができます。 IPルーティングは、インターフェイスとネクストホップIPアドレスへの参照に依存するため、IPsecトンネルモードにより確立された仮想リンクは内部のVNルーティングおよび転送と競合することができます。 IPsecトンネルモードの仕様では、この問題に曖昧で、そうでも準拠した実装では、衝突を避けるために信頼することはできません。トンネルモードの代わりに、私たちはIIPtranを呼び出すIPsecトランスポートモード、一緒に非のIPsec IPIPカプセル化を使用しています。 IPIPカプセル化は、VNのパケットの転送のルックアップの結果として、別個の最初のステップとして起こります。 IPsecトランスポート・モードは、トンネルヘッダのセキュリティアソシエーションデータベース（SAD）の一致によって決定SAを有する得られた（トンネリング）IPパケットを処理します。 IIPtran現在のIPsecアーキテクチャを変更せずにVN内部動的ルーティングをサポートします。 IIPtranは、前述の競合を避けるために、すべての準拠したIPsec実装を設定する方法を示します。 IIPtranは、インターネットキー交換（IKE）とVNルーティングおよびIPsecにそれぞれの影響、ルーティング、ポリシー施行、および相互作用のためのいくつかの代替の機構と比較されます。
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）は二つのモード、トランスポートモードとトンネルモードで構成されている[1]。トランスポートモードは2つのだけエンドホスト間で許可されています。エンドポイントの少なくとも一方が「セキュリティゲートウェイ」である場合、トンネルモードが必要とされている（例えば、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では、ネットワーク内のルータ明らかで動的にパケットを転送（内部）を信頼し、パスが複数のトンネルを横断することができるセキュアトンネル上でパケットを交換します。多くの場合、パスはセキュアコア内のリソースへの1つの安全なトンネルを通過する傾向があることを前提とし、従来の「仮想プライベートネットワーク」（VPN）、これを対比。一般的な安全な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.
この文書では、VN分散マルチホップのリンクを確保するためにIPsecの使用に対応しています。これは、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.
この文書は、IPsec処理からIPトンネルカプセル化の工程を分離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.
この文書の後のセクションでは、異なる提案が全体のIPsecアーキテクチャ、ルーティングプロトコル、セキュリティポリシーの適用に与える影響に着目し、VPNの内部の動的ルーティングのための他の提案にIIPtranを比較し、インターネット鍵交換（IKE）[9] [10 ]。付録には、IPIPカプセル化とカプセル化解除に関連したIPsecでのIPトンネル処理の問題について説明します。
This document assumes familiarity with other Internet standards [1][2], notably with terminology and numerous acronyms therein.
この文書は、特に、その中に用語および多数の頭字語で、[2] [1]他のインターネット標準に精通を想定しています。
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
この文書は、第1「仮想ネットワークのためのIPSEC転送モードの使用」と題し、2000年3月10日にインターネットドラフトとして発行され、最初の2000年3月にアデレードでの第47回IETFでのIPsec WGで提示されたことは、その後、改訂されたと2001年12月にソルトレイクシティの第52回IETFでのIPsec WGに、2001年8月にロンドンで第51回IETFでPPVPN WGに提示され、両方の
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.
バージョン07が承認されるまで、この草案の2002年3月、ミネアポリスでの第53回IETFでのIPsecとPPVPNのWGバージョン04は2002年6月のIPsec WGによって提案に基づいて情報のRFCとして公表のために提出し、その後からIESGレビューの下にありましたその時間の間に2004年6月に出版のために、それが実質的セキュリティと互換性の問題に関しては、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トポロジ内の1つのホップのリンクであるが、基礎となるネットワークに（接続されたリンクの配列）に直接リンクまたは経路のいずれかです。
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の一部ではなく、ベースネットワークであることができるようにするだけを許可します。上記の定義は、明示的にホストおよびルータが複数、並列のVNに参加することができ、層状の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のトランスポートモードとトンネルモード[1]の2つのモードがあります。トランスポートモードでは、既存の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は（図1）元のIPヘッダとパケットペイロードとの間の発信IPパケットにセキュリティ・プロトコル・ヘッダを挿入する[5] [6] [11] [12]。 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トランスポートモードで固定パケットを受信した場合、同様のSAルックアップは、パケットの内容や各SAに対するそのペイロードを検査IPsec処理後の検証ステップが続くIPと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は、発信IPパケット（図2）へのIPsecヘッダ及び追加のIPヘッダを付加します。本質的には、元のパケットは、IPsecは、その後固定し、別のIPパケットのペイロードになります。これは、[1]として記載されている「SAは、本質的に[転送モード] SAがIPトンネルに適用されるトンネルモード」。このセクションの残りの部分に記載されているようしかし、両者の間に有意差があります。
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はまた、元のアウトバウンドパケットヘッダとペイロード（図2、矢印）に基づいており、外側トンネルIPヘッダの送信元および宛先IPアドレスを含む、カプセル化情報を含みます。
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で固定パケットを受信した場合、SAルックアップは、IPsecヘッダと外部IPヘッダの内容に基づいて発生します。次に、パケットは、IPsecヘッダ及び各SAに対する元のパケットとそのペイロード（特に内側IPヘッダとトランスポートヘッダ）の内容をチェックする検証ステップに続いてSAに基づいて、復号化又は認証されます。
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トンネルモードSAにより確立された仮想リンクを持つVPNトポロジーを考えます。レガシーエンドシステムは、エンドツーエンドのIPsec自分をサポートしていない場合、そのようなホップバイホップのセキュリティは、VNルーティングを確保するために、例えば、役立つこと、およびすることができます。
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.)
宛先IPアドレスと転送テーブルに基づいて：VNでの仮想ルータはパケットを通常のインターネットルータが行うのと同じ方法を転送する必要があります。これらの二つのパケットが転送されるべき次のホップ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に到達します。うちのVPNネクストホップゲートウェイBに行くリンク3、およびVPNネクストホップゲートウェイCに行くのリンク4アウト：この着信トラフィック用の2つの発信仮想リンクがあります。
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先Y.省略記号（...）に行く、着信トラフィックが単一のVPN源Xからのものであると仮定し、図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.
二つの問題が発生します。一方が他方のVNのエンドシステム上のソースアドレス選択で、IPsecトンネル・モード・リンク上VNトラフィックの転送です。
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.
ゲートウェイA.ゲートウェイAは今の両方前方およびVPN内の次のホップゲートウェイに進捗状況を作るために、パケットを暗号化するのに必要でYは、リンク2に到着ソースXから宛先にパケットを仮定する。
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アドレスのエントリ。
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のアーキテクチャは、転送テーブルに示されている場合、どのようにトンネルモードSAを定義していません。
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.
Aは、パケットX-> Yを転送する方法を決定しようとしたときに問題が発生します。定期的なIPネットワークでは、この決定は、ネクストホップゲートウェイと関連する発信インターフェースのIPアドレスを示す宛先アドレスY、上のフォワーディングルックアップに依存します。 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.
トンネルモードSAの2つの一般的な実装のシナリオが存在する：一方はトンネルモードSAが仮想インタフェースないファイアウォールのようなパケットマッチング操作に基づいて、別のは、トンネルベースで、仮想インタフェースとしてトンネルモード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トンネルモードSAの存在は、IP転送メカニズムには見えません。ルックアップは、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.
第二のアプローチ - インターフェイスであるとトンネルモードSAを必要とする - それが実装されている方法に応じて（セクション4参照）、動的ルーティングのVPNと互換性があることができます。しかしながら、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.
第二の問題は、送信元ホストのソースアドレス選択です。アプリケーションが別のホストにトラフィックを送信すると、ホストは、送信前に、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仕様は、現在、トンネルモードSAは送信元アドレスと統合方法を定義していません選択。
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）に送信する場合、送信元アドレスは、VN内部の複数のインタフェースを有し、ホストAは、Yに送信する場合、送信元アドレスがIPアドレスである必要があり、トンネル1のXのローカルエンドの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トンネルモードのSAがインターフェイスである必要はないので、ルール（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例、ワイルドカードトンネルアドレスが設定IPsecトンネルを有するもの、特定のワイルドカードを使用して他を考えます。両方の場合において、そのソースアドレスアプリケーションは、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.
IIPtranと呼ばれる - - 上記識別される2つの問題のためこのセクションでは、ソリューションを紹介します。 IIPtranは、カプセル化されたパケットにIPsecトランスポートモードが続く（RFC [2] 2003年ごとに）転送およびソースアドレス選択をサポートIPIPトンネルインターフェースの組み合わせと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トンネルのために、ゲートウェイ自体ソースまたはシンクベースのネットワークトラフィックが場合トンネリング - それらは、ベースネットワーク内のホストとして働きます。したがって、IPsecトランスポート・モードは、[1]によれば、カプセル化されたトラフィックのために、必要でない場合、また、適切です。
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.
結果として、IPIPトンネルデバイスとのIPsecトランスポート・モードで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]一意に（別のIPパケット内のペイロードとしてIPパケットを配置する。）IPIPカプセル化を指定するが、もともとモバイルIPのために開発された仮想トポロジが必要とされたとき、それはしばしば採用されています。例としては、IPマルチキャスト、IPv6、およびモバイルIP自体として新興のプロトコルをサポートする（オーバーレイ）ネットワーク、ならびにインターネット上でプライベートネットワークを提供するシステムの仮想（X-骨[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.)
IPIPアウトバウンドパケット処理は、RFC 2003で指定された[2]、別の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パケット上のIPsecトランスポート・モードの処理に続いて最初のステップとして、このIPIP処理を実行する（図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).
IPsecトンネルモード処理の下で、IPsecヘッダは、内側IPヘッダとペイロードの内容に依存するのに対し、図2と図5との間の主な違いは、提案された解決策では、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トンネルモード処理（図2）によって生成されたVPNパケットから区別することができません。二つの方法は、相互運用、[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トンネルモード、および他の提案される機構の違いの詳細な説明は、このセクションの残りはIIPtranは、セクション2で特定された問題を解決するためのIPsecトランスポート・モードでIPIPトンネルデバイスを組み合わせた方法を説明する第4に従います。
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を説明どのIPsecトンネルモードSAブレークオーバーIP転送、トンネルモードのSAは、ネットワークインタフェースである必要はないからです。 IIPtranは、[2]仮想ネットワークのトポロジを確立するためにRFC 2003 IPIPトンネルを使用しています。 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処理を分離します。 IPsecは（正しく）ルーティングおよび転送のための内部支持を欠いているためにIPsecのIIPtranの使用は、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トンネルモードSAの、VNリンクのためのRFC 2003 IPIPトンネルデバイスを[2]を用いて、[1]もこの文脈でソースアドレス選択を解決するためにソースアドレス選択のための既存のマルチホーム・ソリューションを可能にします。 2.4節に示されるように、[1]によれば、発信パケットのIPソースアドレスは、既存の転送メカニズムによって決定順番にある発信インターフェイスによって決定されます。 IPIPトンネルはVNリンクの文脈で、所望の[1]も動作可能で指定されるように、経路およびアドレス選択（[2]のセクション3.2のように）関連するルートとの本格的なインターフェイスがあるからです。
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リンクを提供する場合の問題を説明し、そして溶液を提案しました。このセクションではIIPtranに、他の人の間で、提案の選択肢の数を紹介、およびIPsecアーキテクチャへの影響を比較して、ルーティング、およびポリシーの施行。
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-確保のVNのためのダイナミック・ルーティングのサポートを確立することを目指し、代替案の数の概要を示します。次のセクションでは、詳細にこれらの提案を比較します。
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ネゴシエーションによって生じるSAD変化に応答して、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の内部インターフェイスとトンネルの関連を含む、[2] RFC 2003 IPIPカプセル化の全体の定義を反復する必要とします。これは、インターネットのモジュラーアーキテクチャを破り、一意単一インターネット標準によって定義されるように、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仕様、特にBITS、他のIPsec設計で解決することが困難であり得る一方（バンプ・イン・スタック）の代替を増大させる必要があります。現在の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:
第二の代替は、IPsecトンネルモード処理の前に、余分な転送ルックアップの追加です。この転送ルックアップはどのルートパケットを[13]に示す「仮想インタフェース」識別子を返します。この時点でこの代替の具体的なドキュメントの欠如に起因する、[1]、二つの変種が可能と推定されているRFC 2401に保留中の更新のために提案されています：
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）上述したものに相当すると思われる、すなわち、すべてのトンネルモードSAはインターフェイスでなければならず、以下に別々に議論されていません。
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処理を防止するために、転送テーブルルックアップはSAD検索を先行しなければなりません。
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.
このアプローチは、動的ルーティングをサポートするが、SADコンテンツが経路交換に含まれているように、ルーティングメカニズムへの変更を必要とします。トランスポート層のセレクタは、このアプローチにどのような影響を与えるかは不明です。
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.
このセクションでは、IPsecのアーキテクチャ上のVN転送、または衝撃の支持体としての評価基準の数に応じて三つの異なる代替と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トンネル+転送モード）と別の1（あたり-SAインターフェイス）の両方がルーティングテーブルに参照することができる本格的なデバイスとして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アーキテクチャは、（いくつかの実装は、別の1を選択したが、それは、仕様によって規定されていない）インターフェースと同様に動作するようにトンネルモードSAを必要としないのでしかし、代替1の正確な動作を定義する現在のIPsecアーキテクチャへの拡張を必要としますトンネルモードSA。提案された解決策は、IPsecにどのような変更を必要とせず、トンネルのRFC 2003には、既にこれらの要件[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.
第三の選択動的VNルーティングをサポートしていますが、ルーティングプロトコルを変更し、作用またはSADエントリに基づいて同期させるために、ルックアップメカニズムを転送する必要があります。これは、ソフトウェアのルーティングおよびIPsecの内部にインターフェースするために、すべての参加ノードにメカニズムを転送に対する実質的な変更を必要とします。これは、現在のインターネット標準の多数の見直しが必要となります。 IPルーティングは、トランスポート層フィールドには依存性がないため、ポートセレクタを指定するトンネルモードSAは、このスキームの下で動作するかも明らかではありません。
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トンネルモードのSAをインターフェースとして表され、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ために提案転送ルックアップは、発信インターフェイスインジケータ並びにネクストホップゲートウェイのIPアドレスの両方を必要とする[1]に記載の弱いESモデルと互換性がありません。例えば、複数のトンネルは、同じ発信インターフェイス、従って同一のSADを使用することができます。フォワーディングルックアップはインタフェースのみを返します。ネクストホップゲートウェイを欠く、正しいSADエントリを決定することができません。 SADは、トンネルモードSAのカプセル化宛先IPアドレスによって索引付けされていないため、ネクストホップゲートウェイ与えられ、役に立たないであろう。
Because alternative 2 fails to support VN routing, it will not be discussed in the remainder of this section.
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ルーティングの目的のために、本格的なインターフェースとして表されるためにSAを必要とします。 SADの変化は、さらに動的これら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]のIPsecの構成要素として、インターフェースごとのSAD値を記載しています。トンネルモードSA自体がインターフェースとして働く場合、以下のように、インターフェイス単位のSADの機能を明確にする必要があります。
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が含まれている必要があります。彼らは（カプセル化ヘッダは、トンネルモードSAの一部である、トランスポートモードSAは、カプセル化を起こさない）IPカプセル化をもたらし、したがって、処理ループにつながるないため、トランスポートモードSAが、禁止されています。ダイナミックルーティングアルゴリズムは、インターフェイス単位の通信に基づいて、トポロジー情報を構築するための複数のトンネルモードSAが、禁止されています。単一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.
第二に、物理インターフェイスのみSADは、IPsecトランスポート・モードSAを含んでいてもよいです。それ以外の場合は、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インタフェースのSAD値は、トンネルモードのみSAを含ませ、かつ定期的なインターフェースのSAD値は、トランスポートモード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トンネルを使用し、トランスポートモードの処理でそれらを組み合わせたものです。トンネルモードの使用を排除することによって、それはインターフェイス単位のSAの内容に関する追加の制約の必要性を除去します。
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トンネルモードデカプセル化し、内部パケットとそれぞれのIPsecトンネルモードSAに対するそのペイロードのポリシーチェック続いて単一ステップでパケットを復号します。 IIPtranはその後RFC 2003にIPIP処理で復号化さIPIPパケットを渡し、受信パケットを復号化し、検証するためのIPsecトランスポート・モードを使用する[2]。その時点で、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.
両者の主な違いは、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処理は、SASは、後続のIPsecまたはファイアウォール処理のために、与えられたパケットにマッチしたかについての情報を保持すべきです。複雑なポリシーを受け入れるためにできるようにするには、最初のインバウンド処理中に任意の時点で保存された処理コンテキストに基づいて機械に入った時点で、元のパケットのフォーマットを再構成することが可能でなければなりません。 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ヘッダとトランスポートヘッダの内容に一致することを可能にします。 SA検索がカプセル化解除前に発生するため、既存のIPSecを使用してIIPtran、トランスポート・ヘッダーの一致をサポートすることはできません。 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ヘッダに遭遇するまで、1に達するまで。」
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のVNは、リンク層とベースの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トンネルモードのSAを介して確立された安全な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.
4ノードのノードAとVN、B、C、およびN（図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.
これらのSAの仮想ソースおよび宛先IPアドレスのセレクタはワイルドカードでない場合、この例では、Aは、BとCにIPsecトンネルモードSAを有し、SAは、動的トンネル上を通過するNからのパケットを許可するように修正される必要がありますVPNサイズが成長するにつれて、BおよびCにこれはすぐに非現実的になります。
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シナリオの大部分をサポートすることができる結果はIIPtranそのかもしれません。
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つの目的は、ポリシールーティングです。異なるSAは異なる見かけ仮想トポロジで、その結果、様々なアプリケーションに適用することができます。 IIPtranは、前方複数、並列のVN上のトラフィックを既存のポリシールーティングの実装を有することにより、よりモジュラーな方法でポリシールーティングをサポートします。ポリシーは、前者の場合のIPsecのセレクタの表現によって制限されている間IIPtranは、任意のIPベースのポリシールーティングスキームをサポートしています。
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.
インターネット鍵交換（IKE）は、[9] [10]動的かつ確実エンドシステム間のIPsecキーを交渉するためのプロトコルです。これは、2つのホストが（例えば、手動でキー付きのSAを介して）キーを交渉するためにIKEを使用せずにIPsecを使用して通信することができるという意味でのIPsecの厳密必要構成要素ではありません。その名前にもかかわらず、IKEはまた、（IPsecトンネルモードのSAが設定されている）、トンネル管理プロトコルとして作用し、ピア間のセキュリティポリシーをネゴシエート。
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トンネルを設定するセキュリティポリシーを交渉するために、まだ指定されていない第二のプロトコルのように使用し、ポリシーで使用するための鍵を交換するために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リンクの作成は以下の手順を実行できます（2）その後のトンネル管理交換を確保するために、ベースネットワーク（1）IKEネゴシエーション[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の使用を拡張して、それが期待され、既存のプロトコルを使用してVPNインフラストラクチャのセキュリティを向上させるであろう、VPNをルーティングするためのIPsecの使用を拡張することです。
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-骨とDynaBoneプロジェクト、特に（現在）グレッグフィンと（過去）エイミー・ヒューズ、スティーブ・ホッツとAnindo Banerjeaのメンバーに感謝したいと思います。
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.
著者らはまた、6月-一郎（いとぢゅん）萩野と我々の注意にこの提案のIKEの影響をもたらすだけでなく、KAMEのIPv6 / IPsecのネットワークスタックでは、この文書にメカニズムを実装するためのKAMEプロジェクトに感謝したいと思います。いくつかのIETFのWG（：スティーブン・ケント、PPVPN：特にIPsecのエリックVyncke、ポール・ナイト、モバイルIPの様々なメンバー）のメンバーは、この文書の以前のリビジョンでの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".
契約の「X-ボーン」と題された数F30602-98-1-0200と数F30602-01-2-0529の下で国防高等研究計画庁（DARPA）と空軍研究所、米空軍資材コマンド、USAF、主催の努力"DynaBone" と題します。
[1] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[1]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[2] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[2]パーキンス、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]タッチ、J.、「X-骨を使用した動的インターネットオーバーレイの展開と管理」。 36号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]タッチ、J.、王、Y.、エッゲルト、L.とG.フィン、 "仮想インターネット・アーキテクチャ"、ISIテクニカルレポートISI-TR-570、ネットワークアーキテクチャ（FDNA）2003年の今後の方向性に関するワークショップ、 2003年3月。
[5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[5]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[6]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[7] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[7]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[8] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, February 1997.
[8] Hamzeh、K.、 "アセンドトンネル管理プロトコル - ATMP"、RFC 2107、1997年2月。
[9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[9]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[10] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Work in Progress, January 2004.
[10]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）議定書"、進歩、2004年1月での作業。
[11] Kent, S., "IP Authentication Header", Work in Progress, February 2004.
[11]ケント、S.、 "IP認証ヘッダー"、進歩、2004年2月に作業。
[12] Kent, S., "IP Encapsulating Security Payload (ESP)", Work in progress, February 2004.
[12]ケント、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]モーグル、J.およびS.デアリング、 "経路MTUディスカバリ"、RFC 1191、1990年11月。
[15] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[15]レイヒー、K.、 "パスMTUディスカバリと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で指定されたIPIPカプセル化ルールとの間の不整合[1]及びモバイルIP [2]で指定されたものがあります。後者の仕様は、標準化過程で、4（タイプ4のIPパケットのペイロード）のIPプロトコル番号を一意IANAに従ってRFC 2003で指定されている[2]。 IPsecは、トランスポートモードを確保することができるIPパケットのタイプのいずれかの制限を指定していないので、IPsecトランスポートパケット内のIPIPの使用は、IPsecトンネルモードと混同することができます。
A.1. Encapsulation Issues
A.1。カプセル化の問題
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]。）これらのフィールドの中にあるときにIP DF（断片化していない）フラグです。内部パケットDFフラグがクリアされている場合、外部パケットはそれをコピーするかを設定してもよいです。内側DFフラグが設定されている場合しかし、外部ヘッダは、それをコピーしなければならない[2]。 IPsecはSAによって指定されるようにそのフラグおよび他の同様のフィールド（TOSなど）、コピークリア、または設定することができる競合ルールを定義します。
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が設定されている内側のパケットをクリア必要とする場合、それが提案されているRFC 2003の処理ルールに違反するパケットではなく、IPsecの降下[2]。同様のルールは、RFC 2003アップデートに含まれるように、TOSおよび他の同様のIPヘッダフィールドのために開発されている[2]。
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].
隠れチャネルを閉鎖するための別のアプローチは、外部ヘッダ（それはインナーヘッダに設定されているか否か）にDFフラグを設定することが常にあります。 DFフラグを設定すると、PMTU検出が正常に動作することができます。この手法の詳細は[2]に記載されています。
A.2. Decapsulation Issues
A.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.
同じキーが与えられると、IPsecトランスポートモードとIPsecトンネルモードパケットと組み合わさIPIPトンネルカプセル化によって作成されたパケットは、ワイヤ上で同一に見えます。 IPsec'edパケットはそれがIPIP内部パケットが含まれて到着したときしたがって、パケットがIPsecトンネルモードまたはIPIPカプセル化されたパケットの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.
着信パケットの処理は、SADがトンネルモードアソシエーションが適用さ、IPsecがパケットをデカプセル化しなければならないことを示す場合、プロトコルタイプ4の内側ペイロードとIPsecパケットをデカプセル化するかどうかを決定する前に、SADをチェックしなければなりません。 SADは、トランスポートモードの関連付けが適用されることを示している場合、IPsecはパケットをデカプセル化してはなりません。これは、SADは、これら2つのオプションのいずれかを示すことが必要です。ワイルドカードSADエントリは（「ANY」、または「トンネルまたはTRANSPORT」）はサポートすることができません。
A.3. ummary
A.3。概要
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.
IPIP規格にIPIPカプセル化の競合のIPsecの使用[2]。この問題は、すでに代わりのIPsec内部IPIPカプセル化の非標準準拠のバリアントを指定する、RFC 2003にアップデートで解決されています。
Authors' Addresses
著者のアドレス
Joe Touch USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 US
ジョー・タッチUSC情報科学研究所4676アドミラルティWayマリナデルレイ、CA 90292米国
Phone: +1 310 822 1511 Fax: +1 310 823 6714 EMail: touch@isi.edu URI: http://www.isi.edu/touch
電話：+1 310 822 1511ファックス：+1 310 823 6714 Eメール：touch@isi.edu URI：http://www.isi.edu/touch
Lars Eggert NEC Network Laboratories Kurfuersten-Anlage 36 Heidelberg 69115 DE
ラースEggertのNECネットワーク研究所Kurfuerstenコンディショニング36ハイデルベルクDE 69115
Phone: +49 6221 90511 43 Fax: +49 6221 90511 55 EMail: lars.eggert@netlab.nec.de URI: http://www.netlab.nec.de/
電話：+49 6221 90511 43ファックス：+49 6221 90511 55電子メール：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
ゆう旬王USC情報科学研究所4676アドミラルティWayマリナデルレイ、CA 90292米国
Phone: +1 310 822 1511 Fax: +1 310 823 6714 EMail: yushunwa@isi.edu URI: http://www.isi.edu/yushunwa
電話：+1 310 822 1511ファックス：+1 310 823 6714 Eメール：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）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。