[要約] RFC 3947は、IKEにおけるNATトラバーサルの交渉に関する仕様です。その目的は、NAT環境下でのセキュアな通信を可能にするために、IKEプロトコルの拡張を提供することです。
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
Negotiation of NAT-Traversal in the IKE
IKE での NAT トラバーサルのネゴシエーション
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネット コミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めます。このプロトコルの標準化状況とステータスについては、最新版の「インターネット公式プロトコル標準」(STD 1) を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権 (C) インターネット協会 (2005)。
Abstract
概要
This 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 つ以上のネットワーク アドレス変換デバイス (NAT) を検出する方法、およびインターネット キー交換 (IKE) の NAT ボックスを介して IPsec パケットの UDP カプセル化の使用をネゴシエートする方法について説明します。
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
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 つの部分に分かれています。最初のセクションでは、IKE フェーズ 1 で NAT トラバーサルをサポートするために必要なものについて説明します。これには、相手側が NAT トラバーサルをサポートしているかどうかの検出や、ピア間に 1 つ以上の NAT があるかどうかの検出が含まれます。
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.)
2 番目の部分では、IKE のクイック モードで UDP カプセル化された IPsec パケットの使用をネゴシエートする方法について説明します。また、必要に応じて、元の送信元アドレスと宛先アドレスをピアに送信する方法についても説明します。これらのアドレスは、NAT 変換後に一致するように TCP/IP チェックサムを段階的に更新するためにトランスポート モードで使用されます。(TCP/IP チェックサムは UDP でカプセル化された IPsec パケット内にあるため、NAT はこれを行うことができません。)
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 アドレスを持っています。
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 以外の宛先ポートを使用する方法がないため、IP ごとにレスポンダーは 1 つだけです)。つまり、構成でわかるのです。
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].
この文書では、「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨」、「してもよい」、および「任意」というキーワードを使用して説明します。要件は、[RFC2119] に記載されているように解釈されます。
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 NAT の背後にある IPsec ホストは 1 つだけ、または
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 最初の 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 に変換します。
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 ペイロードの交換によって決まります。フェーズ 1 の最初の 2 つのメッセージでは、NAT トラバーサル プローブを続行するには、サポートされている場合はこの仕様のベンダー ID ペイロードを送信しなければなりません (そして、両側で受信しなければなりません)。ペイロードの内容は、次の MD5 ハッシュです。
RFC 3947
RFC 3947
The exact content in hex for the payload is
ペイロードの正確な内容は 16 進数で次のようになります。
4a131c81070358455c5728f20e95452f
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 がどこにあるかも検出します。キープアライブは 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 アドレスまたはポートが変化するかどうかを検出する必要があります。これは、両方の IKE ピアの IP アドレスとポートのハッシュを両端に送信することによって行われます。両端でこれらのハッシュを計算し、同じ結果が得られた場合、間に 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 Discovery) ペイロードとして送信されます。各ペイロードには 1 つのハッシュが含まれるため、複数のハッシュの場合は複数の NAT-D ペイロードが送信されます。通常の場合、NAT-D ペイロードは 2 つだけです。
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 ペイロードは、メイン モードの 3 番目と 4 番目のパケット、アグレッシブ モードの 2 番目と 3 番目のパケットに含まれます。
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 ~
+---------------+---------------+---------------+---------------+
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 ペイロードがローカル IP アドレスとポートのいずれにも一致しない場合)、ピア間に動的 NAT が存在することを意味し、このエンドは [RFC3948] で定義されているようにキープアライブの送信を開始する必要があります。] (この端は NAT の背後にあります)。
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):
次の例は、メイン モード (署名による認証) で NAT トラバーサルを使用したフェーズ 1 交換の例です。
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
The following example is of Phase 1 exchange using NAT-Traversal in Aggressive Mode (authentication with signatures):
次の例は、アグレッシブ モード (署名による認証) で NAT トラバーサルを使用したフェーズ 1 交換の例です。
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 -->
The # sign indicates that those packets are sent to the changed port if NAT is detected.
# 記号は、NAT が検出された場合に、それらのパケットが変更されたポートに送信されることを示します。
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 対応 NAT は問題を引き起こす可能性があります ([RFC3715] のセクション 2.3 を参照)。一部の NAT は、NAT の背後に複数のクライアントがある場合でも、IKE 送信元ポート 500 を変更しません ([RFC3715]、セクション 2.3、ケース n を参照)。また、送信元ポートを使用する代わりに、IKE Cookie を使用してトラフィックを逆多重化することもできます ([RFC3715]、セクション 2.3、ケース m を参照)。IKE が NAT の機能を検出するのは難しいため、これらは両方とも汎用 NAT の透過性にとって問題となります。最善のアプローチは、IPsec 対応の NAT の特殊なケースを回避するために、IKE トラフィックをできるだけ早くポート 500 から移動することです。
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 の背後にあるイニシエーターの一般的なケースを考えてみましょう。IPsec 対応 NAT の問題の発生範囲を最小限に抑えるために、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 ペイロードを送信するときにポートを変更しなければなりません (MUST)。イニシエータは、UDP 送信元ポートと宛先ポートの両方を 4500 に設定しなければなりません (MUST)。このピアに送信される後続のすべてのパケット (情報通知を含む) は、ポート 4500 で送信されなければなりません (MUST)。さらに、IKE データには、逆多重化を可能にする非 ESP マーカーが付加されなければなりません (MUST)[RFC3948] で定義されているトラフィックの。
Thus, the IKE packet now looks like this:
したがって、IKE パケットは次のようになります。
IP UDP(4500,4500) <non-ESP marker> HDR*, IDii, [CERT, ] SIG_I
This assumes authentication using signatures. The 4 bytes of non-ESP marker are defined in the [RFC3948].
これは署名を使用した認証を前提としています。4 バイトの非 ESP マーカーは [RFC3948] で定義されています。
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 アドレスを使用するように、ローカル状態を更新しなければなりません (MUST)。NAT は UDP(500,500) を UDP(X,500) にマッピングし、UDP(4500,4500) を UDP(Y,4500) にマッピングするため、通常、ポートは異なります。IP アドレスが変更前の IP アドレスと異なることはほとんどありません。レスポンダは、UDP(4500,Y) を使用して、このピアに対する後続のすべての IKE パケットで応答しなければなりません (MUST)。
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.
同様に、応答側がフェーズ 1 SA のキーを更新する必要がある場合、UDP(4500,Y) を使用してキー更新ネゴシエーションを開始しなければなりません (MUST)。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 で受信された場合、そのパケットは古いものになります。パケットが情報パケットの場合、ローカル ポリシーで許可されていれば処理してもよい(MAY)。パケットがメイン モード パケットまたはアグレッシブ モード パケット (前のパケットと同じ Cookie を含む) である場合、そのパケットは破棄されるべきです(SHOULD)。パケットが新しいメイン モードまたはアグレッシブ交換である場合、パケットは通常どおり処理されます (相手側が再起動している可能性があり、これにより新しい交換が開始されます)。
Here is an example of a Phase 1 exchange using NAT-Traversal in Main Mode (authentication with signatures) with changing port:
次に、メイン モード (署名による認証) で NAT トラバーサルを使用し、ポートを変更してフェーズ 1 交換を行う例を示します。
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
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).
アグレッシブ モードの手順は非常に似ています。NAT が検出された後、イニシエーターは IP UDP(4500,4500) <4 バイトの非 ESP マーカー> HDR*、[CERT、]、NAT-D、NAT-D、および SIG_I を送信します。レスポンダは上記と同様の処理を実行し、成功した場合は内部 IKE ポートを更新しなければなりません (MUST)。レスポンダは、UDP(4500,Y) を使用して、このピアに対する後続のすべての IKE パケットで応答しなければなりません (MUST)。
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*#, ...
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 トラバーサルのサポートが有効な場合、メイン モード/アグレッシブ モードの 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 を変換するポートの背後にあり、イニシエーターが最初にそれに接続する必要がある場合、イニシエーターは通常、他のサーバーに接続することによって、使用するポートを決定する必要があります。イニシエーターは、NAT を通過するためにどのポート (通常は UDP(Z,4500) など) を使用するかを認識すると、これらのポートを使用して開始します。これは、使用するポートが事前にすでにわかっており、追加の変更を行う必要がないという点で、上記のレスポンダーのキー再生成のケースに似ています。また、最初のキープアライブ タイマーは新しいポートへの変更後に開始され、キープアライブはポート 500 に送信されません。
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.
フェーズ 1 の後、両端は、間に NAT が存在するかどうかを認識します。NAT トラバーサルを使用するかどうかの最終決定は、クイック モードに委ねられます。NAT トラバーサルの使用は、クイック モードの SA ペイロード内でネゴシエートされます。クイック モードでは、両端が IPsec パケットの元のアドレス (トランスポート モードの場合) をもう一方の端に送信できるため、NAT 変換後にそれぞれが TCP/IP チェックサム フィールドを修正できます。
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 カプセル化は、NAT による非 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.
また、イニシエータは、その提案に通常のトンネルまたはトランスポート モードと UDP-Encapsulated-Tunnel または UDP-Encapsulated-Transport の両方を含めるべきではありません (SHOULD NOT)。
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 チェックサムの増分更新を実行するには、両方のピアがパケットを構築したときにピアによって使用された元の IP アドレスを知る必要がある場合があります ([RFC3715]、セクション 2.1、ケース b を参照)。イニシエータの場合、元のイニシエータ アドレスはイニシエータの IP アドレスとして定義されます。元のレスポンダー アドレスは、認識されたピアの IP アドレスとして定義されます。レスポンダーの場合、元のイニシエーター アドレスは、認識されたピアのアドレスとして定義されます。元のレスポンダー アドレスは、レスポンダーの 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.
イニシエーター NAT-OA ペイロードが最初です。レスポンダー NAT-OA ペイロードは 2 番目です。
Example 1:
例 1:
Initiator <---------> NAT <---------> Responder
^ ^ ^
Iaddr NatPub Raddr
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 の背後にあり、公開されているレスポンダーと通信しています。イニシエータとレスポンダには IP アドレス Iaddr と Raddr があります。NAT にはパブリック IP アドレス NatPub があります。
Initiator:
イニシエータ：
NAT-OAi = Iaddr NAT-OAr = Raddr
NAT-OAi = Iaddr NAT-OAr = Raddr
Responder: NAT-OAi = NATPub NAT-OAr = Raddr
レスポンダー: NAT-OAi = NATPub NAT-OAr = Raddr
Example 2:
例 2:
Initiator <------> NAT1 <---------> NAT2 <-------> Responder
^ ^ ^ ^
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-OAr = Nat2Pub
Responder: NAT-OAi = Nat1Pub NAT-OAr = Raddr
レスポンダー: NAT-OAi = Nat1Pub NAT-OAr = 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.
トランスポート モードの場合、両端は元のイニシエーター アドレスとレスポンダー アドレスの両方を相手側に送信しなければなりません。トンネル モードの場合、両端は元のアドレスを相手側に送信してはなりません (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.
NAT-OA ペイロードは、クイック モードの最初と 2 番目のパケット内で送信されます。イニシエータは、UDP カプセル化トランスポート モードを提案する場合はペイロードを送信しなければならず、レスポンダは UDP カプセル化トランスポート モードを選択した場合にのみペイロードを送信しなければなりません。イニシエータは NAT-OA ペイロードを送信しますが、UDP カプセル化トランスポート モードとトンネル モードの両方を提案する可能性があります。次に、レスポンダは UDP カプセル化トンネル モードを選択し、NAT-OA ペイロードを送り返しません。
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) |
+---------------+---------------+---------------+---------------+
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 タイプの後の 2 つの予約フィールドはゼロでなければなりません。
The following example is of Quick Mode using NAT-OA payloads:
次の例は、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) -->
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 SA を削除するかを決定するために IP とポート番号を使用してはなりません ([ を参照)RFC3715]、セクション 2.1、ケース c)。代わりに、相手側から送信された ID ペイロードを使用する必要があります (SHOULD)。つまり、INITIAL-CONTACT 通知を相手側から受信した場合、受信側は同じ ID ペイロードに関連付けられたすべての SA を削除する必要があります (SHOULD)。
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 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).
NAT ボックスがまだ生きているマッピングの削除を決定する場合があります (たとえば、キープアライブ間隔が長すぎる場合、または NAT ボックスが再起動された場合)。この問題から回復するには、NAT の背後にない端は、もう一方の端からの最後の有効な UDP カプセル化 IKE または IPsec パケットを使用して、どの IP アドレスとポート アドレスを使用するかを決定する必要があります (SHOULD)。動的 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.
キープアライブは認証されていないため、これらの目的には使用できませんが、IKE 認証された IKE パケットまたは ESP パケットを使用して、IP アドレスまたはポートが変更されたかどうかを検出できます。
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 NAT が登場すると、IP アドレスに基づく認証メカニズムの価値はなくなります。それは必ずしも悪いことではありません (実際のセキュリティでは、IP アドレス以外の認証手段を使用する必要があります)。これは、NAT ボックスの背後にある全員のグループ共有キーを使用しない限り、事前共有キーによる認証をメイン モードで使用できないことを意味します。グループ共有キーを使用すると、グループ内の誰もが他の当事者に対して認証され、グループ内の誰でもであると主張できるようになるため、大きなリスクが生じます。たとえば、通常のユーザーは、vpn ゲートウェイになりすまして中間者として機能し、グループ内の他のユーザーとの間のすべてのトラフィックを読み取り/変更できます。グループ共有キーの使用は推奨されません。
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 ビットで、通常は非常にまばらであるため、攻撃者は、考えられるすべての IP アドレスを試して一致するハッシュを見つけることによって、NAT ボックスの背後で使用されている内部アドレスを見つけることができる可能性があります。ポート番号は通常 500 に固定されており、パケットから Cookie を抽出できます。これにより、ハッシュ計算が 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 ペイロードもベンダー ID ペイロードも、メイン モードでもアグレッシブ モードでも認証されません。これは、攻撃者がそれらのペイロードを削除、変更、または追加できることを意味します。これらを削除または追加することにより、攻撃者はサービス拒否攻撃を引き起こす可能性があります。攻撃者は NAT-D パケットを変更することで、両端でトンネル モードやトランスポート モードを直接使用する代わりに UDP カプセル化モードを使用させ、帯域幅の一部を浪費する可能性があります。
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 クイック モードで元の送信元アドレスを送信すると、NAT の背後にある内部 IP アドレスが相手側に明らかになります。この場合、もう一方の端はすでに認証されており、元の送信元アドレスの送信はトランスポート モードでのみ必要です。
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 アドレスとポートのマッピングを更新し、さらにトラフィックを間違ったホストまたはポートに送信します。この状況は、最初の実際のパケットによって状況が修正されるため、攻撃者がパケットの変更を停止すると、ただちに修正されます。実装では、マッピングが変更されるたびにイベントを監査する必要があります (頻繁に発生するべきではない)。
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:
以下は、「Internet Security Association and Key Management Protocol (ISAKMP) Identifiers」カプセル化モード レジストリに追加された新しい項目です。
Name Value Reference
---- ----- ---------
UDP-Encapsulated-Tunnel 3 [RFC3947]
UDP-Encapsulated-Transport 4 [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]
New IKE payload numbers need to be added to the Next Payload Types registry:
新しい IKE ペイロード番号を Next Payload Types レジストリに追加する必要があります。
NAT-D 20 NAT Discovery Payload NAT-OA 21 NAT Original Address Payload
NAT-D 20 NAT ディスカバリ ペイロード NAT-OA 21 NAT オリジナル アドレス ペイロード
The UNSAF [RFC3424] questions are addressed by the IPsec-NAT compatibility requirements document [RFC3715].
UNSAF [RFC3424] の質問は、IPsec-NAT 互換性要件文書 [RFC3715] で解決されています。
Thanks to Markus Stenberg, Larry DiBurro, and William Dixon, who contributed actively to this document.
この文書に積極的に貢献してくれた Markus Stenberg、Larry DiBurro、William Dixon に感謝します。
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 に感謝します。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins, D. および D. Carrel、「インターネット鍵交換 (IKE)」、RFC 2409、1998 年 11 月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407] Piper, D.、「ISAKMP のインターネット IP セキュリティ ドメインの解釈」、RFC 2407、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.、Volpe, V.、DiBurro, L.、および M. Stenberg、「IPsec パケットの UDP カプセル化」、RFC 3948、2005 年 1 月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、BCP 14、RFC 2119、1997 年 3 月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715] Ababa, B. および W. Dixon、「IPsec ネットワーク アドレス変換 (NAT) 互換性要件」、RFC 3715、2004 年 3 月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424] Daigle, L. および IAB、「ネットワーク アドレス変換全体にわたる一方的セルフアドレス固定 (UNSAF) に関する IAB の考慮事項」、RFC 3424、2002 年 11 月。
Authors' Addresses
著者の住所
Tero Kivinen SafeNet, Inc. Fredrikinkatu 47 FIN-00100 HELSINKI Finland
Tero Kivinen SafeNet, Inc. Fredrikinkatu 47 FIN-00100 HELSINKI Finland
EMail: kivinen@safenet-inc.com
Ari Huttunen F-Secure Corporation Tammasaarenkatu 7, FIN-00181 HELSINKI Finland
Ari Huttunen F-Secure Corporation Tammasaarenkatu 7、FIN-00181 HELSINKI Finland
EMail: Ari.Huttunen@F-Secure.com
Brian Swander Microsoft One Microsoft Way Redmond, WA 98052 USA
Brian Swander Microsoft One Microsoft Way Redmond, WA 98052 USA
EMail: briansw@microsoft.com
Victor Volpe Cisco Systems 124 Grove Street Suite 205 Franklin, MA 02038 USA
Victor Volpe Cisco Systems 124 Grove Street Suite 205 Franklin, MA 02038 USA
EMail: vvolpe@cisco.com
Full Copyright Statement
完全な著作権に関する声明
Copyright (C) The Internet Society (2005).
著作権 (C) インターネット協会 (2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78 に含まれる権利、ライセンス、および制限の対象となり、そこに規定されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF は、本書に記載されているテクノロジの実装または使用に関連すると主張される知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが適用されるかどうかの範囲に関して、いかなる立場も負いません。利用可能であること。また、かかる権利を特定するために独自の努力を行ったことを示すものでもありません。IETF 文書の権利に関する IETF の手順に関する情報は、BCP 78 および BCP 79 に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/ipr) から入手してください。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF は、利害関係者に対し、この規格の実装に必要とされる可能性のある技術をカバーする著作権、特許、特許出願、またはその他の所有権について注意を喚起するよう呼びかけています。情報は IETF (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。