[要約] RFC 3948は、IPsec ESPパケットのUDPカプセル化に関する仕様を定めたものです。このRFCの目的は、UDPを使用してIPsec ESPパケットをトンネリングするための標準化とガイドラインを提供することです。
Network Working Group A. Huttunen
Request for Comments: 3948 F-Secure Corporation
Category: Standards Track B. Swander
Microsoft
V. Volpe
Cisco Systems
L. DiBurro
Nortel Networks
M. Stenberg
January 2005
UDP Encapsulation of IPsec ESP Packets
IPsec ESP パケットの UDP カプセル化
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネット コミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めます。このプロトコルの標準化状況とステータスについては、最新版の「インターネット公式プロトコル標準」(STD 1) を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権 (C) インターネット協会 (2005)。
Abstract
概要
This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for traversing Network Address Translators. ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Whenever negotiated, encapsulation is used with Internet Key Exchange (IKE).
このプロトコル仕様は、ネットワーク アドレス トランスレータを通過するために、UDP パケット内の IP カプセル化セキュリティ ペイロード (ESP) パケットをカプセル化およびカプセル化解除する方法を定義します。このドキュメントで定義されている ESP カプセル化は、IPv4 と IPv6 の両方のシナリオで使用できます。ネゴシエートされるたびに、インターネット キー交換 (IKE) でカプセル化が使用されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. UDP-Encapsulated ESP Header Format . . . . . . . . . . . 3
2.2. IKE Header Format for Port 4500 . . . . . . . . . . . . 4
2.3. NAT-Keepalive Packet Format . . . . . . . . . . . . . . 4
3. Encapsulation and Decapsulation Procedures . . . . . . . . . . 5
3.1. Auxiliary Procedures . . . . . . . . . . . . . . . . . . 5
3.1.1. Tunnel Mode Decapsulation NAT Procedure . . . . 5
3.1.2. Transport Mode Decapsulation NAT Procedure . . . 5
3.2. Transport Mode ESP Encapsulation . . . . . . . . . . . . 6
3.3. Transport Mode ESP Decapsulation . . . . . . . . . . . . 6
3.4. Tunnel Mode ESP Encapsulation . . . . . . . . . . . . . 7
3.5. Tunnel Mode ESP Decapsulation . . . . . . . . . . . . . 7
4. NAT Keepalive Procedure . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5.1. Tunnel Mode Conflict . . . . . . . . . . . . . . . . . . 8
5.2. Transport Mode Conflict . . . . . . . . . . . . . . . . 9
6. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11
A. Clarification of Potential NAT Multiple Client Solutions . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
This protocol specification defines methods to encapsulate and decapsulate ESP packets inside UDP packets for traversing Network Address Translators (NATs) (see [RFC3715], section 2.2, case i). The UDP port numbers are the same as those used by IKE traffic, as defined in [RFC3947].
このプロトコル仕様は、ネットワーク アドレス変換器 (NAT) を通過するために、UDP パケット内の ESP パケットをカプセル化およびカプセル化解除する方法を定義します ([RFC3715]、セクション 2.2、ケース i を参照)。UDP ポート番号は、[RFC3947] で定義されているように、IKE トラフィックで使用されるものと同じです。
The sharing of the port numbers for both IKE and UDP encapsulated ESP traffic was selected because it offers better scaling (only one NAT mapping in the NAT; no need to send separate IKE keepalives), easier configuration (only one port to be configured in firewalls), and easier implementation.
IKE と UDP の両方のカプセル化された ESP トラフィックのポート番号の共有が選択されたのは、より優れたスケーリング (NAT 内に 1 つの NAT マッピングのみ。個別の IKE キープアライブを送信する必要がない)、簡単な構成 (ファイアウォールで構成するポートは 1 つだけ) が提供されるためです。）、実装が簡単になります。
A client's needs should determine whether transport mode or tunnel mode is to be supported (see [RFC3715], Section 3, "Telecommuter scenario"). L2TP/IPsec clients MUST support the modes as defined in [RFC3193]. IPsec tunnel mode clients MUST support tunnel mode.
クライアントのニーズによって、トランスポート モードとトンネル モードのどちらをサポートするかが決定される必要があります ([RFC3715]、セクション 3、「在宅勤務者のシナリオ」を参照)。L2TP/IPsec クライアントは、[RFC3193] で定義されているモードをサポートしなければなりません (MUST)。IPsec トンネル モードのクライアントはトンネル モードをサポートしなければなりません (MUST)。
An IKE implementation supporting this protocol specification MUST NOT use the ESP SPI field zero for ESP packets. This ensures that IKE packets and ESP packets can be distinguished from each other.
このプロトコル仕様をサポートする IKE 実装は、ESP パケットに ESP SPI フィールド 0 を使用してはなりません (MUST NOT)。これにより、IKE パケットと ESP パケットを確実に区別できます。
As defined in this document, UDP encapsulation of ESP packets is written in terms of IPv4 headers. There is no technical reason why an IPv6 header could not be used as the outer header and/or as the inner header.
このドキュメントで定義されているように、ESP パケットの UDP カプセル化は IPv4 ヘッダーに関して記述されています。IPv6 ヘッダーを外部ヘッダーおよび内部ヘッダーとして使用できない技術的な理由はありません。
Because the protection of the outer IP addresses in IPsec AH is inherently incompatible with NAT, the IPsec AH was left out of the scope of this protocol specification. This protocol also assumes that IKE (IKEv1 [RFC2401] or IKEv2 [IKEv2]) is used to negotiate the IPsec SAs. Manual keying is not supported.
IPsec AH の外部 IP アドレスの保護は本質的に NAT と互換性がないため、IPsec AH はこのプロトコル仕様の範囲から除外されました。このプロトコルは、IPsec SA のネゴシエーションに IKE (IKEv1 [RFC2401] または IKEv2 [IKEv2]) が使用されることも前提としています。手動キー入力はサポートされていません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨」、「してもよい」、「任意」は次のとおりです。[RFC2119] に記載されているように解釈されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ESP header [RFC2406] |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The UDP header is a standard [RFC0768] header, where
UDP ヘッダーは標準 [RFC0768] ヘッダーです。
o the Source Port and Destination Port MUST be the same as that used by IKE traffic, o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and o receivers MUST NOT depend on the UDP checksum being a zero value.
o 送信元ポートと宛先ポートは IKE トラフィックで使用されるものと同じでなければなりません (MUST)。 o IPv4 UDP チェックサムはゼロ値として送信されるべきです (SHOULD)。 o 受信者は UDP チェックサムがゼロ値であることに依存してはなりません (MUST NOT)。
The SPI field in the ESP header MUST NOT be a zero value.
ESP ヘッダーの SPI フィールドはゼロ値であってはなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Non-ESP Marker |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE header [RFC2409] |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The UDP header is a standard [RFC0768] header and is used as defined in [RFC3947]. This document does not set any new requirements for the checksum handling of an IKE packet.
UDP ヘッダーは標準 [RFC0768] ヘッダーであり、[RFC3947] で定義されているように使用されます。この文書は、IKE パケットのチェックサム処理に関する新しい要件を設定しません。
A Non-ESP Marker is 4 zero-valued bytes aligning with the SPI field of an ESP packet.
非 ESP マーカーは、ESP パケットの SPI フィールドと一致する 4 つのゼロ値バイトです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xFF |
+-+-+-+-+-+-+-+-+
The UDP header is a standard [RFC0768] header, where
UDP ヘッダーは標準 [RFC0768] ヘッダーです。
o the Source Port and Destination Port MUST be the same as used by UDP-ESP encapsulation of Section 2.1, o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and o receivers MUST NOT depend upon the UDP checksum being a zero value.
o 送信元ポートと宛先ポートはセクション 2.1 の UDP-ESP カプセル化で使用されるものと同じでなければなりません (MUST)。 o IPv4 UDP チェックサムはゼロ値として送信されるべきです (SHOULD)。 o 受信者は UDP チェックサムがゼロ値であることに依存してはなりません (MUST NOT)。
The sender MUST use a one-octet-long payload with the value 0xFF. The receiver SHOULD ignore a received NAT-keepalive packet.
送信者は、値 0xFF を持つ 1 オクテット長のペイロードを使用しなければなりません (MUST)。受信者は、受信した NAT キープアライブ パケットを無視する必要があります (SHOULD)。
When a tunnel mode has been used to transmit packets (see [RFC3715], section 3, criteria "Mode support" and "Telecommuter scenario"), the inner IP header can contain addresses that are not suitable for the current network. This procedure defines how these addresses are to be converted to suitable addresses for the current network.
パケットの送信にトンネル モードが使用されている場合 ([RFC3715]、セクション 3、基準「モード サポート」および「在宅勤務シナリオ」を参照)、内部 IP ヘッダーには現在のネットワークに適さないアドレスが含まれる可能性があります。この手順では、これらのアドレスを現在のネットワークに適したアドレスに変換する方法を定義します。
Depending on local policy, one of the following MUST be done:
ローカル ポリシーに応じて、次のいずれかを実行する必要があります。
1. If a valid source IP address space has been defined in the policy for the encapsulated packets from the peer, check that the source IP address of the inner packet is valid according to the policy. 2. If an address has been assigned for the remote peer, check that the source IP address used in the inner packet is the assigned IP address. 3. NAT is performed for the packet, making it suitable for transport in the local network.
1. 有効な送信元 IP アドレス空間がピアからのカプセル化されたパケットのポリシーで定義されている場合は、内部パケットの送信元 IP アドレスがポリシーに従って有効であることを確認します。2. リモート ピアにアドレスが割り当てられている場合は、内部パケットで使用されている送信元 IP アドレスが割り当てられた IP アドレスであることを確認します。3. パケットに対して NAT が実行され、ローカル ネットワークでの転送に適したものになります。
When a transport mode has been used to transmit packets, contained TCP or UDP headers will have incorrect checksums due to the change of parts of the IP header during transit. This procedure defines how to fix these checksums (see [RFC3715], section 2.1, case b).
パケットの送信にトランスポート モードが使用されている場合、送信中に IP ヘッダーの一部が変更されるため、含まれる TCP または UDP ヘッダーのチェックサムが不正確になります。この手順は、これらのチェックサムを修正する方法を定義します ([RFC3715]、セクション 2.1、ケース b を参照)。
Depending on local policy, one of the following MUST be done:
ローカル ポリシーに応じて、次のいずれかを実行する必要があります。
1. If the protocol header after the ESP header is a TCP/UDP header and the peer's real source and destination IP address have been received according to [RFC3947], incrementally recompute the TCP/UDP checksum:
1. ESP ヘッダーの後のプロトコル ヘッダーが TCP/UDP ヘッダーであり、ピアの実際の送信元および宛先 IP アドレスが [RFC3947] に従って受信されている場合は、TCP/UDP チェックサムを増分的に再計算します。
* Subtract the IP source address in the received packet from the checksum. * Add the real IP source address received via IKE to the checksum (obtained from the NAT-OA) * Subtract the IP destination address in the received packet from the checksum. * Add the real IP destination address received via IKE to the checksum (obtained from the NAT-OA). Note: If the received and real address are the same for a given address (e.g., say the source address), the operations cancel and don't need to be performed.
* 受信パケット内の送信元 IP アドレスをチェックサムから減算します。* IKE 経由で受信した実際の送信元 IP アドレスをチェックサム (NAT-OA から取得) に加算します。 * 受信パケット内の IP 宛先アドレスをチェックサムから減算します。* IKE 経由で受信した実際の IP 宛先アドレスをチェックサム (NAT-OA から取得) に追加します。注: 受信したアドレスと実際のアドレスが特定のアドレス (たとえば、送信元アドレス) に対して同じである場合、操作はキャンセルされるため、実行する必要はありません。
2. If the protocol header after the ESP header is a TCP/UDP header, recompute the checksum field in the TCP/UDP header.
2. ESP ヘッダーの後のプロトコル ヘッダーが TCP/UDP ヘッダーの場合は、TCP/UDP ヘッダーのチェックサム フィールドを再計算します。
3. If the protocol header after the ESP header is a UDP header, set the checksum field to zero in the UDP header. If the protocol after the ESP header is a TCP header, and if there is an option to flag to the stack that the TCP checksum does not need to be computed, then that flag MAY be used. This SHOULD only be done for transport mode, and if the packet is integrity protected. Tunnel mode TCP checksums MUST be verified. (This is not a violation to the spirit of section 4.2.2.7 in [RFC1122] because a checksum is being generated by the sender and verified by the receiver. That checksum is the integrity over the packet performed by IPsec.)
3. ESP ヘッダーの後のプロトコル ヘッダーが UDP ヘッダーの場合は、UDP ヘッダーのチェックサム フィールドをゼロに設定します。ESP ヘッダーの後のプロトコルが TCP ヘッダーであり、TCP チェックサムを計算する必要がないことをスタックにフラグを立てるオプションがある場合、そのフラグを使用してもよい(MAY)。これは、パケットの整合性が保護されている場合、トランスポート モードでのみ実行すべきです(SHOULD)。トンネル モードの TCP チェックサムを検証する必要があります。(チェックサムは送信者によって生成され、受信者によって検証されるため、これは [RFC1122] のセクション 4.2.2.7 の精神に違反しません。そのチェックサムは、IPsec によって実行されるパケットの整合性です。)
In addition an implementation MAY fix any contained protocols that have been broken by NAT (see [RFC3715], section 2.1, case g).
さらに、実装は、NAT によって破壊された含まれるプロトコルを修正してもよい (MAY) ([RFC3715]、セクション 2.1、ケース g を参照)。
BEFORE APPLYING ESP/UDP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP/UDP
-------------------------------------------------------
IPv4 |orig IP hdr | UDP | ESP | | | ESP | ESP|
|(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth|
-------------------------------------------------------
|<----- encrypted ---->|
|<------ authenticated ----->|
1. Ordinary ESP encapsulation procedure is used. 2. A properly formatted UDP header is inserted where shown. 3. The Total Length, Protocol, and Header Checksum (for IPv4) fields in the IP header are edited to match the resulting IP packet.
1. 通常の ESP カプセル化手順が使用されます。2. 適切にフォーマットされた UDP ヘッダーが示されている場所に挿入されます。3. IP ヘッダーの合計長、プロトコル、およびヘッダー チェックサム (IPv4 の場合) フィールドは、結果の IP パケットと一致するように編集されます。
1. The UDP header is removed from the packet. 2. The Total Length, Protocol, and Header Checksum (for IPv4) fields in the new IP header are edited to match the resulting IP packet. 3. Ordinary ESP decapsulation procedure is used. 4. Transport mode decapsulation NAT procedure is used.
1. UDP ヘッダーがパケットから削除されます。2. 新しい IP ヘッダーの合計長、プロトコル、およびヘッダー チェックサム (IPv4 の場合) フィールドは、結果の IP パケットと一致するように編集されます。3. 通常の ESP カプセル化解除手順が使用されます。4. トランスポート モードのカプセル化解除 NAT プロシージャが使用されます。
BEFORE APPLYING ESP/UDP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP/UDP
--------------------------------------------------------------
IPv4 |new h.| UDP | ESP |orig IP hdr | | | ESP | ESP|
|(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth|
--------------------------------------------------------------
|<------------ encrypted ----------->|
|<------------- authenticated ------------>|
1. Ordinary ESP encapsulation procedure is used. 2. A properly formatted UDP header is inserted where shown. 3. The Total Length, Protocol, and Header Checksum (for IPv4) fields in the new IP header are edited to match the resulting IP packet.
1. 通常の ESP カプセル化手順が使用されます。2. 適切にフォーマットされた UDP ヘッダーが示されている場所に挿入されます。3. 新しい IP ヘッダーの合計長、プロトコル、およびヘッダー チェックサム (IPv4 の場合) フィールドは、結果の IP パケットと一致するように編集されます。
1. The UDP header is removed from the packet. 2. The Total Length, Protocol, and Header Checksum (for IPv4) fields in the new IP header are edited to match the resulting IP packet. 3. Ordinary ESP decapsulation procedure is used. 4. Tunnel mode decapsulation NAT procedure is used.
1. UDP ヘッダーがパケットから削除されます。2. 新しい IP ヘッダーの合計長、プロトコル、およびヘッダー チェックサム (IPv4 の場合) フィールドは、結果の IP パケットと一致するように編集されます。3. 通常の ESP カプセル化解除手順が使用されます。4. トンネル モードのカプセル化解除 NAT 手順が使用されます。
The sole purpose of sending NAT-keepalive packets is to keep NAT mappings alive for the duration of a connection between the peers (see [RFC3715], Section 2.2, case j). Reception of NAT-keepalive packets MUST NOT be used to detect whether a connection is live.
NAT キープアライブ パケットを送信する唯一の目的は、ピア間の接続中に NAT マッピングを維持することです ([RFC3715]、セクション 2.2、ケース j を参照)。NAT キープアライブ パケットの受信を、接続がライブかどうかの検出に使用してはなりません (MUST NOT)。
A peer MAY send a NAT-keepalive packet if one or more phase I or phase II SAs exist between the peers, or if such an SA has existed at most N minutes earlier. N is a locally configurable parameter with a default value of 5 minutes.
ピア間に 1 つ以上のフェーズ I またはフェーズ II SA が存在する場合、またはそのような SA が最大 N 分前に存在していた場合、ピアは NAT キープアライブ パケットを送信してもよい(MAY)。N はローカルで構成可能なパラメータで、デフォルト値は 5 分です。
A peer SHOULD send a NAT-keepalive packet if a need for it is detected according to [RFC3947] and if no other packet to the peer has been sent in M seconds. M is a locally configurable parameter with a default value of 20 seconds.
[RFC3947]に従ってNATキープアライブパケットの必要性が検出され、M秒以内に他のパケットがピアに送信されなかった場合、ピアはNATキープアライブパケットを送信すべきである(SHOULD)。M はローカルに設定可能なパラメータで、デフォルト値は 20 秒です。
Implementors are warned that it is possible for remote peers to negotiate entries that overlap in an SGW (security gateway), an issue affecting tunnel mode (see [RFC3715], section 2.1, case e).
実装者は、リモートピアが SGW (セキュリティゲートウェイ) 内で重複するエントリをネゴシエートする可能性があり、これはトンネルモードに影響を与える問題であると警告されています ([RFC3715]、セクション 2.1、ケース e を参照)。
+----+ \ /
| |-------------|----\
+----+ / \ \
Ari's NAT 1 \
Laptop \
10.1.2.3 \
+----+ \ / \ +----+ +----+
| |-------------|----------+------| |----------| |
+----+ / \ +----+ +----+
Bob's NAT 2 SGW Suzy's
Laptop Server
10.1.2.3
Because SGW will now see two possible SAs that lead to 10.1.2.3, it can become confused about where to send packets coming from Suzy's server. Implementors MUST devise ways of preventing this from occurring.
SGW は 10.1.2.3 につながる 2 つの SA を認識することになるため、Suzy のサーバーからのパケットをどこに送信すればよいか混乱する可能性があります。実装者は、これが起こらないようにする方法を考案しなければなりません。
It is RECOMMENDED that SGW either assign locally unique IP addresses to Ari's and Bob's laptop (by using a protocol such as DHCP over IPsec) or use NAT to change Ari's and Bob's laptop source IP addresses to these locally unique addresses before sending packets forward to Suzy's server. This covers the "Scaling" criteria of section 3 in [RFC3715].
SGW は、パケットを Suzy に転送する前に、(DHCP over IPsec などのプロトコルを使用して) Ari と Bob のラップトップにローカルで一意の IP アドレスを割り当てるか、NAT を使用して Ari と Bob のラップトップの送信元 IP アドレスをこれらのローカルで一意のアドレスに変更することを推奨します。サーバ。これは、[RFC3715] のセクション 3 の「スケーリング」基準をカバーします。
Please see Appendix A.
付録 A を参照してください。
Another similar issue may occur in transport mode, with 2 clients, Ari and Bob, behind the same NAT talking securely to the same server (see [RFC3715], Section 2.1, case e).
別の同様の問題は、同じ NAT の背後で同じサーバーと安全に通信している 2 つのクライアント、Ari と Bob のトランスポート モードでも発生する可能性があります ([RFC3715]、セクション 2.1、ケース e を参照)。
Cliff wants to talk in the clear to the same server.
クリフは、同じサーバーと平文で通信したいと考えています。
+----+
| |
+----+ \
Ari's \
Laptop \
10.1.2.3 \
+----+ \ / +----+
| |-----+-----------------| |
+----+ / \ +----+
Bob's NAT Server
Laptop /
10.1.2.4 /
/
+----+ /
| |/
+----+
Cliff's
Laptop
10.1.2.5
Now, transport SAs on the server will look like this:
これで、サーバー上のトランスポート SA は次のようになります。
To Ari: Server to NAT, <traffic desc1>, UDP encap <4500, Y>
To Bob: Server to NAT, <traffic desc2>, UDP encap <4500, Z>
Cliff's traffic is in the clear, so there is no SA.
クリフは交通量が少ないため、SA はありません。
<traffic desc> is the protocol and port information. The UDP encap ports are the ports used in UDP-encapsulated ESP format of section 2.1. Y,Z are the dynamic ports assigned by the NAT during the IKE negotiation. So IKE traffic from Ari's laptop goes out on UDP <4500,4500>. It reaches the server as UDP <Y,4500>, where Y is the dynamically assigned port.
<traffic desc> はプロトコルとポートの情報です。UDP カプセル化ポートは、セクション 2.1 の UDP カプセル化 ESP フォーマットで使用されるポートです。Y、Z は、IKE ネゴシエーション中に NAT によって割り当てられる動的ポートです。したがって、Ari のラップトップからの IKE トラフィックは UDP <4500,4500> で送信されます。これは UDP <Y,4500> としてサーバーに到達します。Y は動的に割り当てられたポートです。
If the <traffic desc1> overlaps <traffic desc2>, then simple filter lookups may not be sufficient to determine which SA has to be used to send traffic. Implementations MUST handle this situation, either by disallowing conflicting connections, or by other means.
<traffic desc1> が <traffic desc2> と重複する場合、単純なフィルター検索では、トラフィックの送信にどの SA を使用する必要があるかを判断するのに十分ではない可能性があります。実装は、競合する接続を禁止するか、他の手段によって、この状況に対処しなければなりません (MUST)。
Assume now that Cliff wants to connect to the server in the clear. This is going to be difficult to configure, as the server already has a policy (from Server to the NAT's external address) for securing <traffic desc>. For totally non-overlapping traffic descriptions, this is possible.
ここで、Cliff が平文でサーバーに接続したいとします。サーバーには <traffic desc> を保護するためのポリシー (サーバーから NAT の外部アドレスまで) がすでに存在するため、これを構成するのは困難です。トラフィックの説明がまったく重複していない場合、これは可能です。
Sample server policy could be as follows:
サーバー ポリシーの例は次のとおりです。
To Ari: Server to NAT, All UDP, secure
Ari へ: サーバーから NAT、すべて UDP、安全
To Bob: Server to NAT, All TCP, secure
ボブへ: サーバーから NAT、すべて TCP、安全
To Cliff: Server to NAT, ALL ICMP, clear text
クリフへ: サーバーから NAT、ALL ICMP、クリア テキスト
Note that this policy also lets Ari and Bob send cleartext ICMP to the server.
このポリシーにより、Ari と Bob が平文 ICMP をサーバーに送信できるようになることにも注意してください。
The server sees all clients behind the NAT as the same IP address, so setting up different policies for the same traffic descriptor is in principle impossible.
サーバーは、NAT の背後にあるすべてのクライアントを同じ IP アドレスとして認識するため、同じトラフィック記述子に異なるポリシーを設定することは原理的に不可能です。
A problematic example of configuration on the server is as follows:
サーバー上の問題のある構成例は次のとおりです。
Server to NAT, TCP, secure (for Ari and Bob)
サーバーから NAT、TCP、セキュアへ (Ari と Bob の場合)
Server to NAT, TCP, clear (for Cliff)
サーバーから NAT、TCP、クリア (Cliff 用)
The server cannot enforce his policy, as it is possible that misbehaving Bob sends traffic in the clear. This is indistinguishable from when Cliff sends traffic in the clear. So it is impossible to guarantee security from some clients behind a NAT, while allowing clear text from different clients behind the SAME NAT. If the server's security policy allows this, however, it can do best-effort security: If the client from behind the NAT initiates security, his connection will be secured. If he sends in the clear, the server will still accept that clear text.
不正な動作をするボブが平文でトラフィックを送信する可能性があるため、サーバーは彼のポリシーを強制できません。これは、Cliff がトラフィックを平文で送信する場合と区別できません。したがって、同じ NAT の背後にある別のクライアントからのクリア テキストを許可しながら、NAT の背後にある一部のクライアントからのセキュリティを保証することは不可能です。ただし、サーバーのセキュリティ ポリシーでこれが許可されている場合は、ベストエフォート型のセキュリティを実行できます。NAT の背後からクライアントがセキュリティを開始すると、その接続は保護されます。平文で送信した場合でも、サーバーはその平文を受け入れます。
For security guarantees, the above problematic scenario MUST NOT be allowed on servers. For best effort security, this scenario MAY be used.
セキュリティを保証するために、上記の問題のあるシナリオをサーバー上で許可してはなりません。ベストエフォート型セキュリティの場合、このシナリオを使用してもよい(MAY)。
Please see Appendix A.
付録 A を参照してください。
The UNSAF [RFC3424] questions are addressed by the IPsec-NAT compatibility requirements document [RFC3715].
UNSAF [RFC3424] の質問は、IPsec-NAT 互換性要件文書 [RFC3715] で解決されています。
Thanks to Tero Kivinen and William Dixon, who contributed actively to this document.
この文書に積極的に貢献した Tero Kivinen と William Dixon に感謝します。
Thanks to Joern Sierwald, Tamir Zegman, Tatu Ylonen, and Santeri Paavolainen, who contributed to the early documents about NAT traversal.
NAT トラバーサルに関する初期の文書に貢献した Jorn Sierwald、Tamir Zegman、Tatu Ylonen、Santeri Paavolainen に感謝します。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel, J.、「ユーザー データグラム プロトコル」、STD 6、RFC 768、1980 年 8 月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、BCP 14、RFC 2119、1997 年 3 月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent, S. および R. Atkinson、「インターネット プロトコルのセキュリティ アーキテクチャ」、RFC 2401、1998 年 11 月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406] Kent, S. および R. Atkinson、「IP カプセル化セキュリティ ペイロード (ESP)」、RFC 2406、1998 年 11 月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins, D. および D. Carrel、「インターネット鍵交換 (IKE)」、RFC 2409、1998 年 11 月。
[RFC3947] Kivinen, T., "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947] Kivinen, T.、「IKE における NAT トラバーサルのネゴシエーション」、RFC 3947、2005 年 1 月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden, R.、「インターネット ホストの要件 - 通信層」、STD 3、RFC 1122、1989 年 10 月。
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3193] Patel, B.、Aboba, B.、Dixon, W.、Zorn, G.、および S. Booth、「IPsec を使用した L2TP の保護」、RFC 3193、2001 年 11 月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424] Daigle, L. および IAB、「ネットワーク アドレス変換全体にわたる一方的セルフアドレス固定 (UNSAF) に関する IAB の考慮事項」、RFC 3424、2002 年 11 月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] Ababa, B. および W. Dixon、「IPsec ネットワーク アドレス変換 (NAT) 互換性要件」、RFC 3715、2004 年 3 月。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Work in Progress, October 2004.
[IKEv2] Kaufman, C.、「インターネット キー交換 (IKEv2) プロトコル」、進行中の作業、2004 年 10 月。
This appendix provides clarification about potential solutions to the problem of multiple clients behind the same NAT simultaneously connecting to the same destination IP address.
この付録では、同じ NAT の背後にある複数のクライアントが同じ宛先 IP アドレスに同時に接続する問題に対する潜在的な解決策について説明します。
Sections 5.1 and 5.2 say that you MUST avoid this problem. As this is not a matter of wire protocol, but a matter local implementation, the mechanisms do not belong in the protocol specification itself. They are instead listed in this appendix.
セクション 5.1 と 5.2 では、この問題を回避しなければならないと述べています。これはワイヤ プロトコルの問題ではなく、ローカル実装の問題であるため、メカニズムはプロトコル仕様自体には属しません。代わりに、それらはこの付録にリストされています。
Choosing an option will likely depend on the scenarios for which one uses/supports IPsec NAT-T. This list is not meant to be exhaustive, so other solutions may exist. We first describe the generic choices that solve the problem for all upper-layer protocols.
オプションの選択は、IPsec NAT-T を使用/サポートするシナリオによって異なります。このリストは網羅的なものではないため、他の解決策が存在する可能性があります。まず、すべての上位層プロトコルの問題を解決する一般的な選択肢について説明します。
Generic choices for ESP transport mode:
ESP トランスポート モードの一般的な選択肢:
Tr1) Implement a built-in NAT (network address translation) above IPsec decapsulation.
Tr1) IPsec カプセル化解除の上に組み込みの NAT (ネットワーク アドレス変換) を実装します。
Tr2) Implement a built-in NAPT (network address port translation) above IPsec decapsulation.
Tr2) IPsec カプセル化解除の上に組み込み NAPT (ネットワーク アドレス ポート変換) を実装します。
Tr3) An initiator may decide not to request transport mode once NAT is detected and may instead request a tunnel-mode SA. This may be a retry after transport mode is denied by the responder, or the initiator may choose to propose a tunnel SA initially. This is no more difficult than knowing whether to propose transport mode or tunnel mode without NAT. If for some reason the responder prefers or requires tunnel mode for NAT traversal, it must reject the quick mode SA proposal for transport mode.
Tr3) イニシエータは、NAT が検出されるとトランスポート モードを要求しないことを決定し、代わりにトンネル モード SA を要求する場合があります。これは、レスポンダによってトランスポート モードが拒否された後の再試行である場合もあれば、イニシエータが最初にトンネル SA を提案することを選択する場合もあります。これは、トランスポート モードを提案するか、NAT を使用しないトンネル モードを提案するかを知ることと同じくらい難しいことではありません。何らかの理由で、レスポンダが NAT トラバーサルにトンネル モードを優先または要求する場合、トランスポート モードのクイック モード SA 提案を拒否する必要があります。
Generic choices for ESP tunnel mode:
ESP トンネル モードの一般的な選択肢:
Tn1) Same as Tr1.
Tn1) Tr1と同じ。
Tn2) Same as Tr2.
Tn2) Tr2と同じ。
Tn3) This option is possible if an initiator can be assigned an address through its tunnel SA, with the responder using DHCP. The initiator may initially request an internal address via the DHCP-IPsec method, regardless of whether it knows it is behind a NAT. It may re-initiate an IKE quick mode negotiation for DHCP tunnel SA after the responder fails the quick mode SA transport mode proposal. This happens either when a NAT-OA payload is sent or because it discovers from NAT-D that the initiator is behind a NAT and its local configuration/policy will only accept a NAT connection when being assigned an address through DHCP-IPsec.
Tn3) このオプションは、応答側が DHCP を使用し、イニシエータにそのトンネル SA を通じてアドレスを割り当てることができる場合に可能です。イニシエータは、NAT の背後にあることを認識しているかどうかに関係なく、最初に DHCP-IPsec メソッドを介して内部アドレスを要求することがあります。レスポンダがクイック モード SA トランスポート モードの提案に失敗した後、DHCP トンネル SA の IKE クイック モード ネゴシエーションを再開始する場合があります。これは、NAT-OA ペイロードが送信されたとき、またはイニシエーターが NAT の背後にあり、そのローカル構成/ポリシーが DHCP-IPsec 経由でアドレスが割り当てられている場合にのみ NAT 接続を受け入れることを NAT-D から検出した場合に発生します。
There are also implementation choices that offer limited interoperability. Implementors should specify which applications or protocols should work if these options are selected. Note that neither Tr4 nor Tn4, as described below, are expected to work with TCP traffic.
限定的な相互運用性を提供する実装の選択肢もあります。実装者は、これらのオプションが選択された場合にどのアプリケーションまたはプロトコルが機能するかを指定する必要があります。以下で説明するように、Tr4 も Tn4 も TCP トラフィックでは機能しないことに注意してください。
Limited interoperability choices for ESP transport mode:
ESP トランスポート モードの限定された相互運用性の選択肢:
Tr4) Implement upper-layer protocol awareness of the inbound and outbound IPsec SA so that it doesn't use the source IP and the source port as the session identifier (e.g., an L2TP session ID mapped to the IPsec SA pair that doesn't use the UDP source port or the source IP address for peer uniqueness).
Tr4) 送信元 IP と送信元ポートをセッション識別子として使用しないように、受信および送信 IPsec SA の上位層プロトコル認識を実装します (例: IPsec SA ペアにマッピングされた L2TP セッション ID など)。ピアの一意性のために UDP 送信元ポートまたは送信元 IP アドレスを使用します)。
Tr5) Implement application integration with IKE initiation so that it can rebind to a different source port if the IKE quick mode SA proposal is rejected by the responder; then it can repropose the new QM selector.
Tr5) IKE クイック モード SA プロポーザルがレスポンダによって拒否された場合に、別の送信元ポートに再バインドできるように、IKE 開始とのアプリケーション統合を実装します。その後、新しい QM セレクターを再提案できます。
Limited interoperability choices for ESP tunnel mode:
ESP トンネル モードの相互運用性の選択肢は次のとおりです。
Tn4) Same as Tr4.
Tn4) Tr4と同じ。
Authors' Addresses
著者の住所
Ari Huttunen F-Secure Corporation Tammasaarenkatu 7 HELSINKI FIN-00181 FI
Ari Huttunen F-Secure Corporation Tammasaarenkatu 7 HELSINKI FIN-00181 FI
EMail: Ari.Huttunen@F-Secure.com
Brian Swander Microsoft One Microsoft Way Redmond, WA 98052 US
Brian Swander Microsoft One Microsoft Way Redmond, WA 98052 US
EMail: briansw@microsoft.com
Victor Volpe Cisco Systems 124 Grove Street Suite 205 Franklin, MA 02038 US
Victor Volpe Cisco Systems 124 Grove Street Suite 205 Franklin, MA 02038 US
EMail: vvolpe@cisco.com
Larry DiBurro Nortel Networks 80 Central Street Boxborough, MA 01719 US
Larry DiBurro Nortel Networks 80 Central Street Boxborough, MA 01719 US
EMail: ldiburro@nortelnetworks.com
Markus Stenberg FI
マルクス・ステンバーグ FI
EMail: markus.stenberg@iki.fi
Full Copyright Statement
完全な著作権に関する声明
Copyright (C) The Internet Society (2005).
著作権 (C) インターネット協会 (2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF は、本書に記載されているテクノロジの実装または使用に関連すると主張される知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが適用されるかどうかの範囲に関して、いかなる立場も負いません。利用可能であること。また、かかる権利を特定するために独自の努力を行ったことを示すものでもありません。IETF 文書の権利に関する IETF の手順に関する情報は、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 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/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 (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。