RFC4093 日本語訳
4093 Problem Statement: Mobile IPv4 Traversal of Virtual PrivateNetwork (VPN) Gateways. F. Adrangi, Ed., H. Levkowetz, Ed.. August 2005. (Format: TXT=44082 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Adrangi, Ed.
Request for Comments: 4093 Intel
Category: Informational H. Levkowetz, Ed.
Ericsson
August 2005
ワーキンググループF.Adrangi、エドをネットワークでつないでください。コメントのために以下を要求してください。 4093年のインテルカテゴリ: エド情報のH.Levkowetz、エリクソン2005年8月
Problem Statement: Mobile IPv4 Traversal of
Virtual Private Network (VPN) Gateways
問題声明: 仮想私設網(VPN)ゲートウェイのモバイルIPv4縦断
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 (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
Deploying Mobile-IP v4 in networks that are connected to the Internet through a Virtual Private Network (VPN) gateway presents some problems that do not currently have well-described solutions. This document aims to describe and illustrate these problems, and to propose some guidelines for possible solutions.
Network(VPN)ゲートウェイが提示するVirtual兵士を通してインターネットに接続されるネットワークでモバイルIPがv4であると配布して、現在でないときにするいくつかの問題がソリューションについてよく説明しました。 このドキュメントは、これらの問題を説明して、例証して、可能なソリューションのためのいくつかのガイドラインを提案することを目指します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Overview of the Problem ....................................3
1.2. Specification of Requirements ..............................3
1.3. Terminology ................................................3
2. MIP and VPN Deployment Scenarios ................................4
2.1. MIPv4 HA(s) Inside the Intranet behind a VPN Gateway .......5
2.2. VPN Gateway and MIPv4 HA(s) on the VPN Domain Border .......6
2.3. Combined VPN Gateway and MIPv4 HA ..........................7
2.4. MIPv4 HA(s) Outside the VPN Domain .........................8
2.5. Combined VPN Gateway and MIPv4 HA(s) on the Local Link .....9
3. Deployment Scenarios Selection ..................................9
4. Problem Statement ..............................................10
4.1. Registering in Co-Located Mode ............................11
4.2. Registering via an FA .....................................12
4.3. Summary: MIP Incompatibilities with IPsec-Based
VPN Gateways ..............................................13
1. 序論…2 1.1. 問題の概要…3 1.2. 要件の仕様…3 1.3. 用語…3 2. MIPとVPN展開シナリオ…4 2.1. MIPv4、ハ、VPNゲートウェイの後ろのイントラネットにおける(s)…5 2.2. VPNゲートウェイとMIPv4、ハ、VPNドメイン境界の(s)…6 2.3. 結合したVPNゲートウェイとMIPv4、ハ…7 2.4. MIPv4、ハ、VPNドメインの外の(s)…8 2.5. 結合したVPNゲートウェイとMIPv4、ハ、地方のリンクの(s)…9 3. 展開シナリオ選択…9 4. 問題声明…10 4.1. 共同見つけられたモードで、登録します…11 4.2. FAを通して、登録します…12 4.3. 概要: IPsecベースのVPNゲートウェイがあるMIP非互換性…13
Adrangi & Levkowetz Informational [Page 1] RFC 4093 MIPv4 VPN Traversal Problem Statement August 2005
[1ページ]RFC4093MIPv4 VPN縦断問題声明2005年8月の情報のAdrangi&Levkowetz
5. Solution Guidelines ............................................14
5.1. Preservation of Existing VPN Infrastructure ...............14
5.2. Software Upgrades to Existing VPN Client and Gateways .....14
5.3. IPsec Protocol ............................................14
5.4. Multi-Vendor Interoperability .............................14
5.5. MIPv4 Protocol ............................................15
5.6. Handoff Overhead ..........................................15
5.7. Scalability, Availability, Reliability, and Performance ...15
5.8. Functional Entities .......................................15
5.9. Implications of Intervening NAT Gateways ..................15
5.10. Security Requirements ....................................16
6. Security Considerations ........................................16
7. Acknowledgements ...............................................16
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................17
5. ソリューションガイドライン…14 5.1. 既存のVPNインフラストラクチャの保存…14 5.2. ソフトウェアは既存のVPNクライアントとゲートウェイにアップグレードします…14 5.3. IPsecは議定書を作ります…14 5.4. マルチベンダ相互運用性…14 5.5. MIPv4は議定書を作ります…15 5.6. 移管オーバーヘッド…15 5.7. スケーラビリティ、有用性、信頼性、およびパフォーマンス…15 5.8. 機能的な実体…15 5.9. 介入しているNATゲートウェイの含意…15 5.10. セキュリティ要件…16 6. セキュリティ問題…16 7. 承認…16 8. 参照…17 8.1. 標準の参照…17 8.2. 有益な参照…17
1. Introduction
1. 序論
Mobile IP [RFC3344] agents are being deployed in enterprise networks
to enable mobility across wired and wireless LANs while roaming
inside the enterprise Intranet. With the growing deployment of IEEE
802.11 access points ("hot spots") in public places such as hotels,
airports, and convention centers, and with wireless WAN data networks
such as General Packet Radio Service (GPRS), the need is increasing
for enabling mobile users to maintain their transport connections and
constant reachability while connecting back to their target "home"
networks protected by Virtual Private Network (VPN) technology. This
implies that Mobile IP and VPN technologies have to coexist and
function together in order to provide mobility and security to the
enterprise mobile users.
モバイルIP[RFC3344]エージェントは、企業イントラネットで移動している間、ワイヤードでワイヤレスのLANの向こう側に移動性を可能にするために企業網で配布されています。 IEEE802.11の増加している展開に、アクセスポイント(「ホットスポット」)はホテル、空港、およびコンベンションセンターとして公然とそのようなものを置きます、そして、汎用パケット無線システム(GPRS)などのワイヤレスのWANデータ網で、必要性は、Virtual兵士のNetwork(VPN)技術で保護された彼らの目標「ホーム」ネットワークに接続して戻っている間、モバイルユーザが彼らの輸送の接続と一定の可到達性を維持するのを可能にするために大きくなっています。 これはモバイルIPとVPN技術が企業のモバイルユーザに移動性とセキュリティを提供するために共存していて、一緒に機能しなければならないのを含意します。
The goal of this document is to:
このドキュメントの目標は以下のことのためのことです。
o Identify and describe practical deployment scenarios for Mobile IP
and VPN in enterprise and operator environments.
o 企業におけるモバイルIPとVPNとオペレータ環境のために実用的な展開シナリオを特定して、説明してください。
o Identify example usage scenarios for remote users roaming outside
the "home" network protected by a VPN gateway.
o リモート・ユーザーローミングのためにVPNゲートウェイによって保護された「ホーム」ネットワークの外で例の用法シナリオを特定してください。
o Articulate the problems resulting from Mobile IP and VPN
coexistence.
o モバイルIPとVPN共存から生じることにおける問題について明確に話してください。
o Specify a set of framework guidelines to evaluate proposed
solutions for supporting multi-vendor seamless IPv4 mobility
across IPsec-based VPN gateways.
o 1セットのフレームワークガイドラインを指定して、IPsecベースのVPNゲートウェイの向こう側にマルチベンダのシームレスのIPv4が移動性であるとサポートするために提案されたソリューションを評価してください。
Adrangi & Levkowetz Informational [Page 2] RFC 4093 MIPv4 VPN Traversal Problem Statement August 2005
[2ページ]RFC4093MIPv4 VPN縦断問題声明2005年8月の情報のAdrangi&Levkowetz
1.1. Overview of the Problem
1.1. 問題の概要
Access to the Intranet is typically guarded by both a firewall and a VPN device. The Intranet can only be accessed by respecting the security policies in the firewall and the VPN device.
イントラネットへのアクセスはファイアウォールとVPNデバイスの両方で通常用心深いです。 ファイアウォールとVPNデバイスで安全保障政策を尊敬することによって、イントラネットにアクセスできるだけです。
When MIP is deployed in a corporate Intranet (also referred to as a VPN domain), roaming between the Intranet (i.e., trusted domain) and the Internet (i.e., untrusted domain) becomes problematic. It would be desirable to have seamless session mobility between the two domains, because MIP was designed for session mobility regardless of the network point of attachment. Unfortunately, the current MIP standards fall short of this promise for an important customer segment: corporate users (using VPN for remote access) who desire to add mobility support because of a need to have continuous access to Intranet resources while roaming outside the Intranet from one subnet to another, or between the VPN domain and the Internet.
MIPが法人のイントラネット(また、VPNドメインと呼ばれる)で配布されるとき、イントラネット(すなわち、ドメインを信じる)とインターネット(すなわち、信頼されていないドメイン)の間を移動するのは問題が多くなります。 2つのドメインの間にシームレスのセッションの移動性を持っているのは望ましいでしょう、MIPがネットワーク接着点にかかわらずセッションの移動性のために設計されたので。 残念ながら、現在のMIP規格は重要な顧客層のためにこの約束より下回っています: 1つのサブネットから別のサブネットまでのイントラネットの外、または、VPNドメインとインターネットの間を移動している間にイントラネットリソースに連続したアクセスを持つ必要性のために移動性サポートを加えることを望んでいる企業ユーザー(遠隔アクセスにVPNを使用します)。
From the beginning, one explicitly stated restriction was that it was assumed that installed firewalls and VPN gateways had to be kept unchanged, rather than replaced or upgraded, because they have much wider deployments than MIP at the time of writing. Therefore, any solutions would need to minimize the impact on existing VPN and firewall deployments, related standards, and "de facto" standards.
始めから、1つの明らかに述べられた制限はインストールされたファイアウォールとVPNゲートウェイが取り替えるか、またはアップグレードするよりむしろ変わりがなく保たれなければならないと思われたということでした、それらにはMIPよりはるかに広い展開がこれを書いている時点であるので。 したがって、どんなソリューションも、既存のVPN、ファイアウォール展開、関連する規格、および「事実上」の規格で影響を最小にする必要があるでしょう。
1.2. Specification of Requirements
1.2. 要件の仕様
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本書では、いくつかの単語が、仕様の要件を意味するのに使用されます。 これらの単語はしばしば大文字で書かれます。 キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.3. Terminology
1.3. 用語
MIPv4 Mobile IP for IPv4 [RFC3344]
IPv4のためのMIPv4のモバイルIP[RFC3344]
MIPv6 Mobile IP for IPv6
IPv6のためのMIPv6のモバイルIP
VPN Virtual Private Network
VPNの仮想の私設のネットワーク
GW Gateway
GWゲートウェイ
VPN Domain An Intranet protected by a VPN gateway.
VPN Domain AnイントラネットはVPNゲートウェイによって保護されました。
Adrangi & Levkowetz Informational [Page 3] RFC 4093 MIPv4 VPN Traversal Problem Statement August 2005
[3ページ]RFC4093MIPv4 VPN縦断問題声明2005年8月の情報のAdrangi&Levkowetz
DMZ (Demilitarized Zone) A small network inserted as a
"neutral zone" between a company's private network and
the outside public network to prevent outside users
from getting direct access to the company's private
network.
小さいネットワークがユーザの外で会社の私設のネットワークにダイレクトに近づく手段を得るのを防ぐ会社の私設のネットワークと外の公衆通信回線の間の「ニュートラルゾーン」として挿入したDMZ(非武装地帯。)
Home Network A network, possibly virtual, having a network prefix
matching that of a mobile node's home address.
Network Aネットワークで、ことによると仮想で、モバイルノードのホームアドレスのものに合っているネットワーク接頭語を持っていて、家へ帰ってください。
Home Agent A router on a mobile node's home network which tunnels
datagrams for delivery to the mobile node when it is
away from home, and maintains current location
information for the mobile node.
それが家にいないときに、配送のためにモバイルノードにデータグラムにトンネルを堀って、モバイルノードのために現在の位置情報を維持するモバイルノードのホームネットワークに関するホームエージェントAルータ。
MN Refers to a mobile node that runs both MIP and IPsec-
based VPN client software.
MIPとIPsecの両方を実行するモバイルノードへのミネソタRefersはVPNクライアントソフトウェアを基礎づけました。
MIPv4 inside IPsec-ESP tunnel
MIPv4 packets are encapsulated in an IPsec-ESP tunnel
established between the Mobile Node and the VPN
gateway.
IPsec-超能力トンネルMIPv4パケットの中のMIPv4はモバイルNodeとVPNゲートウェイの間で確立されたIPsec-超能力トンネルでカプセル化されます。
IPsec-ESP inside MIPv4 tunnel
IPsec-ESP packets are encapsulated in a MIPv4 tunnel
established between the Mobile Node and the home agent.
内面のMIPv4トンネルIPsec-超能力パケットがモバイルNodeとホームのエージェントの間で確立されたMIPv4トンネルでカプセルに入れられるIPsec-超能力。
2. MIP and VPN Deployment Scenarios
2. MIPとVPN展開シナリオ
This section describes a set of deployment scenarios wherein MIP agents and VPN gateways have to coexist to provide mobility and security. The intention is to identify practical deployment scenarios for MIP and VPNs where MIP technology might be extended to solve problems resulting from the desire for co-existence.
このセクションはMIPエージェントとVPNゲートウェイが移動性とセキュリティを提供するために共存しなければならない1セットの展開シナリオについて説明します。 意志はMIP技術が共存に関する願望から生じることにおける問題を解決するために広げられるかもしれないMIPとVPNsのために実用的な展開シナリオを特定することです。
The network topology in the following diagrams consists of an Intranet connected to the public network (i.e., the Internet). Here, the word "Intranet" refers to a private network (where private addresses [RFC1918] are typically used) protected by a VPN gateway and perhaps by a layer-3 transparent or non-transparent firewall. When private addresses are used, the non-transparent firewall also functions as a Network Address Translator (NAT) or Network Address Port Translator (NAPT) bridging between the two address realms (i.e., the Intranet and the Internet).
以下のダイヤグラムによるネットワーク形態は公衆通信回線(すなわち、インターネット)に関連づけられたイントラネットから成ります。 ここに、「イントラネット」が私設のネットワーク(プライベート・アドレス[RFC1918]が通常使用されるところ)を示すという単語はVPNゲートウェイの近くと恐らく層-3の透明であるか非透過のファイアウォールのそばに保護されました。 また、プライベート・アドレスが使用されているとき、2つの間でアドレスが分野(すなわち、イントラネットとインターネット)であるとブリッジしながら、非透過のファイアウォールはNetwork Address Translator(NAT)かNetwork Address Port Translator(NAPT)として機能します。
Firewalls may be placed on either side of the VPN gateway; these are referred to as inner and outer firewalls. The inner and outer firewalls typically inspect outbound traffic (i.e., from the Intranet to the Internet) and inbound traffic (i.e., from the Internet to the
ファイアウォールはVPNゲートウェイのどちらかの側面に関して課されるかもしれません。 これらは内側の、そして、外側のファイアウォールと呼ばれます。 内側の、そして、外側のファイアウォールがアウトバウンドトラフィック(すなわち、イントラネットからインターネットまでの)とインバウンドトラフィックを通常点検する、(すなわち、インターネット
Adrangi & Levkowetz Informational [Page 4] RFC 4093 MIPv4 VPN Traversal Problem Statement August 2005
[4ページ]RFC4093MIPv4 VPN縦断問題声明2005年8月の情報のAdrangi&Levkowetz
Intranet), respectively. When a firewall is present, it MUST be configured to allow Mobile IP traffic (both control and tunneled data packets) to go through. As our focus here is the relationship between MIP and VPN, we have purposely omitted firewalls from the following scenarios in order to keep things simple.
イントラネット)、それぞれ。 ファイアウォールが存在しているとき、モバイルIPトラフィック(コントロールとトンネルを堀られたデータ・パケットの両方)が通られるのを許容するのは構成していなければなりません。 ここの私たちの焦点がMIPとVPNとの関係であるので、私たちは事態を簡単に保つために以下のシナリオからファイアウォールをわざわざ省略しました。
It is assumed that encryption is not enforced inside the VPN domain because: 1) the VPN domain (Intranet) is viewed as a trusted network, and users allowed inside the Intranet are also trusted, and 2) it is a common VPN deployment practice where the VPN is used to guard the Intranet resources from unauthorized users attached to an untrusted network, and to provide a secure communication channel for authorized users to access resources inside the Intranet from outside.
暗号化がVPNドメインの中で励行されないと思われる、: 1) VPNドメイン(イントラネット)が信じられたネットワークとして見なされて、また、イントラネットで許容されたユーザが信じられる、そして、認定ユーザが外でイントラネットにおけるリソースにアクセスするのが、VPNが信頼されていないネットワークに配属される権限のないユーザからのイントラネットリソースを警備して、安全な通信チャネルを提供するのに使用されるa一般的なVPN展開練習である2)。
The following sub-sections introduce five representative combinations of MIPv4 HA and VPN gateway placement.
以下の小区分はMIPv4 HAとVPNゲートウェイプレースメントの5つの代表している組み合わせを導入します。
In order to give a reasonably complete survey of MIPv4 and VPN co- existence scenarios, those in Sections 2.3 and 2.5 are included even though, as covered in more detail below, there are no co-existence problems to be solved in these two cases.
MIPv4とVPNの合理的に完全な調査に存在の共同シナリオを与えるために、これらの2つの場合で解決されるために、共存問題は全くさらに詳細に以下にカバーされるようにありませんが、セクション2.3と2.5におけるそれらは含まれています。
2.1. MIPv4 HA(s) Inside the Intranet behind a VPN Gateway
2.1. MIPv4、ハ、VPNゲートウェイの後ろのイントラネットにおける(s)
MIPv4 HAs are deployed inside the Intranet protected by a VPN gateway, and are not directly reachable by the MNs outside the Intranet.
MIPv4 HAsはVPNゲートウェイによって保護されたイントラネットで配布されて、MNsでイントラネットの外で直接届いていません。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ +-------+ .
. |MNs | | FA | . | VPN| | Router| | HA | .
. |away| | | .<=========>| | | 1..n | | 1..n | .
. +----+ +----+ . | GW | +-------+ +-------+ .
. . +----+ .
................... . +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
..外国ネットワーク。 .....VPNドメイン。(イントラネット)..... . . . . . +----+ +----+ . +----+ +-------+ +-------+ . . |MNs| | ファ| . | VPN| | ルータ| | ハ| . . |離れている| | | . <。=========>|、|、| 1..n| | 1..n| . . +----+ +----+ . | GW| +-------+ +-------+ . . . +----+ . ................... . +-------+ +-------+ . . | CN| | MNs| . . | 1..n| | ホーム| . . +-------+ +-------+ . . . ................................
Figure 1
図1
Direct application of MIPv4 standards [RFC3344] is successfully used to provide mobility for users inside the Intranet. However, mobile users outside the Intranet can only access the Intranet resources (e.g., MIP agents) through the VPN gateway, which will allow only
MIPv4規格[RFC3344]のダイレクト適用は、移動性をユーザに提供するのにイントラネットに首尾よく使用されます。 しかしながら、イントラネットの外におけるモバイルユーザはVPNゲートウェイだけを通してイントラネットリソース(例えば、MIPエージェント)にアクセスできるだけです。VPNゲートウェイは許容されるでしょう。
Adrangi & Levkowetz Informational [Page 5] RFC 4093 MIPv4 VPN Traversal Problem Statement August 2005
[5ページ]RFC4093MIPv4 VPN縦断問題声明2005年8月の情報のAdrangi&Levkowetz
authenticated IPsec traffic inside. This implies that the MIPv4 traffic has to run inside IPsec, which leads to two distinct problems:
IPsecトラフィック内部を認証しました。 これは、MIPv4トラフィックが2つの異なった問題を引き起こすIPsecの中で稼働しなければならないのを含意します:
1. When the foreign network has an FA deployed (e.g., as in CDMA
2000), MIPv4 registration becomes impossible. This is because
the MIPv4 traffic between MN and VPN gateway is encrypted, and
the FA (which is likely in a different administrative domain)
cannot inspect the MIPv4 headers needed for relaying the MIPv4
packets. Please see Section 4.2 for more details.
1. 外国ネットワークがFAを配布させるとき(例えば、CDMA2000のように)、MIPv4登録は不可能になります。 これがミネソタとVPNゲートウェイの間のMIPv4トラフィックが暗号化されているからであるFA(異なった管理ドメインでありそうである)はMIPv4パケットをリレーするのに必要であるMIPv4ヘッダーを点検できません。 その他の詳細に関してセクション4.2を見てください。
2. In co-located mode, successful registration is possible but the
VPN tunnel has to be re-negotiated every time the MN changes its
point of network attachment.
2. 共同見つけられたモードで、うまくいっている登録は可能ですが、ミネソタがネットワーク付属のポイントを変えるときはいつも、VPNトンネルは再交渉されなければなりません。
These problems are articulated in Section 4.
これらの問題はセクション4で明確に話されます。
This deployment scenario may not be common yet, but it is practical and is becoming important as there is an increasing need for providing corporate remote users with continuous access to the Intranet resources.
この展開シナリオがまだ一般的でないかもしれませんが、イントラネットリソースへの連続したアクセスを法人のリモート・ユーザーに提供する増加する必要があるとき、それは、実用的であり、重要になっています。
2.2. VPN Gateway and MIPv4 HA(s) on the VPN Domain Border
2.2. VPNゲートウェイとMIPv4、ハ、VPNドメイン境界の(s)
A MIPv4 HA is deployed on the VPN domain border (e.g., in the DMZ) together with the VPN gateway, and it is directly reachable by MNs inside or outside the Intranet.
MIPv4 HAはVPNゲートウェイと共にVPNドメイン境界(例えば、DMZの)で配布されます、そして、それはイントラネットかイントラネットの外におけるMNsで直接届いています。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ .
. |MNs | | FA | . | VPN| | Router| .
. |away| | | .<=========>| | | 1..n | .
. +----+ +----+ . /\ | GW | +-------+ .
. . || +----+ .
. . || +----+ +-------+ +-------+ .
. . ++====>| HA | | CN | | MNs | .
................... | | | 1..n | | home | .
+----+ +-------+ +-------+ .
. .
................................
..外国ネットワーク。 .....VPNドメイン。(イントラネット)..... . . . . . +----+ +----+ . +----+ +-------+ . . |MNs| | ファ| . | VPN| | ルータ| . . |離れている| | | . <。=========>|、|、| 1..n| . . +----+ +----+ . /\ | GW| +-------+ . . . || +----+ . . . || +----+ +-------+ +-------+ . . . ++====>| ハ| | CN| | MNs| . ................... | | | 1..n| | ホーム| . +----+ +-------+ +-------+ . . . ................................
Figure 2
図2
Please note that in deployments where the security policy prohibits direct communication between the MN (roaming outside the Intranet) and outside machines, the HA can be configured to forward only encrypted traffic from/to the MN.
展開では、安全保障政策がミネソタ(イントラネットの外で移動する)と外のマシンとのダイレクトコミュニケーションを禁止するところで/からミネソタまで暗号化されたトラフィックだけを進めるためにHAを構成できます。
Adrangi & Levkowetz Informational [Page 6] RFC 4093 MIPv4 VPN Traversal Problem Statement August 2005
[6ページ]RFC4093MIPv4 VPN縦断問題声明2005年8月の情報のAdrangi&Levkowetz
The MIPv4 HA has a public interface connected to the Internet, and a private interface attached to the Intranet. Mobile users will most likely have a virtual home network associated with the MIPv4 HA's private interface, so that the mobile users are always away from home and thus registered with the MIPv4 HA. Furthermore, in deployments where the VPN gateway and the HA are placed in a corporate DMZ, this implies that MIPv4 traffic will always be routed through the DMZ (regardless of whether MNs are located outside or inside the Intranet), which may not be acceptable to IT departments in large corporations.
MIPv4 HAは公共のインタフェースをインターネットに関連づけさせます、そして、個人的なインタフェースはイントラネットに付きました。 モバイルユーザは、モバイルユーザには、MIPv4 HAの個人的なインタフェースに関連している仮想のホームネットワークがたぶんあるでしょう、いつも遠くでホームから来ていて、このようにしてMIPv4 HAに登録されています。 その上、VPNゲートウェイとHAが法人のDMZに置かれるところで展開では、これは、MIPv4トラフィックがDMZ(MNsがイントラネットの外、または、イントラネットの中において位置しているかどうかにかかわらず)を通していつも発送されるのを含意します。DMZは大企業でIT部に許容できないかもしれません。
This deployment can be used with two different configurations: "MIPv4 inside IPsec-ESP tunnel" and "IPsec-ESP inside MIPv4 tunnel". The "MIPv4 inside IPsec-ESP tunnel" has the same problems as the scenario in Section 2.1. (Namely, MIPv4 registration becomes impossible when the registration is to be done via an FA, and furthermore, in co- located mode, the VPN tunnel has to be re-negotiated every time the MN changes its point of attachment.) The "IPsec-ESP inside MIPv4 tunnel" does not have the problems described in Section 2.1; however, it will require some modifications to the routing logic of the MIPv4 HA or the VPN gateway.
2つの異なった構成と共にこの展開を使用できます: 「IPsec-超能力の中のMIPv4はトンネルを堀っ」て、「IPsec-超能力内部のMIPv4はトンネルを堀ります」。 「IPsec-超能力トンネルの中のMIPv4」には、セクション2.1のシナリオと同じ問題があります。 (登録がFAを通してすることであり、ミネソタが接着点を変えるときはいつも、その上、共同見つけられたモードでVPNトンネルを再交渉しなければならないとき、すなわち、MIPv4登録は不可能になります。) 「MIPv4トンネルの中のIPsec-超能力」には、セクション2.1で説明された問題がありません。 しかしながら、それはMIPv4 HAかVPNゲートウェイのルーティング論理へのいくつかの変更を必要とするでしょう。
2.3. Combined VPN Gateway and MIPv4 HA
2.3. 結合したVPNゲートウェイとMIPv4、ハ。
This is similar to the deployment scenario described in Section 2.2, with the exception that the VPN gateway and MIPv4 HA are running on the same physical machine.
これはセクション2.2で説明された展開シナリオと同様です、VPNゲートウェイとMIPv4 HAが同じ物理的なマシンに実行している例外で。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ .
. |MNs | | FA | . | VPN| | Router| .
. |away| | | .<==========| GW | | 1..n | .
. +----+ +----+ . | + | +-------+ .
. . | HA | .
................... +----+ +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
..外国ネットワーク。 .....VPNドメイン。(イントラネット)..... . . . . . +----+ +----+ . +----+ +-------+ . . |MNs| | ファ| . | VPN| | ルータ| . . |離れている| | | . <。==========| GW| | 1..n| . . +----+ +----+ . | + | +-------+ . . . | ハ| . ................... +----+ +-------+ +-------+ . . | CN| | MNs| . . | 1..n| | ホーム| . . +-------+ +-------+ . . . ................................
Figure 3
図3
Adrangi & Levkowetz Informational [Page 7] RFC 4093 MIPv4 VPN Traversal Problem Statement August 2005
[7ページ]RFC4093MIPv4 VPN縦断問題声明2005年8月の情報のAdrangi&Levkowetz
Running MIPv4 HA and VPN on the same machine resolves routing-related issues that exist in Section 2.2 when a "IPsec-ESP inside MIPv4 tunnel" configuration is used. However, it does not promote multi- vendor interoperability in environments where MIPv4 HA and VPN technologies must be acquired from different vendors.
MIPv4 HAとVPNを同じマシンに実行すると、「MIPv4の中のIPsec-超能力トンネル」構成が使用されているときセクション2.2に存在するルーティング関連の問題は解決されます。 しかしながら、それは異なったベンダーからMIPv4 HAとVPN技術を獲得しなければならない環境におけるマルチベンダー相互運用性を促進しません。
2.4. MIPv4 HA(s) Outside the VPN Domain
2.4. MIPv4、ハ、VPNドメインの外の(s)
In this scenario, MIPv4 HAs are deployed outside the Intranet (e.g., in an operator network), as depicted in Figure 4, below.
このシナリオでは、MIPv4 HAsはイントラネット(例えば、オペレータネットワークにおける)の外で配布されます、図4で表現されて、以下として。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ .
. |MNs | | FA | . | VPN| | Router| .
. |away| | | .<==========| GW | | 1..n | .
. +----+ +----+ . /\ | | +-------+ .
. . || | | .
................... || | | +-------+ +-------+ .
|| | | | CN | | MNs | .
.....MIPv4 Home.... || | | | 1..n | | home | .
. .<===++ | | +-------+ +-------+ .
. +------+ . +----+ .
. | HAs | . . .
. | 1..n | . ................................
. +------+ .
...................
..外国ネットワーク。 .....VPNドメイン。(イントラネット)..... . . . . . +----+ +----+ . +----+ +-------+ . . |MNs| | ファ| . | VPN| | ルータ| . . |離れている| | | . <。==========| GW| | 1..n| . . +----+ +----+ . /\ | | +-------+ . . . || | | . ................... || | | +-------+ +-------+ . || | | | CN| | MNs| . .....MIPv4は家へ帰ります… || | | | 1..n| | ホーム| . . . <。===++ | | +-------+ +-------+ . . +------+ . +----+ . . | 持っています。| . . . . | 1..n| . ................................ . +------+ . ...................
Figure 4
図4
The IPsec tunnel endpoints will be the MN and the VPN gateway. The 'home network' will most likely be a virtual home network, located at the HA, through which authorized remote users (i.e., those that have successfully established a connection to the corporate VPN) can reach the Corporate Intranet and maintain their transport session connectivity while roaming outside the Intranet from one subnet to another. Please note that this deployment scenario does not support mobility inside the Intranet.
IPsecトンネル終点は、ミネソタとVPNゲートウェイになるでしょう。 'ホームネットワーク'はたぶん認可されたリモート・ユーザー(すなわち、首尾よく法人のVPNに取引関係を築いたもの)がイントラネットの外で1つのサブネットから別のサブネットまで移動している間にCorporateイントラネットに達して、彼らの輸送セッションの接続性を維持できる仮想のホームネットワークにHAに位置するなるでしょう。 この展開シナリオはイントラネットで移動性をサポートしません。
In this case, it is most practical to run IPsec-ESP inside a MIPv4 tunnel (i.e., the MIPv4 tunnel endpoints are the MN and the HA; the IPsec-ESP packet from the MN and to the VPN gateway is encapsulated in the MIPv4 tunnel). This is because the MNs can register with the HA without establishing an IPsec tunnel to the VPN gateway.
この場合、MIPv4トンネルの中でIPsec-超能力を管理するのは最も実用的です(すなわち、MIPv4トンネル終点は、ミネソタとHAです; ミネソタとVPNゲートウェイへのIPsec-超能力パケットはMIPv4トンネルでカプセルに入れられます)。 これはMNsがIPsecトンネルをVPNゲートウェイに確立しないでHAとともに記名することができるからです。
Adrangi & Levkowetz Informational [Page 8] RFC 4093 MIPv4 VPN Traversal Problem Statement August 2005
[8ページ]RFC4093MIPv4 VPN縦断問題声明2005年8月の情報のAdrangi&Levkowetz
2.5. Combined VPN Gateway and MIPv4 HA(s) on the Local Link
2.5. 結合したVPNゲートウェイとMIPv4、ハ、地方のリンクの(s)
This is similar to the deployment scenario described in Section 2.3, with the difference that the VPN gateway/HA is sitting on the local link. In this case, the VPN gateway and HA would most naturally be co-located in the same box, although this is in no way a requirement.
これはセクション2.3で説明された展開シナリオと同様です、VPNゲートウェイ/HAが地方のリンクの上に座らせている違いで。 この場合、VPNゲートウェイとHAは最も自然に同じ状態で共同見つけられるでしょう、これが決して要件ではありませんが。
The VPN/HA is assumed to be reachable from the external network; i.e., it is assumed to have a public IP address, and the firewall is assumed to be configured to allow direct access to the VPN/HA from the external network.
VPN/HAが外部のネットワークから届くと思われます。 すなわち、それには公共のIPアドレスがあると思われて、外部のネットワークからVPN/HAに直接アクセスを許すためにファイアウォールが構成されると思われます。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +------+ +-------+ +-------+ .
. |MNs | | FA | . | Fire | | Router| | VPN/HA| .
. |away| | | .<=======>| wall | | 1..n | | 1..n | .
. +----+ +----+ . | | +-------+ +-------+ .
. . | NAT | .
................... +------+ +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
..外国ネットワーク。 .....VPNドメイン。(イントラネット)..... . . . . . +----+ +----+ . +------+ +-------+ +-------+ . . |MNs| | ファ| . | 炎| | ルータ| | VPN/、ハ。| . . |離れている| | | . <。=======>| 壁| | 1..n| | 1..n| . . +----+ +----+ . | | +-------+ +-------+ . . . | NAT| . ................... +------+ +-------+ +-------+ . . | CN| | MNs| . . | 1..n| | ホーム| . . +-------+ +-------+ . . . ................................
Figure 5
図5
This deployment works today without any technical problems with IPsec-ESP running inside a MIPv4 tunnel. If you were to run MIPv inside the IPsec-ESP tunnel, it would have the same problems as in Section 2.1, so it is deployed with the IPsec-ESP running inside the MIPv4 tunnel. This deployment is not practical for large deployments (on the order of thousands of users) because of the large and distributed security perimeter.
この展開は今日、IPsec-超能力がMIPv4の中で稼働であっている中の少しも技術的問題トンネルなしで働いています。 あなたがIPsec-超能力トンネルの中でMIPvを実行するなら、それには、それがセクション2.1のようにIPsec-超能力で配布されることにおけるMIPv4トンネルの中で稼働することにおける同じ問題があるでしょうに。 大きい展開(何千人ものユーザの注文での)には、この展開は大きくて分配されたセキュリティ周辺のために実用的ではありません。
3. Deployment Scenarios Selection
3. 展開シナリオ選択
The deployment scenarios described in Section 2 were evaluated to identify those most in need of solving. The evaluation was done based on two main criteria: 1) Is the deployment scenario common and practical? and 2) Does the deployment scenario reveal any problems resulting from MIPv4 and VPN coexistence?
セクション2で説明された展開シナリオは、解決を必要としてそれらを最も特定するために評価されました。 2つの主な評価基準に基づいて、評価しました: 1) 展開シナリオ一般的であるのと実用的と、2です)。 展開シナリオは何かMIPv4とVPN共存から生じることにおける問題を明らかにしますか?
The authors believe that the scenario in Section 2.1 is the most important and practical one because of a rising need for providing corporate remote users with continuous access to their Intranet resources. After analyzing each scenario, one realizes that problems
作者は、彼らのイントラネットリソースへの連続したアクセスを法人のリモート・ユーザーに提供する上昇している必要性のためにセクション2.1のシナリオが最も重要で実用的なものであると信じています。 各シナリオを分析した後に、人はその問題がわかります。
Adrangi & Levkowetz Informational [Page 9] RFC 4093 MIPv4 VPN Traversal Problem Statement August 2005
[9ページ]RFC4093MIPv4 VPN縦断問題声明2005年8月の情報のAdrangi&Levkowetz
occurring in scenarios in Sections 2.2 and 2.4 are either the same as those in the scenario in Section 2.1 or a subset of them. Therefore, solving the scenario in Section 2.1 will also solve the scenarios in Sections 2.2 and 2.4. The scenarios in Sections 2.3 and 2.5 do not introduce functional problems resulting from MIPv4 and VPN co- existence, and thus there is no need to seek a solution. A solution for the deployment scenario in Section 2.1 is therefore seen as essential, and this in turn can also be applied to solve problems in other scenarios. In subsequent sections, we will articulate the roaming scenarios, the problems, and the solution guidelines relevant to the scenario in Section 2.1.
セクション2.2と2.4のシナリオに起こるのはセクション2.1のシナリオかそれらの部分集合のそれらと同じです。 したがって、また、セクション2.1のシナリオを解決すると、セクション2.2と2.4のシナリオは解決されるでしょう。 セクション2.3と2.5のシナリオがMIPv4とVPNから生じることにおける機能的異常を紹介しない、共同存在、その結果、解決策を捜す必要は全くありません。 したがって、セクション2.1の展開シナリオのためのソリューションを不可欠であるとみなします、そして、また、他のシナリオの問題を解決するために順番にこれを申し込むことができます。 その後のセクションで、私たちはセクション2.1のシナリオに関連しているローミングシナリオ、問題、およびソリューションガイドラインについて明確に話すつもりです。
4. Problem Statement
4. 問題声明
This section describes roaming scenarios corresponding to the deployment scenario in Section 2.1 where an MN needs to have continuous access to the Intranet resources regardless of whether it is roaming inside or outside the Intranet, and their associated problems. The scenarios are constructed based on a multi-subnetted, MIPv4-enabled Intranet (hereafter referred to as Intranet or VPN domain) protected by an IPsec-based VPN gateway as depicted in Figure 6.
このセクションは、関連する問題の中、または、イントラネットと、それらの関連する問題の外で移動しているかどうかにかかわらずミネソタがイントラネットリソースへの連続したアクセスを必要とするところでセクション2.1の展開シナリオに対応するシナリオに移動すると説明します。シナリオは図6に表現されるようにIPsecベースのVPNゲートウェイによって保護されたマルチ「副-網で覆」われて、MIPv4によって可能にされたイントラネット(今後イントラネットかVPNドメインと呼ばれる)に基づいて構成されます。
....Internet....... .....VPN Domain..(Intranet).....
. . . .
. +----+ . +----+ +-------+ +-------+ .
. |MNs | . | VPN| | Router| | VPN/HA| .
. |away| .<=========>| | | 1..n | | 1..n | .
. +----+ . | GW | +-------+ +-------+ .
. . +----+ .
................... . +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
....インターネット… .....VPNドメイン。(イントラネット)..... . . . . . +----+ . +----+ +-------+ +-------+ . . |MNs| . | VPN| | ルータ| | VPN/、ハ。| . . |離れている| . <。=========>|、|、| 1..n| | 1..n| . . +----+ . | GW| +-------+ +-------+ . . . +----+ . ................... . +-------+ +-------+ . . | CN| | MNs| . . | 1..n| | ホーム| . . +-------+ +-------+ . . . ................................
Figure 6: Intranet protected by a VPN gateway
図6: VPNゲートウェイによって保護されたイントラネット
The Intranet, as depicted in Figure 6, may include both wired (IEEE 802.3) and IEEE 802.11 wireless LAN deployments. However, it is also possible to see IEEE 802.11 deployments outside the Intranet due to the perceived lack of current 802.11 security, as depicted in Figure 7.
図6に表現されるイントラネットは802.11のともにワイヤード(IEEE802.3)とIEEE無線LAN展開を含むかもしれません。 しかしながら、また、現在の802.11セキュリティの知覚された不足のためIEEE802.11展開外部イントラネットを見るのも可能です、図7に表現されるように。
Adrangi & Levkowetz Informational [Page 10] RFC 4093 MIPv4 VPN Traversal Problem Statement August 2005
[10ページ]RFC4093MIPv4 VPN縦断問題声明2005年8月の情報のAdrangi&Levkowetz
....Internet....... .....VPN Domain..(Intranet).....
. . . .
. +----+ . +----+ +-------+ +-------+ .
. |MNs | . | VPN| | Router| | VPN/HA| .
. |away| .<=========>| | | 1..n | | 1..n | .
. +----+ . | GW | +-------+ +-------+ .
. . | | .
................... | | +-------+ +-------+ .
| | | CN | | MNs | .
..802.11 Wireless.. <====>| | | 1..n | | home | .
. Network . +----+ +-------+ +-------+ .
. . . .
................... ................................
....インターネット… .....VPNドメイン。(イントラネット)..... . . . . . +----+ . +----+ +-------+ +-------+ . . |MNs| . | VPN| | ルータ| | VPN/、ハ。| . . |離れている| . <。=========>|、|、| 1..n| | 1..n| . . +----+ . | GW| +-------+ +-------+ . . . | | . ................... | | +-------+ +-------+ . | | | CN| | MNs| . ..802.11 ワイヤレスです。 <==>|、|、| 1..n| | ホーム| . . ネットワーク+----+ +-------+ +-------+ . . . . . ................... ................................
Figure 7: IEEE 802.11 Wireless deployment outside the home network
図7: ホームネットワークの外におけるIEEE802.11Wireless展開
4.1. Registering in Co-Located Mode
4.1. 共同見つけられたモードで、登録します。
In co-located mode, the IPsec tunnel endpoints would be at the MN and the VPN gateway, which (supposing we have the scenario described in Section 2.1) results in the mobile-ip tunnel from MN to HA being encapsulated inside the IPsec tunnel. See Figure 8 below. This scenario is still possible, but has some major drawbacks.
共同見つけられたモードには、IPsecトンネル終点がミネソタとVPNゲートウェイにあるでしょう。(それは、ミネソタからIPsecトンネルの中でカプセル化されるHAまでのモバイル-ipトンネルをもたらします(私たちにはセクション2.1で説明されたシナリオがあると思います))。 以下の図8を見てください。 このシナリオには、まだ可能ですが、いくつかの主要な欠点があります。
....Internet....... .....VPN Domain..(Intranet).....
. . . .
. +----+ . +----+ +-------+ +-------+ .
. |MNs | . | VPN| | Router| | VPN/HA| .
. |away|<###################>| |-----| 1..n |->| 1..n | .
. +----+ . \ | GW | +-------+ +-------+ .
. . \ +----+ .
................... mip . +-------+ +-------+ .
inside . | CN | | MNs | .
IPsec . | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
....インターネット… .....VPNドメイン。(イントラネット)..... . . . . . +----+ . +----+ +-------+ +-------+ . . |MNs| . | VPN| | ルータ| | VPN/、ハ。| . . |離れている|<###################>| |-----| 1..n|、-、>| 1..n| . . +----+ . \ | GW| +-------+ +-------+ . . . \ +----+ mip+-------+ +-------+ . 内部。| CN| | MNs| . IPsec。| 1..n| | ホーム| . . +-------+ +-------+ . . . ................................
Figure 8
エイト環
The MN obtains an address at its point of attachment (via DHCP [RFC2131] or some other means), and then sets up an IPsec tunnel to the VPN gateway, after which it can successfully register with its HA through the IPsec tunnel. The IPsec tunnel SA (Security Association) is identified by a triplet consisting of SPI (Security Parameter Index), MN's IP destination address (i.e., the address obtained at the point of attachment), and Security Protocol (AH or ESP) Identifier as described in [RFC2401]. This means that as the MN's IP
ミネソタは、接着点(DHCP[RFC2131]かある他の手段を通した)でアドレスを得て、次に、IPsecトンネルをVPNゲートウェイにセットアップします。(その時、それはIPsecトンネルを通って首尾よくHAとともに記名することができました後)。 IPsecトンネルSA(セキュリティAssociation)は[RFC2401]で説明されるミネソタのSPIから成る三つ子(セキュリティParameter Index)、受信者IPアドレス(すなわち、接着点で得られたアドレス)、およびSecurityプロトコル(AHか超能力)識別子によって特定されます。 これはミネソタIPとしてそれを意味します。
Adrangi & Levkowetz Informational [Page 11] RFC 4093 MIPv4 VPN Traversal Problem Statement August 2005
[11ページ]RFC4093MIPv4 VPN縦断問題声明2005年8月の情報のAdrangi&Levkowetz
destination address changes on each IP subnet handoff, the IPsec tunnel needs to be re-established. This could have noticeable performance implications on real-time applications and in resource- constrained wireless networks. In effect, we don't have mobility support for the tunnel endpoint changes associated with MN movements.
送付先アドレスはそれぞれのIPサブネット移管のときに変化して、IPsecトンネルは、復職する必要があります。 これは、めぼしい性能意味をリアルタイムのアプリケーションに持つことができて、リソースでワイヤレス・ネットワークを抑制しました。 事実上、私たちは移動性にミネソタの運動に関連している終点変化をトンネルにサポートさせません。
4.2. Registering via an FA
4.2. FAを通して、登録します。
In the case where a mobile node is in a network where mobility support is provided through the use of an FA, and no DHCP allocated address and co-located mode is possible, we run into severe trouble. This is illustrated in Figure 9 and explained below:
ネットワークにはモバイルノードがFAの使用で移動性サポートを提供して、どんなDHCPもアドレスを割り当てないで、共同見つけられたモードが可能であるところにある場合では、私たちは激しい問題を出くわします。 これは、図9で例証されて、以下で説明されます:
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ +-------+ .
. |MNs | | FA | . | VPN| | Router| | VPN/HA| .
. |away|<??| |<###########>| |-----| 1..n |->| 1..n | .
. +----+ \ +----+ . \ | GW | +-------+ +-------+ .
. \ . \ +----+ .
...........\....... mip . +-------+ +-------+ .
\ inside . | CN | | MNs | .
MN expects IPsec . | 1..n | | home | .
IPsec traffic . +-------+ +-------+ .
. .
................................
..外国ネットワーク。 .....VPNドメイン。(イントラネット)..... . . . . . +----+ +----+ . +----+ +-------+ +-------+ . . |MNs| | ファ| . | VPN| | ルータ| | VPN/、ハ。| . . |離れている|<?| |<###########>| |-----| 1..n|、-、>| 1..n| . . +----+ \ +----+ . \ | GW| +-------+ +-------+ . . \ . \ +----+ . ...........\… mip+-------+ +-------+ . \内部。| CN| | MNs| . ミネソタはIPsecを予想します。| 1..n| | ホーム| . IPsecトラフィック+-------+ +-------+ . . . ................................
Figure 9
図9
When arriving at the visited network on the left in this figure, the MN has to reach the FA with registration requests in order to have the FA send them on to the HA. However, the MN in all likelihood cannot register with the FA because the registration requests will be sent encrypted, and the FA will not be able to decrypt them. If the MN would have a policy that allowed split tunneling so that it could reach the FA with clear text messages, then the FA would still not be able to get through the VPN gateway unless the HA is reachable from outside and the Intranet security policy allows MIP registration packets to bypass the VPN gateway.
この図で左で訪問されたネットワークに到着するとき、FAにそれらをHAに送らせるように、ミネソタは登録要求でFAに達しなければなりません。 しかしながら、FAが暗号化されていた状態で登録要求を送って、それらを解読することができないので、ミネソタは十中八九FAとともに記名することができません。 ミネソタでクリアテキストメッセージでFAに達することができるように分裂トンネリングを許容した方針があって、HAが外部から届いていて、イントラネット安全保障政策が、MIP登録パケットがVPNゲートウェイを迂回させるのを許容しない場合、FAはまだVPNゲートウェイを通り抜けることができないでしょう。
Even if the HA is reachable and the MIP registration succeeds, the FA (which is likely in a different administrative domain) will not be able to relay packets between the MN and the VPN gateway. Packets from the MN will be encapsulated by the FA with IP-in-IP [RFC2003], which the VPN gateway will drop, and packets from the VPN gateway will have ESP payloads (with IP-in-IP inside), which the FA will drop (as it expects IP-in-IP-encapsulated traffic to the MN).
HAが届いてい、MIP登録が成功しても、FA(異なった管理ドメインでありそうである)はミネソタとVPNゲートウェイの間のパケットをリレーできないでしょう。 (VPNゲートウェイはIPを下げるでしょう)。ミネソタからのパケットはIPにおけるIP[RFC2003]と共にFAによってカプセルに入れられるでしょう、そして、VPNゲートウェイからのパケットには、超能力ペイロード(IPにおけるIP内部がある)があるでしょう(カプセル化されたIPにおけるIPトラフィックをミネソタに予想するとき)。(FAはペイロードを下げるでしょう)。
Adrangi & Levkowetz Informational [Page 12] RFC 4093 MIPv4 VPN Traversal Problem Statement August 2005
[12ページ]RFC4093MIPv4 VPN縦断問題声明2005年8月の情報のAdrangi&Levkowetz
The use of a 'trusted FA' has also been suggested in this scenario, meaning an FA that is actually a combined VPN GW and FA. The scenario will work fine in this case, as the tunnel end-points are at the FA and the VPN gateway as shown in Figure 10 below. However, we cannot expect that the FA in access networks (e.g., wireless hot- spots or CDMA 2000 networks) will have security associations with any given corporate network, so this is not particularly realistic in the general mobility case.
また、'信じられたFA'の使用はこのシナリオに示されました、実際に結合したVPN GWとFAであるFAを意味して。 シナリオはこの場合きめ細かに働くでしょう、トンネルエンドポイントが以下の図10に示されるようにFAとVPNゲートウェイにあるとき。 しかしながら、私たちは、アクセスネットワーク(例えば、ワイヤレスの熱い場所かCDMA2000ネットワーク)におけるFAには企業ネットワークに与えるいずれとのセキュリティ協会があるので、これが一般的な移動性場合で特に現実的でないことを期待できません。
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ +-------+ .
. | FA | | VPN| . | VPN| | Router| | VPN/HA| .
. | |<--| GW |<###########>| |-----| 1..n |->| 1..n | .
. +----+ +----+ . \ | GW | +-------+ +-------+ .
. | . \ +----+ .
. +----+ . mip . +-------+ +-------+ .
. |MNs | . inside . | CN | | MNs | .
. |away| . IPsec . | 1..n | | home | .
. +----+ . . +-------+ +-------+ .
................... . .
................................
..外国ネットワーク。 .....VPNドメイン。(イントラネット)..... . . . . . +----+ +----+ . +----+ +-------+ +-------+ . . | ファ| | VPN| . | VPN| | ルータ| | VPN/、ハ。| . . | | <--、| GW|<###########>| |-----| 1..n|、-、>| 1..n| . . +----+ +----+ . \ | GW| +-------+ +-------+ . . | . \ +----+ . . +----+ . mip+-------+ +-------+ . . |MNs| . 中。| CN| | MNs| . . |離れている| . IPsec。| 1..n| | ホーム| . . +----+ . . +-------+ +-------+ . ................... . . ................................
Figure 10
図10
Furthermore, this solution would leave the traffic between FA and MN unprotected, and as this link in particular may be a wireless link, this is clearly undesirable.
その上、このソリューションはFAとミネソタの間のトラフィックを保護がない状態でおくでしょう、そして、特にこのリンクがワイヤレスのリンクであるかもしれないので、これは明確に望ましくありません。
4.3. Summary: MIP Incompatibilities with IPsec-Based VPN Gateways
4.3. 概要: IPsecベースのVPNゲートウェイがあるMIP非互換性
An MN roaming outside the Intranet has to establish an IPsec tunnel to its home VPN gateway first, in order to be able to register with its home agent. This is because the MN cannot reach its HA (inside the private protected network) directly from the outside. This implies that the MIPv4 traffic from the MN to a node inside the Intranet is forced to run inside an IPsec tunnel, and thus that it will not be in the clear. This in turn leads to two distinct problems depending on whether the MN uses co-located or non-co- located modes to register with its HA.
イントラネットの外で移動するミネソタは最初にIPsecトンネルをホームVPNゲートウェイに確立しなければなりません、ホームのエージェントとともに記名することができるように。 これはミネソタが直接外部からHA(私設の保護されたネットワークにおける)に達することができないからです。 これはイントラネットにおけるミネソタからノードまでのMIPv4トラフィックがIPsecトンネルの中でやむを得ず稼働して、その結果、それが明確にないのを含意します。 または、これが順番によることにおける2つの異なった問題に導く、ミネソタ用途が共同場所を見つけた、非、-、共同、-、HAとともに記名するためにモードの場所を見つけました。
In co-located mode, the IPsec tunnel needs to be re-established on each IP subnet handoff, which will have performance implications on real-time applications and resource-constrained wireless networks.
共同見つけられたモードで、IPsecトンネルは、それぞれのIPサブネット移管のときに復職する必要があります。(移管はリアルタイムのアプリケーションとリソースで制約つきなワイヤレス・ネットワークに性能意味を持つでしょう)。
In non-co-located mode (i.e., using an FA care-of address), the problem becomes severe, as the MN may be unable to register with its HA through the FA because the FA cannot understand MIPv4 registration
非共同見つけられたモード、(すなわち、FAを使用する、注意、-、アドレス)、問題は厳しくなります、FAがMIPv4登録を理解できないのでミネソタがFAを通してHAとともに記名することができないとき
Adrangi & Levkowetz Informational [Page 13] RFC 4093 MIPv4 VPN Traversal Problem Statement August 2005
[13ページ]RFC4093MIPv4 VPN縦断問題声明2005年8月の情報のAdrangi&Levkowetz
requests if they are encrypted in the IPsec tunnel (i.e., split tunneling is not supported). Even if the MN could reach the FA with non-encrypted registration requests (i.e., split tunneling is supported), and the requests going from the FA to the HA can pass through the VPN gateway, there would still be a problem with routing of data packets between the Intranet and the internet. This is because the VPN will not allow IP-in-IP-encapsulated packets from the FA to go through. And furthermore, ESP-encapsulated packets from the VPN gateway to the MN will be dropped by the FA, as it expects IP- in-IP-encapsulated traffic to the MN.
それらがIPsecで暗号化されるなら、要求はトンネルを堀ります(すなわち、分裂トンネリングはサポートされません)。 ミネソタが非暗号化された登録要求でFAに達することができ(すなわち、分裂トンネリングはサポートされます)、FAからHAまで行く要求がVPNゲートウェイを通り抜けることができても、イントラネットとインターネットの間には、データ・パケットのルーティングに関する問題がまだあるでしょう。 これはVPNがFAからのカプセル化されたIPにおけるIPパケットを通らせないからです。 そして、その上、超能力でカプセル化されたVPNゲートウェイからミネソタまでのパケットはFAが下げられるでしょう、カプセル化されたIPにおけるIPトラフィックをミネソタに予想するとき。
5. Solution Guidelines
5. ソリューションガイドライン
This section describes guidelines for a solution to MIPv4 traversal across VPN gateways.
このセクションはVPNゲートウェイの向こう側にソリューションのためのガイドラインについてMIPv4縦断に説明します。
5.1. Preservation of Existing VPN Infrastructure
5.1. 既存のVPNインフラストラクチャの保存
o The solution MUST work with currently deployed VPN gateways. This
is the whole raison d'etre of this investigation: Finding a way
to deploy Mobile-IP in cases where a VPN solution is already in
place.
o ソリューションは現在配布しているVPNゲートウェイで働かなければなりません。 これはこの調査の全体の存在理由です: VPNソリューションが既に適所にある場合でモバイルIPを配布する方法を見つけます。
5.2. Software Upgrades to Existing VPN Client and Gateways
5.2. 既存のVPNクライアントとゲートウェイへのソフトウェアの更新
o The solution SHOULD minimize changes to existing VPN
client/gateway software.
o ソリューションSHOULDは既存のVPNクライアント/ゲートウェイソフトウェアへの変化を最小にします。
5.3. IPsec Protocol
5.3. IPsecプロトコル
o The solution SHOULD NOT require any changes to existing IPsec or
key-exchange standard protocols implemented by VPN gateways.
o ソリューションSHOULD NOTはVPNゲートウェイによって実装された既存のIPsecか主要な交換標準プロトコルへの変化を必要とします。
o The solution SHOULD NOT require that the VPN gateway or the VPN
client implement any new protocols in addition to the existing
standard protocols.
o ソリューションSHOULD NOTは、VPNゲートウェイかVPNクライアントが既存の標準プロトコルに加えたどんな新しいプロトコルも実装するのを必要とします。
5.4. Multi-Vendor Interoperability
5.4. マルチベンダ相互運用性
o The solution MUST provide multi-vendor interoperability, whereby
MIPv4 mobility agents, mobility clients (MN), VPN server, and VPN
client solutions may come from four different vendors. This is
typical for medium and large enterprises that purchase and deploy
best-of-breed multi-vendor solutions for IP routing, VPNs,
firewalls, etc.
o ソリューションはマルチベンダ相互運用性を提供しなければなりません。(MIPv4移動性エージェント、移動性クライアント(ミネソタ)、VPNサーバ、およびVPNクライアントソリューションはそれで4つの異なったベンダーから来るかもしれません)。 IPルーティング、VPNs、ファイアウォールなどのために種類の最善のマルチベンダソリューションを購入して、配布する中型の、そして、大きい企業に、これは典型的です。
Adrangi & Levkowetz Informational [Page 14] RFC 4093 MIPv4 VPN Traversal Problem Statement August 2005
[14ページ]RFC4093MIPv4 VPN縦断問題声明2005年8月の情報のAdrangi&Levkowetz
5.5. MIPv4 Protocol
5.5. MIPv4プロトコル
o The solution MUST adhere to MIPv4 protocol [RFC3344]. That is,
the solution MUST NOT impose any changes that violate MIPv4
protocol.
o ソリューションはMIPv4プロトコル[RFC3344]を固く守らなければなりません。 すなわち、ソリューションはMIPv4プロトコルに違反する少しの変化も課してはいけません。
o The solution MAY introduce new extensions to MIPv4 nodes per
guidelines specified in the MIPv4 protocol [RFC3344]. However, in
order to overcome barriers to deployment, it is highly desirable
to avoid any changes to MIPv4 mobility agents such as the FA and
HA.
o ソリューションは1MIPv4プロトコル[RFC3344]で指定されたガイドラインあたりのMIPv4ノードに新しい拡大を紹介するかもしれません。 しかしながら、展開にバリアを襲うために、FAやHAなどのMIPv4移動性エージェントへのどんな変化も避けるのは非常に望ましいです。
o The solution MAY require more than one instance of MIPv4 running
in parallel (multiple encapsulation).
o ソリューションは平行に稼働するMIPv4(複数のカプセル化)の1つ以上のインスタンスを必要とするかもしれません。
5.6. Handoff Overhead
5.6. 移管オーバーヘッド
o It is imperative to keep the key management overhead down to a
minimum, in order to support fast handoffs across IP subnets.
Therefore, the solution MUST propose a mechanism to avoid or
minimize IPsec tunnel SA renegotiation and IKE renegotiation as
the MN changes its current point of network attachment.
o かぎ管理がオーバーヘッドであることを最小限まで保つのは必須です、IPサブネットの向こう側に速いhandoffsをサポートするために。 したがって、ソリューションは、ミネソタがネットワーク付属の現在のポイントを変えるのに従って、IPsecトンネルSA renegotiationとIKE renegotiationを避けるか、または最小にするためにメカニズムを提案しなければなりません。
5.7. Scalability, Availability, Reliability, and Performance
5.7. スケーラビリティ、有用性、信頼性、およびパフォーマンス
o The solution complexity MUST increase at most linearly with the
number of MNs registered and accessing resources inside the
Intranet.
o ソリューションの複雑さは高々直線的に示されるMNsの数とイントラネットの中でリソースにアクセスする状態で増加しなければなりません。
o The solution MAY introduce additional header or tunneling overhead
if needed.
o 必要であるなら、ソリューションは追加ヘッダーかトンネリングオーバーヘッドを紹介するかもしれません。
5.8. Functional Entities
5.8. 機能的な実体
o The solution MAY introduce new MIPv4-compliant functional
entities.
o ソリューションは新しいMIPv4対応することの機能的な実体を導入するかもしれません。
5.9. Implications of Intervening NAT Gateways
5.9. 介入しているNATゲートウェイの含意
o The solution MUST be able to work with the existing MIPv4 and
IPsec NAT traversal solutions [RFC3519] [RFC3715] [RFC3947].
o ソリューションは既存のMIPv4とIPsec NAT縦断対策[RFC3519][RFC3715][RFC3947]で働くことができなければなりません。
Adrangi & Levkowetz Informational [Page 15] RFC 4093 MIPv4 VPN Traversal Problem Statement August 2005
[15ページ]RFC4093MIPv4 VPN縦断問題声明2005年8月の情報のAdrangi&Levkowetz
5.10. Security Requirements
5.10. セキュリティ要件
o The solution MUST provide security that is not inferior to what is
already provided to existing "nomadic computing" remote access
users; i.e., for confidentiality, authentication, message
integrity, protection against replay attacks, and related security
services.
o ソリューションは「遊牧民的なコンピューティング」遠隔アクセスのユーザを既に存在するのに提供されるものに劣っていないセキュリティに提供しなければなりません。 すなわち、秘密性、認証、メッセージの保全、反射攻撃に対する保護、および関連するセキュリティー・サービスのために。
6. Security Considerations
6. セキュリティ問題
This document describes an existing problem and proposes guidelines for possible solutions; as such, its security implications are indirect, through the guidelines it proposes for the solutions. Section 5.10 gives the relevant security requirements.
このドキュメントは、既存の問題について説明して、可能なソリューションのためのガイドラインを提案します。 そういうものとして、セキュリティ含意はそれがソリューションのために提案するガイドラインを通して間接的です。 セクション5.10は関連セキュリティ要件を与えます。
7. Acknowledgements
7. 承認
The authors who contributed text to this document were, in no particular order: Farid Adrangi, Milind Kulkarni, Gopal Dommety, Eli Gelasco, Qiang Zhang, Sami Vaarala, Dorothy Gellert, Nitsan Baider, and Henrik Levkowetz.
このドキュメントにテキストを寄付した作者はどんな特定のオーダーにもいませんでした: ファリドAdrangi、Milind Kulkarni、ゴパルDommety、イーライGelasco、Qiangチャン、サミVaarala、ドロシー・ゲラート、Nitsan Baider、およびHenrik Levkowetz。
The authors would like to thank other contributors, especially Prakash Iyer, Mike Andrews, Ranjit Narjala, Joe Lau, Kent Leung, Alpesh Patel, Phil Roberts, Hans Sjostrand, Serge Tessier, Antti Nuopponen, Alan O'Neill, Gaetan Feige, and Brijesh Kumar, for their feedback and help in improving this document.
彼らのフィードバックについて他の貢献者(特にプラカシュ・アイヤル)のマイク・アンドリュース、ランジットNarjala、ジョー・ラウ、ケントレオン、Alpeshパテル、フィル・ロバーツ、ハンス・シェストランド、セルジュ・テシエ、Antti Nuopponen、アラン・オニール、ガエタン・フェイジ、およびBrijeshクマーに感謝します、そして、作者はこのドキュメントを改良するのを手伝いたがっています。
Adrangi & Levkowetz Informational [Page 16] RFC 4093 MIPv4 VPN Traversal Problem Statement August 2005
[16ページ]RFC4093MIPv4 VPN縦断問題声明2005年8月の情報のAdrangi&Levkowetz
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3344] パーキンス、C.、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
8.2. Informative References
8.2. 有益な参照
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2003] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
Network Address Translation (NAT) Devices", RFC 3519, May
2003.
[RFC3519] Levkowetz、H.、およびS.Vaarala(「ネットワークアドレス変換(NAT)デバイスのモバイルIP縦断」、RFC3519)は2003がそうするかもしれません。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] AbobaとB.とW.ディクソン、「IPsec-ネットワーク・アドレス翻訳(NAT)互換性要件」、RFC3715、2004年3月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC3947] Kivinen、T.、Swander、B.、Huttunen、A.、およびV.ボルペ、「IKEでのNAT縦断の交渉」、RFC3947、2005年1月。
Adrangi & Levkowetz Informational [Page 17] RFC 4093 MIPv4 VPN Traversal Problem Statement August 2005
[17ページ]RFC4093MIPv4 VPN縦断問題声明2005年8月の情報のAdrangi&Levkowetz
Authors' Addresses
作者のアドレス
Farid Adrangi Intel Corporation 2111 N.E. 25th Avenue Hillsboro OR USA
ファリドAdrangiインテル社2111の東北の第25Avenueのヒルズバロか米国
Phone: +1 503-712-1791 EMail: farid.adrangi@intel.com
以下に電話をしてください。 +1 503-712-1791 メールしてください: farid.adrangi@intel.com
Henrik Levkowetz Ericsson Research Torshamsgatan 23 SE-164 80 Stockholm SWEDEN
Henrik Levkowetzエリクソン研究Torshamsgatan23SE-164 80ストックホルムスウェーデン
Phone: +46 7 08 32 16 08 EMail: henrik@levkowetz.com
以下に電話をしてください。 +46 7 08 32 16 08はメールされます: henrik@levkowetz.com
Adrangi & Levkowetz Informational [Page 18] RFC 4093 MIPv4 VPN Traversal Problem Statement August 2005
[18ページ]RFC4093MIPv4 VPN縦断問題声明2005年8月の情報のAdrangi&Levkowetz
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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.
このドキュメントは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機能のための基金は現在、インターネット協会によって提供されます。
Adrangi & Levkowetz Informational [Page 19]
Adrangi&Levkowetz情報です。[19ページ]
一覧
スポンサーリンク
