[要約] 要約：RFC 5207は、ホスト識別プロトコル（HIP）通信のNATとファイアウォールトラバーサルの問題について説明しています。 目的：このRFCの目的は、HIP通信がNATやファイアウォールを正しくトラバースできるようにするためのガイドラインを提供することです。
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は、インターネット研究タスクフォースの製品であり、インターネット標準のレベルの候補者ではありません。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.
ホストIDプロトコル（HIP）は、2つのインターネットホストが通信する方法を変更します。他のスキームよりも重要な利点の1つは、HIPがインターネットの従来のネットワーク層機能、つまりそのルーターの変更を必要としないことです。ただし、現在のインターネットでは、ルーター以外の多くのデバイスがインターネットの従来のネットワーク層動作を変更しています。これらの「ミドルボックス」は、ソースホストと宛先ホストの間のデータグラムパス上のIPルーターの標準関数以外の機能を実行する中間デバイスです。一部のタイプのミドルボックスは股関節にまったく干渉しない場合がありますが、他のタイプは股関節通信の側面に影響を与える可能性があり、他の人は股関節通信を不可能にすることができます。このドキュメントでは、特定のタイプのミドルボックス、つまりネットワークアドレス翻訳者とファイアウォールを含むネットワークパス全体の股関節通信に関連する問題について説明します。これらのタイプのミドルボックス全体の通信に影響を与える現在の股関節仕様の問題を特定して議論します。このドキュメントは、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.
ホストIDプロトコル（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]は、他の多くのタイプのミドルボックスを識別します。それらを分類する1つの広範な方法は、行動によるものです。最初のグループはパケットで動作し、アプリケーション層のペイロードを変更せず、追加のパケットを挿入しません。このグループには、NAT、NAT-PT、ソックスゲートウェイ、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サーバー、コンテンツ、アプリケーション配信ボックス、ロードバランサーなど） - レベルインターセプター、およびアプリケーションレベルのマルチキャストシステム。ただし、NATとファイアウォールは、インターネットで股関節トラフィックが遭遇する可能性のある最も頻繁なミドルボックスです。その結果、このメモは、NATとファイアウォールのミドルボックスが股関節トラフィックをどのように妨害するかに焦点を当てています。
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].
ミドルボックスは、股関節に2種類の通信問題を引き起こす可能性があります。彼らは、股関節制御トラフィックの送信、またはカプセル化セキュリティペイロード（ESP）[RFC4303]内で運ばれる股関節データトラフィックの送信を妨害することができます。
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.
このメモは、ホストIdentity Protocol Research Groupで議論および修正され、インターネットリサーチステアリンググループ（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）ミドルボックスを横切る股関節のトラバーサルに焦点を当てています。このドキュメントでは、IPアドレスの基本的な翻訳にNATという用語を使用しますが、2つの区別が重要な場合、ポート翻訳[RFC2663]をさらに実行するNATのNAPTという用語を使用します。
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.
股関節は2つのフェーズで動作します。最初に、第2フェーズでアプリケーションデータを交換し始める前に、最初に股関節「ベース交換」の握手を実行します。このセクションでは、NATが股関節イニシエーターからレスポンダーまでのパスに沿って存在する場合、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].
股関節ベース交換は、IPv6とIPv4にさまざまな輸送メカニズムを使用しています。IPv6では、股関節固有のIPv6拡張ヘッダーを使用しますが、IPv4 [RFC5201]を使用してIPペイロードを使用します。
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ベース交換は、問題なく基本NAT（IPアドレスのみを変換する）をトラバースします。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.
2番目の問題は、よく知られている「NATの背後にあるデータレシーバー」問題です。必要な翻訳状態はNATに存在しないため、NATの後ろの股関節ノードは通信自体を開始しない限り到達できません。
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パケットを使用します（ペイロードなし）。新しい股関節拡張ヘッダーには、基本交換情報が含まれています。このアプローチは、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はESPを使用して、基本交換が完了した後に2つの股関節ノード間のデータ送信を保護します。したがって、股関節は、NATトラバーサルに関してIPSECと同じ課題に直面しています。[RFC3715]は、IPSECのこれらの問題について説明し、NAT-Intrincicの問題、NAT実装の問題、ヘルパーの非互換性という3つの異なる問題カテゴリについて説明します。
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-Intrincicの問題に焦点を当てています。他の2つの問題カテゴリは、このドキュメントの範囲外です。それらは、行動ワーキンググループまたは[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ホストは、チェックサム計算中にIPアドレスのホストIDタグ（ヒット）を置き換えることにより、すでにこの問題を回避しています[RFC5201]。
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は、SPI値を使用して、ポート番号ペアを使用して暗号化されていない輸送フローを非難する方法と同様に、異なるIPSECフローを非難することができます。さらに、NATは、ポート番号の変更方法と同様に、スピスを変更する場合があります。ただし、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ファイアウォールとパケットフィルター全体の股関節のトラバーサルに焦点を当てています。これらのタイプのミドルボックスは、個々のパケットを検査し、フィルタールールのセットと関連するアクションに基づいて、何らかの特別な方法でそれらを転送、破棄、または処理するかどうかを決定します。
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.
ポリシールールが股関節ベース交換とIPSECトラフィックがトラバースへのトラフィックを可能にする限り、ファイアウォールは本質的に股関節にとって問題ではありません。次のセクションでは、典型的なファイアウォール構成における股関節の特定の問題について説明します。
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ファイアウォールの一般的で推奨される構成は、デフォルトですべての未知のトラフィックをブロックし、特定のポートと特定の特性（「スクラブされた」トラフィック）で、よく知られている輸送プロトコルのみを許可することです。この共通構成は、股関節ベース交換をブロックします。
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のように、この動作は股関節ベース交換をブロックします。
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ファイアウォールの両方に適用されます。通常、ファイアウォールは、以前のアウトバウンド通信のリターントラフィックを特定できない保護ネットワークへのすべてのトラフィックをブロックします。これは、ファイアウォールが外部のピアからのベース交換の試みをブロックするため、ヒップピアは保護されたネットワークの外側に到達できないことを意味します。
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トラフィックをブロックする一般的に使用されるファイアウォール構成です。ただし、ファイアウォールでは、セキュリティパラメーターインデックス（SPI）多重化されたNAT（SPISAT）に似たメカニズムを使用して、SPIをフロー識別子[Ylitalo]として使用できます。
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とファイアウォールのトラバーサルを改善しようとする股関節の変更の可能性を特定します。特に、これらのミドルボックスの背後にあるヒップピアの到達可能性と股関節ベース交換のトラバーサルを特定します。セクション2および3は、IPv4およびIPv6の股関節ベース交換のカプセル化スキームに関連するいくつかの問題について説明します。
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とファイアウォールの存在下で股関節の動作を改善する可能性があります。また、他のミドルボックスのトラバーサルを支援する場合があります。たとえば、IPおよび輸送層情報を使用するロードバランサーは、UDPにカプセル化された股関節トラフィックで正しく動作できます。
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の後ろにある股関節ノードは、連絡先情報について通信仲間に通知する必要があります。連絡先情報は、NATのパブリックIPアドレスと特定のUDPポート番号です。この測定により、ピアはNATの後ろの股関節ノードにリターントラフィックを送信できます。これには、新しい股関節メカニズムが必要です。
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レジスタの背後にあるヒップノードを使用して、それらを接触するために使用できるランデブーポイントが必要です。NATのタイプに応じて、このランデブーポイントの使用は、ベース交換中または通信インスタンスの期間中にのみ必要とされる場合があります。ランデブーポイントは、セクション3で説明されているように、類似の問題に苦しむため、ファイアウォールの背後にある股関節ノードにも役立ちます。
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]と同様に、ランデブーポイントについてピアに通知します。股関節のピアは、仲間にそれを発表する前に、連絡先の住所を決定する必要があります。
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値を学習することはできません。2つの方法が存在します。
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は股関節ベース交換を観察し、股関節のピアが使用することに同意するSPI値を学習できます。その後、NATはそれに応じて、発信および着信のIPSECフローをマッピングできます。このアプローチは、Architectured Nat、またはSpinat [Ylitalo]と呼ばれ、ファイアウォールでも使用できます。股関節固有の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.
第二に、股関節ピアは、一般的なNATまたはファイアウォールシグナリングプロトコルを使用して、NATおよびファイアウォールに適切なSPI値を明示的に信号を送ることができます。このアプローチでは、ミドルボックスでの股関節固有の変更は必要ありませんが、Endシステムでのシグナル伝達プロトコルとの股関節の統合が必要です。
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）メカニズムを使用することにより、ヒップノードは両方向に使用される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で概説されているソリューションでは、股関節自体やNSIS NATFWシグナリングなどの新しい機能をサポートするために、NATとファイアウォールが更新されることが必要です。NATとファイアウォールはすでに広く展開されています。このようなすべてのミドルボックスをヒップサポートにアップグレードまたは交換することは不可能です。このセクションでは、股関節が認識されていないレガシー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を超える股関節の場合、股関節トラフィックのUDPカプセル化はすでにいくつかのNATトラバーサルの問題を解決しています。通常、UDPパケットは、内部から通信が開始されたときにNATとファイアウォールを通過できます。ただし、最終目的地（NATの場合）に非glexなことができないか、ポリシー（ファイアウォールの場合）に禁止されているため、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のカプセル化により、股関節のベース交換が成功することができる場合でも、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カプセル化を使用することです。すべての股関節トラフィックの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は、広く展開されているユニバーサルプラグアンドプレイ（UPNP）[UPNP]など、他のNAT/ファイアウォールトラバーサルメカニズムを考慮することもできます。UPNPを使用して、ヒップノードと同じリンクでミドルボックスを構成できます。
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バインディングの作成は、非常にセキュリティに敏感なアクションです。ミドルボックス全体の股関節トラバーサルをサポートするためにそうするメカニズムは、十分に保護されるべきです。関連するセキュリティの問題の詳細な議論は、[RFC3715]や[RFC5190]などの対応する標準文書のセキュリティに関する考慮事項セクションに記載されています。
This document has not considered whether some of the options listed above pose additional threats to security of the HIP protocol itself.
このドキュメントでは、上記のオプションの一部が、股関節プロトコル自体のセキュリティに追加の脅威をもたらすかどうかを考慮していません。
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.
次の人々は、Pekka Nikander、Tom Henderson、およびThe Hip Research Groupの思慮深い提案とフィードバックを通じて、この文書の改善に役立ちました。著者は、最終的なレビュアー、ケビンフォール、マークオールマン、カレンソリンズに感謝したいと思います。
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.
Lars EggertとMartin Stiemerlingは、第6回フレームワークプログラムの下で欧州委員会がサポートする研究プロジェクトであるAmbient Networksによって部分的に資金提供されています。本明細書に含まれる見解と結論は著者の見解であり、アンビエントネットワークプロジェクトまたは欧州委員会の表明または黙示のいずれかの公式政策または承認を必ずしも表現するものと解釈すべきではない。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P。およびM. Holdrege、「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.、Volpe、V.、Diburro、L。、およびM. Stenberg、「IPSEC ESPパケットのUDPカプセル化」、RFC 3948、2005年1月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423] Moskowitz、R。およびP. Nikander、「Host Identity Protocol（HIP）Architecture」、RFC 4423、2006年5月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201] Moskowitz、R.、Nikander、P.、Jokela、P.、Ed。、およびT. Henderson、「Host Identity Protocol」、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.
[Nikander] Nikander、P.、Ylitalo、J。、およびJ. Wall、「セキュリティ、モビリティ、マルチホミングの統合」、Proc。ネットワークおよび分散システムセキュリティシンポジウム（NDSS）2003、2003年2月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]大工、B。およびS.ブリム、「ミドルボックス：分類法と問題」、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] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy、「スタン - ネットワークアドレス翻訳者（NAT）を介したユーザーデータグラムプロトコル（UDP）の単純なトラバーサル」、RFC 3489、2003年3月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] Aboba、B。およびW. Dixon、「Ipsec-Networkアドレス翻訳（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] Camarillo、G。およびJ. Rosenberg、「セッション説明プロトコル（SDP）グループ化フレームワークの代替ネットワークアドレスタイプ（ANAT）セマンティクス」、RFC 4091、2005年6月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（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、「Middleboxコミュニケーションのための管理オブジェクトの定義」、RFC 5190、2008年3月。
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206] Henderson、T.、ed。、「ホストIDプロトコルによるエンドホストモビリティとマルチホミング」、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サイト」、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.、Melen、J.、Nikander、P。、およびV. Torvinen、「IPベースのマイクロモビリティのセキュリティの再考」、Proc。第7回情報セキュリティ会議（ISC）2004、2004年9月。
Authors' Addresses
著者のアドレス
Martin Stiemerling NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany
Martin Stiemerling Nec Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115ドイツ
Phone: +49 6221 4342 113
Fax: +49 6221 4342 155
EMail: stiemerling@nw.neclab.eu
URI: http://www.nw.neclab.eu/
Juergen Quittek NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany
Juergen Quittek Nec Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115ドイツ
Phone: +49 6221 4342 115
Fax: +49 6221 4342 155
EMail: quittek@nw.neclab.eu
URI: http://www.nw.neclab.eu/
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
Lars Eggert Nokia Research Center P.O.Box 407 Nokia Group 00045フィンランド
Phone: +358 50 48 24461
EMail: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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への情報をお問い合わせください。