RFC3948 日本語訳
3948 UDP Encapsulation of IPsec ESP Packets. A. Huttunen, B. Swander,V. Volpe, L. DiBurro, M. Stenberg. January 2005. (Format: TXT=30366 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Huttunen
Request for Comments: 3948 F-Secure Corporation
Category: Standards Track B. Swander
Microsoft
V. Volpe
Cisco Systems
L. DiBurro
Nortel Networks
M. Stenberg
January 2005
Huttunenがコメントのために要求するワーキンググループA.をネットワークでつないでください: 3948年のF安全な社のカテゴリ: 規格はM.Stenberg2005年1月にB.SwanderマイクロソフトV.ボルペシスコシステムズL.DiBurroノーテルネットワークを追跡します。
UDP Encapsulation of IPsec ESP Packets
IPsec超能力パケットのUDPカプセル化
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 protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for traversing Network Address Translators. ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Whenever negotiated, encapsulation is used with Internet Key Exchange (IKE).
このプロトコル仕様は、Network Address Translatorsを横断するためにUDPパケットの中で要約するメソッドとdecapsulate IP Encapsulating Security有効搭載量(超能力)パケットを定義します。 IPv4とIPv6シナリオの両方で本書では定義される超能力カプセル化は使用できます。 交渉されるとき、カプセル化はインターネット・キー・エクスチェンジ(IKE)と共に使用されます。
Huttunen, et al. Standards Track [Page 1] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. UDP-Encapsulated ESP Header Format . . . . . . . . . . . 3
2.2. IKE Header Format for Port 4500 . . . . . . . . . . . . 4
2.3. NAT-Keepalive Packet Format . . . . . . . . . . . . . . 4
3. Encapsulation and Decapsulation Procedures . . . . . . . . . . 5
3.1. Auxiliary Procedures . . . . . . . . . . . . . . . . . . 5
3.1.1. Tunnel Mode Decapsulation NAT Procedure . . . . 5
3.1.2. Transport Mode Decapsulation NAT Procedure . . . 5
3.2. Transport Mode ESP Encapsulation . . . . . . . . . . . . 6
3.3. Transport Mode ESP Decapsulation . . . . . . . . . . . . 6
3.4. Tunnel Mode ESP Encapsulation . . . . . . . . . . . . . 7
3.5. Tunnel Mode ESP Decapsulation . . . . . . . . . . . . . 7
4. NAT Keepalive Procedure . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5.1. Tunnel Mode Conflict . . . . . . . . . . . . . . . . . . 8
5.2. Transport Mode Conflict . . . . . . . . . . . . . . . . 9
6. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11
A. Clarification of Potential NAT Multiple Client Solutions . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 パケット・フォーマット. . . . . . . . . . . . . . . . . . . . . . . . 3 2.1。 UDPによってカプセル化された超能力ヘッダー形式. . . . . . . . . . . 3 2.2。 ポート4500.42.3のためのIKEヘッダー形式。 NAT-Keepaliveパケット・フォーマット. . . . . . . . . . . . . . 4 3。 カプセル化と被膜剥離術手順. . . . . . . . . . 5 3.1。 補助の手順. . . . . . . . . . . . . . . . . . 5 3.1.1。 モード被膜剥離術NAT手順. . . . 5 3.1.2にトンネルを堀ってください。 モード被膜剥離術NAT手順. . . 5 3.2を輸送してください。 モード超能力カプセル化. . . . . . . . . . . . 6 3.3を輸送してください。 モード超能力被膜剥離術. . . . . . . . . . . . 6 3.4を輸送してください。 モード超能力カプセル化. . . . . . . . . . . . . 7 3.5にトンネルを堀ってください。 モード超能力被膜剥離術. . . . . . . . . . . . . 7 4にトンネルを堀ってください。 NAT Keepalive手順. . . . . . . . . . . . . . . . . . . 7 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 8 5.1。 モード闘争. . . . . . . . . . . . . . . . . . 8 5.2にトンネルを堀ってください。 モード闘争. . . . . . . . . . . . . . . . 9 6を輸送してください。 IAB問題. . . . . . . . . . . . . . . . . . . . . . 10 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 11 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1。 引用規格. . . . . . . . . . . . . . . . . . 11 8.2。 NATの潜在的倍数クライアントソリューション. . . 12作者のA.明確化が.14の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 15を扱う有益な参照. . . . . . . . . . . . . . . . . 11
1. Introduction
1. 序論
This protocol specification defines methods to encapsulate and decapsulate ESP packets inside UDP packets for traversing Network Address Translators (NATs) (see [RFC3715], section 2.2, case i). The UDP port numbers are the same as those used by IKE traffic, as defined in [RFC3947].
このプロトコル仕様は、Network Address Translators(NATs)を横断するためにUDPパケットの中で要約するメソッドとdecapsulate超能力パケットを定義します([RFC3715]を見てください、セクション2.2、ケースi)。 UDPポートナンバーは[RFC3947]で定義されるようにIKEトラフィックによって使用されるものと同じです。
The sharing of the port numbers for both IKE and UDP encapsulated ESP traffic was selected because it offers better scaling (only one NAT mapping in the NAT; no need to send separate IKE keepalives), easier configuration (only one port to be configured in firewalls), and easier implementation.
より良いスケーリング(NATにおける1つのNATマッピングだけ; 別々のIKE keepalivesを送る必要性がない)、より簡単な構成(1つのファイアウォールで構成されるべきポートだけ)、および、より簡単な実装を提供するので、超能力トラフィックであるとカプセル化されたIKEとUDPの両方のためのポートナンバーの共有は選択されました。
A client's needs should determine whether transport mode or tunnel mode is to be supported (see [RFC3715], Section 3, "Telecommuter scenario"). L2TP/IPsec clients MUST support the modes as defined in [RFC3193]. IPsec tunnel mode clients MUST support tunnel mode.
クライアントの必要性は、交通機関かトンネルモードがサポートされるかどうか([RFC3715]、「在宅勤務者シナリオ」というセクション3を見ます)ことであることを決定するべきです。 L2TP/IPsecクライアントは[RFC3193]で定義されるようにモードをサポートしなければなりません。 IPsecトンネルモードクライアントはトンネルモードをサポートしなければなりません。
Huttunen, et al. Standards Track [Page 2] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[2ページ]。
An IKE implementation supporting this protocol specification MUST NOT use the ESP SPI field zero for ESP packets. This ensures that IKE packets and ESP packets can be distinguished from each other.
このプロトコルが仕様であるとサポートするIKE実装は超能力パケットにESP SPI分野ゼロを使用してはいけません。 これは、互いとIKEパケットと超能力パケットを区別できるのを確実にします。
As defined in this document, UDP encapsulation of ESP packets is written in terms of IPv4 headers. There is no technical reason why an IPv6 header could not be used as the outer header and/or as the inner header.
本書では定義されるように、超能力パケットのUDPカプセル化はIPv4ヘッダーに関して書かれています。 外側のヘッダー内側のヘッダーとしてIPv6ヘッダーを使用できなかったどんな技術的な理由もありません。
Because the protection of the outer IP addresses in IPsec AH is inherently incompatible with NAT, the IPsec AH was left out of the scope of this protocol specification. This protocol also assumes that IKE (IKEv1 [RFC2401] or IKEv2 [IKEv2]) is used to negotiate the IPsec SAs. Manual keying is not supported.
IPsec AHでの外側のIPアドレスの保護が本来NATと両立しないので、IPsec AHはこのプロトコル仕様の範囲から外されました。 また、このプロトコルは、IKE(IKEv1[RFC2401]かIKEv2[IKEv2])がIPsec SAsを交渉するのに使用されると仮定します。 手動の合わせることはサポートされません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Packet Formats
2. パケット・フォーマット
2.1. UDP-Encapsulated ESP Header Format
2.1. UDPによってカプセル化された超能力ヘッダー形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ESP header [RFC2406] |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポート| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 超能力ヘッダー[RFC2406]| ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The UDP header is a standard [RFC0768] header, where
UDPヘッダーは標準の[RFC0768]ヘッダー、どこです。
o the Source Port and Destination Port MUST be the same as that used
by IKE traffic,
o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and
o receivers MUST NOT depend on the UDP checksum being a zero value.
o ○ Source PortとDestination PortはIKEトラフィックによって使用されるそれと同じであるに違いありません、ゼロが評価するように伝えられて、IPv4 UDP Checksum SHOULD。o受信機はゼロが評価するUDPチェックサム存在によってはいけません。
The SPI field in the ESP header MUST NOT be a zero value.
超能力ヘッダーのSPI分野はゼロが値であったならそうしてはいけません。
Huttunen, et al. Standards Track [Page 3] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[3ページ]。
2.2. IKE Header Format for Port 4500
2.2. ポート4500へのIKEヘッダー形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Non-ESP Marker |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE header [RFC2409] |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポート| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 非超能力のマーカー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IKEヘッダー[RFC2409]| ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The UDP header is a standard [RFC0768] header and is used as defined in [RFC3947]. This document does not set any new requirements for the checksum handling of an IKE packet.
UDPヘッダーは、標準の[RFC0768]ヘッダーであり、[RFC3947]で定義されるように使用されています。 このドキュメントはIKEパケットのチェックサム取り扱いのためのどんな新しい要件も設定しません。
A Non-ESP Marker is 4 zero-valued bytes aligning with the SPI field of an ESP packet.
Non-超能力Markerは超能力パケットのSPI分野に並ぶ無評価された4バイトです。
2.3. NAT-Keepalive Packet Format
2.3. NAT-Keepaliveパケット・フォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xFF |
+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポート| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF| +-+-+-+-+-+-+-+-+
The UDP header is a standard [RFC0768] header, where
UDPヘッダーは標準の[RFC0768]ヘッダー、どこです。
o the Source Port and Destination Port MUST be the same as used by
UDP-ESP encapsulation of Section 2.1,
o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and
o receivers MUST NOT depend upon the UDP checksum being a zero
value.
o ○ Source PortとDestination Portはセクション2.1のUDP-超能力カプセル化によって使用されるのと同じであるに違いありません、ゼロが評価するように伝えられて、IPv4 UDP Checksum SHOULD。o受信機はゼロが評価するUDPチェックサム存在によってはいけません。
The sender MUST use a one-octet-long payload with the value 0xFF. The receiver SHOULD ignore a received NAT-keepalive packet.
送付者は値の0xFFがある、ある八重奏長さペイロードを使用しなければなりません。 受信機SHOULDは容認されたNAT-keepaliveパケットを無視します。
Huttunen, et al. Standards Track [Page 4] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[4ページ]。
3. Encapsulation and Decapsulation Procedures
3. カプセル化と被膜剥離術手順
3.1. Auxiliary Procedures
3.1. 補助の手順
3.1.1. Tunnel Mode Decapsulation NAT Procedure
3.1.1. トンネル・モード被膜剥離術NAT手順
When a tunnel mode has been used to transmit packets (see [RFC3715], section 3, criteria "Mode support" and "Telecommuter scenario"), the inner IP header can contain addresses that are not suitable for the current network. This procedure defines how these addresses are to be converted to suitable addresses for the current network.
トンネルモードがパケットを伝えるのに使用されたとき([RFC3715]を見てください、セクション3、評価基準「モードサポート」と「在宅勤務者シナリオ」)、内側のIPヘッダーは現在のネットワークに適していないアドレスを含むことができます。 この手順は現在のネットワークに、適当なアドレスに変換されるこれらのアドレスがことである方法を定義します。
Depending on local policy, one of the following MUST be done:
ローカルの方針によって、以下の1つをしなければなりません:
1. If a valid source IP address space has been defined in the policy
for the encapsulated packets from the peer, check that the source
IP address of the inner packet is valid according to the policy.
2. If an address has been assigned for the remote peer, check that
the source IP address used in the inner packet is the assigned IP
address.
3. NAT is performed for the packet, making it suitable for transport
in the local network.
1. 有効なソースIPアドレス空間がカプセル化されたパケットのために同輩から方針で定義されたなら、方針によると、内側のパケットのソースIPアドレスが有効であることをチェックしてください。 2. リモート同輩のためにアドレスを割り当ててあるなら、アドレスが内側のパケットで使用したソースIPが割り当てられたIPアドレスであることをチェックしてください。 3. それを企業内情報通信網で輸送に適するようにして、NATはパケットのために実行されます。
3.1.2. Transport Mode Decapsulation NAT Procedure
3.1.2. 交通機関被膜剥離術NAT手順
When a transport mode has been used to transmit packets, contained TCP or UDP headers will have incorrect checksums due to the change of parts of the IP header during transit. This procedure defines how to fix these checksums (see [RFC3715], section 2.1, case b).
交通機関がパケットを伝えるのに使用されたとき、IPヘッダーの一部の変化のため、トランジットの間、含まれたTCPかUDPヘッダーには、不正確なチェックサムがあるでしょう。 この手順はこれらのチェックサムを修理する方法を定義します([RFC3715]、セクション2.1を見てください、そして、bをケースに入れてください)。
Depending on local policy, one of the following MUST be done:
ローカルの方針によって、以下の1つをしなければなりません:
1. If the protocol header after the ESP header is a TCP/UDP header
and the peer's real source and destination IP address have been
received according to [RFC3947], incrementally recompute the
TCP/UDP checksum:
1. 次々とプロトコル超能力ヘッダーがTCP/UDPヘッダーと同輩の本当の情報筋であるか、そして、送付先IPアドレスは、[RFC3947]に応じて受け取られて、TCP/UDPチェックサムを増加して再計算します:
* Subtract the IP source address in the received packet from the
checksum.
* Add the real IP source address received via IKE to the
checksum (obtained from the NAT-OA)
* Subtract the IP destination address in the received packet
from the checksum.
* Add the real IP destination address received via IKE to the
checksum (obtained from the NAT-OA).
Note: If the received and real address are the same for a given
address (e.g., say the source address), the operations cancel and
don't need to be performed.
* 容認されたパケットでチェックサムからIPソースアドレスを引き算してください。 * 本当のIPソースアドレスがチェックサム(NAT-OAから、得る)*へのIKEを通して受信されたと言い足してください。容認されたパケットでチェックサムから受信者IPアドレスを引き算してください。 * 本当の受信者IPアドレスがチェックサム(NAT-OAから、得る)へのIKEを通して受信されたと言い足してください。 以下に注意してください。 与えられたアドレスに、受け取られていていて本当のアドレスが同じであるなら(例えば、ソースアドレスを言ってください)、操作は取り消して、実行される必要はありません。
Huttunen, et al. Standards Track [Page 5] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[5ページ]。
2. If the protocol header after the ESP header is a TCP/UDP header,
recompute the checksum field in the TCP/UDP header.
2. プロトコルヘッダーであるなら、超能力ヘッダーの後に、TCP/UDPヘッダーがあって、recomputeはTCP/UDPヘッダーのチェックサム分野です。
3. If the protocol header after the ESP header is a UDP header, set
the checksum field to zero in the UDP header. If the protocol
after the ESP header is a TCP header, and if there is an option
to flag to the stack that the TCP checksum does not need to be
computed, then that flag MAY be used. This SHOULD only be done
for transport mode, and if the packet is integrity protected.
Tunnel mode TCP checksums MUST be verified. (This is not a
violation to the spirit of section 4.2.2.7 in [RFC1122] because a
checksum is being generated by the sender and verified by the
receiver. That checksum is the integrity over the packet
performed by IPsec.)
3. 次々とプロトコル超能力ヘッダーがUDPヘッダーであるなら、UDPヘッダーにチェックサム分野をゼロに設定してください。 超能力ヘッダーの後のプロトコルがTCPヘッダーであり、TCPチェックサムが計算されるために必要としないスタックに旗を揚げさせるオプションがあれば、その旗は使用されるかもしれません。 交通機関のためにして、パケットが保全である場合にだけ、このSHOULDはそうです。保護にされる。 トンネルモードTCPチェックサムについて確かめなければなりません。 これはセクション4.2の精神への違反ではありません。チェックサムがあるので、[RFC1122]の.7は、送付者によって生成されて、受信機について確かめました。(.2 そのチェックサムはIPsecによって実行されたパケットの上の保全です)。
In addition an implementation MAY fix any contained protocols that have been broken by NAT (see [RFC3715], section 2.1, case g).
さらに、実装はNATによって破られたどんな含まれたプロトコルも修理するかもしれません([RFC3715]を見てください、セクション2.1、ケースg)。
3.2. Transport Mode ESP Encapsulation
3.2. 交通機関超能力カプセル化
BEFORE APPLYING ESP/UDP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
超能力/UDPを適用する前に---------------------------- IPv4|orig IP hdr| | | |(どんなオプションも)| TCP| データ| ----------------------------
AFTER APPLYING ESP/UDP
-------------------------------------------------------
IPv4 |orig IP hdr | UDP | ESP | | | ESP | ESP|
|(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth|
-------------------------------------------------------
|<----- encrypted ---->|
|<------ authenticated ----->|
超能力/UDPを適用した後に------------------------------------------------------- IPv4|orig IP hdr| UDP| 超能力| | | 超能力| 超能力| |(どんなオプションも)| Hdr| Hdr| TCP| データ| トレーラ|Auth| ------------------------------------------------------- | <、-、-、-、-- 暗号化されます。---->| | <、-、-、-、-、-- 認証されます。----->|
1. Ordinary ESP encapsulation procedure is used.
2. A properly formatted UDP header is inserted where shown.
3. The Total Length, Protocol, and Header Checksum (for IPv4) fields
in the IP header are edited to match the resulting IP packet.
1. 普通の超能力カプセル化手順は使用されています。 2. 適切にフォーマットされたUDPヘッダーは示されるところに挿入されます。 3. Total Length、プロトコル、およびIPヘッダーのHeader Checksum(IPv4のための)分野は、結果として起こるIPパケットを合わせるために編集されます。
3.3. Transport Mode ESP Decapsulation
3.3. 交通機関超能力被膜剥離術
1. The UDP header is removed from the packet.
2. The Total Length, Protocol, and Header Checksum (for IPv4) fields
in the new IP header are edited to match the resulting IP packet.
3. Ordinary ESP decapsulation procedure is used.
4. Transport mode decapsulation NAT procedure is used.
1. パケットからUDPヘッダーを取り除きます。 2. Total Length、プロトコル、および新しいIPヘッダーのHeader Checksum(IPv4のための)分野は、結果として起こるIPパケットを合わせるために編集されます。 3. 普通の超能力被膜剥離術手順は使用されています。 4. 交通機関被膜剥離術NAT手順は使用されています。
Huttunen, et al. Standards Track [Page 6] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[6ページ]。
3.4. Tunnel Mode ESP Encapsulation
3.4. トンネル・モード超能力カプセル化
BEFORE APPLYING ESP/UDP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
超能力/UDPを適用する前に---------------------------- IPv4|orig IP hdr| | | |(どんなオプションも)| TCP| データ| ----------------------------
AFTER APPLYING ESP/UDP
--------------------------------------------------------------
IPv4 |new h.| UDP | ESP |orig IP hdr | | | ESP | ESP|
|(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth|
--------------------------------------------------------------
|<------------ encrypted ----------->|
|<------------- authenticated ------------>|
超能力/UDPを適用した後に-------------------------------------------------------------- IPv4|新しいh.| UDP| 超能力|orig IP hdr| | | 超能力| 超能力| |(選びます)| Hdr| Hdr|(どんなオプションも)| TCP| データ| トレーラ|Auth| -------------------------------------------------------------- | <、-、-、-、-、-、-、-、-、-、-、-- 暗号化されます。----------->| | <、-、-、-、-、-、-、-、-、-、-、-、-- 認証されます。------------>|
1. Ordinary ESP encapsulation procedure is used. 2. A properly formatted UDP header is inserted where shown. 3. The Total Length, Protocol, and Header Checksum (for IPv4) fields in the new IP header are edited to match the resulting IP packet.
1. 普通の超能力カプセル化手順は使用されています。 2. 適切にフォーマットされたUDPヘッダーは示されるところに挿入されます。 3. Total Length、プロトコル、および新しいIPヘッダーのHeader Checksum(IPv4のための)分野は、結果として起こるIPパケットを合わせるために編集されます。
3.5. Tunnel Mode ESP Decapsulation
3.5. トンネル・モード超能力被膜剥離術
1. The UDP header is removed from the packet.
2. The Total Length, Protocol, and Header Checksum (for IPv4) fields
in the new IP header are edited to match the resulting IP packet.
3. Ordinary ESP decapsulation procedure is used.
4. Tunnel mode decapsulation NAT procedure is used.
1. パケットからUDPヘッダーを取り除きます。 2. Total Length、プロトコル、および新しいIPヘッダーのHeader Checksum(IPv4のための)分野は、結果として起こるIPパケットを合わせるために編集されます。 3. 普通の超能力被膜剥離術手順は使用されています。 4. トンネルモード被膜剥離術NAT手順は使用されています。
4. NAT Keepalive Procedure
4. NAT Keepalive手順
The sole purpose of sending NAT-keepalive packets is to keep NAT mappings alive for the duration of a connection between the peers (see [RFC3715], Section 2.2, case j). Reception of NAT-keepalive packets MUST NOT be used to detect whether a connection is live.
NAT-keepaliveパケットを送る唯一の目的は同輩の間の接続の持続時間のためにNATマッピングを生かす([RFC3715]を見てください、セクション2.2、ケースj)ことです。 接続が活動的であるかどうか検出するのにNAT-keepaliveパケットのレセプションを使用してはいけません。
A peer MAY send a NAT-keepalive packet if one or more phase I or phase II SAs exist between the peers, or if such an SA has existed at most N minutes earlier. N is a locally configurable parameter with a default value of 5 minutes.
同輩が1であるならNAT-keepaliveパケットを送るかもしれませんか、より多くのフェーズの私かフェーズII SAsが同輩の間に存在しているか、またはそのようなSAが高々存在したなら、Nは、より早いのを書き留めます。 Nは5分のデフォルト値がある局所的に構成可能なパラメタです。
A peer SHOULD send a NAT-keepalive packet if a need for it is detected according to [RFC3947] and if no other packet to the peer has been sent in M seconds. M is a locally configurable parameter with a default value of 20 seconds.
[RFC3947]に従ってそれの必要性を見つけて、M秒に同輩への他のパケットを全く送らないなら、A同輩SHOULDはNAT-keepaliveパケットを送ります。 Mは20秒のデフォルト値がある局所的に構成可能なパラメタです。
Huttunen, et al. Standards Track [Page 7] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[7ページ]。
5. Security Considerations
5. セキュリティ問題
5.1. Tunnel Mode Conflict
5.1. トンネル・モード闘争
Implementors are warned that it is possible for remote peers to negotiate entries that overlap in an SGW (security gateway), an issue affecting tunnel mode (see [RFC3715], section 2.1, case e).
リモート同輩がSGW(セキュリティゲートウェイ)(トンネルモード([RFC3715]を見てください、セクション2.1、ケースe)に影響する問題)に重なるエントリーを交渉するように、作成者はそれが可能であるのに注意されます。
+----+ \ /
| |-------------|----\
+----+ / \ \
Ari's NAT 1 \
Laptop \
10.1.2.3 \
+----+ \ / \ +----+ +----+
| |-------------|----------+------| |----------| |
+----+ / \ +----+ +----+
Bob's NAT 2 SGW Suzy's
Laptop Server
10.1.2.3
+----+ \ / | |-------------|----\ +----+/\\アリのNAT1円のラップトップ10.1円.2.3円+----+ \ / \ +----+ +----+ | |-------------|----------+------| |----------| | +----+ / \ +----+ +----+ ボブのNAT2SGWスージーのラップトップサーバ10.1.2.3
Because SGW will now see two possible SAs that lead to 10.1.2.3, it can become confused about where to send packets coming from Suzy's server. Implementors MUST devise ways of preventing this from occurring.
SGWがそうするので、今、10.1に通じる2可能なSAsを見てください。それはパケットをスージーのサーバからどこに来させるかに関して混乱するようになることができます。.2 .3 作成者はこれが起こるのを防ぐ方法を工夫しなければなりません。
It is RECOMMENDED that SGW either assign locally unique IP addresses to Ari's and Bob's laptop (by using a protocol such as DHCP over IPsec) or use NAT to change Ari's and Bob's laptop source IP addresses to these locally unique addresses before sending packets forward to Suzy's server. This covers the "Scaling" criteria of section 3 in [RFC3715].
SGWが局所的に、アリのものへの固有のIPアドレスとボブのラップトップ(IPsecの上のDHCPなどのプロトコルを使用するのによる)を割り当てるか、またはスージーのサーバにパケットを考慮させるために送る前にソースIPがこれらの局所的にユニークなアドレスに扱うアリとボブのラップトップを変えるのにNATを使用するのが、RECOMMENDEDです。これは[RFC3715]のセクション3の「スケーリング」評価基準をカバーしています。
Please see Appendix A.
Appendix Aを見てください。
Huttunen, et al. Standards Track [Page 8] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[8ページ]。
5.2. Transport Mode Conflict
5.2. 交通機関闘争
Another similar issue may occur in transport mode, with 2 clients, Ari and Bob, behind the same NAT talking securely to the same server (see [RFC3715], Section 2.1, case e).
別の同様の問題は交通機関で起こるかもしれません、2人のクライアント、アリ、およびボブと共に、しっかりと同じサーバと話す同じNATの後ろで([RFC3715]を見てください、セクション2.1、ケースe)。
Cliff wants to talk in the clear to the same server.
クリフは同じサーバへの明確で話したがっています。
+----+
| |
+----+ \
Ari's \
Laptop \
10.1.2.3 \
+----+ \ / +----+
| |-----+-----------------| |
+----+ / \ +----+
Bob's NAT Server
Laptop /
10.1.2.4 /
/
+----+ /
| |/
+----+
Cliff's
Laptop
10.1.2.5
+----+ | | +----+ \アリのラップトップ10.1円の.2.3円\+----+ \ / +----+ | |-----+-----------------| | +----+ / \ +----+ ボブのNATサーバラップトップ/10.1.2.4//+----+ / | |/ +----+ クリフのラップトップ10.1.2、.5
Now, transport SAs on the server will look like this:
現在、サーバの輸送SAsはこれに似るでしょう:
To Ari: Server to NAT, <traffic desc1>, UDP encap <4500, Y>
アリに: NAT、<トラフィックdesc1>、UDP encap<4500、Y>へのサーバ
To Bob: Server to NAT, <traffic desc2>, UDP encap <4500, Z>
ボブに: NAT、<トラフィックdesc2>、UDP encap<4500、Z>へのサーバ
Cliff's traffic is in the clear, so there is no SA.
クリフのトラフィックが明確にあるので、SAが全くありません。
<traffic desc> is the protocol and port information. The UDP encap ports are the ports used in UDP-encapsulated ESP format of section 2.1. Y,Z are the dynamic ports assigned by the NAT during the IKE negotiation. So IKE traffic from Ari's laptop goes out on UDP <4500,4500>. It reaches the server as UDP <Y,4500>, where Y is the dynamically assigned port.
<トラフィックdesc>はプロトコルとポート情報です。 UDP encapポートはセクション2.1のUDPによってカプセル化された超能力形式に使用されるポートです。 Y、ZはIKE交渉の間にNATによって割り当てられたダイナミックなポートです。 それで、アリのラップトップからのIKEトラフィックはUDP<4500、4500>で出かけます。 それはUDP<Y、4500>としてサーバに達します。そこでは、Yがダイナミックに割り当てられたポートです。
If the <traffic desc1> overlaps <traffic desc2>, then simple filter lookups may not be sufficient to determine which SA has to be used to send traffic. Implementations MUST handle this situation, either by disallowing conflicting connections, or by other means.
<トラフィックdesc1>が<トラフィックdesc2>を重ね合わせるなら、当時の簡単なフィルタルックアップは、どのSAがトラフィックを送るのに使用されなければならないかを決定するために十分でないかもしれません。 実装は闘争接続を禁じるか、または他の手段でこの状況を扱わなければなりません。
Huttunen, et al. Standards Track [Page 9] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[9ページ]。
Assume now that Cliff wants to connect to the server in the clear. This is going to be difficult to configure, as the server already has a policy (from Server to the NAT's external address) for securing <traffic desc>. For totally non-overlapping traffic descriptions, this is possible.
今、クリフが明確でサーバに接続したがっていると仮定してください。 構成するのはこれが難しくなるでしょう、サーバに方針が<トラフィックがdesc>であると機密保護するために既にあるとき(ServerからNATの外部アドレスまで)。 非重なっている完全にトラフィック記述において、これは可能です。
Sample server policy could be as follows:
サンプルサーバ方針は以下の通りであるかもしれません:
To Ari: Server to NAT, All UDP, secure
アリに: All UDPの、そして、安全なNATへのサーバ
To Bob: Server to NAT, All TCP, secure
ボブに: All TCPの、そして、安全なNATへのサーバ
To Cliff: Server to NAT, ALL ICMP, clear text
クリフに: NATへのサーバ、ALL ICMPはテキストをクリアします。
Note that this policy also lets Ari and Bob send cleartext ICMP to the server.
また、アリとボブがこの方針でcleartext ICMPをサーバに送ることができることに注意してください。
The server sees all clients behind the NAT as the same IP address, so setting up different policies for the same traffic descriptor is in principle impossible.
サーバが、NATの後ろですべてのクライアントを同じIPアドレスと考えるので、同じトラフィック記述子のために異なった方針をセットアップするのは原則として不可能です。
A problematic example of configuration on the server is as follows:
サーバでの構成の問題の多い例は以下の通りです:
Server to NAT, TCP, secure (for Ari and Bob)
TCPの、そして、安全なNATへのサーバ(アリとボブのための)
Server to NAT, TCP, clear (for Cliff)
NATへのサーバ、TCPはクリアします。(クリフのための)
The server cannot enforce his policy, as it is possible that misbehaving Bob sends traffic in the clear. This is indistinguishable from when Cliff sends traffic in the clear. So it is impossible to guarantee security from some clients behind a NAT, while allowing clear text from different clients behind the SAME NAT. If the server's security policy allows this, however, it can do best-effort security: If the client from behind the NAT initiates security, his connection will be secured. If he sends in the clear, the server will still accept that clear text.
ふらちな事をしているボブが明確でトラフィックを送るのが、可能であるときに、サーバは彼の方針を実施できません。 これはクリフが明確でトラフィックを送る時から区別がつきません。 それで、NATの後ろで何人かのクライアントから安全を保障するのはSAME NATの後ろの異なったクライアントからのクリアテキストを許容している間、不可能です。 しかしながら、サーバの安全保障政策がこれを許容するなら、ベストエフォート型セキュリティができます: NATの後ろからのクライアントがセキュリティを開始すると、彼の接続を保証するでしょう。 彼が明確を送ると、それでも、サーバはそのクリアテキストを受け入れるでしょう。
For security guarantees, the above problematic scenario MUST NOT be allowed on servers. For best effort security, this scenario MAY be used.
セキュリティ保証のために、サーバに上の問題の多いシナリオを許容してはいけません。 ベストエフォート型セキュリティのために、このシナリオは使用されるかもしれません。
Please see Appendix A.
Appendix Aを見てください。
6. IAB Considerations
6. IAB問題
The UNSAF [RFC3424] questions are addressed by the IPsec-NAT compatibility requirements document [RFC3715].
IPsec-NAT互換性要件ドキュメント[RFC3715]によってUNSAF[RFC3424]質問は扱われます。
Huttunen, et al. Standards Track [Page 10] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[10ページ]。
7. Acknowledgments
7. 承認
Thanks to Tero Kivinen and William Dixon, who contributed actively to this document.
Tero Kivinenとウィリアム・ディクソンをありがとうございます。(ディクソンは、活発にこのドキュメントに貢献しました)。
Thanks to Joern Sierwald, Tamir Zegman, Tatu Ylonen, and Santeri Paavolainen, who contributed to the early documents about NAT traversal.
NAT縦断に関する早めのドキュメントに貢献したJoern Sierwald、タミールZegman、Tatu Ylonen、およびSanteri Paavolainenのおかげで。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[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月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC3947] Kivinen, T., "Negotiation of NAT-Traversal in the IKE",
RFC 3947, January 2005.
[RFC3947] Kivinen、T.、「IKEでのNAT縦断の交渉」、RFC3947、2005年1月。
8.2. Informative References
8.2. 有益な参照
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,
"Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3193] パテルとB.とAbobaとB.とディクソンとW.とゾルン、G.とS.ブース、「IPsecを使用することでL2TPを固定します」、RFC3193、2001年11月。
[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月。
[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月。
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
Work in Progress, October 2004.
[IKEv2] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」が進歩、2004年10月に働いています。
Huttunen, et al. Standards Track [Page 11] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[11ページ]。
Appendix A. Clarification of Potential NAT Multiple Client Solutions
NATの潜在的倍数クライアントソリューションの付録A.明確化
This appendix provides clarification about potential solutions to the problem of multiple clients behind the same NAT simultaneously connecting to the same destination IP address.
この付録は、同時に同じ送付先IPアドレスに接続しながら、同じNATの後ろで潜在的ソリューションに関して複数のクライアントの問題に明確化を提供します。
Sections 5.1 and 5.2 say that you MUST avoid this problem. As this is not a matter of wire protocol, but a matter local implementation, the mechanisms do not belong in the protocol specification itself. They are instead listed in this appendix.
セクション5.1と5.2は、あなたがこの問題を避けなければならないと言います。 これがワイヤプロトコルの問題ではなく、件の地方の実装であるので、プロトコル仕様自体にはメカニズムがありません。 それらは代わりにこの付録に記載されています。
Choosing an option will likely depend on the scenarios for which one uses/supports IPsec NAT-T. This list is not meant to be exhaustive, so other solutions may exist. We first describe the generic choices that solve the problem for all upper-layer protocols.
オプションを選ぶのはおそらく1つがIPsec NAT Tを使用するか、または支持するシナリオによるでしょう。 このリストが徹底的であることが意味されないので、他の解決策は存在するかもしれません。 私たちは最初に、すべての上側の層のプロトコルのために問題を解決する一般的な選択について説明します。
Generic choices for ESP transport mode:
超能力のための一般的な選択はモードを輸送します:
Tr1) Implement a built-in NAT (network address translation) above IPsec decapsulation.
Tr1) IPsec被膜剥離術を超えて内蔵のNAT(ネットワークアドレス変換)を実行してください。
Tr2) Implement a built-in NAPT (network address port translation) above IPsec decapsulation.
Tr2) IPsec被膜剥離術を超えて内蔵のNAPT(ナプト)を実行してください。
Tr3) An initiator may decide not to request transport mode once NAT is detected and may instead request a tunnel-mode SA. This may be a retry after transport mode is denied by the responder, or the initiator may choose to propose a tunnel SA initially. This is no more difficult than knowing whether to propose transport mode or tunnel mode without NAT. If for some reason the responder prefers or requires tunnel mode for NAT traversal, it must reject the quick mode SA proposal for transport mode.
Tr3) 創始者は、NATがいったん検出されると交通機関を要求しないと決めて、代わりにトンネルモードSAを要求するかもしれません。 交通機関が応答者によって否定された後にこれは再試行であるかもしれませんか創始者が、初めはトンネルSAを提案するのを選ぶかもしれません。 NATなしで交通機関かトンネルモードを提案するかどうかを知っているほどこれは難しくはありません。 ある理由で応答者がNAT縦断のためのトンネルモードを好むか、または必要とするなら、それは交通機関のための迅速なモードSA提案を拒絶しなければなりません。
Generic choices for ESP tunnel mode:
超能力のための一般的な選択はモードにトンネルを堀ります:
Tn1) Same as Tr1.
Tn1) Tr1と同じです。
Tn2) Same as Tr2.
Tn2) Tr2と同じです。
Tn3) This option is possible if an initiator can be assigned an address through its tunnel SA, with the responder using DHCP. The initiator may initially request an internal address via the DHCP-IPsec method, regardless of whether it knows it is behind a NAT. It may re-initiate an IKE quick mode negotiation for DHCP tunnel SA after the responder fails the quick mode SA transport mode proposal. This happens either when a NAT-OA payload is sent or because it
Tn3) トンネルSAを通してアドレスを創始者に割り当てることができるなら、このオプションは可能です、応答者がDHCPを使用していて。 創始者は初めはDHCP-IPsec方法で内部のアドレスを要求するかもしれません、NATの後ろにあるのを知っているかどうかにかかわらず。 応答者が迅速なモードSA交通機関提案に失敗した後にそれはDHCPトンネルSAのためにIKEの迅速なモード交渉を再開始するかもしれません。 または、NAT-OAペイロードを送るとき、これが起こる、それ
Huttunen, et al. Standards Track [Page 12] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[12ページ]。
discovers from NAT-D that the initiator is behind a NAT and its local configuration/policy will only accept a NAT connection when being assigned an address through DHCP-IPsec.
NAT Dから、創始者がNATの後ろにいて、アドレスがDHCP-IPsecを通して割り当てられるときだけローカルの構成/方針がNAT接続を受け入れると発見します。
There are also implementation choices that offer limited interoperability. Implementors should specify which applications or protocols should work if these options are selected. Note that neither Tr4 nor Tn4, as described below, are expected to work with TCP traffic.
また、限られた相互運用性を提供する実現選択があります。 作成者は、これらのオプションが選択されるならどのアプリケーションかプロトコルが働くべきであるかを指定するべきです。 以下で説明されないTr4もTn4もTCP交通で働くと予想されることに注意してください。
Limited interoperability choices for ESP transport mode:
超能力のための株式会社相互運用性選択はモードを輸送します:
Tr4) Implement upper-layer protocol awareness of the inbound and outbound IPsec SA so that it doesn't use the source IP and the source port as the session identifier (e.g., an L2TP session ID mapped to the IPsec SA pair that doesn't use the UDP source port or the source IP address for peer uniqueness).
Tr4) セッション識別子(例えばIDが同輩のユニークさにUDPソース港かソースIPアドレスを使用しないIPsec SA組に写像したL2TPセッション)としてソースIPとソース港を使用しないように、本国行きの、そして、外国行きのIPsec SAの上側の層のプロトコル認識を実行してください。
Tr5) Implement application integration with IKE initiation so that it can rebind to a different source port if the IKE quick mode SA proposal is rejected by the responder; then it can repropose the new QM selector.
Tr5) IKEの迅速なモードSA提案が応答者によって拒絶されるなら異なったソースにポートを縛り直すことができるように、IKE開始と共にアプリケーション統合を実行してください。 そして、それは新しいQMセレクタを再提案できます。
Limited interoperability choices for ESP tunnel mode:
超能力のための株式会社相互運用性選択はモードにトンネルを堀ります:
Tn4) Same as Tr4.
Tn4) Tr4と同じです。
Huttunen, et al. Standards Track [Page 13] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[13ページ]。
Authors' Addresses
作者のアドレス
Ari Huttunen F-Secure Corporation Tammasaarenkatu 7 HELSINKI FIN-00181 FI
アリのHuttunenのF安全な社のTammasaarenkatu7ヘルシンキフィン-00181FI
EMail: Ari.Huttunen@F-Secure.com
メール: Ari.Huttunen@F-Secure.com
Brian Swander Microsoft One Microsoft Way Redmond, WA 98052 US
ブライアンSwanderマイクロソフト1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: briansw@microsoft.com
メール: briansw@microsoft.com
Victor Volpe Cisco Systems 124 Grove Street Suite 205 Franklin, MA 02038 US
ビクタボルペシスコシステムズ124木立通りSuite205MA02038フランクリン(米国)
EMail: vvolpe@cisco.com
メール: vvolpe@cisco.com
Larry DiBurro Nortel Networks 80 Central Street Boxborough, MA 01719 US
ラリーDiBurroノーテルは米国で80セントラル・ストリートBoxborough、MA 01719をネットワークでつなぎます。
EMail: ldiburro@nortelnetworks.com
メール: ldiburro@nortelnetworks.com
Markus Stenberg FI
マーカスStenberg FI
EMail: markus.stenberg@iki.fi
メール: markus.stenberg@iki.fi
Huttunen, et al. Standards Track [Page 14] RFC 3948 UDP Encapsulation of IPsec ESP Packets January 2005
Huttunen、他 規格は超能力パケット2005年1月にIPsecのRFC3948UDPカプセル化を追跡します[14ページ]。
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機能のための基金は現在、インターネット協会によって提供されます。
Huttunen, et al. Standards Track [Page 15]
Huttunen、他 標準化過程[15ページ]
一覧
スポンサーリンク
