RFC3884 日本語訳
3884 Use of IPsec Transport Mode for Dynamic Routing. J. Touch, L.Eggert, Y. Wang. September 2004. (Format: TXT=59437 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Touch
Request for Comments: 3884 ISI
Category: Informational L. Eggert
NEC
Y. Wang
ISI
September 2004
コメントを求めるワーキンググループJ.接触要求をネットワークでつないでください: 3884年のISIカテゴリ: 情報のL.のエッゲルトNEC Y.ワングISI2004年9月
Use of IPsec Transport Mode for Dynamic Routing
IPsec交通機関のダイナミックルーティングの使用
Status of this Memo
この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).
Copyright(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
IPsecは信じられたコンポーネントのコミュニケーションを保護するためにマルチホップネットワークのリンクを固定できます、例えば、安全な仮想ネットワーク(VN)、オーバレイ、または仮想私設網(VPN)のために。 IPルーティングがインタフェースの参照と次のホップIPアドレスによるので、IPsecトンネルモードで設立された仮想のリンクはVNsの中でルーティングと推進と衝突できます。 IPsecトンネルモード仕様がこの問題であいまいであるので、対応する実装さえ摩擦を避けると信じることができません。 トンネルモードへの代替手段はIPsec交通機関と共に非IPsec IPIPカプセル化を使用します。(私たちはそれをIIPtranと呼びます)。 IPIPカプセル化は別々の初期段階、VNパケットの推進ルックアップの結果として起こります。 SAがある結果として起こる(トンネルを堀られる)IPパケットがセキュリティ協会データベースを通して決定したIPsec交通機関プロセス(SAD)はトンネルヘッダーに合っています。 IIPtranはダイナミックルーティングをサポートします。
Touch, et al. Informational [Page 1] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[1ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
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の中で。 IIPtranは前述の闘争を避けるためにどうどんな対応するIPsec実装も構成するかを示します。 また、IIPtranはVNルーティングとそれらのそれぞれの影響のためにインターネット・キー・エクスチェンジ(IKE)との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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2。 歴史. . . . . . . . . . . . . . . . . . . . 3 2を記録してください。 問題記述。 . . . . . . . . . . . . . . . . . . . . . 4 2.1. IPsec概要. . . . . . . . . . . . . . . . . . . . . 5 2.2。 例. . . . . . . . . . . . . . . . . . . 6 2.3を転送します。 問題1: 問題. . . . . . . . . . . . . . 7 2.4を転送します。 問題2: ソースアドレス選択. . . . . . . . . . 8 3。 IIPtran: IPIPトンネルデバイス+IPsecはモード. . . . . 9 3.1を輸送します。 IIPtranは.103.2を詳しく述べます。 問題1を解決します: 問題. . . . . . . . . . 11 3.3を転送します。 問題2を解決します: ソースアドレス選択. . . . . . 12 4。 比較. . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1。 他の提案されたソリューション. . . . . . . . . . . . . . . . 12 4.1.1。 代替手段1: インタフェースSAsとIPsec。 . . . . 13 4.1.2. 代替手段2: 初期の推進ルックアップがあるIPsec。 . . . . . . . . . . . . . . . 13 4.1.3. 代替手段3: 統合推進. . . . . . . . . . . . . . . . . . . 14 4.2があるIPsec。 議論. . . . . . . . . . . . . . . . . . . . . . . 14 4.2.1。 VNルート設定サポートと複雑さ. . . . . . . 14 4.2.2。 IPsecアーキテクチャ. . . . . . . . 15 4.2.3で影響を与えてください。 方針実施とセレクタ. . . . . . . . 16 4.2.4。 IKEは.195に影響を与えます。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 19 6。 概要と推薦. . . . . . . . . . . . . . . . . 20 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 20 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1。 引用規格. . . . . . . . . . . . . . . . . . 20 8.2。 有益な参照. . . . . . . . . . . . . . . . . 21A.カプセル化/被膜剥離術は.22A.1を発行します。 カプセル化は.22A.2を発行します。 被膜剥離術は.23A.3を発行します。 付録概要. . . . . . . . . . . . . . . . . . . . 23作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 24の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 25
Touch, et al. Informational [Page 2] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[2ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
1. Introduction
1. 序論
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.
安全なVNを作成して、仮想ネットワーク(VN)のリンクを固定するのにIPsecを使用できます。 安全な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.
このドキュメントは、マルチホップ、分配されたVNのリンクを固定するためにIPsecの使用を扱います。 それはIPsecトンネルモードで設立された仮想のリンクがVNの中でどうルーティングと推進と衝突できるかを説明します、インタフェースと次のホップIPアドレスの参照へのIPルーティングの依存のため。
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.
このドキュメントの後のセクションはVPNsの中でダイナミックルーティングのための他の提案とIIPtranを比較します、異なった提案が総合的なIPsecアーキテクチャ、ルーティング・プロトコル、安全保障政策実施、およびインターネット・キー・エクスチェンジ(IKE)[9][10]に持っている影響力に焦点を合わせて。 付録は、IPトンネル処理がIPIPカプセル化と被膜剥離術に関連するIPsecの問題であると扱います。
This document assumes familiarity with other Internet standards [1][2], notably with terminology and numerous acronyms therein.
このドキュメントはそこに用語と多数の頭文字語で他のインターネット標準[1][2]への親しみを著しく仮定します。
1.2. Document History
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
2000年3月10日のインターネットDraftに「IPSEC交通機関の仮想ネットワークの使用」に権利を与えて、2000年3月に最初にアデレードにおける第47IETFのIPsec WGで寄贈したとき、最初に、このドキュメントを発行しました。 それは、2001年8月のロンドンにおける第51IETFのPPVPN WGと、そして、2001年12月のソルトレイクシティーにおける第52IETFのIPsec WGと、そして、両方に次に、改訂されて、提示されました。
Touch, et al. Informational [Page 3] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[3ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
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.
2002年3月のミネアポリスにおける第53IETFのIPsecとPPVPN WGs。 この草稿のバージョン04は、2002年6月に公表のためにIPsec WGによる勧めに基づくInformational RFCとして提出して、2004年6月に、バージョン07が公表のために承認されるまで、その時からのIESGレビューでありました。 その時の間、フィードバックによると、それはIPsec仕様との相互作用に関してIESGから実質的に改訂されました。(RFC2401[1])とセキュリティと互換性の問題に関する他のプロトコル。
2. Problem Description
2. 問題記述
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に参加するのを明らかに許容して、層にされたVNs(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.
VPNをもたらして、VNが、仮想のリンクが[3][4]であると機密保護するのは、役に立つ場合があります。 これは、終わりから終わりへのセキュリティに同等ではありませんが、終わりのホストが自分たちで安全なコミュニケーションをサポートしないとき、役に立つ場合があります。 それは、VPNでのルーティングを保証して、異なったVPNsのトラフィックを隔離するためにホップごとの追加レベルのネットワークセキュリティを提供できます。
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アーキテクチャとゲートウェイ[1]のそばでIPsecトンネルモード仮想のリンクから一般的に成ります。 しかしながら、IPsecトンネルモードのこの現在の必要な使用はダイナミックルーティング[3]と両立しない場合があります。
Touch, et al. Informational [Page 4] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[4ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
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輸送とトンネルモード処理のときに短い概要を提供します、従う問題シナリオの理解において、それが関連している限り。 以下のセクションは、一般的な例に基づいて詳細に問題を発送すると論じます。
2.1. IPsec Overview
2.1. 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ヘッダーの内容はセキュリティ協会データベース(SAD)でSAの場所を見つけるのにペイロード(特にトランスポート層ヘッダー)と同様にオリジナルのパケットのヘッダー(図1、矢)のコンテンツを使用する「セキュリティ協会」(SA)ルックアップの結果に基づいています。
Original Outbound Packet Outbound Packet (IPsec Transport Mode)
+-----------+---------+ +-----------+==============+---------+
| IP Header | Payload | | IP Header | IPsec Header | Payload |
+-----------+---------+ +-----------+==============+---------+
| ^
| |
+-------------+
SA Lookup
オリジナルの外国行きのパケット外国行きのパケット(IPsec交通機関)+-----------+---------+ +-----------+==============+---------+ | IPヘッダー| 有効搭載量| | IPヘッダー| IPsecヘッダー| 有効搭載量| +-----------+---------+ +-----------+==============+---------+ | ^ | | +-------------+ SAルックアップ
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ルックアップはそれを処理するIPsecがそれぞれのSAに対してパケットとそのペイロードのコンテンツをチェックした後に検証ステップがあとに続いた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 prependsが出発しているIPパケット(図2)へのIPsecヘッダーと追加IPヘッダーであるときに。 本質では、オリジナルのパケットは別のIPパケットのペイロードになります。(次に、IPsecはそれを機密保護します)。 これは、[1] 「トンネルモードSAは本質的にはIPトンネルに適用された[交通機関]SAである」ので説明されます。 しかしながら、2つの間には、著しい違いがこのセクションの残りで説明されるようにあります。
Touch, et al. Informational [Page 5] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[5ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
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がまた、オリジナルの外国行きのパケットのヘッダーとそのペイロード(図2、矢)に基づいている外トンネルIPヘッダーのために演説するソースと目的地を含んでいて。
Outbound Packet (IPsec Tunnel Mode)
+==================+==============+-----------------+---------+
| Tunnel IP Header | IPsec Header | Orig. IP Header | Payload |
+==================+==============+-----------------+---------+
^ ^ | |
| | | |
| +--------------+ |
| SA Lookup |
| |
+---------------------------------+
IP Encapsulation
外国行きのパケット(IPsecトンネル・モード)+==================+==============+-----------------+---------+ | トンネルIPヘッダー| IPsecヘッダー| Orig。 IPヘッダー| 有効搭載量| +==================+==============+-----------------+---------+ ^ ^ | | | | | | | +--------------+ | | SAルックアップ| | | +---------------------------------+ IPカプセル化
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に対して解読されるか、または認証されます。
2.2. Forwarding Example
2.2. 推進の例
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.
仮想のリンクがIPsecトンネルモードSAsによって設立されている状態で、VPNトポロジーを考えてください、[1]への承諾に必要であるように。 レガシーエンドシステムが自分たちで終わりから終わりへの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.)
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個の出発している仮想のリンクがあります: VPN次のホップゲートウェイBへの3の行くのは外にリンクします、そして、VPN次のホップゲートウェイCへの4の行くのは外にリンクします。
Touch, et al. Informational [Page 6] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[6ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
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から来ていると仮定してください。Ellipses(…)は図3の複数の仮想のリンクを表します。
B ---...---
/ \
/ 3 \
/ \
X ---...--- A D ---...--- Y
1 2 \ /
\ 4 /
\ /
C ---...---
B---...--- /\/3\/円のX---...--- D---...--- 4/\/C Y1 2円/円---...---
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トラフィックの推進である、もう片方がVNエンドシステムにおけるソースアドレス選択です。
2.3. Problem 1: Forwarding Issues
2.3. 問題1: 推進問題
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までのパケットがゲートウェイAが現在ともに進める必要があるゲートウェイA.でリンク2の上に到着すると仮定してください、そして、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アドレスを写像します。
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.
AがパケットX>Yを進める方法を決めようとするとき、問題は起こります。 通常のIPネットワークでは、この決定は次のホップゲートウェイのIPアドレスと関連外国行きのインタフェースを示す送付先アドレスYに関する推進ルックアップによります。 VNの場合では、推進ルックアップは仮想の送付先アドレスに起こります。 そのような仮想の送付先アドレスの推進ルックアップが成功するように、仮想インターフェース(トンネル)を通したルートは推進テーブルに存在しなければなりません。
Touch, et al. Informational [Page 7] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[7ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
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つの一般的な実装シナリオがあります: トンネルモードSAsが仮想インターフェースでなく、別のものがトンネルベースであり、トンネルモードSAを仮想インターフェースとして扱うところで1つはファイアウォールのようなパケット合っている操作に基づいています。 現在のIPsecアーキテクチャは1かもう片方を強制しません。
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推進メカニズムに目に見えません。 ルックアップは、テーブルを進めながら、既存のIPからSAルックアッププロセス、伝統的なIP推進ルックアップよりファイアウォールに厳密なマッチング、および独立者に合っている規則を使用します。 SAルックアップは、パケットがどの仮想のリンクに送られるかを決定します、トンネルモードSAがカプセル化情報を含んでいるので。 このルックアップとその後のトンネルモード処理はともに既存のIP推進テーブルのコンテンツを無視します、静電気かダイナミックルーティングが使用されているか否かに関係なく。 その結果、このタイプのトンネルモード処理はダイナミックに発送されたVPNsと両立しないです。
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の仕様対応することの実装と互換性があることの追加利益があります。
2.4. Problem 2: Source Address Selection
2.4. 問題2: ソースアドレス選択
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に関連づけられます(以上はそれであるなら少なくとも2VNsに接続します。)。 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のトンネル1の地方の端のIPアドレスであるに違いありません。 ホストA(VNの中に複数のインタフェースを持っています)がYに発信するなら、ソースアドレスはトンネル3か4の地方の端のIPアドレスであるに違いありません。
Touch, et al. Informational [Page 8] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[8ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
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アドレスに付いて、ホストは代わりにそれらのトラフィック[7]のための1つを選ぶことができません。 ソースアドレス選択のための大いにインタフェースとルートの概念による規則。
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つのケース、IPsecトンネルがワイルドカードトンネルアドレスなしで構成されていることの1つが他の使用のあるワイルドカードであると考えてください。 どちらの場合も、ソースアドレスがRFC1122[7]規則で設定されるアプリケーションはそのホストのベースネットワーク(デフォルトルートを通した)のソースアドレスと(例えば、)遠く離れたトンネル終点の送付先アドレスがあるパケットを送るかもしれません。
3. IIPtran: IPIP Tunnel Devices + IPsec Transport Mode
3. IIPtran: IPIPトンネルデバイス+IPsec交通機関
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トンネルのインタフェースの組み合わせに取り替えます。(カプセル化されたパケットのIPsec交通機関があとに続いたRFC2003[2])に従って。
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トンネルモード(前者のためのホスト間通信、および後者のためのすべてのトランジットコミュニケーション)の適切な使用を定義します。 トランジットコミュニケーションにIPsec交通機関を使用するので、IIPtranは、この要件に違反するように見えます。
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交通機関も適切です。
Touch, et al. Informational [Page 9] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[9ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
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がどう上で特定されたそれぞれのその問題を訴えるかを論ずるでしょう。
3.1. IIPtran Details
3.1. IIPtranの詳細
IIPtran uses IPIP tunnels (as defined in RFC 2003 [2]), followed by IPsec transport mode on the encapsulated packet.
IIPtranはIPIPトンネルを使用します。(カプセル化されたパケットのIPsec交通機関があとに続いたRFC2003[2])で定義されるように。
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).
RFC2003[2]は唯一IPIPカプセル化を指定します(ペイロードとして別のIPパケットにIPパケットを置きます。)。 仮想のtopologiesが必要であったときに、元々MobileIPのために開発されていて、それはしばしば採用されました。 例はサポートするIP Multicastや、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.)
別のIPヘッダーと共にそれをprependingすることによって、RFC2003[2]によって指定されるIPIPの外国行きのパケット処理は既存のIPパケットにトンネルを堀ります。(図4。)
Outbound Packet (IPIP Tunnel)
+==================+-----------------+---------+
| Tunnel IP Header | Orig. IP Header | Payload |
+==================+-----------------+---------+
^ |
| |
+------------------+
IPIP Encapsulation
外国行きのパケット(IPIPはトンネルを堀る)+==================+-----------------+---------+ | トンネルIPヘッダー| Orig。 IPヘッダー| 有効搭載量| +==================+-----------------+---------+ ^ | | | +------------------+ IPIPカプセル化
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。)
Touch, et al. Informational [Page 10] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[10ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
Outbound Packet (IPIP Tunnel + IPsec Transport Mode)
+==================+==============+-----------------+---------+
| Tunnel IP Header | IPsec Header | Orig. IP Header | Payload |
+==================+==============+-----------------+---------+
^ | ^ |
| | | |
| +---------------+ |
| SA Lookup |
| |
+----------------------------------+
IPIP Encapsulation
外国行きのパケット(IPIPトンネル+IPsec交通機関)+==================+==============+-----------------+---------+ | トンネルIPヘッダー| IPsecヘッダー| Orig。 IPヘッダー| 有効搭載量| +==================+==============+-----------------+---------+ ^ | ^ | | | | | | +---------------+ | | SAルックアップ| | | +----------------------------------+ IPIPカプセル化
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トンネルモード処理でよりますが(セクション2.1を見てください)、提案されたソリューションでは、IPsecヘッダーが外側のIPヘッダーに基づいているということです。
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].
しかしながら、IPsecトンネルモード処理(図2)で生成されたVPNパケットとワイヤの上の結果として起こるVPNパケット(図5)を区別できません。 そして、両端[3]での適切な構成を考えて、2つのメソッドが共同利用します。
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がセクション2で特定された問題を解決するためにどうIPIPトンネルデバイスを結合するかをIPsec交通機関に説明するでしょう。
3.2. Solving Problem 1: Forwarding Issues
3.2. 問題1を解決します: 推進問題
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トンネルモードの上でSAsを進めるIPがどう壊れるかを説明しました、トンネルモードSAsがネットワーク・インターフェースであることが必要でないので。 IIPtranは、仮想ネットワークのトポロジーを証明するのにRFC2003IPIPトンネル[2]を使用します。 RFC2003[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.
RFC2003[2]は、2個のIPヘッダーの間にIPsecヘッダーを挿入する問題がIPIPカプセル化の結果であると扱いました。 IIPtranはこの構成で詳細を提供して、仮想ネットワークでそれがどうダイナミックルーティングを可能にするかを示します。
Touch, et al. Informational [Page 11] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[11ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
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.
RFC2003IPIPトンネル[2]が既に静電気かダイナミックルーティングをサポートすることができる完全な仮想ネットワークを提供することに注意するのは重要です。 IPIPがトンネルを堀る使用の提案されたソリューションはルーティングと推進からIPsec処理のIPsec交通機関で衝撃を吸収します。 IPsecのIIPtranの使用はVNのリンクを固定するのに制限されます(VPNを作成して)、IPsecが(正しく)ルーティングと推進の内部のサポートを欠いているので。
3.3. Solving Problem 2: Source Address Selection
3.3. 問題2を解決します: ソースアドレス選択
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.
VNリンクへのデバイス[2]がIPsecトンネルモードSAsの代わりに許容するRFC2003IPIPトンネルを使用して、ソースへの既存のマルチホーミング解決は、このような関係においてはまた、ソースアドレス選択を解決するために選択[1]を扱います。 セクション2.4にみられるように、[1]によると、外国行きのパケットのIPソースアドレスは外国行きのインタフェースのそばで決定しています。(順番に、インタフェースは、メカニズムを進めながら存在することによって、決定します)。 関連ルートでIPIPがトンネルを堀るのが、完全なインタフェースの理由です。(また、[2])のセクション3.2のように、[1]のルートと指定されるとしてのアドレス選択はVNリンクの文脈で望まれているように作動できます。
4. Comparison
4. 比較
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と特に多くの提案された選択肢を導入して、それらの効果を比較します。
4.1. Other Proposed Solutions
4.1. 他の提案されたソリューション
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アーキテクチャをかなり簡素化して、modularizesします。
Touch, et al. Informational [Page 12] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[12ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
4.1.1. Alternative 1: IPsec with Interface SAs
4.1.1. 代替手段1: インタフェースSAsと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はダイナミックにSAD変化であって、例えば、引き起こされることに対応した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.
このアプローチは、ダイナミックルーティングと既存のソースアドレスが選択規則であるとサポートしますが、IPsecアーキテクチャへのトンネルのモードSAインタフェースとそれらの関連管理手順を定義する拡大を必要とします。
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]).
それは、RFC2003IPIPカプセル化[2]の全体の定義について摘記するのを必要とするでしょう、インタフェースがあるトンネルの協会を含んでいて、IPsecの中で。 ただ一つのインターネット標準によって唯一定義されるとして、これは、IPパケットでインターネットのモジュールのアーキテクチャを破って、タイプ4IPの仕様に違反します。([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、(中で突き当たる、-、-、スタック) 代替です。 現在のIPsec仕様は、あいまいであり、この実装を許容しますが、実装の独立しているデザインは望ましいです。
4.1.2. Alternative 2: IPsec with Initial Forwarding Lookup
4.1.2. 代替手段2: 初期の推進ルックアップがある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がモード処理にトンネルを堀る前に2番目の代替手段は付加的な推進ルックアップの追加です。 この推進ルックアップは「仮想インターフェース」識別子を返すでしょう。(それは、パケット[13]を発送する方法を示します)。 今回のRFC2401[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についてインタフェースでなければならなく、別々に以下で議論しません。
Touch, et al. Informational [Page 13] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[13ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
4.1.3. Alternative 3: IPsec with Integrated Forwarding
4.1.3. 代替手段3: 統合推進があるIPsec
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番目の代替手段で、ルーティング・プロトコルと推進メカニズムは、推進を決定にするように経路指定テーブルとSADsの両方に相談するように変更されます。 索表を進めて、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内容はルート交換に含まれています。 トランスポート層セレクタがどのようにこのアプローチに影響するかは、不明瞭です。
4.2. Discussion
4.2. 議論
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.
このセクションが3つの異なった選択肢を比較して、VNのサポートなどの多くの評価基準に従ったIIPtranはIPsecアーキテクチャで進めるか、または影響を与えます。
4.2.1. VN Routing Support and Complexity
4.2.1. VNルート設定サポートと複雑さ
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アーキテクチャが、トンネルモードSAsが同様にインタフェースに振る舞うのを必要としないので(いくらかのimplementersが代替の1を選びましたが、それは仕様で強制されません)、代替の1は現在のIPsecアーキテクチャへのトンネルモードSAsの正確な動きを定義する拡大を必要とします。 提案されたソリューションがIPsecと、そして、トンネルに少しのそのような変化も必要としないので、RFC2003は既にそれらの要件[2]を指定します。 その上、それらの要件の追加は、余分であり、潜在的にRFC2003[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
代替手段3は、ダイナミックなVNがルーティングであるとサポートしますが、ルーティング・プロトコルを変更して、SADエントリーに基づいて行動するか、または連動するようにルックアップメカニズムを進めるのを必要とします。 これはIPsecのインターナルに連結するようにすべて参加しているノードでルーティングソフトウェアと推進メカニズムへの大きな変化を必要とします。 これは、多くの現在のインターネット標準を改訂するのを必要とするでしょう。 また、それはそうです。
Touch, et al. Informational [Page 14] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[14ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
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.
トランスポート層フィールドに関して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処理の前の追加推進ルックアップは無関係です、IPsecトンネルモードSAsがインタフェースとして表されないで、その結果、IPルーティング・プロトコルに目に見えません。
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モデルと互換性がありません。[1]は外国行きのインタフェースインディケータと次のホップゲートウェイのIPアドレスの両方を必要とします。 例えば、複数のトンネルが同じ外向的なインタフェースとその結果同じ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がルーティングであるとサポートしないので、このセクションの残りでそれについて議論しないでしょう。
4.2.2. Impact on the IPsec Architecture
4.2.2. IPsecアーキテクチャで影響を与えてください。
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がルーティングの目的のための完全なインタフェースとして表されるのを必要とします。 その上、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:
さらに、RFC2401[1]は1インタフェースあたりのSADsをIPsecの部品として記述します。 トンネルモードSAs自身がインタフェースとして機能するとき、1インタフェースあたりの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
まず最初に、それぞれのトンネルインタフェースSADはちょうど1IPsecのトンネルモードSAを含まなければなりません。 交通機関SAsは禁止されています、彼らがIPカプセル化(カプセル化ヘッダーはトンネルモードSAの一部です、SAがカプセル化を引き起こさない交通機関)をもたらして、その結果、したがって、処理ループに通じないでしょう。 複数のトンネルモードSAsが禁止されている、ダイナミックルーティングアルゴリズムは組み立てます。
Touch, et al. Informational [Page 15] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[15ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
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.
トポロジー情報は1インタフェースあたりのコミュニケーションを基礎づけました。 異なった仮想のリンク(トンネル)を単一のSAインタフェースに合併すると、ルーティングイベントは、SAインタフェースを共有しながら、不当に他のリンクに付ける1個の仮想のリンクで引き起こされる場合があります。
Second, only the SAD of physical interfaces may contain IPsec transport mode SAs; otherwise, the current issues with VN routing remain unsolved.
2番目に、物理インターフェースのSADだけが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インタフェースのSADsは、交通機関だけSAsを含むようにトンネルモードだけSAs、および通常のインタフェースのSADsを含みます。 したがって、トンネルカプセル化は本質的には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トンネルを使用して、交通機関処理にそれらを結合します。 トンネルモードの使用を排除することによって、それは1インタフェースあたりのSAsのコンテンツで追加規制の必要性を取り除きます。
4.2.3. Policy Enforcement and Selectors
4.2.3. 方針実施とセレクタ
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に対してあとに続いたシングルステップでモードdecapsulatesにトンネルを堀って、パケットを解読します。 IIPtranは入って来るパケットを解読して、確かめるのにIPsec交通機関を使用して、次に、RFC2003IPIP処理[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がdecapsulatedパケットの上で追加処理を必要とする、自己のそれぞれの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
IPsecアーキテクチャドキュメント[1]のセクション5.2に述べられるように、IPsec処理はSAsが何に関して与えられたパケットに合っていたかという情報を保有するべきです、その後のIPsecかファイアウォール処理のために。 最初にいつでも本国行きの間に保存している処理文脈に基づいたマシンを入れたとき、複合体を考慮するのは方針を受け入れて、オリジナルのパケットの形式を再建するのは可能であるべきです。
Touch, et al. Informational [Page 16] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[16ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
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交通機関にもかかわらず、IPIP被膜剥離術に続く別々のステップとして固定された特定のIPIPトンネルの上で到着した場合にだけ、IIPtranは入って来るVNパケットを受け入れます。
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]であることに注意してください。 実験はこの相互運用性について確かめて、考えて、ワイヤの上の結果として起こるパケットの違いが全くないので、著しく、キーを当ててください。
4.2.3.1. Selector Expressiveness
4.2.3.1. セレクタ表情の豊かさ
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."
RFC2401[1]は、輸送が入れ子にされた数個がヘッダーであったかもしれないならヘッダーをパケットの中で深く層にすると明らかに認めて、システムが「トランスポート・プロトコルとして認識するどちらかに遭遇するか、拡張ヘッダーのリストにないものに達する、またはトランスポート・プロトコルを不透明に表す超能力ヘッダーに遭遇するまで'プロトコル'か'次のHeader'分野をチェックするパケットのヘッダーを通して鎖を作ること」を(引用します)許容します。
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ヘッダーのコンテンツでセレクタを合わせさせます。 したがって、従来のIPsecがモードにトンネルを堀るとき、IIPtranの下の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の現在の使用と一致しています。 次のセクションはそのセレクタについて論じます。仮想ネットワークの役に立たないかもしれません。
Touch, et al. Informational [Page 17] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[17ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
4.2.3.2. Role of Selectors for VPNs
4.2.3.2. VPNsのためのセレクタの役割
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のダイナミックルーティングをサポートするためにwildcardedされる必要があります。 その結果、.1(提案された拡大のない)が重要なコネがVNシナリオであったならそうしないかもしれない制限説明されたコネ4.2.3。
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、B、C、およびN(図6)があるVNであると考えてください。 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に持っています、そして、仮想のソースと目的地IPへのセレクタがそれらのSAsのために扱うC.Ifはワイルドカードではありません、そして、SAは、NからのパケットがトンネルをBに通り過ぎるのを許容するようにダイナミックに変更される必要があります、そして、VPNサイズは非実用的になりますが、C.Thisは急速になります。
B
/
/
/
N ------ A
\
\
\
C
B///N------ \\\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セレクタの完全な表情の豊かさをサポートする拡大のないIIPtranがまだ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つの目的は方針ルーティングです。 異なった見かけの仮想のtopologiesをもたらして、異なったSAsは異なったアプリケーションに適用できます。 IIPtranは複数の、そして、平行なVNsの上で既存の方針ルーティング実装を持っているのによる、よりモジュールの方法で方針ルーティングに前進のトラフィックをサポートします。 IIPtranは、任意のIPベースの方針ルーティングが体系であるとサポートします、方針がIPsecのセレクタの表情の豊かさによって前の場合が制限されますが。
Touch, et al. Informational [Page 18] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[18ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
4.2.4. IKE Impact
4.2.4. IKE影響
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キーを交渉するプロトコルです。 キー(例えば手動で合わせられたSAsを通して)を交渉するのは、2人のホストがIKEを使用していなくてIPsecを使用することで交信できるという意味におけるIPsecの厳密に必要な部品ではありません。 名前にもかかわらず、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 modularizes IPsecと同様であるか。インターネット標準。 例えば、VPNリンク作成はこれらの方法に従うかもしれません: (1) (3) 確立したトンネルの上のIKE交換があとに続いた、安全なVPNリンクを作成したベースネットワークで(2) その後のトンネルが管理交換[8]であると機密保護するベースネットワークにおけるIKE交渉。
5. Security Considerations
5. セキュリティ問題
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を発送して、既存のプロトコルを使用することでVPNインフラストラクチャのセキュリティを増強するためにそれが望まれているIPsecの使用を広げることです。
Touch, et al. Informational [Page 19] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[19ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
6. Summary and Recommendations
6. 概要と推薦
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(既存の標準のIPIPカプセル化に伴うIPsec(すなわち、交通機関)の部分集合の合成物)が、より簡単で、かつモジュールである共同利用できて、規格を従わせる同等物をもたらすのがわかります。
7. Acknowledgments
7. 承認
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.
作者はこのドキュメント、著しく(現在)のグレッグフィンランド人、(過去)のエイミー・ヒューズ、スティーブHotz、およびAnindoバネルジーの後ろでUSC/ISIで考えへの彼らの貢献についてX-骨と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.
また、作者は本書ではKAME IPv6/IPsecネットワークスタックでメカニズムを実装することと同様に私たちの留意への6月-ichiro(itojun)Haginoとこの提案の含意をIKEにもたらすためのKAMEプロジェクトに感謝したがっています。 数個のIETF WGs(特にIPsec: スティーブン・ケント、PPVPN: エリックVyncke、ポール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)と空軍研究所によって後援された取り組み、空軍Materiel Command、協定番号F30602-98-1-0200の下におけるUSAFは「X骨」と数に"DynaBone"の権利を与えられたF30602-01-2-0529の権利を与えました。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[1] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[2] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[2] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、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-骨を使用することで展開と管理をかぶせた」コンピュータNetworks Vol.36、No.2-3、2001年7月。
Touch, et al. Informational [Page 20] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[20ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
[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] ネットワークアーキテクチャ(FDNA)2003(2003年3月)の接触とJ.とワングとY.とエッゲルトとL.とG.フィンランド人、「仮想のインターネットアーキテクチャ」、ISI技術報告書ISI-TR-570、将来の方向に関するワークショップ。
[5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[5] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[6] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[7] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[7] ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[8] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC
2107, February 1997.
[8]Hamzeh、K.、「トンネル管理プロトコルを昇ってください--ATMP」、RFC2107、2月1997日
8.2. Informative References
8.2. 有益な参照
[9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[9] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 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」、進行中のWork、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探索」、RFC1191、1990年11月。
[15] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923,
September 2000.
[15]レーヒー、K.、「経路MTU発見に関するTCP問題」、RFC2923、2000年9月。
Touch, et al. Informational [Page 21] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[21ページ]のRFC3884IPsecは2004年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]によって指定されたものの間には、矛盾があります。 後者の仕様は標準化過程です、そして、IANA[2]によると、4(タイプ4のIPパケットのペイロード)のIPプロトコル番号はRFC2003によって唯一指定されます。 IPsec輸送パケットの中のIPIPの使用はIPsecトンネルモードに混乱できます、IPsecが交通機関が機密保護することができるIPパケットのタイプにおけるどんな限界も指定しないので。
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仕様は、安定を得るためにそのような分野を制御しなければならないのを示します。 さもなければ、そのような分野は内側のパケットのヘッダーと外側のパケットのヘッダーの間にひそかなチャンネルを供給するかもしれません。 しかしながら、内側のものがMTU発見「ブラックホール」[14][15]を防ぐように設定されるとき、RFC2003[2]は、外側の分野がクリアされないのを必要とします。
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がRFC2003処理規則[2]に違反するよりむしろそのパケットを下げるよう提案されます。 同様の規則は、RFC2003[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].
いつもDFが外側のヘッダーで旗を揚げさせるセットにはひそかなチャンネルを閉じることへの別のアプローチがあります(それが内側のヘッダーに設定されるか否かに関係なく)。 DF旗を設定するのに、通常、PMTU発見は作動します。 [2]でこのアプローチの詳細について議論します。
Touch, et al. Informational [Page 22] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[22ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
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交通機関に結合されたIPIPトンネルカプセル化によって作成されたパケットとIPsecトンネルモードパケットはワイヤで同じに見えます。 IPIPの内側のパケットを含むIPsec'edパケットが到着するとき、したがって、パケットがパケットであるとカプセル化されたIPIPのIPsecトンネルモードかIPsec交通機関を使用することで作成されたか否かに関係なく、区別するのは可能ではありません。 どちらの場合も、外側のヘッダーのプロトコル分野はIPsec(AHか超能力)です、そして、内側のデータのための「次のヘッダー」分野は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.
入って来るパケット処理はdecapsulate IPsecに、プロトコルの内側のペイロードがあるパケットが4をタイプするかどうか決定する前に、SADをチェックしなければなりません。 SADが、トンネルモード協会が適用されるのを示すなら、IPsecはパケットをdecapsulateしなければなりません。 SADが、交通機関協会が適用されるのを示すなら、IPsecはパケットをdecapsulateしてはいけません。 これは、SADがこれらの2つのオプションの1つを示すのを必要とします。 ワイルドカードSADエントリー(「いずれも」、または「トンネルか輸送」)をサポートすることができません。
A.3. Appendix Summary
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カプセル化のIPsecの使用はIPIP規格[2]と衝突します。 この問題はアップデートで既にRFC2003に解決されています、IPsecの中でIPIPカプセル化の標準的でない従っている異形を指定することの代わりに。
Touch, et al. Informational [Page 23] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[23ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
Authors' Addresses
作者のアドレス
Joe Touch USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 US
ジョーTouch USC情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア90292米国
Phone: +1 310 822 1511 Fax: +1 310 823 6714 EMail: touch@isi.edu URI: http://www.isi.edu/touch
以下に電話をしてください。 +1 310 822、1511Fax: +1 6714年の310 823メール: touch@isi.edu ユリ: http://www.isi.edu/touch
Lars Eggert NEC Network Laboratories Kurfuersten-Anlage 36 Heidelberg 69115 DE
ラースエッゲルトNECネットワーク研究所Kurfuersten-原基36ハイデルベルグ69115DE
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、Fax: +49 6221 90511 55はメールされます: lars.eggert@netlab.nec.de ユリ: http://www.netlab.nec.de/
Yu-Shun Wang USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 US
米国でワングUSC情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 90292をユーと同じくらい避けてください。
Phone: +1 310 822 1511 Fax: +1 310 823 6714 EMail: yushunwa@isi.edu URI: http://www.isi.edu/yushunwa
以下に電話をしてください。 +1 310 822、1511Fax: +1 6714年の310 823メール: yushunwa@isi.edu ユリ: http://www.isi.edu/yushunwa
Touch, et al. Informational [Page 24] RFC 3884 IPsec Transport Mode for Dynamic Routing September 2004
接触、他 情報[24ページ]のRFC3884IPsecは2004年9月にダイナミックルーティングのためにモードを輸送します。
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Touch, et al. Informational [Page 25]
接触、他 情報[25ページ]
一覧
スポンサーリンク
