RFC3947 日本語訳
3947 Negotiation of NAT-Traversal in the IKE. T. Kivinen, B. Swander,A. Huttunen, V. Volpe. January 2005. (Format: TXT=34759 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Kivinen
Request for Comments: 3947 SafeNet
Category: Standards Track B. Swander
Microsoft
A. Huttunen
F-Secure Corporation
V. Volpe
Cisco Systems
January 2005
Kivinenがコメントのために要求するワーキンググループT.をネットワークでつないでください: 3947年のSafeNetカテゴリ: 社のV.ボルペシスコシステムズ2005年1月にF安全な標準化過程B.SwanderマイクロソフトA.Huttunen
Negotiation of NAT-Traversal in the IKE
IKEでのNAT縦断の交渉
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of IPsec packets through NAT boxes in Internet Key Exchange (IKE).
このドキュメントは、どのように、IPsecホストの間の1台以上のネットワーク・アドレス翻訳装置(NATs)を検出するか、そして、インターネット・キー・エクスチェンジ(IKE)でどのようにNAT箱を通したIPsecパケットのUDPカプセル化の使用を交渉するかを説明します。
Kivinen, et al. Standards Track [Page 1] RFC 3947 Negotiation of NAT-Traversal in the IKE January 2005
Kivinen、他 規格は2005年1月にIKEでのNAT縦断のRFC3947交渉を追跡します[1ページ]。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . . 3
3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Detecting Support of NAT-Traversal. . . . . . . . . . . . 4
3.2. Detecting the Presence of NAT . . . . . . . . . . . . . . 4
4. Changing to New Ports . . . . . . . . . . . . . . . . . . . . . 6
5. Quick Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Negotiation of the NAT-Traversal Encapsulation. . . . . . 9
5.2. Sending the Original Source and Destination Addresses . . 9
6. Initial Contact Notifications. . . . . . . . . . . . . . . . . 11
7. Recovering from the Expiring NAT Mappings. . . . . . . . . . . 11
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 13
10. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 要件. . . . . . . . . . . . . . . . . 3 3の仕様。 フェーズ1.33.1。 NAT縦断のサポートを検出します。 . . . . . . . . . . . 4 3.2. NAT. . . . . . . . . . . . . . 4 4の存在を検出します。 新しいポート. . . . . . . . . . . . . . . . . . . . . 6 5に変化します。 迅速なモード。 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. NAT縦断カプセル化の交渉。 . . . . . 9 5.2. 一次資料と送付先アドレス. . 9 6を送ります。 連絡通知に頭文字をつけてください。 . . . . . . . . . . . . . . . . 11 7. 期限が切れているNATマッピングから、回復します。 . . . . . . . . . . 11 8. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 12 9. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 13 10. IAB問題. . . . . . . . . . . . . . . . . . . . . . 14 11。 承認。 . . . . . . . . . . . . . . . . . . . . . . . 14 12. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1。 引用規格. . . . . . . . . . . . . . . . . . 14 12.2。 有益な参照. . . . . . . . . . . . . . . . . 14作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 15の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
1. 序論
This document is split into two parts. The first describes what is needed in IKE Phase 1 for NAT-Traversal support. This includes detecting whether the other end supports NAT-Traversal, and detecting whether there is one or more NATs between the peers.
このドキュメントは2つの部品に分けられます。 1番目はIKE Phase1でNAT縦断サポートに必要であるものについて説明します。 これは、もう一方の端がNAT縦断を支持するかどうか検出して、同輩の間には、1NATsがあるかを検出するのを含んでいます。
The second part describes how to negotiate the use of UDP encapsulated IPsec packets in IKE's Quick Mode. It also describes how to transmit the original source and destination addresses to the peer, if required. These addresses are used in transport mode to update the TCP/IP checksums incrementally so that they will match after the NAT transform. (The NAT cannot do this, because the TCP/IP checksum is inside the UDP encapsulated IPsec packet.)
第二部はUDPの使用を交渉するのがIKEのクィックModeでどうIPsecパケットをカプセルに入れったかを説明します。 また、それは必要なら、一次資料と送付先アドレスを同輩に伝える方法を説明します。 これらのアドレスは、NATが変形した後に合うようにTCP/IPチェックサムを増加してアップデートするのに交通機関で使用されます。 (NATはこれができないで、TCP/IPチェックサムが中にあるので、UDPはIPsecパケットをカプセルに入れりました。)
The document [RFC3948] describes the details of UDP encapsulation, and [RFC3715] provides background information and motivation of NAT- Traversal in general. In combination with [RFC3948], this document represents an "unconditionally compliant" solution to the requirements as defined by [RFC3715].
ドキュメント[RFC3948]はUDPカプセル化の詳細について説明します、そして、[RFC3715]は一般に、NAT縦断の基礎的な情報と動機を提供します。 [RFC3948]と組み合わせて、[RFC3715]によって定義されるようにこのドキュメントは要件の「無条件に言いなりになっている」解決策を表します。
In the basic scenario for this document, the initiator is behind NA(P)T, and the responder has a fixed static IP address.
このドキュメントのための基本的なシナリオには、創始者がNA(P)Tの後ろにいます、そして、応答者には、固定静的IPアドレスがあります。
Kivinen, et al. Standards Track [Page 2] RFC 3947 Negotiation of NAT-Traversal in the IKE January 2005
Kivinen、他 規格は2005年1月にIKEでのNAT縦断のRFC3947交渉を追跡します[2ページ]。
This document defines a protocol that will work even if both ends are behind NAT, but the process of how to locate the other end is out of the scope of this document. In one scenario, the responder is behind a static host NAT (only one responder per IP, as there is no way to use any destination ports other than 500/4500). That is, it is known by the configuration.
NATの後ろに両端があっても、このドキュメントは働いているプロトコルを定義しますが、このドキュメントの範囲の外にどうもう一方の端の場所を見つけるかに関する過程があります。 1つのシナリオには、応答者が静的なホストNATの後ろにいる、(500/4500以外のどんな仕向港も使用する方法が全くないので1IPあたり1人の応答者だけ すなわち、それは構成によって知られています。
2. Specification of Requirements
2. 要件の仕様
This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and "OPTIONAL" to describe requirements. They are to be interpreted as described in [RFC2119].
このドキュメントは“MUST"、「必須NOT」が「必要である」というキーワードを使用するものとします、“SHALL"、「」、“SHOULD"、「」 「お勧め、「5月」、要件について説明するために「任意」であるべきである」。 それらは[RFC2119]で説明されるように解釈されることになっています。
3. Phase 1
3. フェーズ1
The detection of support for NAT-Traversal and detection of NAT along the path between the two IKE peers occurs in IKE [RFC2409] Phase 1.
NAT縦断のサポートの検出と2人のIKE同輩の間の経路に沿ったNATの検出はIKE[RFC2409]フェーズ1で起こります。
The NAT may change the IKE UDP source port, and recipients MUST be able to process IKE packets whose source port is different from 500. The NAT does not have to change the source port if:
NATはIKE UDPソース港を変えるかもしれません、そして、受取人はソース港が500と異なっているIKEパケットを処理できなければなりません。 NATがソース港を変える必要はない、:
o only one IPsec host is behind the NAT, or
o または1人のIPsecホストしかNATの後ろにいない。
o for the first IPsec host, the NAT can keep the port 500, and the
NAT will only change the port number for later connections.
o 第1代IPsecホストに関しては、NATはポート500を保つことができます、そして、NATは後の接続のためにポートナンバーを変えるだけでしょう。
Recipients MUST reply back to the source address from the packet (see [RFC3715], section 2.1, case d). This means that when the original responder is doing rekeying or sending notifications to the original initiator, it MUST send the packets using the same set of port and IP numbers used when the IKE SA was last used.
受取人はパケットからのソースアドレスに応じて戻らなければなりません([RFC3715]、セクション2.1を見てください、そして、dをケースに入れてください)。 これは、オリジナルの応答者が「再-合わせ」ることをしているとき、オリジナルの創始者に通告を送っていて、IKE SAが最後に使用されたとき使用される同じセットのポートとIP番号を使用して、パケットを送らなければならないことを意味します。
For example, when the initiator sends a packet with source and destination port 500, the NAT may change it to a packet with source port 12312 and destination port 500. The responder must be able to process the packet whose source port is 12312. It must reply back with a packet whose source port is 500 and destination port is 12312. The NAT will then translate this packet to source port 500 and destination port 500.
創始者がソースと仕向港500があるパケットを送るとき、例えば、NATはソース港12312と仕向港500でそれをパケットに変えるかもしれません。 応答者はソース港が12312であるパケットを処理できなければなりません。 それはソース港が500であるパケットで返答し返さなければなりません、そして、仕向港は12312です。 そして、NATはソース港500と仕向港500にこのパケットを移すでしょう。
Kivinen, et al. Standards Track [Page 3] RFC 3947 Negotiation of NAT-Traversal in the IKE January 2005
Kivinen、他 規格は2005年1月にIKEでのNAT縦断のRFC3947交渉を追跡します[3ページ]。
3.1. Detecting Support of NAT-Traversal
3.1. NAT縦断のサポートを検出します。
The NAT-Traversal capability of the remote host is determined by an exchange of vendor ID payloads. In the first two messages of Phase 1, the vendor id payload for this specification MUST be sent if supported (and it MUST be received by both sides) for the NAT- Traversal probe to continue. The content of the payload is the MD5 hash of
リモートホストのNAT縦断能力は業者IDペイロードの交換で決定します。 Phase1に関する最初の2つのメッセージでは、NAT縦断探測装置が続くように支持するなら(両側はそれを受け取らなければなりません)、この仕様のための業者イドペイロードを送らなければなりません。 ペイロードの内容はMD5細切れ肉料理です。
RFC 3947
RFC3947
The exact content in hex for the payload is
ペイロードのための十六進法における正確な内容はそうです。
4a131c81070358455c5728f20e95452f
4a131c81070358455c5728f20e95452f
3.2. Detecting the Presence of NAT
3.2. NATの存在を検出します。
The NAT-D payload not only detects the presence of NAT between the two IKE peers, but also detects where the NAT is. The location of the NAT device is important, as the keepalives have to initiate from the peer "behind" the NAT.
NAT Dペイロードは、2人のIKE同輩の間のNATの存在を検出するだけではなく、NATがどこにあるかを検出もします。 keepalivesが同輩“behind"からNATを開始しなければならないとき、NAT装置の位置は重要です。
To detect NAT between the two hosts, we have to detect whether the IP address or the port changes along the path. This is done by sending the hashes of the IP addresses and ports of both IKE peers from each end to the other. If both ends calculate those hashes and get same result, they know there is no NAT between. If the hashes do not match, somebody has translated the address or port. This means that we have to do NAT-Traversal to get IPsec packets through.
2人のホストの間のNATを検出するために、私たちは、IPアドレスかポートが経路に沿って変化するかどうか検出しなければなりません。 発信することによってこれをする、IPアドレスを論じ尽くして、各端からのもう片方への両方のIKE同輩に移植します。 両端であるなら、ものが同じ結果を論じ尽くして、得ると見込んでください、そして、それらは、NATが全く間にないのを知っています。 論じ尽くす、合わないでください、そして、だれかがアドレスかポートを翻訳しました。 これは、私たちがIPsecパケットを通り抜けるためにNAT縦断をしなければならないことを意味します。
If the sender of the packet does not know his own IP address (in case of multiple interfaces, and the implementation does not know which IP address is used to route the packet out), the sender can include multiple local hashes to the packet (as separate NAT-D payloads). In this case, NAT is detected if and only if none of the hashes match.
パケットの送付者が彼自身のIPアドレスを知らないなら(インタフェース、および実現がそうしない倍数の場合に、どのIPアドレスがパケットを外に発送するのに使用されるかを知ってください)、送付者はローカルがパケット(別々のNAT Dペイロードとしての)に論じ尽くす倍数を入れることができます。 この場合NATが検出される、なにもだけである、マッチを論じ尽くします。
The hashes are sent as a series of NAT-D (NAT discovery) payloads. Each payload contains one hash, so in case of multiple hashes, multiple NAT-D payloads are sent. In the normal case there are only two NAT-D payloads.
論じ尽くす、一連のNAT D(NAT発見)ペイロードとして、送ります。 各ペイロードが、ある細切れ肉料理を含んでいる、複数の場合にそのように、論じ尽くす、複数のNAT Dペイロードを送ります。 正常な場合には、2個のNAT Dペイロードしかありません。
The NAT-D payloads are included in the third and fourth packets of Main Mode, and in the second and third packets in the Aggressive Mode.
NAT DペイロードはAggressive ModeにおけるMain Modeの3番目と4番目のパケット、2番目、および3番目のパケットに含まれています。
Kivinen, et al. Standards Track [Page 4] RFC 3947 Negotiation of NAT-Traversal in the IKE January 2005
Kivinen、他 規格は2005年1月にIKEでのNAT縦断のRFC3947交渉を追跡します[4ページ]。
The format of the NAT-D packet is
NAT Dパケットの形式はそうです。
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload length |
+---------------+---------------+---------------+---------------+
~ HASH of the address and port ~
+---------------+---------------+---------------+---------------+
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 +---------------+---------------+---------------+---------------+ | 次の有効搭載量| 予約されます。| ペイロード長| +---------------+---------------+---------------+---------------アドレスとポート~+の+ ~HASH---------------+---------------+---------------+---------------+
The payload type for the NAT discovery payload is 20.
NAT発見ペイロードのためのペイロードタイプは20歳です。
The HASH is calculated as follows:
HASHは以下の通り計算されます:
HASH = HASH(CKY-I | CKY-R | IP | Port)
細切れ肉料理は細切れ肉料理と等しいです。(CKY-I| CKY-R|IP|ポート)
This uses the negotiated HASH algorithm. All data inside the HASH is in the network byte-order. The IP is 4 octets for an IPv4 address and 16 octets for an IPv6 address. The port number is encoded as a 2 octet number in network byte-order. The first NAT-D payload contains the remote end's IP address and port (i.e., the destination address of the UDP packet). The remaining NAT-D payloads contain possible local-end IP addresses and ports (i.e., all possible source addresses of the UDP packet).
これは交渉されたHASHアルゴリズムを使用します。 ネットワークバイトオーダーにはHASHの中のすべてのデータがあります。 IPはIPv4アドレスのための4つの八重奏とIPv6アドレスのための16の八重奏です。 ポートナンバーはネットワークバイトオーダーにおける2八重奏番号としてコード化されます。 最初のNAT DペイロードはリモートエンドのIPアドレスとポート(すなわち、UDPパケットの送付先アドレス)を含んでいます。 残っているNAT Dペイロードは可能な地方の終わりのIPアドレスとポート(UDPパケットのすなわちすべての可能なソースアドレス)を含んでいます。
If there is no NAT between the peers, the first NAT-D payload received should match one of the local NAT-D payloads (i.e., the local NAT-D payloads this host is sending out), and one of the other NAT-D payloads must match the remote end's IP address and port. If the first check fails (i.e., first NAT-D payload does not match any of the local IP addresses and ports), it means that there is dynamic NAT between the peers, and this end should start sending keepalives as defined in the [RFC3948] (this end is behind the NAT).
同輩の間には、NATが全くなければ、受け取られた最初のNAT Dペイロードは地方のNAT Dペイロード(すなわちこのホストが外の地方のNAT Dペイロードを送って)の1つに合っているはずです、そして、他のNAT Dペイロードの1つはリモートエンドのIPアドレスとポートに合わなければなりません。 最初のチェックが失敗するなら(すなわち、最初のNAT Dペイロードはローカルアイピーアドレスとポートのいずれにも合っていません)、それは、同輩の間には、ダイナミックなNATがあることを意味します、そして、この終わりは[RFC3948](NATの後ろにこの終わりはある)で定義されるようにkeepalivesを送り始めるべきです。
The CKY-I and CKY-R are the initiator and responder cookies. They are added to the hash to make precomputation attacks for the IP address and port impossible.
CKY-IとCKY-Rは創始者と応答者クッキーです。 それらは、IPアドレスとポートのための前計算攻撃を不可能にするように細切れ肉料理に加えられます。
The following example is of a Phase 1 exchange using NAT-Traversal in Main Mode (authentication with signatures):
以下の例には、Phase1交換がMain Mode(署名による認証)でNAT縦断を使用するのがあります:
Initiator Responder
------------ ------------
HDR, SA, VID -->
<-- HDR, SA, VID
HDR, KE, Ni, NAT-D, NAT-D -->
<-- HDR, KE, Nr, NAT-D, NAT-D
HDR*#, IDii, [CERT, ] SIG_I -->
<-- HDR*#, IDir, [CERT, ], SIG_R
創始者応答者------------ ------------ HDR、SA、VID--><--NAT D、NAT D--><--HDR、SA、VID HDR、KE、Ni、HDR、KE、Nr、NAT D、NAT D HDR*#、IDii、[本命]SIG_I--><--HDR*#、IDir[本命]、SIG_R
Kivinen, et al. Standards Track [Page 5] RFC 3947 Negotiation of NAT-Traversal in the IKE January 2005
Kivinen、他 規格は2005年1月にIKEでのNAT縦断のRFC3947交渉を追跡します[5ページ]。
The following example is of Phase 1 exchange using NAT-Traversal in Aggressive Mode (authentication with signatures):
以下の例には、Phase1交換がAggressive Mode(署名による認証)でNAT縦断を使用するのがあります:
Initiator Responder
------------ ------------
HDR, SA, KE, Ni, IDii, VID -->
<-- HDR, SA, KE, Nr, IDir,
[CERT, ], VID, NAT-D,
NAT-D, SIG_R
HDR*#, [CERT, ], NAT-D, NAT-D,
SIG_I -->
創始者応答者------------ ------------ Ni、IDii、VID--><--HDR、SA、KE、HDR、SA、KE、Nr、IDir[本命]、VID、ナット-D、ナット-D、SIG_R HDR*#[本命]、NAT D、NAT D、SIG_I--、>。
The # sign indicates that those packets are sent to the changed port if NAT is detected.
#サインは、NATが検出されるならそれらのパケットが変えられたポートに送られるのを示します。
4. Changing to New Ports
4. 新しいポートに変化します。
IPsec-aware NATs can cause problems (See [RFC3715], section 2.3). Some NATs will not change IKE source port 500 even if there are multiple clients behind the NAT (See [RFC3715], section 2.3, case n). They can also use IKE cookies to demultiplex traffic instead of using the source port (See [RFC3715], section 2.3, case m). Both of these are problematic for generic NAT transparency, as it is difficult for IKE to discover the capabilities of the NAT. The best approach is simply to move the IKE traffic off port 500 as soon as possible to avoid any IPsec-aware NAT special casing.
IPsec意識しているNATsは問題を起こすことができます([RFC3715]、セクション2.3を見てください)。 複数のクライアントがNATの後ろにいても([RFC3715]を見てください、セクション2.3、ケースn)、いくつかのNATsはIKEソース港500を変えないでしょう。 また、彼らはソース港を使用することの代わりに「反-マルチプレックス」交通にIKEクッキーを使用できます([RFC3715]を見てください、セクション2.3、ケースm)。 一般的なNAT透明に、これらの両方が問題が多いです、IKEがNATの能力を発見するのが、難しいので。 最も良いアプローチはできるだけ早くどんなIPsec意識しているNAT特別なケーシングも避けるためにポート500で単にIKE交通を動かすことです。
Take the common case of the initiator behind the NAT. The initiator must quickly change to port 4500 once the NAT has been detected to minimize the window of IPsec-aware NAT problems.
NATの後ろで創始者のよくある例を取ってください。 創始者は、NATがIPsec意識しているNAT問題の窓を最小にするためにいったん検出されたあとに4500を移植するために急速に変化しなければなりません。
In Main Mode, the initiator MUST change ports when sending the ID payload if there is NAT between the hosts. The initiator MUST set both UDP source and destination ports to 4500. All subsequent packets sent to this peer (including informational notifications) MUST be sent on port 4500. In addition, the IKE data MUST be prepended with a non-ESP marker allowing for demultiplexing of traffic, as defined in [RFC3948].
ホストの間には、NATがあればIDペイロードを送るとき、Main Modeでは、創始者はポートを変えなければなりません。 創始者はUDPソースと仕向港の両方を4500に設定しなければなりません。 この同輩(情報の通知を含んでいる)に送られたすべてのその後のパケットをポート4500に送らなければなりません。 さらに、非超能力のマーカーが交通の逆多重化を考慮している状態で、IKEデータをprependedしなければなりません、[RFC3948]で定義されるように。
Thus, the IKE packet now looks like this:
したがって、IKEパケットは現在、これに似ています:
IP UDP(4500,4500) <non-ESP marker> HDR*, IDii, [CERT, ] SIG_I
IP UDP(4500、4500)、<、非、-、超能力、マーカー>HDR*、IDii、[CERT]SIG_I
This assumes authentication using signatures. The 4 bytes of non-ESP marker are defined in the [RFC3948].
これは、署名を使用することで認証を仮定します。 非超能力のマーカーの4バイトは[RFC3948]で定義されます。
Kivinen, et al. Standards Track [Page 6] RFC 3947 Negotiation of NAT-Traversal in the IKE January 2005
Kivinen、他 規格は2005年1月にIKEでのNAT縦断のRFC3947交渉を追跡します[6ページ]。
When the responder gets this packet, the usual decryption and processing of the various payloads is performed. If these are successful, the responder MUST update local state so that all subsequent packets (including informational notifications) to the peer use the new port, and possibly the new IP address obtained from the incoming valid packet. The port will generally be different, as the NAT will map UDP(500,500) to UDP(X,500), and UDP(4500,4500) to UDP(Y,4500). The IP address will seldom be different from the pre- changed IP address. The responder MUST respond with all subsequent IKE packets to this peer by using UDP(4500,Y).
応答者がこのパケットを得るとき、様々なペイロードの普通の復号化と処理は実行されます。 これらがうまくいくなら、応答者が地方の状態をアップデートしなければならないので、同輩へのすべてのその後のパケット(情報の通知を含んでいる)が新しいポート、およびことによると入って来る有効なパケットから入手された新しいIPアドレスを使用します。 NATがUDP(X、500)にUDP(500,500)を写像して、UDP(4500、4500)をUDP(Y、4500)への写像になるので、一般に、ポートは異なるでしょう。 IPアドレスはあらかじめ変えられたIPアドレスとめったに異ならないでしょう。 応答者は、すべてのその後のIKEパケットでUDP(4500、Y)を使用することによって、この同輩に応じなければなりません。
Similarly, if the responder has to rekey the Phase 1 SA, then the rekey negotiation MUST be started by using UDP(4500,Y). Any implementation that supports NAT traversal MUST support negotiations that begin on port 4500. If a negotiation starts on port 4500, then it doesn't need to change anywhere else in the exchange.
1SA、そして、同様に、応答者がrekeyにPhaseを持っているなら、UDPを使用することによって、rekey交渉を始めなければなりません(4500、Y)。 NAT縦断を支持するどんな実現もポート4500の上で始まる交渉を支持しなければなりません。 交渉がポート4500を始動するなら、それは交換における他のどこかを変える必要はありません。
Once port change has occurred, if a packet is received on port 500, that packet is old. If the packet is an informational packet, it MAY be processed if local policy allows this. If the packet is a Main Mode or an Aggressive Mode packet (with the same cookies as previous packets), it SHOULD be discarded. If the packet is a new Main Mode or Aggressive exchange, then it is processed normally (the other end might have rebooted, and this is starting new exchange).
ポート500の上にパケットを受け取るならポート変化がいったん起こると、そのパケットは古いです。 パケットが情報のパケットであるなら、ローカルの方針がこれを許容するなら、それは処理されるかもしれません。 パケットは、Main ModeかAggressive Modeパケット(前のパケットと同じクッキーがある)であり、それはSHOULDです。捨てられます。 パケットが新しいMain ModeかAggressive交換であるなら、通常、それは処理されます(もう一方の端がリブートされたかもしれません、そして、これは始めの新しい交換です)。
Here is an example of a Phase 1 exchange using NAT-Traversal in Main Mode (authentication with signatures) with changing port:
ここに、Phase1交換に関する例がMain Mode(署名による認証)でポートを変えるのにNAT縦断を使用することであります:
Initiator Responder
------------ ------------
UDP(500,500) HDR, SA, VID -->
<-- UDP(500,X) HDR, SA, VID
UDP(500,500) HDR, KE, Ni,
NAT-D, NAT-D -->
<-- UDP(500,X) HDR, KE, Nr,
NAT-D, NAT-D
UDP(4500,4500) HDR*#, IDii,
[CERT, ]SIG_I -->
<-- UDP(4500,Y) HDR*#, IDir,
[ CERT, ], SIG_R
創始者応答者------------ ------------ UDP(500,500) HDR、SA、VID--><--UDP(500、X)HDR、SA、VID UDP(500,500) HDR、KE、Ni、NAT D、NAT D--><--UDP(500、X)HDR、KE、Nr、NAT D、NAT D UDP(4500、4500)HDR*#、IDii、[本命]SIG_I--><--UDP(4500、Y)HDR*#、IDir[本命]、SIG_R
The procedure for Aggressive Mode is very similar. After the NAT has been detected, the initiator sends IP UDP(4500,4500) <4 bytes of non-ESP marker> HDR*, [CERT, ], NAT-D, NAT-D, and SIG_I. The responder does similar processing to the above, and if successful, MUST update it's internal IKE ports. The responder MUST respond with all subsequent IKE packets to this peer by using UDP(4500,Y).
Aggressive Modeのための手順は非常に同様です。 NATが検出された後に、創始者が非超能力のマーカー>HDR*の4バイトをIP UDP(4500、4500)<に送る、[CERT]、NAT D、NAT D、およびSIG_I。 応答者は、上記、うまくいくなら同様の処理をして、それの内部のIKEポートをアップデートしなければなりません。 応答者は、すべてのその後のIKEパケットでUDP(4500、Y)を使用することによって、この同輩に応じなければなりません。
Kivinen, et al. Standards Track [Page 7] RFC 3947 Negotiation of NAT-Traversal in the IKE January 2005
Kivinen、他 規格は2005年1月にIKEでのNAT縦断のRFC3947交渉を追跡します[7ページ]。
Initiator Responder
------------ ------------
UDP(500,500) HDR, SA, KE,
Ni, IDii, VID -->
<-- UDP(500,X) HDR, SA, KE,
Nr, IDir, [CERT, ],
VID, NAT-D, NAT-D,
SIG_R
UDP(4500,4500) HDR*#, [CERT, ],
NAT-D, NAT-D,
SIG_I -->
<-- UDP(4500, Y) HDR*#, ...
創始者応答者------------ ------------ UDP(500,500) HDR、SA、KE、Ni、IDii、VID--><--UDP(500、X)HDR、SA、KE、Nr、IDir[本命]、VID、ナット-D、ナット-D、SIG_R UDP(4500、4500)HDR*#[本命]、NAT D、NAT D、SIG_I--><--UDP(4500、Y)HDR*#…
If the support of the NAT-Traversal is enabled, the port in the ID payload in Main Mode/Aggressive Mode MUST be set to 0.
NAT縦断のサポートが可能にされるなら、Main Mode/攻撃的なModeのIDペイロードのポートを0に設定しなければなりません。
The most common case for the responder behind the NAT is if the NAT is simply doing 1:1 address translation. In this case, the initiator still changes both ports to 4500. The responder uses an algorithm identical to that above, although in this case Y will equal 4500, as no port translation is happening.
NATの後ろの応答者のための最も一般的なケースはNATが単に1:1アドレス変換をしているかどうかということです。 この場合、創始者はまだ両方のポートを4500に変えています。 応答者は上のそれと同じアルゴリズムを使用します、Yがこの場合4500と等しいでしょうが、ポート翻訳が全く起こっていないとき。
A different port change case involves out-of-band discovery of the ports to use. Those discovery methods are out of the scope of this document. For instance, if the responder is behind a port translating NAT, and the initiator needs to contact it first, then the initiator will have to determine which ports to use, usually by contacting some other server. Once the initiator knows which ports to use to traverse the NAT, generally something like UDP(Z,4500), it initiates using these ports. This is similar to the responder rekey case above in that the ports to use are already known up front, and no additional change has to take place. Also, the first keepalive timer starts after the change to the new port, and no keepalives are sent to the port 500.
異なったポート変化ケースはバンドの外で使用するポートの発見にかかわります。 このドキュメントの範囲の外にそれらの発見方法があります。 例えば、応答者がNATを翻訳しながらポートの後ろにいて、創始者が、最初にそれに連絡する必要があると、創始者は、どのポートを使用するかを決心しなければならないでしょう、通常、ある他のサーバに連絡することによって。一度、創始者は、これらのポートを使用することでそれが一般に、UDP(Z、4500)のように開始するNATを横断するのにどのポートを使用したらよいかを知っています。 これは上で使用するポートが既に前払いで知られているという点において応答者rekey事件と同様です、そして、付加的な変化は全く行われてはいけません。 また、最初のkeepaliveタイマは新しいポートへの変化の後に始動します、そして、keepalivesを全くポート500に送りません。
5. Quick Mode
5. 迅速なモード
After Phase 1, both ends know whether there is a NAT present between them. The final decision of using NAT-Traversal is left to Quick Mode. The use of NAT-Traversal is negotiated inside the SA payloads of Quick Mode. In Quick Mode, both ends can also send the original addresses of the IPsec packets (in case of the transport mode) to the other end so that each can fix the TCP/IP checksum field after the NAT transformation.
Phase1の後に、両端は、それらの間の現在のNATがあるかどうかを知っています。 使用NAT縦断の最終決定はクィックModeに残されます。 NAT縦断の使用はクィックModeのSAペイロードの中に交渉されます。 また、クィックModeでは、両端は、それぞれがNAT変化の後にTCP/IPチェックサム分野を修理できるように、IPsecパケット(交通機関の場合の)のオリジナルのアドレスをもう一方の端に送ることができます。
Kivinen, et al. Standards Track [Page 8] RFC 3947 Negotiation of NAT-Traversal in the IKE January 2005
Kivinen、他 規格は2005年1月にIKEでのNAT縦断のRFC3947交渉を追跡します[8ページ]。
5.1. Negotiation of the NAT-Traversal Encapsulation
5.1. NAT縦断カプセル化の交渉
The negotiation of the NAT-Traversal happens by adding two new encapsulation modes. These encapsulation modes are
NAT縦断の交渉は、2つの新しいカプセル化モードを加えながら、偶然通りかかります。 これらのカプセル化モードはそうです。
UDP-Encapsulated-Tunnel 3 UDP-Encapsulated-Transport 4
要約されたUDPがトンネルを堀っている3、UDPが輸送を要約した、4
It is not normally useful to propose both normal tunnel or transport mode and UDP-Encapsulated modes. UDP encapsulation is required to fix the inability to handle non-UDP/TCP traffic by NATs (see [RFC3715], section 2.2, case i).
通常、正常なトンネルか交通機関とUDPによって要約されたモードの両方を提案するのは役に立ちません。 UDPカプセル化が、NATsによる非UDP/TCP交通を扱うことができないことを修理するのに必要です([RFC3715]、セクション2.2を見てください、そして、iをケースに入れてください)。
If there is a NAT box between hosts, normal tunnel or transport encapsulations may not work. In this case, UDP-Encapsulation SHOULD be used.
ホストの間には、NAT箱があれば、正常なトンネルか輸送カプセル化が働かないかもしれません。 この場合UDP-カプセル化SHOULD、使用されてください。
If there is no NAT box between, there is no point in wasting bandwidth by adding UDP encapsulation of packets. Thus, UDP- Encapsulation SHOULD NOT be used.
NAT箱が全く間になければ、パケットのUDPカプセル化を加えることによって帯域幅を浪費する意味が全くありません。 その結果、UDPカプセル化SHOULD NOT、使用されてください。
Also, the initiator SHOULD NOT include both normal tunnel or transport mode and UDP-Encapsulated-Tunnel or UDP-Encapsulated- Transport in its proposals.
また、創始者SHOULD NOTはともに正常なトンネルか交通機関を含んでいます、そして、UDPがトンネルを要約しているか、UDPによって要約された輸送のコネは提案を含んでいます。
5.2. Sending the Original Source and Destination Addresses
5.2. 一次資料と送付先アドレスを送ります。
To perform incremental TCP checksum updates, both peers may need to know the original IP addresses used by their peers when those peers constructed the packet (see [RFC3715], section 2.1, case b). For the initiator, the original Initiator address is defined to be the Initiator's IP address. The original Responder address is defined to be the perceived peer's IP address. For the responder, the original Initiator address is defined to be the perceived peer's address. The original Responder address is defined to be the Responder's IP address.
増加のTCPチェックサムアップデートを実行するために、両方の同輩は、それらの同輩がパケットを組み立てたとき([RFC3715]を見てください、セクション2.1、ケースb)彼らの同輩によって使用されたオリジナルのIPアドレスを知る必要があるかもしれません。 創始者に関しては、オリジナルのInitiatorアドレスは、InitiatorのIPアドレスになるように定義されます。 オリジナルのResponderアドレスは、知覚された同輩のIPアドレスになるように定義されます。 応答者に関しては、オリジナルのInitiatorアドレスは、知覚された同輩のアドレスになるように定義されます。 オリジナルのResponderアドレスは、ResponderのIPアドレスになるように定義されます。
The original addresses are sent by using NAT-OA (NAT Original Address) payloads.
NAT-OA(NAT Original Address)ペイロードを使用することによって、オリジナルのアドレスを送ります。
The Initiator NAT-OA payload is first. The Responder NAT-OA payload is second.
Initiator NAT-OAペイロードは1番目です。 Responder NAT-OAペイロードは2番目です。
Example 1:
例1:
Initiator <---------> NAT <---------> Responder
^ ^ ^
Iaddr NatPub Raddr
創始者<。--------->NAT<。--------->応答者^ ^ ^Iaddr NatPub Raddr
Kivinen, et al. Standards Track [Page 9] RFC 3947 Negotiation of NAT-Traversal in the IKE January 2005
Kivinen、他 規格は2005年1月にIKEでのNAT縦断のRFC3947交渉を追跡します[9ページ]。
The initiator is behind a NAT talking to the publicly available responder. Initiator and Responder have the IP addresses Iaddr and Raddr. NAT has public IP address NatPub.
創始者は、公的に手があいている応答者と話しながら、NATの後ろにいます。 創始者とResponderには、IPアドレスのIaddrとRaddrがあります。 NATには、公共のIPアドレスNatPubがあります。
Initiator:
創始者:
NAT-OAi = Iaddr
NAT-OAr = Raddr
NAT-OAiはIaddr NATオール=Raddrと等しいです。
Responder:
NAT-OAi = NATPub
NAT-OAr = Raddr
応答者: NAT-OAiはNATPub NATオール=Raddrと等しいです。
Example 2:
例2:
Initiator <------> NAT1 <---------> NAT2 <-------> Responder
^ ^ ^ ^
Iaddr Nat1Pub Nat2Pub Raddr
創始者<。------>NAT1<。--------->NAT2<。------->応答者^ ^ ^ ^Iaddr Nat1Pub Nat2Pub Raddr
Here, NAT2 "publishes" Nat2Pub for Responder and forwards all traffic to that address to Responder.
ここで、NAT2はResponderのためにNat2Pubを「発行し」て、Responderへのそのアドレスにすべての交通を送ります。
Initiator:
NAT-OAi = Iaddr
NAT-OAr = Nat2Pub
創始者: NAT-OAiはIaddr NATオール=Nat2Pubと等しいです。
Responder:
NAT-OAi = Nat1Pub
NAT-OAr = Raddr
応答者: NAT-OAiはNat1Pub NATオール=Raddrと等しいです。
In the case of transport mode, both ends MUST send both original Initiator and Responder addresses to the other end. For tunnel mode, both ends SHOULD NOT send original addresses to the other end.
交通機関の場合では、両端はオリジナルのInitiatorとResponderの両方にアドレスをもう一方の端まで送らなければなりません。 トンネルモード、SHOULD NOTが送る両端に、もう片方へのオリジナルのアドレスは終わります。
The NAT-OA payloads are sent inside the first and second packets of Quick Mode. The initiator MUST send the payloads if it proposes any UDP-Encapsulated-Transport mode, and the responder MUST send the payload only if it selected UDP-Encapsulated-Transport mode. It is possible that the initiator sends the NAT-OA payload but proposes both UDP-Encapsulated transport and tunnel mode. Then the responder selects the UDP-Encapsulated tunnel mode and does not send the NAT-OA payload back.
クィックModeの1番目と2番目のパケットの中でNAT-OAペイロードを送ります。 UDPが交通機関を要約していた状態でそれがいずれかも提案するなら、創始者はペイロードを送らなければなりません、そして、UDPが交通機関を要約していた状態で選択されて、応答者はそれである場合にだけペイロードを送らなければなりません。 創始者がNAT-OAペイロードを送りますが、UDPによって要約された輸送とトンネルモードの両方を提案するのは、可能です。 次に、応答者は、UDPによって要約されたトンネルモードを選択して、NAT-OAペイロードを返送しません。
Kivinen, et al. Standards Track [Page 10] RFC 3947 Negotiation of NAT-Traversal in the IKE January 2005
Kivinen、他 規格は2005年1月にIKEでのNAT縦断のRFC3947交渉を追跡します[10ページ]。
The format of the NAT-OA packet is
NAT-OAパケットの形式はそうです。
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload length |
+---------------+---------------+---------------+---------------+
| ID Type | RESERVED | RESERVED |
+---------------+---------------+---------------+---------------+
| IPv4 (4 octets) or IPv6 address (16 octets) |
+---------------+---------------+---------------+---------------+
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 +---------------+---------------+---------------+---------------+ | 次の有効搭載量| 予約されます。| ペイロード長| +---------------+---------------+---------------+---------------+ | IDタイプ| 予約されます。| 予約されます。| +---------------+---------------+---------------+---------------+ | IPv4(4つの八重奏)かIPv6アドレス(16の八重奏)| +---------------+---------------+---------------+---------------+
The payload type for the NAT original address payload is 21.
NATの元のアドレスペイロードのためのペイロードタイプは21歳です。
The ID type is defined in the [RFC2407]. Only ID_IPV4_ADDR and ID_IPV6_ADDR types are allowed. The two reserved fields after the ID Type must be zero.
IDタイプは[RFC2407]で定義されます。 ID_IPV4だけが許容されています_ADDRと_ID IPV6_ADDRが、タイプする。 ID Typeがゼロになったに違いない後に2は分野を予約しました。
The following example is of Quick Mode using NAT-OA payloads:
以下の例には、クィックModeがNAT-OAペイロードを使用するのがあります:
Initiator Responder
------------ ------------
HDR*, HASH(1), SA, Ni, [, KE]
[, IDci, IDcr ]
[, NAT-OAi, NAT-OAr] -->
<-- HDR*, HASH(2), SA, Nr, [, KE]
[, IDci, IDcr ]
[, NAT-OAi, NAT-OAr]
HDR*, HASH(3) -->
創始者応答者------------ ------------ HDR*、細切れ肉料理(1)、SA、Ni[KE][IDci、IDcr][NAT-OAi、NATオール]--><--HDR*、細切れ肉料理(2)、SA、Nr、HDR*、[KE][IDci、IDcr][NAT-OAi、NATオール]細切れ肉料理(3)-->。
6. Initial Contact Notifications
6. 初期接触通知
The source IP and port address of the INITIAL-CONTACT notification for the host behind NAT are not meaningful (as NAT can change them), so the IP and port numbers MUST NOT be used to determine which IKE/IPsec SAs to remove (see [RFC3715], section 2.1, case c). The ID payload sent from the other end SHOULD be used instead; i.e., when an INITIAL-CONTACT notification is received from the other end, the receiving end SHOULD remove all the SAs associated with the same ID payload.
NATの後ろのホストのためのINITIAL-CONTACT通知のソースIPとポートアドレスが重要でないので(NATがそれらを変えることができるとき)、どのIKE/IPsec SAsを取り外したらよいかを決定するのにIPとポートナンバーを使用してはいけません([RFC3715]を見てください、セクション2.1、ケースc)。 IDペイロードはもう片方から終わりのSHOULDを送りました。代わりに使用されてください。 すなわち、もう一方の端からINITIAL-CONTACT通知を受け取るとき、受信終わりのSHOULDは同じIDペイロードに関連しているすべてのSAsを取り外します。
7. Recovering from the Expiring NAT Mappings
7. 期限が切れているNATマッピングから、回復します。
There are cases where NAT box decides to remove mappings that are still alive (for example, when the keepalive interval is too long, or when the NAT box is rebooted). To recover from this, ends that are NOT behind NAT SHOULD use the last valid UDP encapsulated IKE or IPsec packet from the other end to determine which IP and port addresses should be used. The host behind dynamic NAT MUST NOT do
ケースがNAT箱がまだ生きているマッピングを取り除くと決める(keepalive間隔が例えば長過ぎるか、またはNAT箱がリブートされるとき)ところにあります。 これから回復するなら、NAT SHOULDの後ろのそうでない終わりは、どのIPとポートアドレスが使用されるべきであるかを決定するのにもう一方の端からIKEかIPsecパケットであるとカプセル化された最後の有効なUDPを使用します。 ダイナミックなNATの後ろのホストはしてはいけません。
Kivinen, et al. Standards Track [Page 11] RFC 3947 Negotiation of NAT-Traversal in the IKE January 2005
Kivinen、他 規格は2005年1月にIKEでのNAT縦断のRFC3947交渉を追跡します[11ページ]。
this, as otherwise it opens a DoS attack possibility because the IP address or port of the other host will not change (it is not behind NAT).
これ、さもなければ、開くとき、もう片方のホストのIPアドレスかポートが変化しないので(NATの後ろにそれはありません)、DoSは可能性を攻撃します。
Keepalives cannot be used for these purposes, as they are not authenticated, but any IKE authenticated IKE packet or ESP packet can be used to detect whether the IP address or the port has changed.
それらが認証されないので、これらの目的にKeepalivesを使用できませんが、どんなIKEもIKEパケットを認証したか、またはIPアドレスかポートが変化したかどうか検出するのに超能力パケットは使用できます。
8. Security Considerations
8. セキュリティ問題
Whenever changes to some fundamental parts of a security protocol are proposed, the examination of security implications cannot be skipped. Therefore, here are some observations about the effects, and about whether or not these effects matter.
セキュリティプロトコルのいくつかの基本的な部分への変化が提案されるときはいつも、セキュリティ含意の試験をサボることができません。 したがって効果に関するいくつかの観測がここにあって、これらの効果が重要であるかどうかを。
o IKE probes reveal NAT-Traversal support to anyone watching the
traffic. Disclosing that NAT-Traversal is supported does not
introduce new vulnerabilities.
o IKE徹底的調査は、トラフィックを見ながら、NAT縦断サポートをだれにも明らかにします。 NAT縦断がサポートされるのを明らかにするのが新しい脆弱性を導入しません。
o The value of authentication mechanisms based on IP addresses
disappears once NATs are in the picture. That is not necessarily
a bad thing (for any real security, authentication measures other
than IP addresses should be used). This means that authentication
with pre-shared keys cannot be used in Main Mode without using
group-shared keys for everybody behind the NAT box. Using group
shared keys is a huge risk because it allows anyone in the group
to authenticate to any other party and claim to be anybody in the
group; e.g., a normal user could impersonate a vpn-gateway and act
as a man in the middle, and read/modify all traffic to/from others
in the group. Use of group-shared keys is NOT RECOMMENDED.
o 画像にNATsがいったんあると、IPアドレスに基づく認証機構の値は見えなくなります。 それは必ず悪いものであるというわけではありません(どんな物上担保のためにも、IPアドレス以外の認証測定は使用されるべきです)。 これは、Main ModeでNAT箱の後ろのみんなにグループによって共有されたキーを使用しないであらかじめ共有されたキーによる認証を使用できないことを意味します。 いかなる他のパーティーとクレームにも認証するグループのだれでもグループでだれでもある許容するので、グループの共有されたキーを使用するのは、巨大なリスクです。 例えば、普通のユーザは、グループですべてのトラフィックを他のものからの/に男性として中央でVPNゲートウェイと行為をまねて、読み込むか、または変更できました。 グループによって共有されたキーの使用はNOT RECOMMENDEDです。
o As the internal address space is only 32 bits and is usually very
sparse, it might be possible for the attacker to find out the
internal address used behind the NAT box by trying all possible
IP-addresses to find the matching hash. The port numbers are
normally fixed to 500, and the cookies can be extracted from the
packet. This limits the hash calculations to 2^32. If an
educated guess of the private address space is made, then the
number of hash calculations needed to find out the internal IP
address goes down to 2^24 + 2 * (2^16).
o 内部のアドレス空間が32ビットだけであり、通常非常にまばらであるときに、攻撃者がNAT箱の後ろで合っているハッシュを見つけるためにすべての可能なIP-アドレスを試みることによって使用される内部のアドレスを見つけるのは、可能であるかもしれません。 通常、500にポートナンバーを固定しています、そして、パケットからクッキーを抽出できます。 これはハッシュ計算を2^32に制限します。 プライベート・アドレススペースの経験に基づいた推測をするなら、ハッシュ計算の数は、内部のIPアドレスが2^24+2*(2^16)に降りるのを見つける必要がありました。
o Neither NAT-D payloads nor Vendor ID payloads are authenticated in
Main Mode nor in Aggressive Mode. This means that attacker can
remove those payloads, modify them, or add them. By removing or
adding them, the attacker can cause Denial of Service attacks. By
modifying the NAT-D packets, the attacker can cause both ends to
use UDP-Encapsulated modes instead of directly using tunnel or
transport mode, thus wasting some bandwidth.
o NAT DペイロードもVendor IDペイロードもMain ModeとAggressive Modeで認証されません。 これは、攻撃者がそれらのペイロードを取り外すか、それらを変更するか、またはそれらを加えることができることを意味します。 それらを取り除くか、または加えることによって、攻撃者はサービス妨害攻撃を引き起こす場合があります。 NAT Dパケットを変更することによって、攻撃者は両端に直接トンネルか交通機関を使用することの代わりにUDPによってカプセル化されたモードを使用させることができます、その結果、いくらかの帯域幅を浪費します。
Kivinen, et al. Standards Track [Page 12] RFC 3947 Negotiation of NAT-Traversal in the IKE January 2005
Kivinen、他 規格は2005年1月にIKEでのNAT縦断のRFC3947交渉を追跡します[12ページ]。
o Sending the original source address in the Quick Mode reveals the
internal IP address behind the NAT to the other end. In this case
we have already authenticated the other end, and sending the
original source address is only needed in transport mode.
o クィックModeの一次資料アドレスを送ると、内部のIPアドレスはNATの後ろでもう一方の端に明らかにされます。 この場合、私たちは既にもう一方の端を認証しました、そして、一次資料アドレスを送るのが交通機関で必要であるだけです。
o Updating the IKE SA/ESP UDP encapsulation IP addresses and ports
for each valid authenticated packet can cause DoS if an attacker
can listen to all traffic in the network, change the order of the
packets, and inject new packets before the packet he has already
seen. In other words, the attacker can take an authenticated
packet from the host behind NAT, change the packet UDP source or
destination ports or IP addresses and send it out to the other end
before the real packet reaches it. The host not behind the NAT
will update its IP address and port mapping and send further
traffic to the wrong host or port. This situation is fixed
immediately when the attacker stops modifying the packets, as the
first real packet will fix the situation. Implementations SHOULD
AUDIT the event every time the mapping is changed, as it should
not happen that often.
o それぞれの有効な認証されたパケットのためにIKE SA/ESP UDPカプセル化IPアドレスとポートをアップデートするのは、彼が既に見たパケットの前で攻撃者がネットワークですべてのトラフィックを聞くことができるならDoSを引き起こして、パケットの注文を変えて、新しいパケットを注入できます。 言い換えれば、本当のパケットがそれに達する前に、攻撃者は、NATの後ろでホストから認証されたパケットを取って、パケットUDPソース、仕向港またはIPアドレスを変えて、もう一方の端にそれを出すことができます。 ホストは、NATの後ろでそのIPアドレスとポートマッピングをアップデートして、間違ったホストかポートにさらなるトラフィックを送らないでしょう。 すぐ攻撃者が、パケットを変更するのを止めると、この状況は固定されています、最初の本当のパケットが状況を修理するとき。 マッピングを変えるときはいつも、それとしたイベントがそうするべきである実装SHOULD AUDITはそんなにしばしば起こるというわけではありません。
9. IANA Considerations
9. IANA問題
This document contains two new "magic numbers" allocated from the existing IANA registry for IPsec and renames existing registered port 4500. This document also defines 2 new payload types for IKE.
このドキュメントは、IPsecのために既存のIANA登録から割り当てられた2新しい「マジックナンバー」を含んでいて、登録されたポート4500に存在を改名します。 また、このドキュメントはIKEのための2つの新しいペイロードタイプを定義します。
The following are new items that have been added in the "Internet Security Association and Key Management Protocol (ISAKMP) Identifiers" Encapsulation Mode registry:
↓これは「インターネットセキュリティ協会とKey Managementプロトコル(ISAKMP)識別子」Encapsulation Mode登録で加えられる新商品です:
Name Value Reference
---- ----- ---------
UDP-Encapsulated-Tunnel 3 [RFC3947]
UDP-Encapsulated-Transport 4 [RFC3947]
名前値の参照---- ----- --------- トンネルであるとカプセル化されたUDP3[RFC3947]輸送であるとカプセル化されたUDP4[RFC3947]
Change in the registered port registry:
登録されたポート登録で変化してください:
Keyword Decimal Description Reference
------- ------- ----------- ---------
ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFC3947]
ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC3947]
キーワード小数記述参照------- ------- ----------- --------- ipsec-nat-t4500/tcp IPsec NAT縦断[RFC3947]ipsec-nat-t4500/udp IPsec NAT縦断[RFC3947]
Kivinen, et al. Standards Track [Page 13] RFC 3947 Negotiation of NAT-Traversal in the IKE January 2005
Kivinen、他 規格は2005年1月にIKEでのNAT縦断のRFC3947交渉を追跡します[13ページ]。
New IKE payload numbers need to be added to the Next Payload Types registry:
新しいIKEペイロード番号は、Next有効搭載量Types登録に加えられる必要があります:
NAT-D 20 NAT Discovery Payload
NAT-OA 21 NAT Original Address Payload
21NATオリジナルが有効搭載量を扱うというNAT D20NAT発見有効搭載量NAT-OA
10. IAB Considerations
10. IAB問題
The UNSAF [RFC3424] questions are addressed by the IPsec-NAT compatibility requirements document [RFC3715].
IPsec-NAT互換性要件ドキュメント[RFC3715]によってUNSAF[RFC3424]質問は扱われます。
11. Acknowledgments
11. 承認
Thanks to Markus Stenberg, Larry DiBurro, and William Dixon, who contributed actively to this document.
活発にこのドキュメントに貢献したマーカスStenberg、ラリーDiBurro、およびウィリアム・ディクソンをありがとうございます。
Thanks to Tatu Ylonen, Santeri Paavolainen, and Joern Sierwald, who contributed to the document used as the base for this document.
このドキュメントにベースとして使用されるドキュメントに貢献したTatu Ylonen、Santeri Paavolainen、およびJoern Sierwaldのおかげで。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec Packets", RFC 3948,
January 2005.
[RFC3948]HuttunenとA.とSwanderとB.とボルペとV.とDiBurro、L.とM.Stenberg、「IPsecパケットのUDPカプセル化」RFC3948(2005年1月)。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
12.2. Informative References
12.2. 有益な参照
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] AbobaとB.とW.ディクソン、「IPsec-ネットワーク・アドレス翻訳(NAT)互換性要件」、RFC3715、2004年3月。
[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問題」、RFC3424、2002年11月。
Kivinen, et al. Standards Track [Page 14] RFC 3947 Negotiation of NAT-Traversal in the IKE January 2005
Kivinen、他 規格は2005年1月にIKEでのNAT縦断のRFC3947交渉を追跡します[14ページ]。
Authors' Addresses
作者のアドレス
Tero Kivinen SafeNet, Inc. Fredrikinkatu 47 FIN-00100 HELSINKI Finland
Tero Kivinen SafeNet Inc.Fredrikinkatu47フィン-00100ヘルシンキフィンランド
EMail: kivinen@safenet-inc.com
メール: kivinen@safenet-inc.com
Ari Huttunen F-Secure Corporation Tammasaarenkatu 7, FIN-00181 HELSINKI Finland
HuttunenのF安全な社のTammasaarenkatu7、アリフィン-00181ヘルシンキフィンランド
EMail: Ari.Huttunen@F-Secure.com
メール: Ari.Huttunen@F-Secure.com
Brian Swander Microsoft One Microsoft Way Redmond, WA 98052 USA
ブライアンSwanderマイクロソフト1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: briansw@microsoft.com
メール: briansw@microsoft.com
Victor Volpe Cisco Systems 124 Grove Street Suite 205 Franklin, MA 02038 USA
ビクタボルペシスコシステムズ124木立通りSuite205MA02038フランクリン(米国)
EMail: vvolpe@cisco.com
メール: vvolpe@cisco.com
Kivinen, et al. Standards Track [Page 15] RFC 3947 Negotiation of NAT-Traversal in the IKE January 2005
Kivinen、他 規格は2005年1月にIKEでのNAT縦断のRFC3947交渉を追跡します[15ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントは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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Kivinen, et al. Standards Track [Page 16]
Kivinen、他 標準化過程[16ページ]
一覧
スポンサーリンク
