[要約] 要約： RFC 4487は、モバイルIPv6とファイアウォールの問題を説明し、解決策を提案するものです。目的： 1. モバイルIPv6とファイアウォールの相互運用性の問題を特定し、解決策を提供する。 2. モバイルIPv6の展開を促進し、セキュリティ上の問題を解決する。 3. モバイルユーザーのエクスペリエンスを向上させるために、ファイアウォールの制約を克服する方法を提案する。
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
モバイルIPv6およびファイアウォール：問題ステートメント
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).
Copyright（c）The Internet Society（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のモビリティサポートは、RFC 3775で指定されているように標準化されています。モバイルIPv6が最近の標準であるという事実を考えると、IPv6ネットワークで利用可能なほとんどのファイアウォールはモバイルIPv6をサポートしていません。
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.
RETURN ROUDABILITY TEST（RRT）：RETURNルーティング可能性テストは、RFC 3775 [1]で定義されている手順です。ルート最適化（RO）の前に実行されます。ここでは、モバイルノード（MN）が特派員ノード（CN）に、モバイルノードのデータトラフィックを主張されたケアオブアドレス（COA）に向けるよう指示します。返品ルー上の手順は、ある程度のセキュリティ保証を提供し、モバイル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：テストinitのケア
o HA: Home Agent
o HA：ホームエージェント
o HoA: Home Address
o HOA：ホームアドレス
o HoTI: Home Test Init
o Hoti：ホームテストの初期
o HoT: Home Test
o ホット：ホームテスト
o MN: Mobile Node
o MN：モバイルノード
o RO: Route Optimization
o RO：ルート最適化
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つのパラメーターを調べます：oソースIPアドレス
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 [2]のセクション3.29によると、ステートフルパケットフィルタリングは、ファイアウォールによって維持されている状態テーブルの内容に基づいてトラフィックを転送または拒否するプロセスを指します。これらのタイプのファイアウォールは、外部ネットワークからの未承諾の着信トラフィックをブロックするなど、さまざまな脅威からネットワークを保護するために一般的に展開されます。以下は、後続のセクションで説明されているように、モバイル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:
モバイルIPv6仕様は、モバイルノード（MN）、特派員ノード（CN）、およびホームエージェント（HA）の3つの主要なエンティティを定義します。これらの各エンティティは、1つまたは多くのファイアウォールによって保護されているネットワークにある場合があります。
o Section 5.1 analyzes the issues when the MN is in a network protected by firewall(s)
o セクション5.1は、MNがファイアウォールによって保護されているネットワーク内にある場合の問題を分析します
o Section 5.2 analyzes the issues when the CN is in a network protected by firewall(s)
o セクション5.2は、CNがファイアウォールによって保護されているネットワーク内にある場合の問題を分析します
o Section 5.3 analyzes the issues when the HA is in a network protected by firewall(s)
o セクション5.3は、HAがファイアウォールによって保護されているネットワークにある場合の問題を分析します
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は、外部ネットワークからファイアウォールで保護されているネットワークに移動している場合があります。このケースの問題は、セクション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など）には、適切なルールと構成が実施される必要があります。
Let's consider MN A, in a network protected by firewall(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：MNがファイアウォールによって保護されているネットワーク内にある場合のMIP6とファイアウォールの間の問題
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）をホームエージェントに送信する必要があります。拘束力のある更新と謝辞は、MIPV6仕様[1]に従って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のホームエージェントによって傍受され、MNのCOAにトンネルします[1]。
* 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を保護するファイアウォールに到着すると、着信パケットが既存の状態と一致しない可能性があるため、パケットが削除される場合があります。セクション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がファイアウォールによって保護されているネットワークにあるときに、特派員ノードが通信を確立するのを防ぐ場合があります。
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と外部ノードBの間の通信を仮定しましょう。MNAは、HAを通過せずにMNとCNの間でパケットを直接交換できるように、ルート最適化（RO）を使用したい場合があります。ただし、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.
第4号：MN Aがホームエージェント（RESP。CRORENCTINENTノード）にバインディングアップデートを正常に送信すると仮定します。cn）MNのCOAへ。ただし、ファイアウォールに対応する状態はない場合があります。したがって、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 Aが移動すると、別のファイアウォールが提供するリンクに移動する場合があります。MN AはBUをそのCNに送信している可能性があります。ただし、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の通信機能は、ファイアウォールルールの影響を受けます。
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.
ネットワーク内のMNを考えて、ファイアウォールによって保護されているネットワーク内の特派員ノードCと通信しましょう。MNとHAの間に設定された逆トンネルを介してMNがパケットを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：CNがファイアウォールで保護されているネットワーク内にある場合のMIP6とファイアウォールの間の問題
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：MN BがCN（CN C）との通信を確立するとき、MN（MN B）は、MN Bが通信のためにモバイルIPv6プロトコルが提供するモビリティサポートを利用したい場合、CN（CN C）との通信を確立するときにホームアドレス（HOA B）を使用する必要があります。したがって、CN Cを使用すると、CN Cを保護するファイアウォールによって作成された状態は、C（IP C）のIPアドレスとノード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
Destination Port Number: #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:
ノードCとBは互いにトポロジーに近い場合がありますが、Bのホームエージェントは遠く離れている可能性があり、その結果、パフォーマンスを遅らせて劣化させるトロンボーン効果が生じる可能性があります。MN Bは、ノードCを使用してルート最適化手順を開始することを決定する場合があります。ルート最適化では、MN BがノードCにバインディングアップデートを送信する必要があります。住所。ただし、バインディングアップデートを送信する前に、モバイルノードは最初に返品ルー上のテストを実行する必要があります。
* Mobile Node B has to send a Home Test Init (HoTI) message via its home agent and
* モバイルノードBは、ホームエージェントを介してホームテストinit（hoti）メッセージを送信する必要があります。
* a Care of Test Init (COTI) message directly to its Correspondent Node C.
* 特派員ノードCに直接テストinit（coti）メッセージのケア
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.
テストinitメッセージのケアは、ソースアドレスとして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.
Hotiはモビリティヘッダーパケットであり、プロトコルタイプがファイアウォールの確立された状態とは異なるため（（2）を参照）、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：Return Rusabilityテストの問題
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).
1. これらの着信パケットはCOAから送信され、ダウンリンクパケットフィルターと一致しないため、COAから来ます（2）。
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. アップリンクパケットフィルターが実装されている場合、CNからCOAに送信されます。アップリンクパケットは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はさまざまなファイアウォールによって保護されている場合があり、MNのIPアドレスの変更の結果として、着信と発信トラフィックは異なるファイアウォールを通過する場合があります。新しいファイアウォールには、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:
ホームエージェントがファイアウォールによって保護されているネットワークにあるシナリオでは、次の問題が存在する可能性があります。
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トラフィックをブロックする場合、MIPV6シグナル伝達の多く（バインディングアップデート、ホットなど）がファイアウォールでドロップされ、MNがバインディングキャッシュの更新を防ぐことができますバインディングアップデート、ホット、およびその他の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：ホームエージェントを保護するファイアウォールが未承諾の着信トラフィックをブロックする場合（たとえば、ステートフル検査パケットフィルターがそうであるように）、ファイアウォールはCNSからの接続セットアップ要求、およびMNSからパケットをドロップする場合があります。
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号：ホームエージェントがいくつかのファイアウォールによって保護されているネットワークにある場合、MN/CNのIPアドレスの変更により、異なるファイアウォールを介してホームエージェントとの交通の通過が発生する可能性があります。流れ。結果として、ファイアウォールでパケットがドロップされる場合があります。
Let's consider an HA in a network protected by firewall(s). The following issues need to be investigated:
ファイアウォールで保護されているネットワーク内の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）を取得した後、ホームエージェントにバインディングアップデートを送信します。拘束力のある更新と謝辞は、MIPV6仕様[1]に従って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のHAによってMNのCOAに転送されます。ただし、パケットがファイアウォールに到着すると、着信するトラフィックは既存の状態と一致しない可能性があり、したがってファイアウォールがドロップする場合があります。
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を保護するファイアウォールによって削除される場合があります。ファイアウォールは、デフォルトのルールとして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にバインディングアップデートを正常に送信したと仮定した場合、パケットはCNからMNのCOAおよびMNのCOAから送信されます。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).
ただし、CNからMNのCOAに送信されたパケットは、MNを保護するファイアウォールの既存のエントリと一致しないため、ファイアウォールによってドロップされます。
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が送信したトラフィック）に適用された場合、MNのCOAからCNに送信されたパケットは、ファイアウォールのエントリも一致しない可能性があり、削除される場合があります。
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.
James Kempf、Samita Chakrabarti、Giaretta Gerardo、Steve Bellovin、Henrik Levkowetz、Spencer Dawkinsの貴重なコメントに感謝します。彼らの提案は、ドキュメントのプレゼンテーションと内容の両方を改善するのに役立ちました。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1] Johnson、D.、Perkins、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。、ホーイハン、K。、ホイハン、K。、スティーブンス、R。、スティフェル、B。、アモン、A。、およびC.トブキン、「チェックポイントng vpn-1/ firewall--1高度な構成とトラブルシューティング "、Syngress Publishing Inc.、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] Chen、X.、Rinne、J.、Wiljakka、J。、およびM. Watson、「GPRS/UMTSパケットフィルタリングとのMIPV6相互作用の問題声明」、2006年1月の作業進行中。
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フォーブスアベニューピッツバーグ、ペンシルバニア州15213アメリカ
EMail: franckle@cmu.edu
Stefano Faccin Nokia Research Center 6000 Connection Drive Irving, TX 75039 USA
Stefano Faccin Nokia Research Center 6000 Connection Drive Irving、TX 75039 USA
EMail: sfaccinstd@gmail.com
Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA
Basavaraj Patil Nokia 6000 Connection Drive Irving、TX 75039 USA
EMail: Basavaraj.Patil@nokia.com
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich、Bavaria 81739ドイツ
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。