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. 本文書はインターネットコミュニティのインターネット標準化手続きで開発 されたプロトコルを規定するものであり、改善となる議論及び提案を求める ものである。本プロトコルの標準化の状況については「インターネット公式 プロトコル標準(Internet Official Protocol Standards)」(STD 1)の最新版 を参照すること。本文書の配布に制限はない。 Copyright Notice 著作権表記 Copyright (C) The Internet Society (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). 本プロトコル仕様は、ネットワークアドレス変換装置(Network Address Translators)越えを行うために、UDP パケットの中への IP 暗号ペイロード (Encapsulating Security Payload:ESP)のカプセル化とそのカプセル開放 を行う手順を規定する。本文書で規定される ESP カプセル化は、 IPv4、IPv6 のいずれの場合でも利用可能である。カプセル化は、 自動鍵交換(IKE)でネゴシエーションを行う場合には必ず利用される。 Huttunen, et al. Standards Track [Page 1] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 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 1. Introduction 1. はじめに 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 越えを行うために([RFC 3715] のセクション2.2、 ケース i を参照)、UDP パケットの中への ESP パケットのカプセル化と そのカプセル開放を行う手順を規定する。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 テーブルにおいて一つの NAT マッピングだけで済み、別個に IKE キープアライブを送信する必要がない)、設定しやすく(ファイアウォールに 一つだけポートを設定すればよい)、実装が容易になるからである。 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. トランスポートモードとトンネルモードのいずれがサポートされるべきかは、 クライアントがそれを必要とするかどうかで決まる([RFC 3715] のセクション3、 "Telecommuter scenario" を参照)。L2TP/IPsec クライアントは、[RFC 3193] に規定されるモードを定義しなければならない(MUST)。IPsec トンネルモード クライアントは、トンネルモードをサポートしなければならない(MUST)。 Huttunen, et al. Standards Track [Page 2] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 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 フィールドにゼロを入れてはいけない(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 は本プロトコル仕様の対象外となった。 本プロトコルは、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", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", そして "OPTIONAL" といったキーワードは、[RFC2119]で解説される意味を想定している。 2. Packet Formats 2. パケット形式 2.1. UDP-Encapsulated ESP Header Format 2.1. UDP にカプセル化された ESP ヘッダ形式 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 ヘッダは以下の条件を満たす [RFC 768] 標準ヘッダである。 o the Source Port and Destination Port MUST be the same as that used by IKE traffic, o 送信元ポートと宛先ポートは、IKE トラフィックにおいて使用されるのと 同じものでなくてはならない(MUST)。 o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and o IPv4 UDP チェックサムにはゼロを入れて送信されるべきであり(SHOULD)、また o receivers MUST NOT depend on the UDP checksum being a zero value. o 受信者は、UDP チェックサム値がゼロであるかで判断してはいけない (MUST NOT)。 The SPI field in the ESP header MUST NOT be a zero value. ESP ヘッダの SPI フィールドがゼロがあってはならない(MUST NOT)。 Huttunen, et al. Standards Track [Page 3] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 2.2. IKE Header Format for Port 4500 2.2. ポート4500番向け IKE ヘッダ形式案 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 ヘッダは [RFC 768] 標準形式のヘッダであり、[RFC3947] に規定される 形で使用される。本文書は、IKE パケットのチェックサム処理に関して新たな 要求事項を提起するものではない。 A Non-ESP Marker is 4 zero-valued bytes aligning with the SPI field of an ESP packet. Non-ESP Marker は、ESP ヘッダであれば SPI フィールドにあたる4バイトの 0が割り当てられた領域である。 2.3. NAT-Keepalive Packet Format 2.3. NAT-keepalive パケット形式 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 ヘッダは以下の条件を満たす [RFC 768] 標準ヘッダである。 o the Source Port and Destination Port MUST be the same as used by UDP-ESP encapsulation of Section 2.1, o 送信元ポートと宛先ポートはセクション2.1の UDP-ESP カプセル化 において使用されるのと同じものでなくてはならない(MUST)。 o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and o IPv4 UDP チェックサムにはゼロ値を入れて送信されるべきであり(SHOULD)、また o receivers MUST NOT depend upon the UDP checksum being a zero value. 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. 送信者は、1バイトのペイロードに 0xFF という値を入れるべきである(SHOULD)。 受信者は、受信した NAT-keepalive パケットを無視すべきである(SHOULD)。 Huttunen, et al. Standards Track [Page 4] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 3. Encapsulation and Decapsulation Procedures 3. カプセル化とカプセル開放の手順 3.1. Auxiliary Procedures 3.1. 補助手順 3.1.1. Tunnel Mode Decapsulation NAT Procedure 3.1.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. パケットの伝送にトンネルモードが使用される場合([RFC 3715] のセクション3 で規定される "Mode support" と "Telecommuter scenario" を参照)、 内側の IP パケットは、実際にパケットが流れるネットワークにふさわしく ないアドレスを含むことになる。この手順は、そうしたアドレスを実際に パケットが流れるネットワークにふさわしいアドレスに変換する手法を定義する。 Depending on local policy, one of the following MUST be done: ローカルポリシーに応じて、以下のいずれかが行われなくてはならない(MUST): 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. 1. カプセル化されるパケットについて、ポリシーにおいて有効な送信元 IP アドレス範囲がピアで規定されているなら、内側パケットの送信元 IP アドレスがそのポリシーに適合していることをチェックする。 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. 2. リモート側のピアのアドレスが指定されているなら、内側パケットで 使用される送信元 IP アドレスが、その指定された IP アドレスである ことをチェックする。 3. NAT is performed for the packet, making it suitable for transport in the local network. 3. NAT 処理をパケットに施し、ローカルネットワークに伝送するのに 適したものにする。 3.1.2. Transport Mode Decapsulation NAT Procedure 3.1.2. トランスポートモードにおいてカプセル開放を行う 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 ヘッダに不正確なチェックサムが入ることになる。ここに示す手順は、 そうしたチェックサムの修正方法を規定するものである([RFC 3715] の セクション2.1、ケース b を参照)。 Depending on local policy, one of the following MUST be done: ローカルポリシーに応じて、以下のいずれかが行われなくてはならない(MUST): 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. * チェックサムから受信パケットの送信元 IP アドレスの内容を除外する * Add the real IP source address received via IKE to the checksum (obtained from the NAT-OA) * IKE により受信している本当の送信元 IP アドレス(NAT-OA ペイロードから取得)の内容をチェックサムに追加する * Subtract the IP destination address in the received packet from the checksum. * チェックサムから受信パケットの宛先 IP アドレスの内容を除外する * Add the real IP destination address received via IKE to the checksum (obtained from the NAT-OA). * IKE により受信している本当の宛先 IP アドレス(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. 注記:受信したアドレスと本当のアドレスが特定のアドレスならば (例えば、送信元アドレス)、以上の操作は中止され、 実行する必要はない。 Huttunen, et al. Standards Track [Page 5] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 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 チェックサムは検証されなくてはならない(MUST)。 (これは、チェックサムはパケットの送信者により生成され、受信者により 検証されるという [RFC1112] のセクション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)([RFC 3715] のセクション2.1. ケース g を参照)。 3.2. Transport Mode ESP Encapsulation 3.2. トランスポートモード ESP のカプセル化 BEFORE APPLYING ESP/UDP ESP/UDP 適用前 ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING ESP/UDP 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. 1. 通常の ESP カプセル化処理を適用。 2. A properly formatted UDP header is inserted where shown. 2. 適当にフォーマットされた UDP ヘッダを図のように挿入。 3. The Total Length, Protocol, and Header Checksum (for IPv4) fields in the IP header are edited to match the resulting IP packet. 3. IP ヘッダにおけるトータル長、プロトコル、そしてヘッダチェックサム (IPv4 用)フィールドを、結果としてできる IP パケットに適合するよう に編集。 3.3. Transport Mode ESP Decapsulation 3.3. トランスポートモード ESP のカプセル開放 1. The UDP header is removed from the packet. 1. UDP ヘッダをパケットから除去。 2. The Total Length, Protocol, and Header Checksum (for IPv4) fields in the new IP header are edited to match the resulting IP packet. 2. 新しい IP ヘッダのトータル長、プロトコル、そしてヘッダチェックサム (IPv4 用)フィールドを、結果としてできる IP パケットに適合するよう に編集。 3. Ordinary ESP decapsulation procedure is used. 3. 通常の ESP カプセル開放処理を適用。 4. Transport mode decapsulation NAT procedure is used. 4. トランスポートモードにおいてカプセル開放を行う NAT の手順を適用。 Huttunen, et al. Standards Track [Page 6] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 3.4. Tunnel Mode ESP Encapsulation 3.4. トンネルモード ESP のカプセル化 BEFORE APPLYING ESP/UDP ESP/UDP 適用前 ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING ESP/UDP 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. 1. 通常の ESP カプセル化処理を適用。 2. A properly formatted UDP header is inserted where shown. 2. 適当にフォーマットされた UDP ヘッダを図のように挿入。 3. The Total Length, Protocol, and Header Checksum (for IPv4) fields in the new IP header are edited to match the resulting IP packet. 3. 新しい IP ヘッダにおけるトータル長、プロトコル、そしてヘッダチェック サム(IPv4 用)フィールドを、結果としてできる IP パケットに適合する ように編集。 3.5. Tunnel Mode ESP Decapsulation 3.5. トンネルモード ESP のカプセル開放 1. The UDP header is removed from the packet. 1. UDP ヘッダをパケットから除去。 2. The Total Length, Protocol, and Header Checksum (for IPv4) fields in the new IP header are edited to match the resulting IP packet. 2. 新しい IP ヘッダのトータル長、プロトコル、そしてヘッダチェックサム (IPv4 用)フィールドを、結果としてできる IP パケットに適合するよう に編集。 3. Ordinary ESP decapsulation procedure is used. 3. 通常の ESP カプセル開放処理を適用。 4. Tunnel mode decapsulation NAT procedure is used. 4. トンネルモードにおいてカプセル開放を行う NAT の手順を適用。 4. NAT Keepalive Procedure 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-keepalive パケットを送信するのは、単にピア間でコネクションが 張られている期間中、NAT のマッピングを生きたままにしておくためである ([RFC 3715] のセクション2.2、ケース j を参照)。NAT-keepalive パケット は、コネクションが生きているかを検出するのに利用してはならない (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、もしくはフェーズ2の SA が存在する場合、 つまり最大 N 分前までそのような SA が存在していたら、ピアは NAT-keepalive パケットを送信してもよい(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. NAT-keepalive パケットが [RFC3947] により検出され、しかもそのピアに 対して他にはパケットが M 秒送信されていない場合、ピアは NAT-keepalive パケットを送信すべきである(SHOULD)。M はデフォルト値が20秒のローカルに 設定可能なパラメータとする。 Huttunen, et al. Standards Track [Page 7] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 5. Security Considerations 5. セキュリティについての考慮事項 5.1. Tunnel Mode Conflict 5.1. トンネルモードの衝突 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 (セキュリティゲートウェイ)の中で重複するエントリ をネゴシエート可能であることを実装者は気をつける必要がある。これが トンネルモードに影響する問題になる([RFC 3715] のセクション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 に変換される二つの SA を通すことに なるので、Suzy のサーバから来るパケットをどちらに送ってよいか混乱する 可能性がある。実装者は、こうした問題が起こるのを防ぐ策を考案しなくて はならない(MUST)。 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]. (DHCP over IPsec などのプロトコルを利用して)SGW が Ari と Bob のラップトップにローカルでユニークな IP アドレスを割り当てるか、 さもなくば Suzy のサーバ宛てのパケットを送信する前に、NAT を利用して Ari と Bob の送信元 IP アドレスをこうしたローカルでユニークなアドレス に変換するかのいずれかが推奨される(RECOMMENDED)。これは [RFC 3715] のセクション3における "Scaling" の基準を対象としている。 Please see Appendix A. Appendix A を参照のこと。 Huttunen, et al. Standards Track [Page 8] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 5.2. Transport Mode Conflict 5.2. トランスポートモードの衝突 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). 別の似た問題が、トランスポートモードにおいて、Ari と Bob という同一の NAT 装置の背後にある二つのクライアントが同じサーバとセキュアに通信 する場合に起こるかもしれない([RFC 3715] のセクション2.1、 ケース e を参照)。 Cliff wants to talk in the clear to the same server. Cliff が同じサーバと平文で通信しようとする。 +----+ | | +----+ \ 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, , UDP encap <4500, Y> To Bob: Server to NAT, , UDP encap <4500, Z> Cliff's traffic is in the clear, so there is no SA. Cliff との通信は平文で行うので、Cliff に関する SA はない。 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 , where Y is the dynamically assigned port. とはプロトコルとポート番号情報のことである。 UDP encap ポートとは、セクション2.1で示した UDP でカプセル化された ESP 形式で利用されるポート番号である。Y と Z は IKE ネゴシエーション時に NAT により割り当てられた動的ポートのことである。 Ari のデスクトップからの IKE トラフィックは UDP <4500,4500> で行われるので、サーバに UDP として届くということは、 Y が動的に割り当てられたポートということになる。 If the overlaps , 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. が と重なる場合、単純なフィルタ検査 （filter lookups）では、どちらの SA にトラフィックを送信する必要 があるか満足に決定できないかもしれない。実装者は、コネクションの 衝突を認めないか、もしくは別の手段を講じるなりしてこうした状況を 処理しなければならない(MUST)。 Huttunen, et al. Standards Track [Page 9] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 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 . For totally non-overlapping traffic descriptions, this is possible. 今度は Cliff が平文でサーバと接続しようとすると仮定する。 サーバには既に(サーバから NAT の外部アドレス方向の) をセキュアにするためのポリシーがあるので、これを設定するのは 難しくなる。完全にトラフィックに重複がなければ、これは可能になる。 Sample server policy could be as follows: サンプルとなるサーバポリシーとしては以下のようなものが可能: To Ari: Server to NAT, All UDP, secure To Bob: Server to NAT, All TCP, secure To Cliff: Server to NAT, ALL ICMP, clear text 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) Server to NAT, TCP, clear (for 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. Bob が不正に平文でトラフィックを送信することが可能なので、 サーバがポリシーを遵守させることができないのだ。 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. セキュリティを保証するには、上記の問題となるシナリオを サーバ上で許可してはならない(MUST NOT)。ベストエフォート型の セキュリティを実現するのなら、このシナリオを適用してもよい(MAY)。 Please see Appendix A. Appendix A を参照のこと。 6. IAB Considerations 6. IAB についての考慮 The UNSAF [RFC3424] questions are addressed by the IPsec-NAT compatibility requirements document [RFC3715]. UNSAF [RFC 3424] の問題は、IPsec-NAT の互換性要件を扱ったドキュメント [RFC 3715]において解決されている。 Huttunen, et al. Standards Track [Page 10] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 7. Acknowledgments 7. 謝辞 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 traversal に関するドラフトに貢献してくれた Joern Sierwald、 Tatu Ylonen、そして Santeri Paavolainen に感謝する。 8. References 8. 参考文献 8.1. Normative References 8.1. 標準を定めた参考文献 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC3947] Kivinen, T., "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005. 8.2. Informative References 8.1. 標準以外の参考文献 [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001. [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004. [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Work in Progress, October 2004. Huttunen, et al. Standards Track [Page 11] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 Appendix A. Clarification of Potential NAT Multiple Client Solutions Appendix A. 複数の NAT クライアントに可能な解決策の解説 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では、この問題を避けなくてならない(MUST)と言っている。 これはワイヤプロトコルの問題ではなく、ローカルな実装の問題なので、 そのメカニズムは本プロトコル仕様の範疇ではない。その代わりとして、 本付録に記載する。 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 が検出されれば、IKE 通信の開始側(initiator)はトランスポート モードを要求しないことにして、代わりにトンネルモード SA を要求するかも しれない。これは受信側(responder)にトランスポートモードを拒否された後の リトライでそうなるかもしれないし、最初からトンネルモード SA を提案する ように開始側が選択しているかもしれない。これは NAT なしでトランスポート モードを提案すべきか、トンネルモードを提案すべきか考えることより難しい ことではない。何か理由があって受信側で NAT traversal を行うために トンネルモードの方を選んだり要求したりするなら、クイックモードにおける トランスポートモードの 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 Huttunen, et al. Standards Track [Page 12] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 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) この選択肢は、IKE 通信の開始側が DHCP を利用して受信側から トンネルモード SA を通してアドレスを割り当ててもらえる場合に選択可能 である。開始側は、自分が NAT の背後にいるか知っているかどうかに関わらず、 最初から DHCP-IPsec の手法により内部アドレスを要求するかもしれない。 受信側がクイックモードの SA 提案においてトランスポート モードを拒否した後に DHCP トンネル SA について IKE クイックモードの ネゴシエーションを再度開始するかもしれない。これは NAT-OA ペイロード が送信されるか、NAT-D から開始側が NAT の背後にいて、そのローカルな 設定/ポリシーが、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) セッションの識別子として送信元 IP アドレスや送信元ポートを利用 しないように、内向きと外向きの IPsec SA を識別する上位層プロトコルを 実装すること(例えば、ピアの唯一性を保つために UDP ソースポート、 もしくは送信元 IP アドレスを利用しない IPsec SA の組にマップされた L2TP セッション ID)。 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 提案が受信側により拒否されたなら、 別の送信元ポートに再度バインドし、新規の QM セレクタを再提案できるよう にアプリケーションを IKE 開始と統合するよう実装すること。 Limited interoperability choices for ESP tunnel mode: ESP トンネルモードに関して相互接続性に制限のある選択肢に 以下のものがある: Tn4) Same as Tr4. Tn4) Tr4 と同じ。 Huttunen, et al. Standards Track [Page 13] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 Authors' Addresses 著者の住所 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 EMail: briansw@microsoft.com 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 EMail: ldiburro@nortelnetworks.com Markus Stenberg FI EMail: markus.stenberg@iki.fi Huttunen, et al. Standards Track [Page 14] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005 Full Copyright Statement 著作権表示全文 Copyright (C) The Internet Society (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. 本文書はBCP78に含まれる権利、認可、制限の適用を受け、またそこで 示されているもの以外について、著者がすべての権利を保持します。 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 編集者の職務に対する資金は、現在 Internet Society により 提供されている。 Huttunen, et al. Standards Track [Page 15] ___________________________________________________________________ [日本語訳について] この文書は、RFC3948 UDP Encapsulation of IPsec Packets ( http://www.ietf.org/rfc/rfc3948.txt ) の、yomoyomo (ymgrtq at yamdas dot org) による日本語訳です。誤訳、誤記などの 指摘を歓迎しますので、電子メールでお知らせいただけると幸いです。 本訳文について、誤訳を指摘してくださった吉澤政洋さんに感謝します。 初出公開： 2003年01月28日、最終更新日： 2005年01月14日