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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

TRUNCATE TABLE テーブルを空にする

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る