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
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を参照のこと）。 [RFC3947]で定義されるようにUDPポート番号は、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の両方のポート番号の共有は、それがより良いスケーリング（別のIKEキープアライブを送信する必要はありませんNATで唯一のNATマッピング）を提供していますので、ESPトラフィックが選択されたカプセル化）、かつ容易に実装。
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章、「在宅勤務シナリオ」）。 [RFC3193]で定義されているL2TP / IPSecクライアントは、モードをサポートしなければなりません。 IPsecトンネルモードのクライアントは、トンネルモードをサポートしなければなりません。
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フィールドにゼロを使用してはなりません。これは、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は、このプロトコル仕様の範囲の外に残っていました。このプロトコルは、IKE（IKEv1の[RFC2401]かのIKEv2 [IKEv2の]）はIPSec SAをネゴシエートするために使用されることを想定しています。手動キー入力がサポートされていません。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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のIPv4 UDPチェックサムがゼロ値として送信されるべきであり、O受信機はUDPチェックサムがゼロ値であることに依存してはなりませんOソースポートと宛先ポートは、IKEトラフィックによって使用されているものと同じでなければなりません。
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のIPv4 UDPチェックサムがゼロ値として送信されるべきである（SHOULD）O、2.1節のUDP-ESPのカプセル化で使用される送信元ポートと宛先ポートが同じでなければならない、とO受信機は、UDPチェックサムがゼロ値であることに依存してはなりません。
The sender MUST use a one-octet-long payload with the value 0xFF. The receiver SHOULD ignore a received NAT-keepalive packet.
送信者は、値は0xFFに1オクテット長のペイロードを使用しなければなりません。受信機は、受信NATキープアライブパケットを無視すべきです。
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).
トランスポートモードでは、パケットを送信するために使用されている場合、含まれるTCPまたはUDPヘッダが原因輸送中のIPヘッダの部分の変化に間違ったチェックサムを有することになります。この手順では、（[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.
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.)
ESPヘッダの後プロトコルヘッダがUDPヘッダである場合3. UDPヘッダゼロにチェックサムフィールドを設定します。 ESPヘッダの後プロトコルがTCPヘッダであり、TCPチェックサムを計算する必要がないスタックにフラグのオプションが存在する場合、そのフラグが使用されてもよい。場合これは、トランスポートモードのみのために行われるべきであり、パケットが完全性保護されている場合。トンネルモードの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によって破壊されている任意の含まれるプロトコルを固定してもよい（セクション2.1、ケースG、[RFC3715]参照）。
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キープアライブパケットを送信する唯一の目的は、（[RFC3715]、セクション2.2、ケースjを参照）、ピア間の接続の間生きているNATマッピングを維持することです。 NATキープアライブパケットの受信は、接続が生きているかどうかを検出するために使用してはいけません。
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.
一の以上の相IまたはフェーズIIは、SAが同位の間に存在する場合、または、そのようなSAが早く、ほとんどのN分に存在している場合、ピアは、NATキープアライブパケットを送信することができます。 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]に従って検出され、ピアに他のパケットがM秒で送信されていない場合のために必要な場合、ピアは、NATキープアライブパケットを送信すべきです。 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を表示されますので、スージーのサーバーから来たパケットを送信する場所について混乱することができます。実装者は、この発生を防止する方法を考案しなければなりません。
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はどちらか（たとえば、IPsecのオーバーDHCPなどのプロトコルを使用して）アリさんとボブのラップトップにローカルで一意のIPアドレスを割り当てるか、スージーのを楽しみにパケットを送信する前に、これらのローカルで一意のアドレスにアリさんとボブのラップトップの送信元IPアドレスを変更するためにNATを使用することをお勧めしますサーバ。これは、[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（[RFC3715]、セクション2.1、ケースEを参照）の後ろに、2つのクライアント、アリとボブと、トランスポート・モードで行うことができます。
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>
アリへ：NATのサーバー、<交通desc1>、UDP ENCAP <4500、Y>
To Bob: Server to NAT, <traffic desc2>, UDP encap <4500, Z>
ボブに：NATのサーバー、<交通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.
<交通DESC>は、プロトコルおよびポート情報です。 UDPのENCAPポートはセクション2.1のUDPカプセル化ESP形式で使用されるポートです。 Y、Zは、IKEネゴシエーション中にNATによって割り当てられた動的ポートです。だから、アリのラップトップからのIKEトラフィックはUDP <4500,4500>に出て行きます。これは、Yは、動的に割り当てられたポートであるUDP <Y、4500>、などのサーバに到達しました。
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.
<交通desc1>が<トラフィックdesc2を>重なる場合、単純なフィルタ検索はSAがトラフィックを送信するために使用されなければならないかを決定するのに十分ではないかもしれません。実装は競合の接続を拒否することによって、または他の手段のいずれかによって、この状況に対処しなければなりません。
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.
クリフが明確でサーバーに接続したいと仮定する。これは、サーバがすでに（NATの外部アドレスにサーバからの）方針を持っているように、<交通DESC>を確保するために、構成することが困難になるだろう。完全に非重複トラフィックの説明については、これは可能です。
Sample server policy could be as follows:
次のようにサンプルのサーバポリシーは次のようになります。
To Ari: Server to NAT, All UDP, secure
アリへ：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.
このポリシーはまた、アリとボブはサーバに平文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.
サーバは、その同じトラフィック記述子のために異なるポリシーを設定することは原則的に不可能であり、同じIPアドレスとNATの背後にすべてのクライアントを見ています。
A problematic example of configuration on the server is as follows:
次のようにサーバ上の構成の問題の例は次のとおりです。
Server to NAT, TCP, secure (for Ari and Bob)
（アリとボブのための）NAT、TCPのサーバ、セキュアな
Server to NAT, TCP, clear (for Cliff)
（クリフ用）NAT、TCPへのサーバー、明確な
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.
ボブをふらちなことは明らかでトラフィックを送信することが可能であるように、サーバーは、彼のポリシーを適用することはできません。これは、クリフが明確にトラフィックを送信する場合と区別がつきません。だから、同じ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.
安全保障のために、上記の問題のシナリオは、サーバー上で許可されてはなりません。ベストエフォートセキュリティを確保するために、このシナリオを使用することができます。
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とウィリアム・ディクソン、に感謝します。
Thanks to Joern Sierwald, Tamir Zegman, Tatu Ylonen, and Santeri Paavolainen, who contributed to the early documents about NAT traversal.
NATトラバーサルに関する早期の文書に貢献しJoern Sierwald、タミールZegman、タトゥYlonenと、そしてサンテリPaavolainen、に感謝します。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]ポステル、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（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]ブレーデン、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]パテル、B.、Aboba、B.、ディクソン、W.、ゾルン、G.、およびS.ブース、 "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.
、RFC 3424、2002年11月、 "ネットワークアドレス変換アクロス一方的な自己アドレス固定するためのIABの考慮事項（UNSAF）" [RFC3424] Daigle氏、L.とIAB、。
[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月。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Work in Progress, October 2004.
[IKEv2の]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）議定書"、進歩、2004年10月に作業。
Appendix A. Clarification of Potential NAT Multiple Client Solutions
潜在的なNAT複数のクライアント・ソリューションの付録A.明確化
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.
この付録では、同時に同じ宛先IPアドレスに接続し、同じNATの背後にある複数のクライアントの問題への解決策についての明確化を提供します。
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.
オプションを選択すると、おそらく1が使用するためのシナリオに依存します/ 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.
イニシエータは、DHCPを使用して応答して、そのトンネルSAを介してアドレスを割り当てることができる場合TN3）このオプションが可能です。イニシエータは最初にかかわらず、それがNATの背後にあることを知っているかどうかの、DHCP-IPsecの方法を介して内部アドレスを要求することができます。レスポンダは、クイックモードSAのトランスポートモードの提案を失敗した後にはDHCPトンネルSAのためのIKEクイックモードネゴシエーションを再度開始することができます。 NAT-OAペイロードが送信されるとき、またはそれがイニシエータがNATの背後にあることがNAT-Dから検出し、そのローカル設定/ポリシーのみDHCP-のIPsecを介してアドレスが割り当てられてNAT接続を受け入れるので、これはどちらかが起こります。
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）は、セッション識別子（例えば、ないIPsec SAのペアにマッピングされたL2TPセッションID、ソースIP、ソースポートを使用しないように、インバウンドおよびアウトバウンドのIPsec SAの上位層プロトコル認識を実装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.
IKEクイックモードSAの提案が応答者によって拒否された場合、それは別のソースポートに再バインドすることができるようにTr5が）IKE開始とアプリケーションの統合を実装します。それは新しいQMセレクタをreproposeすることができます。
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
アリHuttunen F-Secureの株式会社Tammasaarenkatu 7 FIN-00181 HELSINKI FI
EMail: Ari.Huttunen@F-Secure.com
メールアドレス：Ari.Huttunen@F-Secure.com
Brian Swander Microsoft One Microsoft Way Redmond, WA 98052 US
ブライアンSwanderマイクロソフト1マイクロソフト道、レッドモンド、ワシントン98052米国
EMail: briansw@microsoft.com
メールアドレス：briansw@microsoft.com
Victor Volpe Cisco Systems 124 Grove Street Suite 205 Franklin, MA 02038 US
ビクターボルペシスコシステムズ124グローブストリートスイート205フランクリン、MA 02038米国
EMail: vvolpe@cisco.com
メールアドレス：vvolpe@cisco.com
Larry DiBurro Nortel Networks 80 Central Street Boxborough, MA 01719 US
ラリーDiBurroノーテルネットワーク80中央ストリートボックスボロー、MA 01719米国
EMail: ldiburro@nortelnetworks.com
メールアドレス：ldiburro@nortelnetworks.com
Markus Stenberg FI
マルクスステンバーグFI
EMail: markus.stenberg@iki.fi
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the 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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。