Network Working Group F. Le
Request for Comments: 4487 CMU
Category: Informational S. Faccin
B. Patil
Nokia
H. Tschofenig
Siemens
May 2006
Mobile IPv6 and Firewalls: Problem Statement
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document captures the issues that may arise in the deployment of IPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such as General Packet Radio Service / Universal Mobile Telecommunications System (GPRS/UMTS) and CDMA2000 networks.
この文書では、彼らがモバイルIPv6とファイアウォールをサポートしている場合、IPv6ネットワークの展開で発生する可能性のある問題をキャプチャします。問題だけでなく、企業ネットワークを保護するファイアウォールに適用可能であるが、このような汎用パケット無線サービス/ユニバーサル移動体通信システム（GPRS / UMTS）およびCDMA2000ネットワークなどの3Gモバイルネットワークにも適用可能です。
The goal of this document is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions.
このドキュメントの目標は、ファイアウォールとモバイルIPv6の問題を強調し、さらなる議論のためのイネーブラとして機能することです。ここで特定された問題は、適切なソリューションを開発することによって解決することができます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Abbreviations ...................................................4
4. Overview of Firewalls ...........................................4
5. Analysis of Various Scenarios Involving MIP6 Nodes and
Firewalls .......................................................6
5.1. Scenario Where the Mobile Node Is in a Network
Protected by Firewall(s) ...................................7
5.2. Scenario Where the Correspondent Node Is in a
Network Protected by Firewall(s) ...........................9
5.3. Scenario Where the HA Is in a Network Protected by
Firewall(s) ...............................................12
5.4. Scenario Where the MN Moves to a Network Protected by
Firewall(s) ...............................................12
6. Conclusions ....................................................13
7. Security Considerations ........................................14
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................14
Appendix A. Applicability to 3G Networks ..........................15
Network elements such as firewalls are an integral aspect of a majority of IP networks today, given the state of security in the Internet, threats, and vulnerabilities to data networks. Current IP networks are predominantly based on IPv4 technology, and hence firewalls have been designed for these networks. Deployment of IPv6 networks is currently progressing, albeit at a slower pace. Firewalls for IPv6 networks are still maturing and in development.
ファイアウォールなどのネットワーク要素は、データネットワークにインターネット、脅威、脆弱性のセキュリティの状態を与えられたIPネットワークの大多数の今日の不可欠な側面です。現在のIPネットワークは、主にIPv4の技術に基づいており、したがって、ファイアウォールは、これらのネットワークのために設計されています。遅いペースではあるIPv6ネットワークの展開は、現在、進められています。 IPv6ネットワークのためのファイアウォールは、まだ成熟し、開発中されています。
Mobility support for IPv6 has been standardized as specified in RFC 3775. Given the fact that Mobile IPv6 is a recent standard, most firewalls available for IPv6 networks do not support Mobile IPv6.
IPv6のモビリティサポートは、Mobile IPv6は、最近の標準であり、IPv6ネットワークで利用可能なほとんどのファイアウォールは、モバイルIPv6をサポートしていないという事実を考えるとRFC 3775.に指定されている標準化されています。
Unless firewalls are aware of Mobile IPv6 protocol details, these security devices will interfere with the smooth operation of the protocol and can be a detriment to deployment.
ファイアウォールは、モバイルIPv6プロトコルの詳細を認識していない限り、これらのセキュリティデバイスは、プロトコルの円滑な運営を妨害すると展開を損なうことができます。
Mobile IPv6 enables IP mobility for IPv6 nodes. It allows a mobile IPv6 node to be reachable via its home IPv6 address irrespective of any link that the mobile attaches to. This is possible as a result of the extensions to IPv6 defined in the Mobile IPv6 specification [1].
モバイルIPv6は、IPv6ノードのIPモビリティを可能にします。これは、モバイルIPv6ノードに関係なく、モバイルがに接続することを任意のリンクのそのホームIPv6アドレス経由で到達可能にすることができます。これは、モバイルIPv6仕様[1]で定義されたIPv6への拡張の結果として可能です。
Mobile IPv6 protocol design also incorporates a feature termed Route Optimization. This set of extensions is a fundamental part of the protocol that enables optimized routing of packets between a mobile node and its correspondent node and therefore optimized performance of the communication.
モバイルIPv6プロトコルの設計はまた、ルート最適化と呼ばれる機能が組み込まれています。拡張機能のセットは、モバイルノードとコレスポンデントノードとの通信の、したがって最適化された性能との間のパケットの最適なルーティングを可能にするプロトコルの基本的な部分です。
In most cases, current firewall technologies, however, do not support Mobile IPv6 or are not even aware of Mobile IPv6 headers and extensions. Since most networks in the current business environment deploy firewalls, this may prevent future large-scale deployment of the Mobile IPv6 protocol.
ほとんどの場合、現在のファイアウォール技術は、しかし、モバイルIPv6をサポートしていない、あるいはモバイルIPv6ヘッダと拡張を認識していません。現在のビジネス環境の中で最もネットワークがファイアウォールを展開しているので、これはモバイルIPv6プロトコルの将来の大規模な展開を防ぐことができます。
This document presents in detail some of the issues that firewalls present for Mobile IPv6 deployment, as well as the impact of each issue.
この文書では、詳細なモバイルIPv6の展開だけでなく、各問題の影響のために存在ファイアウォールの問題のいくつかを紹介します。
Return Routability Test (RRT): The Return Routability Test is a procedure defined in RFC 3775 [1]. It is performed prior to the Route Optimization (RO), where a mobile node (MN) instructs a correspondent node (CN) to direct the mobile node's data traffic to its claimed care-of address (CoA). The Return Routability procedure provides some security assurance and prevents the misuse of Mobile IPv6 signaling to maliciously redirect the traffic or to launch other attacks.
リターンルータビリティテスト（RRT）：リターンルータビリティテストは、[1] RFC 3775で定義された手順です。それは前に、移動ノード（MN）はその主張気付アドレス（CoA）にモバイルノードのデータトラフィックを指示するために、通信相手ノード（CN）を指示ルート最適化（RO）に行われます。リターンルータビリティ手順は、いくつかのセキュリティ保証を提供し、悪意を持ってトラフィックをリダイレクトしたり、他の攻撃を開始するためのシグナリングモバイルIPv6の不正使用を防止します。
This document uses the following abbreviations:
このドキュメントでは、次の略語を使用しています：
o CN: Correspondent Node
O CN：相手ノード
o CoA: Care of Address
OアシルCoA：気付アドレス
o CoTI: Care of Test Init
OのCoTI：試験開始のケア
o HA: Home Agent
またはHA：ホームエージェント
o HoA: Home Address
OのHoA：ホームアドレス
o HoTI: Home Test Init
OのHoTI：ホーム試験開始
o HoT: Home Test
OのHoT：ホームテスト
o MN: Mobile Node
OのMN：モバイルノード
o RO: Route Optimization
お ろ： ろうて おｐちみざちおん
o RRT: Return Routability Test
O RRT：リターンルータビリティテスト
The following section provides a brief overview of firewalls. It is intended as background information so that issues with the Mobile IPv6 protocol can then be presented in detail in the following sections.
次のセクションでは、ファイアウォールの簡単な概要を提供します。モバイルIPv6プロトコルの問題は、次のセクションで詳細に提示することができるように、背景情報として意図されています。
There are different types of firewalls, and state can be created in these firewalls through different methods. Independent of the adopted method, firewalls typically look at five parameters of the traffic arriving at the firewalls: o Source IP address
そこのファイアウォールの異なる種類があり、状態は異なる方法でこれらのファイアウォール内に作成することができます。採用方法の独立した、ファイアウォールは通常、ファイアウォールに到着するトラフィックの5つのパラメータを見て：送信元IPアドレスO
o Destination IP address
O宛先IPアドレス
o Protocol type
Oプロトコル種別
o Source port number
O送信元ポート番号
o Destination port number
O宛先ポート番号
Based on these parameters, firewalls usually decide whether to allow the traffic or to drop the packets. Some firewalls may filter only incoming traffic, while others may also filter outgoing traffic.
これらのパラメータに基づいて、ファイアウォールは、通常のトラフィックを許可するか、パケットをドロップするかどうかを決定します。他の人も発信トラフィックをフィルタリングすることができる一方で、一部のファイアウォールでは、着信トラフィックだけをフィルタリングすることができます。
According to Section 3.29 of RFC 2647 [2], stateful packet filtering refers to the process of forwarding or rejecting traffic based on the contents of a state table maintained by a firewall. These types of firewalls are commonly deployed to protect networks from different threats, such as blocking unsolicited incoming traffic from the external networks. The following briefly describes how these firewalls work since they can create additional problems with the Mobile IPv6 protocol as described in the subsequent sections.
RFC 2647のセクション3.29によれば、[2]、ステートフルパケットフィルタリングファイアウォールによって維持される状態テーブルの内容に基づいて転送または拒否トラフィックのプロセスを指します。ファイアウォールのこれらのタイプは、一般的に、このような外部のネットワークから迷惑着信トラフィックをブロックするなど、さまざまな脅威からネットワークを保護するために配備されています。簡単に、次の次のセクションで説明するように、彼らはモバイルIPv6プロトコルとの付加的な問題を作成することができますので、これらのファイアウォールがどのように機能するかについて説明します。
In TCP, an MN sends a TCP SYN message to connect to another host in the Internet.
TCPでは、MNは、インターネットで別のホストに接続するためのTCP SYNメッセージを送信します。
Upon receiving that SYN packet, the firewall records the source IP address, the destination IP address, the Protocol type, the source port number, and the destination port number indicated in that packet before transmitting it to the destination.
そのSYNパケットを受信すると、ファイアウォールは、送信元IPアドレス、宛先IPアドレス、プロトコルタイプ、送信元ポート番号、宛先に送信する前に、そのパケットが示す宛先ポート番号を記録します。
When an incoming message from the external networks reaches the firewall, it searches the packet's source IP address, destination IP address, Protocol type, source port number, and destination port number in its entries to see if the packet matches the characteristics of a request sent previously. If so, the firewall allows the packet to enter the network. If the packet was not solicited from an internal node, the packet is blocked.
外部ネットワークからの着信メッセージがファイアウォールに到達すると、それは、パケットが送信された要求の特性に合致するかどうかを確認するために、パケットの送信元IPアドレス、宛先IPアドレス、プロトコルタイプ、送信元ポート番号、およびそのエントリの宛先ポート番号を検索します以前に。その場合、ファイアウォールは、パケットがネットワークに侵入することができます。パケットが内部ノードから勧誘されなかった場合は、パケットがブロックされています。
When the TCP close session packets are exchanged or after some configurable period of inactivity, the associated entry in the firewall is deleted. This mechanism prevents entries from remaining when TCP are abruptly terminated.
TCPクローズセッションパケットを交換したりしている場合、非アクティブのいくつかの設定可能な期間の後、ファイアウォール内の関連エントリが削除されます。このメカニズムは、TCPが突然終了したとき、残りのエントリを防ぐことができます。
A similar entry is created when using UDP. The difference with this transport protocol is that UDP is connectionless and does not have packets signaling the initiation or termination of a session. Consequently, the duration of the entries relies solely on timers.
UDPを使用した場合と同様のエントリが作成されます。このトランスポートプロトコルとの違いは、UDPはコネクションレスで、セッションの開始や終了をシグナリングパケットを持っていないということです。このため、エントリの期間は、タイマーのみに依存しています。
The following section describes various scenarios involving MIP6 nodes and firewalls and also presents the issues related to each scenario.
次のセクションでは、MIP6ノードとファイアウォールを含むさまざまなシナリオを説明し、また、各シナリオに関連する問題を提示します。
The Mobile IPv6 specifications define three main entities: the mobile node (MN), the correspondent node (CN), and the home agent (HA). Each of these entities may be in a network protected by one or many firewalls:
モバイルノード（MN）、コレスポンデントノード（CN）、およびホームエージェント（HA）：モバイルIPv6の仕様は、3つの主要なエンティティを定義します。これらのエンティティのそれぞれは、一つまたは多くのファイアウォールで保護されたネットワークであってもよいです。
o Section 5.1 analyzes the issues when the MN is in a network protected by firewall(s)
MNがあるときにO部5.1は、ファイアウォールで保護されたネットワーク内の問題を分析し、（S）
o Section 5.2 analyzes the issues when the CN is in a network protected by firewall(s)
CNのときOセクション5.2は、ファイアウォールによって保護されたネットワーク内の問題を分析し、（S）
o Section 5.3 analyzes the issues when the HA is in a network protected by firewall(s)
HAである場合Oセクション5.3は、ファイアウォールによって保護されたネットワーク内の問題を分析し、（S）
The MN may also be moving from an external network, to a network protected by firewall(s). The issues of this case are described in Section 5.4.
MNはまた、ファイアウォール（S）で保護されたネットワークに、外部ネットワークから移動してもよいです。この例の問題は、5.4節で説明されています。
Some of the described issues (e.g., Sections 5.1 and 5.2) may require modifications to the protocols or to the firewalls, and others (e.g., Section 5.3) may require only that appropriate rules and configuration be in place.
上記問題（例えば、セクション5.1および5.2）のいくつかは、プロトコルまたはファイアウォールへの変更を必要とするかもしれない、そして他の（例えば、第5.3節）は、適切なルールと構成が適所にあることのみを必要とするかもしれません。
5.1. Scenario Where the Mobile Node Is in a Network Protected by Firewall(s)
5.1. モバイルノードは、ファイアウォールで保護されたネットワークにされるシナリオ（S）
Let's consider MN A, in a network protected by firewall(s).
のは、ファイアウォール（S）で保護されたネットワークでは、MN Aを考えてみましょう。
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +---+ +----+ of A +---+
| | A | | FW | | B |
| +---+ +----+ +---+
|Internal | External
| MN | Node
| |
+----------------+
Network protected
Figure 1: Issues between MIP6 and firewalls when MN is in a network protected by firewalls
図1：MIP6とファイアウォールとの間の問題MNがファイアウォールによって保護されたネットワークであります
A number of issues need to be considered:
多くの問題を考慮する必要があります。
Issue 1: When MN A connects to the network, it should acquire a local IP address (CoA) and send a Binding Update (BU) to its Home Agent to update the HA with its current point of attachment. The Binding Updates and Acknowledgements should be protected by IPsec ESP according to the MIPv6 specifications [1]. However, as a default rule, many firewalls drop IPsec ESP packets because they cannot determine whether inbound ESP packets are legitimate. It is difficult or impossible to create useful state by observing the outbound ESP packets. This may cause the Binding Updates and Acknowledgements between the mobile nodes and their home agent to be dropped.
問題1：MN Aがネットワークに接続すると、それはローカルIPアドレス（CoA）を取得し、添付ファイルの現在のポイントとHAを更新するために、そのホームエージェントにバインディング・アップデート（BU）を送信する必要があります。結合更新と謝辞[1]のMIPv6仕様に応じたIPsec ESPによって保護されるべきです。彼らはインバウンドESPパケットが正当であるかどうかを判断できないためただし、デフォルトルールとして、多くのファイアウォールでは、IPsec ESPパケットをドロップします。アウトバウンドESPパケットを観察することによって有益な状態を作成することは困難または不可能です。これは、モバイルノードとそのホームエージェントとの間のバインディング更新と謝辞がドロップされる可能性があります。
Issue 2: Let's now consider a node in the external network, B, trying to establish a communication with MN A.
問題2：MN Aとの通信を確立しようとすると、今度は、外部ネットワーク、Bでノードを考えてみましょう
* B sends a packet to the mobile node's home address.
* Bは、モバイルノードのホームアドレスにパケットを送信します。
* The packet is intercepted by the MN's home agent, which tunnels it to the MN's CoA [1].
*パケットはMNのCoA [1]にそれをトンネルMNのホーム・エージェントによってインターセプトされます。
* When arriving at the firewall(s) protecting MN A, the packet may be dropped since the incoming packet may not match any existing state. As described in Section 4, stateful inspection packet filters (for example) typically drop unsolicited incoming traffic.
着信パケットが既存の状態と一致しない可能性があるため* MN Aを保護するファイアウォール（S）に到達すると、パケットは廃棄されてもよいです。セクション4で説明したように、（例えば）ステートフルインスペクションパケットフィルタは、典型的には、一方的な着信トラフィックをドロップします。
* B will thus not be able to contact MN A and establish a communication.
* Bは、このようにMN Aに連絡し、通信を確立することができません。
Even though the HA is updated with the location of an MN, firewalls may prevent correspondent nodes from establishing communications when the MN is in a network protected by firewall(s).
HAは、MNの位置が更新されるにもかかわらず、MNがファイアウォール（S）で保護されたネットワークにある場合、ファイアウォールは、通信を確立するから対応ノードを防止することができます。
Issue 3: Let's assume a communication between MN A and an external node B. MN A may want to use Route Optimization (RO) so that packets can be directly exchanged between the MN and the CN without passing through the HA. However, the firewalls protecting the MN might present issues with the Return Routability procedure that needs to be performed prior to using RO.
問題3：のは、MN AおよびMN Aがパケットを直接HAを経由せずにMNとCNの間で交換することができるように、ルート最適化（RO）を使用することもでき、外部ノードBとの間の通信を仮定する。しかし、MNを保護するファイアウォールは、ROを使用する前に実行する必要があるリターンルータビリティ手順の問題を提示する可能性があります。
According to the MIPv6 specifications, the Home Test message of the RRT must be protected by IPsec in tunnel mode. However, firewalls might drop any packet protected by ESP, since the firewalls cannot analyze the packets encrypted by ESP (e.g., port numbers). The firewalls may thus drop the Home Test messages and prevent the completion of the RRT procedure.
MIPv6の仕様によれば、RRTのホームテストメッセージは、トンネルモードのIPsecによって保護されなければなりません。ファイアウォールがESP（例えば、ポート番号）で暗号化されたパケットを解析することができないので、ファイアウォールでは、ESPで保護されたパケットをドロップする可能性があります。ファイアウォールは、このようにホームテストメッセージを削除し、RRT手順の完了を防止することができます。
Issue 4: Let's assume that MN A successfully sends a Binding Update to its home agent (resp. correspondent nodes) -- which solves issue 1 (resp. issue 3) -- and that the subsequent traffic is sent from the HA (resp. CN) to the MN's CoA. However there may not be any corresponding state in the firewalls. The firewalls protecting A may thus drop the incoming packets.
（。RESP通信員ノード）：問題4者は、MN Aが正常にそのホームエージェントにバインディングアップデートを送信すると仮定しよう - 解決問題1 - とその後のトラフィックはHA（それぞれから送信されていること（それぞれの問題3。）。 MNのCoAをCN）。しかし、ファイアウォール内の任意の対応する状態が存在しなくてもよいです。 Aを保護するファイアウォールは、このように着信パケットをドロップすることができます。
The appropriate states for the traffic to the MN's CoA need to be created in the firewall(s).
MNのCoAへのトラフィックのための適切な状態は、ファイアウォール（複数可）で作成する必要があります。
Issue 5: When MN A moves, it may move to a link that is served by a different firewall. MN A might be sending a BU to its CN; however, incoming packets may be dropped at the firewall, since the firewall on the new link that the MN attaches to does not have any state that is associated with the MN.
問題5：移動をMNすると、それは別のファイアウォールによって提供されるリンクに移動してもよいです。 MN Aは、そのCNへBUを送信することがあります。ただし、着信パケットは、MNは、MNに関連付けられた状態を持っていないために添付していること、新しいリンク上のファイアウォールから、ファイアウォールでドロップすることができます。
The issues described above result from the fact that the MN is behind the firewall. Consequently, the MN's communication capability with other nodes is affected by the firewall rules.
問題は、MNがファイアウォールの背後にあるという事実から、その結果、上記の。その結果、他のノードとMNの通信機能は、ファイアウォールルールの影響を受けています。
5.2. Scenario Where the Correspondent Node Is in a Network Protected by Firewall(s)
5.2. 相手ノードがファイアウォールで保護されたネットワークにされるシナリオ（S）
Let's consider an MN in a network, communicating with a Correspondent Node C in a network protected by firewall(s). There are no issues with the presence of a firewall in the scenario where the MN is sending packets to the CN via a reverse tunnel that is set up between the MN and HA. However, firewalls may present different issues to Route Optimization.
のは、ファイアウォール（S）で保護されたネットワークにおける通信相手ノードのCとの通信、ネットワーク内のMNを考えてみましょう。 MNは、MNとHAとの間に設定されている逆方向トンネルを介してCNにパケットを送信しているシナリオでは、ファイアウォールの存在と全く問題がありません。しかし、ファイアウォールは経路最適化にさまざまな問題を提示することができます。
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +---+ +----+ of B
| |CN | | FW |
| | C | +----+
| +---+ | +---+
| | | B |
| | +---+
+----------------+ External Mobile
Network protected Node
by a firewall
Figure 2: Issues between MIP6 and firewalls when a CN is in a network protected by firewalls
図2：MIP6とファイアウォールとの間の問題CNは、ファイアウォールによって保護されたネットワークであります
The following issues need to be considered:
次の問題を考慮する必要があります。
Issue 1: The MN (MN B) should use its Home Address (HoA B) when establishing the communication with the CN (CN C), if MN B wants to take advantage of the mobility support provided by the Mobile IPv6 protocol for its communication with CN C. The state created by the firewall protecting CN C is therefore created based on the IP address of C (IP C) and the home address of Node B (IP HoA B). The states may be created via different means, and the protocol type as well as the port numbers depend on the connection setup.
問題1：CN（CN C）との通信を確立するときにMN Bはその通信のためのモバイルIPv6プロトコルが提供するモビリティサポートを利用したい場合はMN（MN B）は、そのホームアドレス（HoA B）を使用する必要がありますCN CとCN Cを保護するファイアウォールによって作成された状態は、したがって、CのIPアドレス（IP C）とノードB（IP HoAとB）のホームアドレスに基づいて作成されます。状態は、異なる手段を介して作成することができ、及びプロトコルタイプ並びにポート番号は、接続設定に依存します。
Uplink packet filters (1)
アップリンクパケットフィルタ（1）
Source IP address: IP C
送信元IPアドレス：IP C
Destination IP address: HoA B
送信先IPアドレス：HoAをB
Protocol Type: TCP/UDP
プロトコルタイプ：TCP / UDP
Source Port Number: #1
送信元ポート番号：＃1
Destination Port Number: #2
宛先ポート番号：＃2
Downlink packet filters (2)
ダウンリンク・パケット・フィルタ（2）
Source IP address: HoA B
送信元IPアドレス：HoAをB
Destination IP address: IP C
送信先IPアドレス：IP C
Protocol Type: TCP/UDP
プロトコルタイプ：TCP / UDP
Source Port Number: #2
送信元ポート番号：＃2
Destination Port Number: #1
宛先ポート番号：＃1
Nodes C and B might be topologically close to each other, while B's home agent may be far away, resulting in a trombone effect that can create delay and degrade the performance. MN B may decide to initiate the route optimization procedure with Node C. Route optimization requires MN B to send a Binding Update to Node C in order to create an entry in its binding cache that maps the MN's home address to its current care-of-address. However, prior to sending the binding update, the mobile node must first execute a Return Routability Test:
Bのホームエージェントは、遅延を作成し、パフォーマンスが低下する可能性がトロンボーンの効果が得られ、遠くかもしれないがノードCとBは、互いに位相幾何学的に近いかもしれません。 MN BはノードCルートの最適化とルート最適化手順を開始することを決定することが、現在の気付にMNのホームアドレスをマッピングし、そのバインディングキャッシュにエントリを作成するために、ノードCへのバインディングアップデートを送信するためにMNのBを必要とします住所。しかし、バインディング更新を送信する前に、モバイルノードは最初リターンルータビリティテストを実行する必要があります。
* Mobile Node B has to send a Home Test Init (HoTI) message via its home agent and
*モバイルノードBは、そのホームエージェントを介してホーム試験開始（HoTIに）メッセージを送信する必要があると
* a Care of Test Init (COTI) message directly to its Correspondent Node C.
*試験開始のケア（COTI）メッセージを直接そのコレスノードCへ
The Care of Test Init message is sent using the CoA of B as the source address. Such a packet does not match any entry in the protecting firewall (2). The CoTi message will thus be dropped by the firewall.
試験開始メッセージのケアは、送信元アドレスとしてBのCoAを使用して送信されます。そのようなパケットは、ファイアウォール保護（2）内の任意のエントリと一致しません。 CoTiメッセージは、このようにファイアウォールによって廃棄されます。
The HoTI is a Mobility Header packet, and as the protocol type differs from the established state in the firewall (see (2)), the HoTI packet will also be dropped.
（（2）参照）のHoTIは、モビリティヘッダパケットであり、プロトコルタイプは、ファイアウォールで確立された状態と異なるように、たHoTIパケットも破棄されます。
As a consequence, the RRT cannot be completed, and route optimization cannot be applied. Every packet has to go through Node B's home agent and tunneled between B's home agent and B.
その結果、RRTを完了することはできませんし、ルート最適化を適用することはできません。すべてのパケットは、ノードBのホームエージェントを介して行かなければならないとBのホームエージェントとBの間でトンネリング
+----------------+
| +----+ HoTI (HoA) +----+
| | FW |X<---------------|HA B|
| +----X +----+
| +------+ | ^ CoTI & HoTI ^
| | CN C | | | dropped by FW |
| +------+ | | | HoTI
| | | |
| | | CoTI (CoA)+------+
| | +------------------| MN B |
+----------------+ +------+
Network protected External Mobile
by a firewall Node
Figure 3: Issues with Return Routability Test
図3：リターンルータビリティテストの問題
Issue 2: Let's assume that the Binding Update to the CN is successful; the firewall(s) might still drop packets that are:
問題2：のは、CNへのバインディングアップデートが成功したと仮定しよう。ファイアウォール（複数可）残っているパケットをドロップすることがあります。
1. coming from the CoA, since these incoming packets are sent from the CoA and do not match the Downlink Packet filter (2).
これらの着信パケットは、アシルCoAから送信され、（2）ダウンリンクパケットフィルタに一致しないので、1は、アシルCoAから来ます。
2. sent from the CN to the CoA if uplink packet filters are implemented. The uplink packets are sent to the MN's CoA and do not match the uplink packet filter (1).
アップリンクパケットフィルタが実装されている場合は、2のCoAにCNから送信されました。アップリンクパケットはMNのCoAに送信され、アップリンクパケットフィルタに一致しない（1）。
The packet filters for the traffic sent to (resp. from) the CoA need to be created in the firewall(s).
送られた（それぞれから）トラフィックに対するパケットフィルタCoAがファイアウォール（複数可）で作成する必要があります。
Requiring the firewalls to update the connection state upon detecting Binding Update messages from a node outside the network protected by the firewall does not appear feasible or desirable, since currently the firewall does not have any means to verify the validity of Binding Update messages and therefore to modify the state information securely. Changing the firewall states without verifying the validity of the Binding Update messages could lead to denial of service attacks. Malicious nodes may send fake binding updates, forcing the firewall to change its state information, and therefore leading the firewall to drop packets from the connections that use the legitimate addresses. An adversary might also use an address update to enable its own traffic to pass through the firewall and enter the network.
現在のファイアウォールが更新メッセージをバインディングの妥当性を検証するための任意の手段を有し、従ってにないため、ファイアウォールによって保護されたネットワーク外のノードからのバインディング更新メッセージを検出する接続状態を更新するために、ファイアウォールを必要とすることは、実現可能な又は望ましい現れませんしっかりと状態情報を変更します。バインディング更新メッセージの妥当性を検証せずにファイアウォールの状態を変更すると、サービス拒否攻撃につながる可能性があります。悪意のあるノードは、その状態情報を変更するためにファイアウォールを強制的に、偽のバインディング更新を送信し、したがって、正当なアドレスを使用する接続からのパケットをドロップするようにファイアウォールをリードすることができます。敵はまた、ファイアウォールを通過してネットワークに侵入するために、独自のトラフィックを有効にするには、アドレス更新を使用する場合があります。
Issue 3: Let's assume that the Binding Update to the CN is successful. The CN may be protected by different firewalls, and as a result of the MN's change of IP address, incoming and outgoing traffic may pass through a different firewall. The new firewall may not have any state associated with the CN, and incoming packets (and potentially outgoing traffic as well) may be dropped at the firewall.
問題3：のは、CNへのバインディングアップデートが成功したと仮定しよう。 CNは異なるファイアウォールによって保護されていてもよく、およびIPアドレスのMNの変化の結果として、着信および発信トラフィックは、別のファイアウォールを通過してもよいです。新しいファイアウォールは、ファイアウォールでドロップされてもよいCN、及び着信パケット（および同様に潜在的に発信トラフィック）に関連する任意の状態を有していなくてもよいです。
Firewall technology allows clusters of firewalls to share state [3]. This, for example, allows the support of routing asymmetry. However, if the previous and the new firewalls, through which the packets are routed after the Binding Update has been sent, do not share state, this may result in packets being dropped at the new firewall. As the new firewall does not have any state associated with the CN, incoming packets (and potentially outgoing traffic as well) may be dropped at the new firewall.
ファイアウォール技術は、ファイアウォールのクラスタが状態を共有することができます[3]。これは、例えば、非対称ルーティングのサポートを可能にします。パケットがバインディングアップデート後に送信する際に経由する、以前と新しいファイアウォールが送信された場合は、状態を共有しない、これはパケットが新しいファイアウォールで廃棄される可能性があります。新しいファイアウォールがCNに関連する任意の状態を持たないように、着信パケット（および同様に潜在的に発信トラフィックは）新しいファイアウォールで滴下してもよいです。
In the scenarios where the home agent is in a network protected by firewall(s), the following issues may exist:
ホームエージェントは、ファイアウォール（S）で保護されたネットワークにあるシナリオでは、以下の問題が存在することがあります。
Issue 1: If the firewall(s) protecting the home agent block ESP traffic, much of the MIPv6 signaling (e.g., Binding Update, HoT) may be dropped at the firewall(s), preventing MN(s) from updating their binding cache and performing Route Optimization, since Binding Update, HoT, and other MIPv6 signaling must be protected by IPsec ESP.
問題1：ホームエージェントブロックESPトラフィックを保護するファイアウォール（s）は、MIPv6のシグナリングの多くが（例えば、バインディングアップデート、ホット）、その結合キャッシュを更新からMN（複数可）を防止し、ファイアウォール（S）でドロップする可能性がある場合そしてルート最適化を実行し、更新、熱い、および他のMIPv6のシグナリングをバインドするのでIPsecのESPによって保護されなければなりません。
Issue 2: If the firewall(s) protecting the home agent block unsolicited incoming traffic (e.g., as stateful inspection packet filters do), the firewall(s) may drop connection setup requests from CNs, and packets from MNs.
問題2：もしホームエージェントブロック迷惑着信トラフィックを保護するファイアウォール（複数可）（例えば、ステートフルインスペクションパケットフィルタがそうであるように）、ファイアウォール（複数可）のMNからの接続設定のCNからの要求、およびパケットをドロップすることがあります。
Issue 3: If the home agent is in a network protected by several firewalls, an MN/CN's change of IP address may result in the passage of traffic to and from the home agent through a different firewall that may not have the states corresponding to the flows. As a consequence, packets may be dropped at the firewall.
問題3：ホームエージェントは、いくつかのファイアウォールで保護されたネットワーク内にある場合は、IPアドレスのMN / CNの変更はに対応する状態を持っていない可能性が異なるファイアウォールを介してホームエージェントへとからのトラフィックの通過をもたらすことができます流れ。その結果、パケットがファイアウォールでドロップすることができます。
Let's consider an HA in a network protected by firewall(s). The following issues need to be investigated:
のは、ファイアウォール（S）で保護されたネットワークでHAを考えてみましょう。次の問題を調査する必要があります
Issue 1: Similarly to issue 1 described in Section 5.1, the MN will send a Binding Update to its home agent after acquiring a local IP address (CoA). The Binding Updates and Acknowledgements should be protected by IPsec ESP according to the MIPv6 specifications [1]. However, as a default rule, many firewalls drop ESP packets. This may cause the Binding Updates and Acknowledgements between the mobile nodes and their home agent to be dropped.
問題1：同様にセクション5.1で説明した1を発行する、MNは、ローカルIPアドレス（CoA）を取得した後にそのホームエージェントにバインディングアップデートを送信します。結合更新と謝辞[1]のMIPv6仕様に応じたIPsec ESPによって保護されるべきです。ただし、デフォルトルールとして、多くのファイアウォールはESPパケットをドロップします。これは、モバイルノードとそのホームエージェントとの間のバインディング更新と謝辞がドロップされる可能性があります。
Issue 2: The MN may be in a communication with a CN, or a CN may be attempting to establish a connection with the MN. In both cases, packets sent from the CN will be forwarded by the MN's HA to the MN's CoA. However, when the packets arrive at the firewall(s), the incoming traffic may not match any existing state, and the firewall(s) may therefore drop it.
問題2：MNはCN、またはCNと通信することができるがMNとの接続を確立しようとすることができます。どちらの場合も、CNから送信されたパケットは、MNのCoAをMNのHAによって転送されます。パケットがファイアウォール（S）に到着したときしかし、着信トラフィックは、既存の状態と一致しない場合があり、ファイアウォール（単数または複数）は、したがって、それをドロップしてもよいです。
Issue 3: If the MN is in a communication with a CN, the MN may attempt to execute an RRT for packets to be route optimized. Similarly to issue 3, Section 5.1, the Home Test message that should be protected by ESP may be dropped by firewall(s) protecting the MN. Firewall(s) may as a default rule drop any ESP traffic. As a consequence, the RRT cannot be completed.
問題3：MNがCNと通信している場合、MNは、ルートが最適化されるパケットのためのRRTを実行しようと試みることができます。同様に3を発行するために、セクション5.1、ESPによって保護されるべきであるホームテストメッセージは、MNを保護するファイアウォール（S）でドロップすることができます。ファイアウォール（複数可）デフォルトルールとして、任意のESPトラフィックをドロップすることがあります。その結果、RRTを完了することはできません。
Issue 4: If the MN is in a communication with a CN, and assuming that the MN successfully sent a Binding Update to its CN to use Route Optimization, packets will then be sent from the CN to the MN's CoA and from the MN's CoA to the CN.
問題4：MNがCNと通信しており、かつMNが正常にルート最適化を使用するには、そのCNにバインディングアップデートを送ったことを仮定した場合、パケットはその後、MNのCoAへとへのMNのCoAからCNから送信されますCN。
Packets sent from the CN to the MN's CoA may, however, not match any existing entry in the firewall(s) protecting the MN, and therefore be dropped by the firewall(s).
MNのCoAをCNから送信されたパケットは、しかしながら、MNを保護するファイアウォール（S）内の既存のエントリと一致しない場合があり、したがって、ファイアウォール（S）によってドロップされます。
If packet filtering is applied to uplink traffic (i.e., traffic sent by the MN), packets sent from the MN's CoA to the CN may not match any entry in the firewall(s) either and may be dropped as well.
パケットフィルタリングは、トラフィックをアップリンクするために適用された場合（すなわち、MNによって送信されるトラフィック）は、CNとMNのCoAから送信されるパケットは、いずれかのファイアウォール（S）内のエントリと一致しない場合があり、同様に滴下してもよいです。
Current firewalls may not only prevent route optimization but may also prevent regular TCP and UDP sessions from being established in some cases. This document describes some of the issues between the Mobile IPv6 protocol and current firewall technologies.
現在のファイアウォールは、ルート最適化を防ぐことができないだけでなく、いくつかのケースでは確立されてから、通常のTCPおよびUDPセッションを防ぐことができます。この文書では、モバイルIPv6プロトコルと現在のファイアウォール技術間の問題のいくつかを説明します。
This document captures the various issues involved in the deployment of Mobile IPv6 in networks that would invariably include firewalls. A number of different scenarios are described, which include configurations where the mobile node, correspondent node, and home agent exist across various boundaries delimited by the firewalls. This enables a better understanding of the issues when deploying Mobile IPv6 as well as the issues for firewall design and policies to be installed therein.
この文書は、必ずファイアウォールが含まれるネットワークにおけるモバイルIPv6の展開に関わる様々な問題をキャプチャします。異なるシナリオの数は、モバイルノード、コレスポンデント・ノード、及びホーム・エージェントは、ファイアウォールによって区切られ、様々な境界を越えて存在する構成を含んでいる、記載されています。これは、モバイルIPv6を導入する問題をより良く理解するだけでなく、ファイアウォールの設計およびポリシーが搭載されるために問題を可能にします。
This document describes several issues that exist between the Mobile IPv6 protocol and firewalls.
この文書では、モバイルIPv6プロトコルとファイアウォールの間に存在するいくつかの問題について説明します。
Firewalls may prevent Mobile IP6 signaling in addition to dropping incoming/outgoing traffic.
ファイアウォールは発信/着信トラフィックをドロップに加えて、モバイルIP6シグナル伝達を防止することができます。
If the firewall configuration is modified in order to support the Mobile IPv6 protocol but not properly configured, many attacks may be possible as outlined above: malicious nodes may be able to launch different types of denial of service attacks.
悪意のあるノードがサービス拒否攻撃の種類を起動することができる場合がファイアウォール構成は、モバイルIPv6プロトコルをサポートするために修正が、正しく設定されていない場合、上記で概説したように、多くの攻撃が可能です。
We would like to thank James Kempf, Samita Chakrabarti, Giaretta Gerardo, Steve Bellovin, Henrik Levkowetz, and Spencer Dawkins for their valuable comments. Their suggestions have helped improve both the presentation and the content of the document.
私たちは、彼らの貴重なコメントのためにジェームス・ケンプ、Samita Chakrabarti、Giarettaヘラルド、スティーブBellovin氏、ヘンリクLevkowetz、およびスペンサードーキンスに感謝したいと思います。彼らの提案は、プレゼンテーションや文書の内容の両方を向上させる助けました。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[2] Newman, D., "Benchmarking Terminology for Firewall Performance", RFC 2647, August 1999.
[2]ニューマン、D.、 "ファイアウォールのパフォーマンスのためのベンチマーク用語"、RFC 2647、1999年8月。
[3] Noble, J., Doug, D., Hourihan, K., Hourihan, K., Stephens, R., Stiefel, B., Amon, A., and C. Tobkin, "Check Point NG VPN-1/ Firewall-1 Advanced Configuration and Troubleshooting", Syngress Publishing Inc., 2003.
[3]ノーブル、J.、ダグ、D.、Hourihan、K.、Hourihan、K.、ステファン、R.、スティーフェル、B.、アモン、A.、およびC. Tobkin、「チェックポイントNG VPN-1 / FireWall-1の高度な構成およびトラブルシューティング」、Syngress出版社、2003年。
[4] Chen, X., Rinne, J., Wiljakka, J., and M. Watson, "Problem Statement for MIPv6 Interactions with GPRS/UMTS Packet Filtering", Work in Progress, January 2006.
[4]チェン、X.、リンネ、J.、Wiljakka、J.、およびM.ワトソン、 "GPRS / UMTSパケットフィルタリングとMIPv6の相互作用のための問題文"、進歩、2006年1月の作業。
Appendix A. Applicability to 3G Networks
3Gネットワークへの付録A.の適用性
In 3G networks, different packet filtering functionalities may be implemented to prevent malicious nodes from flooding or launching other attacks against the 3G subscribers. The packet filtering functionality of 3G networks is further described in [4]. Packet filters are set up and applied to both uplink and downlink traffic: outgoing and incoming data not matching the packet filters is dropped. The issues described in this document also apply to 3G networks.
3Gネットワークでは、異なるパケットフィルタリング機能は、フラッディングまたは3G加入者に対する他の攻撃を悪意のあるノードを防ぐために実施されてもよいです。 3Gネットワークのパケットフィルタリング機能は、さらに、[4]に記載されています。パケットフィルタを設定し、アップリンク及びダウンリンクトラフィックの両方に適用される：パケットフィルタと一致しない発信及び着信データがドロップされます。この文書で説明する問題も3Gネットワークに適用されます。
Authors' Addresses
著者のアドレス
Franck Le Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213 USA
フランク・ル・カーネギーメロン大学5000フォーブス・アベニューピッツバーグ、PA 15213 USA
EMail: franckle@cmu.edu
メールアドレス：franckle@cmu.edu
Stefano Faccin Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA
ステファノFaccinノキア・リサーチセンター6000接続のドライブアーヴィング、TX 75039 USA
EMail: sfaccinstd@gmail.com
メールアドレス：sfaccinstd@gmail.com
Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA
Basavarajパティルノキア6000接続のドライブアーヴィング、TX 75039 USA
EMail: Basavaraj.Patil@nokia.com
メールアドレス：Basavaraj.Patil@nokia.com
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
ハンネスTschofenigシーメンスオットー・ハーンリング6ミュンヘン、バイエルン81739ドイツ
EMail: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com
電子メール：Hannes.Tschofenig@siemens.com URI：http://www.tschofenig.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。