Network Working Group M. Stiemerling
Request for Comments: 5207 J. Quittek
Category: Informational NEC
L. Eggert
Nokia
April 2008
NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication
ホスト識別プロトコル（HIP）通信のNATやファイアウォール越えの問題
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
IESG Note
IESG注意
This RFC is a product of the Internet Research Task Force and is not a candidate for any level of Internet Standard. The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment.
このRFCはインターネットリサーチタスクフォースの製品であり、インターネットStandardのどんなレベルの候補ではありません。 IRTFはインターネット関連の研究開発活動の成果を公表しています。これらの結果は、展開に適していない可能性があります。
Abstract
抽象
The Host Identity Protocol (HIP) changes the way in which two Internet hosts communicate. One key advantage over other schemes is that HIP does not require modifications to the traditional network-layer functionality of the Internet, i.e., its routers. In the current Internet, however, many devices other than routers modify the traditional network-layer behavior of the Internet. These "middleboxes" are intermediary devices that perform functions other than the standard functions of an IP router on the datagram path between source and destination hosts. Whereas some types of middleboxes may not interfere with HIP at all, others can affect some aspects of HIP communication, and others can render HIP communication impossible. This document discusses the problems associated with HIP communication across network paths that include specific types of middleboxes, namely, network address translators and firewalls. It identifies and discusses issues in the current HIP specifications that affect communication across these types of middleboxes. This document is a product of the IRTF HIP Research Group.
ホストアイデンティティプロトコル（HIP）は、2つのインターネットホストが通信する方法を変更します。他のスキーム上重要な利点の1つは、HIPは、インターネットの伝統的なネットワーク層の機能、すなわち、そのルータの変更を必要としないことです。現在のインターネットでは、しかし、ルータ以外の多くのデバイスは、インターネットの伝統的なネットワーク層の動作を変更します。これらの「中間装置」は、送信元と宛先ホスト間のデータグラムの経路上のIPルータの標準機能以外の機能を実行する仲介装置です。ミドルボックスの種類によっては、すべてのHIPに干渉しないかもしれないのに対し、他の人は、HIP通信のいくつかの側面に影響を与えることができ、その他はHIP通信が不可能にすることができます。この文書では、中間装置の特定のタイプ、すなわち、ネットワークアドレス変換およびファイアウォールを含むネットワーク経路を横切るHIP通信に関連する問題を論じています。これは、識別し、ミドルボックスのこれらのタイプ間通信に影響を与える現在のHIP仕様での問題について説明します。この文書では、IRTFのHIP研究グループの製品です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. HIP across NATs . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Phase 1: HIP Base Exchange . . . . . . . . . . . . . . . . 4
2.1.1. IPv4 HIP Base Exchange . . . . . . . . . . . . . . . . 4
2.1.2. IPv6 HIP Base Exchange . . . . . . . . . . . . . . . . 5
2.2. Phase 2: ESP Data Exchange . . . . . . . . . . . . . . . . 5
3. HIP Across Firewalls . . . . . . . . . . . . . . . . . . . . . 6
3.1. Phase 1: HIP Base Exchange . . . . . . . . . . . . . . . . 6
3.1.1. IPv4 HIP Base Exchange . . . . . . . . . . . . . . . . 6
3.1.2. IPv6 HIP Base Exchange . . . . . . . . . . . . . . . . 6
3.2. Phase 2: ESP Data Exchange . . . . . . . . . . . . . . . . 7
4. HIP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 7
5. NAT Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Legacy NAT and Firewall Traversal . . . . . . . . . . . . . . 8
7. HIP across Other Middleboxes . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
The current specification of the Host Identity Protocol (HIP) [RFC4423] assumes simple Internet paths, where routers forward globally routable IP packets based on their destination address alone.
ホスト識別プロトコル（HIP）[RFC4423]の現在の仕様では、前方だけで自分の宛先アドレスに基づいてグローバルにルーティング可能なIPパケットをルーターで簡単なインターネットパスを、前提としています。
In the current Internet, such pure paths are becoming increasingly rare. For a number of reasons, several types of devices modify or extend the pure forwarding functionality the Internet's network layer used to deliver. [RFC3234] coins the term middleboxes for such devices: "A middlebox is (...) any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host".
現在のインターネットでは、純粋な経路はますます稀になってきています。多くの理由により、デバイスのいくつかのタイプを提供するために使用され、純粋な転送機能、インターネットのネットワーク層を変更または拡張します。 [RFC3234]硬貨ような装置のための用語中間装置は：「ミドル（...）は、ソースホストと宛先ホスト間のデータグラムの経路上のIPルータの通常の、標準的な機能以外の機能を実行する任意の中間デバイスです」。
Middleboxes affect communication in a number of ways. For example, they may inspect the flows of some transport protocols, such as TCP, and selectively drop, insert, or modify packets. If such devices encounter a higher-layer protocol they do not support, or even a variant of a supported protocol that they do not know how to handle, communication across the middlebox may become impossible for these kinds of traffic.
ミドルボックスは、いくつかの方法で通信に影響を与えます。例えば、それらは、TCPのようないくつかのトランスポートプロトコルのフローを検査し、選択ドロップ、挿入、またはパケットを変更することができます。このようなデバイスは、彼らがサポートしていない上位層プロトコル、またはそれらが処理する方法がわからないサポートされるプロトコルのも、変種が発生した場合は、ミドル間の通信は、トラフィックのこれらの種類のために不可能になることがあります。
There are many different variants of middleboxes. The most common ones are network address translators and firewalls. [RFC3234] identifies many other types of middleboxes. One broad way of classifying them is by behavior. The first group operates on packets, does not modify application-layer payloads, and does not insert additional packets. This group includes NAT, NAT-PT, SOCKS gateways, IP tunnel endpoints, packet classifiers, markers, schedulers, transport relays, IP firewalls, application firewalls, involuntary packet redirectors, and anonymizers.
ミドルボックスのさまざまなバリエーションがあります。最も一般的なものは、ネットワークアドレス変換およびファイアウォールです。 [RFC3234]は中間装置の多くの他のタイプを識別する。それらを分類する一つの広い方法は行動です。最初のグループは、アプリケーション層のペイロードを変更しない、パケット上で動作し、追加のパケットを挿入しません。このグループはNAT、NAT-PT、SOCKSゲートウェイ、IPトンネルエンドポイント、パケット分類、マーカー、スケジューラ、輸送リレー、IPファイアウォール、アプリケーション・ファイアウォール、不随意パケットリダイレクタ、およびアノニマイザを含みます。
Other middleboxes exist (such as TCP performance-enhancing proxies, application-level gateways, gatekeepers, session control boxes, transcoders, proxies, caches, modified DNS servers, content and applications distribution boxes, and load balancers) that divert or modify URLs, application-level interceptors, and application-level multicast systems. However, NATs and firewalls are the most frequent middleboxes that HIP traffic can encounter in the Internet. Consequently, this memo focuses on how NAT and firewall middleboxes can interfere with HIP traffic.
他の中間装置が存在する（例えば、TCP性能向上プロキシとして、アプリケーション・レベルのゲートウェイ、ゲートキーパー、セッション制御ボックス、トランスコーダ、プロキシ、キャッシュ、修飾されたDNSサーバ、コンテンツおよびアプリケーション配信ボックス、およびロードバランサ）流用またはURLを変更し、アプリケーションレベルのインターセプタ、およびアプリケーションレベルマルチキャストシステム。しかし、NATのファイアウォールは、HIPトラフィックがインターネットに遭遇することができ、最も頻度の高いミドルボックスです。したがって、このメモは、NATやファイアウォールミドルボックスは、HIPトラフィックを妨げることができる方法に焦点を当てています。
Middleboxes can cause two different kinds of communication problems for HIP. They can interfere with the transmission of HIP control traffic or with the transmission of the HIP data traffic carried within the Encapsulating Security Payload (ESP) [RFC4303].
MiddleboxesはHIPのためのコミュニケーションの問題の2種類を引き起こす可能性があります。彼らは、HIP制御トラフィックの送信またはカプセル化セキュリティペイロード（ESP）[RFC4303]の中で運ばHIPデータトラフィックの伝送を妨害することができます。
This document serves mainly as a problem description that solution proposals can reference. But it also discusses known approaches to solving the problem and gives recommendations for certain approaches depending on the specific scenario. It does not promote the use of any of the discussed types of middleboxes.
この文書では、主に溶液の提案が参照できる問題の説明としての役割を果たす。しかし、それはまた、問題を解決するための公知のアプローチを説明し、特定のシナリオに応じて、特定のアプローチのための推奨事項を示します。これは、ミドルボックスの議論タイプのいずれかの利用を促進しません。
This memo was discussed and modified in the Host Identity Protocol Research Group, was reviewed by the Internet Research Steering Group (IRSG), and represents a consensus view of the research group at the time of its submission for publication.
このメモは、議論し、ホスト識別プロトコル研究グループに変更された、インターネットリサーチの運営グループ（IRSG）によって検討され、出版のためにその提出時の研究グループの一致した見解を示しました。
This section focuses on the traversal of HIP across network address translator (NAT) middleboxes. This document uses the term NAT for a basic translation of IP addresses, whereas it uses the term NAPT for NATs that additionally perform port translation [RFC2663], if a differentiation between the two is important.
このセクションでは、ネットワークアドレス変換（NAT）ミドルボックス間HIPのトラバーサルに焦点を当てています。 2間の差別化が重要であるならば、それは、さらにポート変換[RFC2663]を実行するNATのための長期的なNAPTを使用するのに対し、この文書では、IPアドレスの基本的な翻訳のための用語NATを使用しています。
HIP operates in two phases. It first performs a HIP "base exchange" handshake before starting to exchange application data in the second phase. This section describes the problems that occur in each of the two phases when NATs are present along the path from the HIP initiator to the responder.
HIPは2つのフェーズで動作します。なお、第一、第二フェーズでアプリケーションデータの交換を開始する前に、HIP「塩基交換」ハンドシェイクを行います。このセクションでは、NATをレスポンダにHIP開始から経路に沿って存在しているときに、2つの相のそれぞれにおいて発生する問題を説明しています。
The HIP base exchange uses different transport mechanisms for IPv6 and IPv4. With IPv6, it uses a HIP-specific IPv6 extension header, whereas it uses the IP payload with IPv4 [RFC5201].
HIP基本交換は、IPv6とIPv4の異なるトランスポート機構を使用します。それは、IPv4 [RFC5201]とIPペイロードを使用し、一方、IPv6では、それは、HIP固有のIPv6拡張ヘッダを使用します。
The HIP protocol specification [RFC5201] suggests encapsulating the IPv4 HIP base exchange in a new IP payload type. The chances of NAT traversal for this traffic are different, depending on the type of NAT in the path. The IPv4 HIP base exchange traverses basic NATs (that translate IP addresses only) without problems, if the NAT only interprets and modifies the IP header, i.e., it does not inspect the IP payload.
HIPプロトコル仕様[RFC5201]は新しいIPペイロードタイプのIPv4 HIP基本交換をカプセル化を示唆しています。このトラフィックのためのNATトラバーサルのチャンスはパスでNATの種類に応じて、異なっています。 IPv4 HIP基本交換は問題なく（つまり、IPアドレスだけを変換する）基本のNATを横断する、NATのみ解釈およびIPヘッダを変更する場合、すなわち、それはIPペイロードを検査しません。
However, basic NATs are rare. NAPT devices that inspect and translate transport-layer port numbers are much more common. Because the IP payload used for the IPv4 base exchange does not contain port numbers or other demultiplexing fields, NAPTs cannot relay it.
しかし、基本的なNATは稀です。トランスポート層のポート番号を検査し、翻訳しNAPTデバイスがはるかに一般的です。 IPv4ベースの交換に使用されるIPペイロードは、ポート番号または他の分離フィールドが含まれていないので、NAPTsはそれを中継することはできません。
A second issue is the well-known "data receiver behind a NAT" problem. HIP nodes behind a NAT are not reachable unless they initiate the communication themselves, because the necessary translation state is otherwise not present at the NAT.
第二の問題は、問題のよく知られた「NATの背後にあるデータ受信機」です。彼らは通信そのものを開始しない限り、必要な変換状態は、そうでない場合はNATに存在しないため、NATの背後にあるHIPノードは、到達可能ではありません。
The IPv6 HIP base exchange uses empty IPv6 packets (without a payload). New HIP extension headers carry the base exchange information. This approach can cause problems if NAT middleboxes translate or multiplex IP addresses.
IPv6 HIP基本交換は、（ペイロードなし）空のIPv6パケットを使用します。新しいHIP拡張ヘッダは、基本情報交換を運びます。 NATミドルボックスは、IPアドレスを変換するか、多重場合には、このアプローチは、問題を引き起こす可能性があります。
At this time, IPv6 NATs are rare. However, when they exist, IPv6 NATs operate similarly to IPv4 NATs. Consequently, they will likely block IP payloads other than the "well-known" transport protocols. This includes the IPv6 HIP base exchange, which does not contain any IP payload.
この時点では、IPv6のNATは稀です。それらが存在するときただし、IPv6のNATはIPv4のNATのと同様に動作します。その結果、彼らはおそらく、「周知の」トランスポートプロトコル以外のIPペイロードをブロックします。これは、任意のIPペイロードが含まれていないIPv6のHIP基本交換を、含まれています。
HIP uses ESP to secure the data transmission between two HIP nodes after the base exchange completes. Thus, HIP faces the same challenges as IPsec with regard to NAT traversal. [RFC3715] discusses these issues for IPsec and describes three distinct problem categories: NAT-intrinsic issues, NAT implementation issues, and helper incompatibilities.
HIPは、塩基交換が完了した後、2つのHIPノード間のデータ伝送を確保するためにESPを使用します。このように、HIPは、NATトラバーサルに関してのIPsecと同じ課題に直面しています。 [RFC3715]はIPsecのために、これらの問題を議論し、三つの異なる問題のカテゴリ説明：NAT-固有の問題、NATの実装上の問題、およびヘルパー非互換性を。
This section focuses on the first category, i.e., NAT-intrinsic issues. The two other problem categories are out of this document's scope. They are addressed in the BEHAVE working group or in [RFC3489].
このセクションでは、最初のカテゴリ、すなわち、NAT-固有の問題に焦点を当てています。他の二つの問題のカテゴリは、この文書の範囲外です。彼らはBEHAVEワーキンググループまたは[RFC3489]で扱われています。
With ESP-encrypted data traffic, all upper-layer headers are invisible to a NAT. Thus, changes of the IP header during NAT traversal can invalidate upper-layer checksums contained within the ESP-protected payload. HIP hosts already avoid this problem by substituting Host Identity Tags (HITs) for IP addresses during checksum calculations [RFC5201].
ESP暗号化データトラフィックでは、すべての上位層ヘッダはNATには見えません。このように、NATトラバーサル中のIPヘッダの変更は、ESP-保護ペイロード内に含まれる上位層チェックサムを無効にすることができます。 HIPホストは、すでにチェックサム計算[RFC5201]の間、IPアドレスのホストアイデンティティタグ（ヒット）を代入することで、この問題を回避します。
Although the traversal of ESP-encrypted packets across NATs is possible, [RFC3715] notes that the Security Parameter Index (SPI) values of such traffic have only one-way significance. NATs can use SPI values to demultiplex different IPsec flows, similar to how they use port number pairs to demultiplex unencrypted transport flows. Furthermore, NATs may modify the SPIs, similar to how they modify port numbers, when multiple IPsec nodes behind them happen to choose identical SPIs. However, NATs can only observe the SPIs of outgoing IPsec flows and cannot determine the SPIs of the corresponding return traffic.
NATを越えESP-暗号化されたパケットのトラバースが可能ですが、[RFC3715]は、このようなトラフィックのセキュリティパラメータインデックス（SPI）の値は一方向のみの意義を持っていることを指摘します。 NATは、彼らが暗号化されていない交通の流れを分離するために、ポート番号のペアを使用する方法に似て異なるIPsecのフローを、逆多重化するためにSPI値を使用することができます。さらに、NATはその背後にある複数のIPsecノードが同じSPIを選択することが発生したとき、彼らは、ポート番号を変更する方法に似SPIを、変更することができます。しかし、NATは、発信のみのIPsecフローのSPIを観察することができ、対応するリターントラフィックのSPIを判断することはできません。
This section focuses on the traversal of HIP across IP firewalls and packet filters. These types of middleboxes inspect individual packets and decide whether to forward, discard, or process them in some special way, based on a set of filter rules and associated actions.
このセクションでは、IPファイアウォールやパケットフィルタ全体でHIPのトラバーサルに焦点を当てています。ミドルボックスのこれらのタイプは、個々のパケットを検査し、フィルタルールと関連するアクションのセットに基づいて、いくつかの特別な方法で、前方破棄、またはそれらを処理するかどうかを決定します。
Firewalls are not inherently problematic for HIP, as long as their policy rules permit HIP base exchange and IPsec traffic to traverse. The next sections discuss specific issues for HIP in typical firewall configurations.
ファイアウォールは、限り、彼らのポリシールールは、HIP基本交換と通過するIPSecトラフィックを許可するよう、HIPのための本質的には問題ありません。次のセクションでは、一般的なファイアウォール設定でのHIPのための具体的な問題を議論します。
A common and recommended configuration for IPv4 firewalls is to block all unknown traffic by default and to allow well-known transport protocols only and often just on specific ports and with specific characteristics ("scrubbed" traffic). This common configuration blocks the HIP base exchange.
共通とIPv4ファイアウォールの設定をお勧めしますが、デフォルトではすべての未知のトラフィックをブロックするだけで、多くの場合、単に特定のポート上で、特定の特性（トラフィックを「スクラブ」）でよく知られているトランスポートプロトコルを可能にすることです。この一般的な構成ブロックHIPベース交換。
The configuration of IPv6 firewalls is similar to IPv4 firewalls. Many IPv4 firewalls discard any IP packet that includes an IP option. With IPv6, the expectation is that firewalls will block IPv6 extension headers in general or will at least block unknown extension headers. Furthermore, payloads other than specific, well-known transport protocols are likely to be blocked as well. Like IPv4, this behavior blocks the HIP base exchange.
IPv6のファイアウォールの構成は、IPv4ファイアウォールと同様です。多くのIPv4のファイアウォールは、IPオプションを含む任意のIPパケットを破棄する。 IPv6では、期待はファイアウォールは、一般的にIPv6拡張ヘッダまたはあろう少なくともブロック未知の拡張ヘッダをブロックすることです。さらに、特定の以外のペイロードは、よく知られているトランスポートプロトコルは、同様にブロックされる可能性があります。 IPv4のと同様に、この動作ブロックHIPベース交換。
A problem similar to the "data receiver behind a NAT" issue (see Section 2.1.1) applies to both IPv4 and IPv6 firewalls. Typically, firewalls block all traffic into the protected network that is not identifiable return traffic of a prior outbound communication. This means that HIP peers are not reachable outside the protected network, because firewalls block base exchange attempts from outside peers.
「データ受信NATの背後にある」問題と同様の問題は、（2.1.1項を参照）、IPv4およびIPv6のファイアウォールの両方に適用されます。一般的に、ファイアウォールは、従来のアウトバウンド通信の識別可能なリターントラフィックない保護されたネットワーク内のすべてのトラフィックをブロックします。これは、ファイアウォールが外部ピアから塩基交換の試みをブロックするためHIPピアは、保護されたネットワークの外に到達できないことを意味します。
Firewalls are less problematic than NATs with regard to passing ESP traffic. The largest concern is commonly used firewall configurations that block ESP traffic, because it is not a well-known transport protocol and ports cannot be used to identify return flows. However, firewalls could use mechanisms similar to Security Parameter Index (SPI) multiplexed NAT (SPINAT) to use SPIs as flow identifiers [YLITALO].
ファイアウォールはESPトラフィックを渡すことに関連してNATのより少ない問題があります。最大の懸念は、一般的に、それはよく知られているトランスポートプロトコルではなく、ポートはリターンフローを識別するために使用することはできませんので、ESPトラフィックをブロックするファイアウォール設定を使用しています。しかし、ファイアウォールはフロー識別子[YLITALO]としてSPIを使用するセキュリティパラメータインデックス（SPI）多重NAT（SPINAT）に似たメカニズムを使用することができます。
This section identifies possible changes to HIP that attempt to improve NAT and firewall traversal, specifically, the reachability of HIP peers behind those middleboxes and traversal of the HIP base exchange. Sections 2 and 3 describe several problems related to encapsulation schemes for the HIP base exchange in IPv4 and IPv6.
このセクションでは、NATやファイアウォール越え、具体的には、これらのミドルボックスの背後にあるHIPピアの到達可能性およびHIP基本交換のトラバーサルを改善しようとするHIPへの可能な変更を識別する。セクション2及び3は、IPv4およびIPv6でHIP基本交換のためのカプセル化方式に関連するいくつかの問題を記載しています。
UDP may improve HIP operation in the presence of NATs and firewalls. It may also aid traversal of other middleboxes. For example, load balancers that use IP- and transport-layer information can correctly operate with UDP-encapsulated HIP traffic.
UDPは、NATをして、ファイアウォールの存在下でHIP処理を改善することがあります。また、他のミドルボックスの横断を助けることができます。例えば、IP-とトランスポート層の情報を使用するロードバランサは、正しくUDPカプセル化HIPトラフィックで動作することができます。
HIP nodes located behind a NAT must notify their communication peers about the contact information. The contact information is the NAT's public IP address and a specific UDP port number. This measure enables the peers to send return traffic to HIP nodes behind the NAT. This would require a new HIP mechanism.
NATの背後にあるHIPノードは、コンタクト情報についての彼らの通信ピアに通知しなければなりません。連絡先情報は、NATのパブリックIPアドレスと特定のUDPポート番号です。この措置は、NATの背後にあるHIPノードへのリターントラフィックを送信するためにピアを可能にします。これは、新しいHIPメカニズムを必要とします。
To be reachable behind a NAT, a rendezvous point is required that lets HIP nodes behind a NAT register an IP address and port number that can be used to contact them. Depending on the type of NAT, use of this rendezvous point may be required only during the base exchange or throughout the duration of a communication instance. A rendezvous point is also useful for HIP nodes behind firewalls, because they suffer from an analogous problem, as described in Section 3.
NATの背後に到達可能であるためには、ランデブーポイントがNATの背後にあるHIPノードは、それらを連絡するために使用することができますIPアドレスとポート番号を登録することができますことが必要です。 NATのタイプに応じて、このランデブーポイントの使用は、塩基交換中または通信インスタンスの期間を通じてのみ必要とされ得ます。それらは類似の問題に悩まされるので、第3節で説明したようにランデブーポイントは、また、ファイアウォールの後ろにHIPノードのために有用です。
The proposed mobility management packet exchange [RFC5206] [NIKANDER] can support this method of NAT traversal. The original intention of this extension is to support host mobility and multihoming. This mechanism is similar to the Alternate Network Address Types (ANAT) described in [RFC4091]. However, HIP peers use mobility management messages to notify peers about rendezvous points, similar to [RFC4091]. HIP peers must determine their contact address before they can announce it to their peers.
提案されたモビリティ管理パケット交換[RFC5206]は[NIKANDER] NATトラバーサルのこのメソッドをサポートすることができます。この拡張機能の本来の意図は、ホストモビリティとマルチホーミングをサポートすることです。このメカニズムは、[RFC4091]に記載の代替ネットワークアドレスタイプ（ANAT）と同様です。しかしながら、HIPピアは[RFC4091]と同様ランデブーポイント、約ピアに通知する移動管理メッセージを使用します。彼らは仲間にそれを発表する前に、HIPピアは、自分の連絡先アドレスを決定する必要があります。
IPsec SPIs have only one-way significance, as described in Section 2.2. Consequently, NATs and firewalls can observe the SPI values of outgoing packets, but they cannot learn the SPI values of the corresponding inbound return traffic in the same way. Two methods exist:
2.2節で説明したようにIPsecのSPIは、一方向のみの意義を持っています。そのため、NATのファイアウォールは、送信パケットのSPI値を観察することができますが、彼らは同じように対応するインバウンドリターントラフィックのSPI値を知ることはできません。二つの方法が存在します。
First, NATs can observe the HIP base exchange and learn the SPI values that HIP peers agree to use. Afterwards, NATs can map outgoing and incoming IPsec flows accordingly. This approach is called architectured NAT, or SPINAT [YLITALO], and can be used by firewalls as well. It requires HIP-specific NAT modifications.
まず、NATはHIP基本交換を観察し、HIPピアが使用することに同意SPI値を学ぶことができます。その後、NATはそれに応じて発信および着信のIPSecフローをマッピングすることができます。このアプローチは、NAT、またはSPINAT [YLITALO]をアーキテクチャ・呼ばれ、そして同様にファイアウォールで使用することができます。これは、HIP-固有のNATの変更が必要となります。
Second, HIP peers can use a generic NAT or firewall signaling protocol to explicitly signal appropriate SPI values to their NATs and firewalls. This approach does not require HIP-specific changes at the middlebox, but does require integration of HIP with the signaling protocol at the end systems.
第二に、HIPピアは明示的にNATをファイアウォールに適切なSPI値を知らせるために、一般的なNATやファイアウォールのシグナリングプロトコルを使用することができます。このアプローチは、ミドルでHIP固有の変更を必要としないが、エンドシステムでのシグナリングプロトコルとHIPの統合を必要としません。
Possible solutions for signaling SPI values are the mechanisms proposed in the IETF NSIS WG (NATFW NSLP) and MIDCOM MIB module [RFC5190]. Using MIDCOM in the context of HIP requires additional knowledge about network topology. For example, in multihomed environments with different border NATs or firewalls, a host must know which of the multiple NATs/firewalls to signal. Therefore, this solution can be problematic.
SPI値をシグナリングするための可能な解決策は、IETF NSIS WG（NATFW NSLP）とMIDCOM MIBモジュール[RFC5190]で提案された機構です。 HIPの文脈でMIDCOMを使用すると、ネットワークトポロジに関する追加の知識が必要です。例えば、異なる境界のNATやファイアウォールとマルチホーム環境では、ホストはシグナリングする複数のNAT /ファイアウォールのかを知る必要があります。したがって、この解決策は、問題となり得ます。
By using the NSIS NAT/FW traversal (NATFW NSLP) mechanism HIP nodes can signal the used SPI values for both directions. NATFW NSLP ensures that signaling messages will reach all NATs and firewalls along the data path (path-coupled signaling). Although NSIS is generally supported at both peers, the NATFW NSLP offers a "proxy mode" for scenarios where only one end supports NSIS. This has deployment advantages.
NSIS NAT / FWトラバーサルを使用して（NATFW NSLP）機構HIPノードは両方向のために使用されるSPI値をシグナリングすることができます。 NATFW NSLPシグナリングメッセージは、データパス（経路結合シグナル）に沿ったすべてのNATやファイアウォールに到達することを確実にします。 NSISは、一般的に両方のピアでサポートされていますが、NATFW NSLPは、一端のみがNSISをサポートシナリオの「プロキシモード」を提供しています。これは、展開の利点があります。
The solutions outlined in Section 5 require that NATs and firewalls are updated to support new functions, such as HIP itself or NSIS NATFW signaling. NATs and firewalls are already widely deployed. It will be impossible to upgrade or replace all such middleboxes with HIP support. This section explores how HIP operates in the presence of legacy NATs and firewalls that are not HIP-aware. Because the vast majority of deployed NATs currently support IPv4 only, this section focuses on them.
第5節で概説したソリューションは、NATのとファイアウォールは、このようなHIP自身やNSIS NATFWシグナリングなどの新機能を、サポートするように更新されている必要があります。 NATのファイアウォールは、すでに広く普及しています。アップグレードまたはHIPをサポートしているようなすべてのミドルボックスを交換することは不可能になります。このセクションでは、HIPは、HIP-認識していないレガシーのNATやファイアウォールの存在下でどのように動作するかを探ります。展開のNATの大半は、現在、IPv4のみをサポートしているため、このセクションでは、それらに焦点を当てています。
For HIP over IPv4, UDP encapsulation of HIP traffic already solves some NAT traversal issues. Usually, UDP packets can traverse NATs and firewalls when communication was initiated from the inside. However, traffic initiated outside a NAT is typically dropped, because it cannot be demultiplexed to the final destination (for NATs) or is prohibited by policy (for firewalls).
IPv4のオーバーHIPのために、HIPトラフィックのUDPカプセル化は、すでにいくつかのNATトラバーサルの問題を解決します。通信は内部から開始されたとき通常、UDPパケットは、NATをし、ファイアウォールを通過することができます。それは（NATのための）最終的な宛先に分波することができないか（ファイアウォール用）ポリシーによって禁止されているのでしかし、NATの外に開始されるトラフィックは、一般的に、廃棄されます。
Even when UDP encapsulation enables the HIP base exchange to succeed, ESP still causes problems [RFC3715]. Some NAT implementations offer "VPN pass-through", where the NAT learns about IPsec flows and tries to correlate outgoing and incoming SPI values. This often works reliably only for a small number of nodes behind a single NAT, due to the possibility of SPI collisions.
UDPカプセル化が成功するためにHIP基本交換を可能にした場合でも、ESPはまだ問題[RFC3715]を発生します。いくつかのNATの実装が提供する「VPNパススルー」NATはIPsecのフローについて学習し、発信および着信SPI値を相関しようと、。これは、しばしばSPI衝突の可能性に、単一のNATの背後にあるノードの数が少ないために確実に動作します。
A better solution may be to use UDP encapsulation for ESP [RFC3948], enabled through a new parameter in the base exchange. It is for further study whether to mandate UDP encapsulation for all HIP traffic to reduce the complexity of the protocol.
よりよい解決策はESP [RFC3948]のためのUDPカプセル化を使用することも、塩基交換で新しいパラメータを使用して有効。これは、プロトコルの複雑さを軽減するために、すべてのHIPトラフィックのUDPカプセル化を強制するかどうか、今後の検討課題です。
HIP may also consider other NAT/firewall traversal mechanisms, such as the widely deployed Universal Plug and Play (UPNP) [UPNP]. UPNP can be used to configure middleboxes on the same link as a HIP node.
HIPはまた、広く展開されているユニバーサルプラグなどの他のNAT /ファイアウォールトラバーサルメカニズムを考えると、（UPNP）[UPNP]をプレイしてもよいです。 UPnPはHIPノードと同じリンク上のミドルボックスを設定するために使用することができます。
This document focuses on NAT and firewall middleboxes and does not discuss other types identified in [RFC3234]. NATs and firewalls are the most frequently deployed middleboxes at the time of writing. However, future versions of this document may describe how HIP interacts with other types of middleboxes.
この文書では、NATやファイアウォールのミドルボックスに焦点を当て、[RFC3234]で識別される他のタイプについては説明しません。 NATのファイアウォールは、最も頻繁に書いている時点でミドルボックスを展開しています。しかし、このドキュメントの将来のバージョンでは、HIPは、ミドルボックスの他のタイプとどのように相互作用するか記述することができます。
Opening pinholes in firewalls (i.e., loading firewall rules allowing packets to traverse) and creating NAT bindings are highly security-sensitive actions. Any mechanism that does so in order to support HIP traversal across middleboxes should be well protected. Detailed discussion of the related security issues can be found in the security considerations sections of the corresponding standards documents, such as [RFC3715] and [RFC5190].
ファイアウォールにピンホールを開く（すなわち、パケットが横断することを可能にするファイアウォールルールをロード）し、NATバインディングを作成することは非常に機密性の高いアクションです。そうミドルボックス間でHIPトラバーサルをサポートするために十分に保護されなければならないん任意のメカニズム。関連するセキュリティ上の問題の詳細な議論は、このような[RFC3715]と[RFC5190]のように、対応する規格文書のセキュリティの考慮事項のセクションに記載されています。
This document has not considered whether some of the options listed above pose additional threats to security of the HIP protocol itself.
この文書では、上記のオプションのいくつかは、HIPプロトコル自体のセキュリティに追加の脅威をもたらすかどうかを検討していません。
The following people have helped to improve this document through thoughtful suggestions and feedback: Pekka Nikander, Tom Henderson, and the HIP research group. The authors would like to thank the final reviewers, Kevin Fall, Mark Allman, and Karen Sollins.
ペッカNikander、トム・ヘンダーソン、およびHIP研究グループ：次の人は思慮深い提案やフィードバックを通じて、この文書を改善するために役立っています。著者は、最終的な査読、ケビン秋、マーク・オールマン、そしてカレンSollinsに感謝したいと思います。
Lars Eggert and Martin Stiemerling are partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks project or the European Commission.
ラースエッゲルトとマーティンStiemerlingの一部が周囲のネットワーク、その第6次フレームワークプログラムの下で、欧州委員会でサポートされている研究プロジェクトによって資金を供給されています。ここに含まれている見解と結論は著者のものであり、周囲のネットワークプロジェクトや欧州委員会の、明示または黙示、必ずしも公式のポリシーまたは推薦を表すものとして解釈すべきではありません。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948] Huttunen、A.、Swander、B.、ボルペ、V.、DiBurro、L.、及びM.ステンバーグ、 "IPsecのESPパケットのUDPカプセル化"、RFC 3948、2005年1月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]モスコウィッツ、R.とP. Nikander、 "ホストアイデンティティプロトコル（HIP）アーキテクチャ"、RFC 4423、2006年5月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]モスコウィッツ、R.、Nikander、P.、Jokela、P.、エド。、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、RFC 5201、2008年4月。
[NIKANDER] Nikander, P., Ylitalo, J., and J. Wall, "Integrating Security, Mobility, and Multi-Homing in a HIP Way", Proc. Network and Distributed Systems Security Symposium (NDSS) 2003, February 2003.
、PROC "HIPウェイでのセキュリティ、モビリティ、およびマルチホーミングの統合" [NIKANDER] Nikander、P.、Ylitalo、J.、およびJ.ウォール、。ネットワークと分散システムセキュリティシンポジウム（NDSS）2003、2003年2月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B.とS.つば、 "のMiddleboxes：分類と課題"、RFC 3234、2002年2月。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[RFC3489]ローゼンバーグ、J.、ワインバーガー、J.、のHuitema、C.、およびR.マーイ、 - 2003年3月、RFC 3489 "STUNネットワークを介して、ユーザーデータグラムプロトコル（UDP）の簡単なトラバーサルは、翻訳者（NATのを）アドレス"。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] Aboba、B.とW.ディクソン、 "IPsecでネットワークアドレス変換（NAT）の互換性の要件"、RFC 3715、2004年3月。
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[RFC4091]キャマリロ、G.およびJ.ローゼンバーグ、RFC 4091、2005年6月 "セッション記述プロトコル（SDP）グループ化フレームワークの代替ネットワークアドレスタイプ（ANAT）セマンティクス"。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC5190] Quittek, J., Stiemerling, M., and P. Srisuresh, "Definitions of Managed Objects for Middlebox Communication", RFC 5190, March 2008.
[RFC5190] Quittek、J.、Stiemerling、M.、およびP. Srisuresh、 "ミドルコミュニケーションのための管理オブジェクトの定義"、RFC 5190、2008年3月。
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206]ヘンダーソン、T.、エド。、「エンドホストモビリティとマルチホーミングをホストアイデンティティプロトコルで」、RFC 5206、2008年4月。
[UPNP] UPNP Web Site, "Universal Plug and Play Web Site", Web Site http://www.upnp.org/, July 2005.
[UPNP] UPNPのウェブサイト、 "ユニバーサルプラグアンドプレイのWebサイト"、Webサイトのhttp://www.upnp.org/、2005年7月。
[YLITALO] Ylitalo, J., Melen, J., Nikander, P., and V. Torvinen, "Re-Thinking Security in IP-Based Micro-Mobility", Proc. 7th Information Security Conference (ISC) 2004, September 2004.
[YLITALO] Ylitalo、J.、メレン、J.、Nikander、P.、およびV. Torvinen、 "IPベースのマイクロモビリティにおける再思考セキュリティ"、PROC。第七情報セキュリティ会議（ISC）2004、2004年9月。
Authors' Addresses
著者のアドレス
Martin Stiemerling NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany
マーティンStiemerling NECヨーロッパ社Kurfürsten-Anlageの36 69115ハイデルベルクドイツ
Phone: +49 6221 4342 113 Fax: +49 6221 4342 155 EMail: stiemerling@nw.neclab.eu URI: http://www.nw.neclab.eu/
電話：+49 6221 4342 113ファックス：+49 6221 4342 155電子メール：stiemerling@nw.neclab.eu URI：http://www.nw.neclab.eu/
Juergen Quittek NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany
ユルゲンQuittek NECヨーロッパ社Kurfuerstenコンディショニング36 69115ハイデルベルクドイツ
Phone: +49 6221 4342 115 Fax: +49 6221 4342 155 EMail: quittek@nw.neclab.eu URI: http://www.nw.neclab.eu/
電話：+49 6221 4342 115ファックス：+49 6221 4342 155電子メール：quittek@nw.neclab.eu URI：http://www.nw.neclab.eu/
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
ラースEggertのノキア・リサーチセンター私書箱ボックス407ノキアグループ00045フィンランド
Phone: +358 50 48 24461 EMail: lars.eggert@nokia.com URI: http://research.nokia.com/people/lars_eggert/
電話番号：+358 50 48 24461電子メール：lars.eggert@nokia.com URI：http://research.nokia.com/people/lars_eggert/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に及びhttp://www.rfc-editor.org/copyright.htmlに含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST 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が表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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に情報を記述してください。