[要約] RFC 8229は、IKEとIPsecパケットのTCPカプセル化に関する仕様です。その目的は、IKEおよびIPsecトラフィックをTCPプロトコルを使用して送信するための標準化とガイドラインを提供することです。
Internet Engineering Task Force (IETF) T. Pauly
Request for Comments: 8229 Apple Inc.
Category: Standards Track S. Touati
ISSN: 2070-1721 Ericsson
R. Mantha
Cisco Systems
August 2017
TCP Encapsulation of IKE and IPsec Packets
IKEおよびIPsecパケットのTCPカプセル化
Abstract
概要
This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP.
このドキュメントでは、UDPを介したIKEネゴシエーションをブロックする可能性のあるネットワークミドルボックスを通過するために、TCP接続を介してインターネットキー交換プロトコル（IKE）およびIPsecパケットを転送する方法について説明します。この方法は「TCPカプセル化」と呼ばれ、TCP接続を介してセキュリティアソシエーションの確立用のIKEパケットとカプセル化セキュリティペイロード（ESP）パケットの両方を送信します。この方法は、UDPを介してIKEをネゴシエートできない場合のフォールバックオプションとして使用することを目的としています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8229.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8229で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Prior Work and Motivation ..................................4
1.2. Terminology and Notation ...................................5
2. Configuration ...................................................5
3. TCP-Encapsulated Header Formats .................................6
3.1. TCP-Encapsulated IKE Header Format .........................6
3.2. TCP-Encapsulated ESP Header Format .........................7
4. TCP-Encapsulated Stream Prefix ..................................7
5. Applicability ...................................................8
5.1. Recommended Fallback from UDP ..............................8
6. Connection Establishment and Teardown ...........................9
7. Interaction with NAT Detection Payloads ........................11
8. Using MOBIKE with TCP Encapsulation ............................11
9. Using IKE Message Fragmentation with TCP Encapsulation .........12
10. Considerations for Keep-Alives and Dead Peer Detection ........12
11. Middlebox Considerations ......................................12
12. Performance Considerations ....................................13
12.1. TCP-in-TCP ...............................................13
12.2. Added Reliability for Unreliable Protocols ...............14
12.3. Quality-of-Service Markings ..............................14
12.4. Maximum Segment Size .....................................14
12.5. Tunneling ECN in TCP .....................................14
13. Security Considerations .......................................15
14. IANA Considerations ...........................................16
15. References ....................................................16
15.1. Normative References .....................................16
15.2. Informative References ...................................17
Appendix A. Using TCP Encapsulation with TLS ......................18
Appendix B. Example Exchanges of TCP Encapsulation with TLS .......19
B.1. Establishing an IKE Session ................................19
B.2. Deleting an IKE Session ....................................21
B.3. Re-establishing an IKE Session .............................22
B.4. Using MOBIKE between UDP and TCP Encapsulation .............23
Acknowledgments ...................................................25
Authors' Addresses ................................................25
The Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] is a protocol for establishing IPsec Security Associations (SAs), using IKE messages over UDP for control traffic, and using Encapsulating Security Payload (ESP) [RFC4303] messages for encrypted data traffic. Many network middleboxes that filter traffic on public hotspots block all UDP traffic, including IKE and IPsec, but allow TCP connections through because they appear to be web traffic. Devices on these networks that need to use IPsec (to access private enterprise networks, to route Voice over IP calls to carrier networks, or because of security policies) are unable to establish IPsec SAs. This document defines a method for encapsulating IKE control messages as well as IPsec data messages within a TCP connection.
インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）[RFC7296]は、IPsecセキュリティアソシエーション（SA）を確立し、UDPを介して制御トラフィックにIKEメッセージを使用し、暗号化データトラフィックにカプセル化セキュリティペイロード（ESP）[RFC4303]メッセージを使用するためのプロトコルです。 。パブリックホットスポットでトラフィックをフィルタリングする多くのネットワークミドルボックスは、IKEやIPsecを含むすべてのUDPトラフィックをブロックしますが、TCP接続はWebトラフィックのように見えるため許可します。 IPsecを使用する必要があるこれらのネットワーク上のデバイス（プライベートエンタープライズネットワークにアクセスする、Voice over IP通話をキャリアネットワークにルーティングする、またはセキュリティポリシーのため）は、IPsec SAを確立できません。このドキュメントでは、TCP接続内でIKE制御メッセージとIPsecデータメッセージをカプセル化する方法を定義します。
Using TCP as a transport for IPsec packets adds a third option to the list of traditional IPsec transports:
IPsecパケットのトランスポートとしてTCPを使用すると、従来のIPsecトランスポートのリストに3番目のオプションが追加されます。
1. Direct. Currently, IKE negotiations begin over UDP port 500. If no Network Address Translation (NAT) device is detected between the Initiator and the Responder, then subsequent IKE packets are sent over UDP port 500, and IPsec data packets are sent using ESP.
1. 直接。現在、IKEネゴシエーションはUDPポート500で開始されます。イニシエーターとレスポンダーの間でネットワークアドレス変換（NAT）デバイスが検出されない場合、後続のIKEパケットはUDPポート500で送信され、IPsecデータパケットはESPを使用して送信されます。
2. UDP Encapsulation [RFC3948]. If a NAT is detected between the Initiator and the Responder, then subsequent IKE packets are sent over UDP port 4500 with four bytes of zero at the start of the UDP payload, and ESP packets are sent out over UDP port 4500. Some peers default to using UDP encapsulation even when no NAT is detected on the path, as some middleboxes do not support IP protocols other than TCP and UDP.
2. UDPカプセル化[RFC3948]。イニシエーターとレスポンダーの間でNATが検出された場合、後続のIKEパケットはUDPペイロードの先頭に4バイトのゼロが付いたUDPポート4500を介して送信され、ESPパケットはUDPポート4500を介して送信されます。一部のミドルボックスはTCPおよびUDP以外のIPプロトコルをサポートしていないため、パスでNATが検出されない場合でもUDPカプセル化を使用します。
3. TCP Encapsulation. If the other two methods are not available or appropriate, IKE negotiation packets as well as ESP packets can be sent over a single TCP connection to the peer.
3. TCPカプセル化。他の2つの方法が利用できないか適切でない場合、IKEネゴシエーションパケットとESPパケットを単一のTCP接続を介してピアに送信できます。
Direct use of ESP or UDP encapsulation should be preferred by IKE implementations due to performance concerns when using TCP encapsulation (Section 12). Most implementations should use TCP encapsulation only on networks where negotiation over UDP has been attempted without receiving responses from the peer or if a network is known to not support UDP.
ESPまたはUDPカプセル化を直接使用することは、TCPカプセル化を使用するときのパフォーマンスの問題のために（セクション12）、IKE実装で推奨されます。ほとんどの実装では、ピアからの応答を受信せずにUDPを介したネゴシエーションが試行されたネットワーク、またはネットワークがUDPをサポートしていないことがわかっている場合にのみ、TCPカプセル化を使用する必要があります。
Encapsulating IKE connections within TCP streams is a common approach to solve the problem of UDP packets being blocked by network middleboxes. The specific goals of this document are as follows:
TCPストリーム内にIKE接続をカプセル化することは、ネットワークミドルボックスによってブロックされるUDPパケットの問題を解決するための一般的なアプローチです。このドキュメントの具体的な目標は次のとおりです。
o To promote interoperability by defining a standard method of framing IKE and ESP messages within TCP streams.
o TCPストリーム内でIKEおよびESPメッセージをフレーミングする標準的な方法を定義することにより、相互運用性を促進します。
o To be compatible with the current IKEv2 standard without requiring modifications or extensions.
o 変更や拡張を必要とせずに、現在のIKEv2標準と互換性がある。
o To use IKE over UDP by default to avoid the overhead of other alternatives that always rely on TCP or Transport Layer Security (TLS) [RFC5246].
o IKE over UDPをデフォルトで使用して、常にTCPまたはトランスポート層セキュリティ（TLS）[RFC5246]に依存する他の選択肢のオーバーヘッドを回避する。
Some previous alternatives include:
以前の代替案には次のものがあります。
Cellular Network Access Interworking Wireless LAN (IWLAN) uses IKEv2 to create secure connections to cellular carrier networks for making voice calls and accessing other network services over Wi-Fi networks. 3GPP has recommended that IKEv2 and ESP packets be sent within a TLS connection to be able to establish connections on restrictive networks.
セルラーネットワークアクセスインターワーキングワイヤレスLAN（IWLAN）は、IKEv2を使用してセルラーキャリアネットワークへの安全な接続を作成し、音声通話を行ったり、Wi-Fiネットワーク経由で他のネットワークサービスにアクセスしたりします。 3GPPは、IKEv2およびESPパケットをTLS接続内で送信して、制限的なネットワークで接続を確立できるようにすることを推奨しています。
ISAKMP over TCP Various non-standard extensions to the Internet Security Association and Key Management Protocol (ISAKMP) have been deployed that send IPsec traffic over TCP or TCP-like packets.
ISAKMP over TCPインターネットセキュリティアソシエーションおよびキー管理プロトコル（ISAKMP）に対するさまざまな非標準の拡張機能が展開され、TCPまたはTCPのようなパケットを介してIPsecトラフィックを送信します。
Secure Sockets Layer (SSL) VPNs Many proprietary VPN solutions use a combination of TLS and IPsec in order to provide reliability. These often run on TCP port 443.
Secure Sockets Layer（SSL）VPN多くの独自仕様のVPNソリューションは、信頼性を提供するためにTLSとIPsecの組み合わせを使用しています。これらは多くの場合、TCPポート443で実行されます。
IKEv2 over TCP IKEv2 over TCP as described in [IKE-over-TCP] is used to avoid UDP fragmentation.
[IKE-over-TCP]で説明されているIKEv2 over TCP IKEv2 over TCPは、UDPフラグメンテーションを回避するために使用されます。
This document distinguishes between the IKE peer that initiates TCP connections to be used for TCP encapsulation and the roles of Initiator and Responder for particular IKE messages. During the course of IKE exchanges, the role of IKE Initiator and Responder may swap for a given SA (as with IKE SA rekeys), while the Initiator of the TCP connection is still responsible for tearing down the TCP connection and re-establishing it if necessary. For this reason, this document will use the term "TCP Originator" to indicate the IKE peer that initiates TCP connections. The peer that receives TCP connections will be referred to as the "TCP Responder". If an IKE SA is rekeyed one or more times, the TCP Originator MUST remain the peer that originally initiated the first IKE SA.
このドキュメントでは、TCPカプセル化に使用されるTCP接続を開始するIKEピアと、特定のIKEメッセージに対するイニシエーターおよびレスポンダーの役割を区別しています。 IKE交換の過程で、IKEイニシエーターとレスポンダーの役割が特定のSAにスワップする場合があります（IKE SAキー再生成の場合と同様）。一方、TCP接続のイニシエーターは、TCP接続を切断して再確立する責任があります。必要。このため、このドキュメントでは「TCP発信元」という用語を使用して、TCP接続を開始するIKEピアを示します。 TCP接続を受信するピアは、「TCPレスポンダ」と呼ばれます。 IKE SAが1回以上キーが再生成される場合、TCP発信者は最初のIKE SAを最初に開始したピアのままである必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
One of the main reasons to use TCP encapsulation is that UDP traffic may be entirely blocked on a network. Because of this, support for TCP encapsulation is not specifically negotiated in the IKE exchange. Instead, support for TCP encapsulation must be pre-configured on both the TCP Originator and the TCP Responder.
TCPカプセル化を使用する主な理由の1つは、ネットワーク上でUDPトラフィックが完全にブロックされる可能性があることです。このため、TCPカプセル化のサポートは、IKE交換では特にネゴシエートされません。代わりに、TCPカプセル化のサポートは、TCP発信者とTCPレスポンダの両方で事前設定する必要があります。
Implementations MUST support TCP encapsulation on TCP port 4500, which is reserved for IPsec NAT traversal.
実装では、IPsec NATトラバーサル用に予約されているTCPポート4500でのTCPカプセル化をサポートする必要があります。
Beyond a flag indicating support for TCP encapsulation, the configuration for each peer can include the following optional parameters:
TCPカプセル化のサポートを示すフラグの他に、各ピアの設定には、次のオプションパラメータを含めることができます。
o Alternate TCP ports on which the specific TCP Responder listens for incoming connections. Note that the TCP Originator may initiate TCP connections to the TCP Responder from any local port.
o 特定のTCPレスポンダが着信接続をリッスンする代替TCPポート。 TCP Originatorは、任意のローカルポートからTCP ResponderへのTCP接続を開始する場合があることに注意してください。
o An extra framing protocol to use on top of TCP to further encapsulate the stream of IKE and IPsec packets. See Appendix A for a detailed discussion.
o TCPの上で使用する追加のフレーミングプロトコル。IKEおよびIPsecパケットのストリームをさらにカプセル化します。詳細については、付録Aを参照してください。
Since TCP encapsulation of IKE and IPsec packets adds overhead and has potential performance trade-offs compared to direct or UDP-encapsulated SAs (as described in Section 12), implementations SHOULD prefer ESP direct or UDP-encapsulated SAs over TCP-encapsulated SAs when possible.
IKEおよびIPsecパケットのTCPカプセル化はオーバーヘッドを追加し、直接またはUDPカプセル化SA（セクション12で説明）と比較して潜在的なパフォーマンストレードオフがあるため、実装は、可能な場合、TCPカプセル化SAよりもESP直接またはUDPカプセル化SAを優先する必要があります。 。
Like UDP encapsulation, TCP encapsulation uses the first four bytes of a message to differentiate IKE and ESP messages. TCP encapsulation also adds a Length field to define the boundaries of messages within a stream. The message length is sent in a 16-bit field that precedes every message. If the first 32 bits of the message are zeros (a non-ESP marker), then the contents comprise an IKE message. Otherwise, the contents comprise an ESP message. Authentication Header (AH) messages are not supported for TCP encapsulation.
UDPカプセル化と同様に、TCPカプセル化もメッセージの最初の4バイトを使用して、IKEメッセージとESPメッセージを区別します。 TCPカプセル化では、ストリーム内のメッセージの境界を定義するためのLengthフィールドも追加されます。メッセージの長さは、すべてのメッセージの前にある16ビットのフィールドで送信されます。メッセージの最初の32ビットがゼロ（非ESPマーカー）の場合、内容はIKEメッセージを構成します。それ以外の場合、コンテンツにはESPメッセージが含まれます。認証ヘッダー（AH）メッセージは、TCPカプセル化ではサポートされていません。
Although a TCP stream may be able to send very long messages, implementations SHOULD limit message lengths to typical UDP datagram ESP payload lengths. The maximum message length is used as the effective MTU for connections that are being encrypted using ESP, so the maximum message length will influence characteristics of inner connections, such as the TCP Maximum Segment Size (MSS).
TCPストリームは非常に長いメッセージを送信できる可能性がありますが、実装では、メッセージの長さを一般的なUDPデータグラムのESPペイロードの長さに制限する必要があります（SHOULD）。最大メッセージ長は、ESPを使用して暗号化されている接続の有効なMTUとして使用されるため、最大メッセージ長は、TCP最大セグメントサイズ（MSS）などの内部接続の特性に影響します。
Note that this method of encapsulation will also work for placing IKE and ESP messages within any protocol that presents a stream abstraction, beyond TCP.
このカプセル化方式は、TCPを超えてストリームの抽象化を提供する任意のプロトコル内にIKEおよびESPメッセージを配置する場合にも機能することに注意してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Non-ESP Marker |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IKE header [RFC7296] ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
図1
The IKE header is preceded by a 16-bit Length field in network byte order that specifies the length of the IKE message (including the non-ESP marker) within the TCP stream. As with IKE over UDP port 4500, a zeroed 32-bit non-ESP marker is inserted before the start of the IKE header in order to differentiate the traffic from ESP traffic between the same addresses and ports.
IKEヘッダーの前には、TCPバイトストリーム内のIKEメッセージ（非ESPマーカーを含む）の長さを指定するネットワークバイトオーダーの16ビットの長さフィールドがあります。 IKE over UDPポート4500と同様に、トラフィックを同じアドレスとポートの間のESPトラフィックと区別するために、IKEヘッダーの開始前にゼロ化された32ビットの非ESPマーカーが挿入されます。
o Length (2 octets, unsigned integer) - Length of the IKE packet, including the Length field and non-ESP marker.
o 長さ（2オクテット、符号なし整数）-長さフィールドと非ESPマーカーを含む、IKEパケットの長さ。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ESP header [RFC4303] ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
図2
The ESP header is preceded by a 16-bit Length field in network byte order that specifies the length of the ESP packet within the TCP stream.
ESPヘッダーの前には、TCPバイトストリーム内のESPパケットの長さを指定するネットワークバイトオーダーの16ビットの長さフィールドがあります。
The Security Parameter Index (SPI) field [RFC7296] in the ESP header MUST NOT be a zero value.
ESPヘッダーのセキュリティパラメータインデックス（SPI）フィールド[RFC7296]はゼロ値であってはなりません。
o Length (2 octets, unsigned integer) - Length of the ESP packet, including the Length field.
o 長さ（2オクテット、符号なし整数）-長さフィールドを含む、ESPパケットの長さ。
Each stream of bytes used for IKE and IPsec encapsulation MUST begin with a fixed sequence of six bytes as a magic value, containing the characters "IKETCP" as ASCII values. This value is intended to identify and validate that the TCP connection is being used for TCP encapsulation as defined in this document, to avoid conflicts with the prevalence of previous non-standard protocols that used TCP port 4500. This value is only sent once, by the TCP Originator only, at the beginning of any stream of IKE and ESP messages.
IKEおよびIPsecカプセル化に使用される各バイトストリームは、マジック値として6バイトの固定シーケンスで始まり、ASCII値として「IKETCP」という文字が含まれている必要があります。この値は、このドキュメントで定義されているように、TCP接続がTCPカプセル化に使用されていることを識別および検証して、TCPポート4500を使用していた以前の非標準プロトコルの普及との競合を回避することを目的としています。この値は、 TCP発信者のみ、IKEおよびESPメッセージのストリームの最初。
If other framing protocols are used within TCP to further encapsulate or encrypt the stream of IKE and ESP messages, the stream prefix must be at the start of the TCP Originator's IKE and ESP message stream within the added protocol layer (Appendix A). Although some framing protocols do support negotiating inner protocols, the stream prefix should always be used in order for implementations to be as generic as possible and not rely on other framing protocols on top of TCP.
TCP内で他のフレーミングプロトコルを使用してIKEおよびESPメッセージのストリームをさらにカプセル化または暗号化する場合、ストリームプレフィックスは、追加されたプロトコルレイヤー内のTCP発信者のIKEおよびESPメッセージストリームの先頭にある必要があります（付録A）。一部のフレーミングプロトコルは内部プロトコルのネゴシエーションをサポートしていますが、実装を可能な限り汎用的にし、TCP上の他のフレーミングプロトコルに依存しないように、ストリームプレフィックスを常に使用する必要があります。
0 1 2 3 4 5
+------+------+------+------+------+------+
| 0x49 | 0x4b | 0x45 | 0x54 | 0x43 | 0x50 |
+------+------+------+------+------+------+
Figure 3
図3
TCP encapsulation is applicable only when it has been configured to be used with specific IKE peers. If a Responder is configured to use TCP encapsulation, it MUST listen on the configured port(s) in case any peers will initiate new IKE sessions. Initiators MAY use TCP encapsulation for any IKE session to a peer that is configured to support TCP encapsulation, although it is recommended that Initiators should only use TCP encapsulation when traffic over UDP is blocked.
TCPカプセル化は、特定のIKEピアで使用するように構成されている場合にのみ適用できます。レスポンダがTCPカプセル化を使用するように構成されている場合、ピアが新しいIKEセッションを開始する場合に備えて、構成されたポートでリッスンする必要があります。イニシエーターは、TCPカプセル化をサポートするように構成されたピアへのすべてのIKEセッションにTCPカプセル化を使用できます（ただし、UDP上のトラフィックがブロックされている場合にのみイニシエーターがTCPカプセル化を使用することをお勧めします）。
Since the support of TCP encapsulation is a configured property, not a negotiated one, it is recommended that if there are multiple IKE endpoints representing a single peer (such as multiple machines with different IP addresses when connecting by Fully Qualified Domain Name, or endpoints used with IKE redirection), all of the endpoints equally support TCP encapsulation.
TCPカプセル化のサポートは構成されたプロパティであり、ネゴシエートされたプロパティではないため、単一のピアを表す複数のIKEエンドポイント（完全修飾ドメイン名で接続するときに異なるIPアドレスを持つ複数のマシン、または使用されるエンドポイントなど）がある場合に推奨されますIKEリダイレクションの場合）、すべてのエンドポイントがTCPカプセル化を等しくサポートします。
If TCP encapsulation is being used for a specific IKE SA, all messages for that IKE SA and its Child SAs MUST be sent over a TCP connection until the SA is deleted or IKEv2 Mobility and Multihoming (MOBIKE) is used to change the SA endpoints and/or the encapsulation protocol. See Section 8 for more details on using MOBIKE to transition between encapsulation modes.
TCPカプセル化が特定のIKE SAに使用されている場合、SAが削除されるか、IKEv2モビリティとマルチホーミング（MOBIKE）を使用してSAエンドポイントを変更するまで、そのIKE SAとその子SAのすべてのメッセージをTCP接続経由で送信する必要があります。 /またはカプセル化プロトコル。 MOBIKEを使用してカプセル化モードを切り替える詳細については、セクション8を参照してください。
Since UDP is the preferred method of transport for IKE messages, implementations that use TCP encapsulation should have an algorithm for deciding when to use TCP after determining that UDP is unusable. If an Initiator implementation has no prior knowledge about the network it is on and the status of UDP on that network, it SHOULD always attempt to negotiate IKE over UDP first. IKEv2 defines how to use retransmission timers with IKE messages and, specifically, IKE_SA_INIT messages [RFC7296]. Generally, this means that the implementation will define a frequency of retransmission and the maximum number of retransmissions allowed before marking the IKE SA as failed. An implementation can attempt negotiation over TCP once it has hit the maximum retransmissions over UDP, or slightly before to reduce connection setup delays. It is recommended that the initial message over UDP be retransmitted at least once before falling back to TCP, unless the Initiator knows beforehand that the network is likely to block UDP.
UDPはIKEメッセージのトランスポートの優先メソッドであるため、TCPカプセル化を使用する実装には、UDPが使用不可であると判断した後でTCPをいつ使用するかを決定するアルゴリズムが必要です。イニシエーター実装が、それがオンになっているネットワークとそのネットワーク上のUDPのステータスについて事前の知識がない場合、常に最初にUDPを介してIKEのネゴシエーションを試みる必要があります。 IKEv2は、IKEメッセージ、特にIKE_SA_INITメッセージ[RFC7296]で再送信タイマーを使用する方法を定義します。一般に、これは、実装がIKE SAを失敗としてマークする前に許可される再送信の頻度と再送信の最大数を定義することを意味します。実装は、UDPを介した最大再送信に達した後、または少し前にTCPを介したネゴシエーションを試行して、接続セットアップの遅延を減らすことができます。イニシエーターがネットワークがUDPをブロックする可能性が高いことを事前に認識していない限り、TCPにフォールバックする前に、UDPを介した初期メッセージを少なくとも1回再送信することをお勧めします。
When the IKE Initiator uses TCP encapsulation, it will initiate a TCP connection to the Responder using the configured TCP port. The first bytes sent on the stream MUST be the stream prefix value (Section 4). After this prefix, encapsulated IKE messages will negotiate the IKE SA and initial Child SA [RFC7296]. After this point, both encapsulated IKE (Figure 1) and ESP (Figure 2) messages will be sent over the TCP connection. The TCP Responder MUST wait for the entire stream prefix to be received on the stream before trying to parse out any IKE or ESP messages. The stream prefix is sent only once, and only by the TCP Originator.
IKEイニシエーターがTCPカプセル化を使用する場合、構成されたTCPポートを使用してレスポンダへのTCP接続を開始します。ストリームで送信される最初のバイトは、ストリームプレフィックス値でなければなりません（セクション4）。このプレフィックスの後、カプセル化されたIKEメッセージは、IKE SAと最初の子SA [RFC7296]をネゴシエートします。この後、カプセル化されたIKE（図1）とESP（図2）の両方のメッセージがTCP接続を介して送信されます。 TCPレスポンダは、IKEまたはESPメッセージの解析を試みる前に、ストリームプレフィックス全体がストリームで受信されるのを待機する必要があります。ストリームプレフィックスは1回だけ送信され、TCP発信者によってのみ送信されます。
In order to close an IKE session, either the Initiator or Responder SHOULD gracefully tear down IKE SAs with DELETE payloads. Once the SA has been deleted, the TCP Originator SHOULD close the TCP connection if it does not intend to use the connection for another IKE session to the TCP Responder. If the connection is left idle and the TCP Responder needs to clean up resources, the TCP Responder MAY close the TCP connection.
IKEセッションを閉じるには、イニシエーターまたはレスポンダーのいずれかが、DELETEペイロードを使用してIKE SAを適切に破棄する必要があります（SHOULD）。 SAが削除されると、TCP発信者は、TCPレスポンダへの別のIKEセッションに接続を使用する予定がない場合、TCP接続を閉じる必要があります（SHOULD）。接続がアイドル状態のままで、TCPレスポンダがリソースをクリーンアップする必要がある場合、TCPレスポンダはTCP接続を閉じてもよい（MAY）。
An unexpected FIN or a TCP Reset on the TCP connection may indicate a loss of connectivity, an attack, or some other error. If a DELETE payload has not been sent, both sides SHOULD maintain the state for their SAs for the standard lifetime or timeout period. The TCP Originator is responsible for re-establishing the TCP connection if it is torn down for any unexpected reason. Since new TCP connections may use different ports due to NAT mappings or local port allocations changing, the TCP Responder MUST allow packets for existing SAs to be received from new source ports.
TCP接続での予期しないFINまたはTCPリセットは、接続の喪失、攻撃、またはその他のエラーを示している可能性があります。 DELETEペイロードが送信されていない場合、両側は、標準のライフタイムまたはタイムアウト期間の間、SAの状態を維持する必要があります（SHOULD）。 TCPオリジネーターは、予期しない理由で切断された場合に、TCP接続を再確立する責任があります。 NATマッピングまたはローカルポート割り当ての変更により、新しいTCP接続は異なるポートを使用する可能性があるため、TCPレスポンダは、既存のSAのパケットを新しいソースポートから受信できるようにする必要があります。
A peer MUST discard a partially received message due to a broken connection.
接続が切断されたため、ピアは部分的に受信したメッセージを破棄する必要があります。
Whenever the TCP Originator opens a new TCP connection to be used for an existing IKE SA, it MUST send the stream prefix first, before any IKE or ESP messages. This follows the same behavior as the initial TCP connection.
TCP Originatorが既存のIKE SAに使用される新しいTCP接続を開くときは常に、IKEまたはESPメッセージの前に、まずストリームプレフィックスを送信する必要があります。これは、最初のTCP接続と同じ動作に従います。
If a TCP connection is being used to resume a previous IKE session, the TCP Responder can recognize the session using either the IKE SPI from an encapsulated IKE message or the ESP SPI from an encapsulated ESP message. If the session had been fully established previously, it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES message if MOBIKE is supported, or an informational message (a keep-alive) otherwise.
TCP接続を使用して以前のIKEセッションを再開している場合、TCPレスポンダは、カプセル化されたIKEメッセージのIKE SPIまたはカプセル化されたESPメッセージのESP SPIを使用してセッションを認識できます。以前にセッションが完全に確立されている場合、MOBIKEがサポートされている場合はTCP OriginatorがUPDATE_SA_ADDRESSESメッセージを送信するか、そうでない場合は情報メッセージ（キープアライブ）を送信することをお勧めします。
The TCP Responder MUST NOT accept any messages for the existing IKE session on a new incoming connection, unless that connection begins with the stream prefix. If either the TCP Originator or TCP Responder detects corruption on a connection that was started with a valid stream prefix, it SHOULD close the TCP connection. The connection can be determined to be corrupted if there are too many subsequent messages that cannot be parsed as valid IKE messages or ESP messages with known SPIs, or if the authentication check for an ESP message with a known SPI fails. Implementations SHOULD NOT tear down a connection if only a single ESP message has an unknown SPI, since the SPI databases may be momentarily out of sync. If there is instead a syntax issue within an IKE message, an implementation MUST send the INVALID_SYNTAX notify payload and tear down the IKE SA as usual, rather than tearing down the TCP connection directly.
TCPレスポンダは、その接続がストリームプレフィックスで始まる場合を除き、新しい着信接続で既存のIKEセッションのメッセージを受け入れてはなりません（MUST NOT）。 TCP OriginatorまたはTCP Responderのいずれかが、有効なストリームプレフィックスで開始された接続の破損を検出した場合、TCP接続を閉じる必要があります（SHOULD）。有効なIKEメッセージまたは既知のSPIを持つESPメッセージとして解析できない後続のメッセージが多すぎる場合、または既知のSPIを持つESPメッセージの認証チェックが失敗した場合、接続が破損していると判断できます。 SPIデータベースが一時的に同期していない可能性があるため、単一のESPメッセージのみに不明なSPIがある場合、実装は接続を切断しないでください。代わりにIKEメッセージ内に構文の問題がある場合、実装は、TCP接続を直接切断するのではなく、通常どおりにINVALID_SYNTAX通知ペイロードを送信してIKE SAを切断する必要があります。
A TCP Originator SHOULD only open one TCP connection per IKE SA, over which it sends all of the corresponding IKE and ESP messages. This helps ensure that any firewall or NAT mappings allocated for the TCP connection apply to all of the traffic associated with the IKE SA equally.
TCPオリジネーターは、IKE SAごとに1つのTCP接続のみを開く必要があり（SHOULD）、対応するすべてのIKEおよびESPメッセージを送信します。これにより、TCP接続に割り当てられたファイアウォールまたはNATマッピングが、IKE SAに関連付けられたすべてのトラフィックに等しく適用されるようになります。
Similarly, a TCP Responder SHOULD at any given time send packets for an IKE SA and its Child SAs over only one TCP connection. It SHOULD choose the TCP connection on which it last received a valid and decryptable IKE or ESP message. In order to be considered valid for choosing a TCP connection, an IKE message must be successfully decrypted and authenticated, not be a retransmission of a previously received message, and be within the expected window for IKE message IDs. Similarly, an ESP message must pass authentication checks and be decrypted, and must not be a replay of a previous message.
同様に、TCPレスポンダは、常に1つのTCP接続を介してIKE SAとその子SAのパケットを送信する必要があります（SHOULD）。それはそれが有効で解読可能なIKEまたはESPメッセージを最後に受信したTCP接続を選択するべきです（SHOULD）。 TCP接続の選択に有効と見なされるには、IKEメッセージが正常に復号化および認証され、以前に受信したメッセージの再送信ではなく、IKEメッセージIDの予想されるウィンドウ内にある必要があります。同様に、ESPメッセージは認証チェックを通過して復号化される必要があり、前のメッセージの再生であってはなりません。
Since a connection may be broken and a new connection re-established by the TCP Originator without the TCP Responder being aware, a TCP Responder SHOULD accept receiving IKE and ESP messages on both old and new connections until the old connection is closed by the TCP Originator. A TCP Responder MAY close a TCP connection that it perceives as idle and extraneous (one previously used for IKE and ESP messages that has been replaced by a new connection).
TCP Responderが認識せずに接続が切断され、新しい接続がTCP Originatorによって再確立される可能性があるため、TCP Responderは、古い接続がTCP Originatorによって閉じられるまで、古い接続と新しい接続の両方でIKEおよびESPメッセージの受信を受け入れる必要があります（SHOULD）。 。 TCPレスポンダは、それがアイドルで無関係であると認識しているTCP接続を閉じる可能性があります（以前は、新しい接続で置き換えられたIKEおよびESPメッセージに使用されていました）。
Multiple IKE SAs MUST NOT share a single TCP connection, unless one is a rekey of an existing IKE SA, in which case there will temporarily be two IKE SAs on the same TCP connection.
既存のIKE SAのキー再生成でない限り、複数のIKE SAが単一のTCP接続を共有してはなりません。その場合、同じTCP接続に一時的に2つのIKE SAが存在します。
When negotiating over UDP port 500, IKE_SA_INIT packets include NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads to determine if UDP encapsulation of IPsec packets should be used. These payloads contain SHA-1 digests of the SPIs, IP addresses, and ports as defined in [RFC7296]. IKE_SA_INIT packets sent on a TCP connection SHOULD include these payloads with the same content as when sending over UDP and SHOULD use the applicable TCP ports when creating and checking the SHA-1 digests.
UDPポート500を介してネゴシエートする場合、IKE_SA_INITパケットにはNAT_DETECTION_SOURCE_IPおよびNAT_DETECTION_DESTINATION_IPペイロードが含まれており、IPsecパケットのUDPカプセル化を使用する必要があるかどうかを判断します。これらのペイロードには、[RFC7296]で定義されているSPI、IPアドレス、およびポートのSHA-1ダイジェストが含まれています。 TCP接続で送信されるIKE_SA_INITパケットには、UDP経由で送信する場合と同じ内容のこれらのペイロードが含まれている必要があり（SHOULD）、SHA-1ダイジェストを作成および確認するときに適切なTCPポートを使用する必要があります（SHOULD）。
If a NAT is detected due to the SHA-1 digests not matching the expected values, no change should be made for encapsulation of subsequent IKE or ESP packets, since TCP encapsulation inherently supports NAT traversal. Implementations MAY use the information that a NAT is present to influence keep-alive timer values.
SHA-1ダイジェストが期待値と一致しないためにNATが検出された場合、TCPカプセル化は本質的にNATトラバーサルをサポートしているため、後続のIKEまたはESPパケットのカプセル化を変更する必要はありません。実装は、NATが存在するという情報を使用して、キープアライブタイマー値に影響を与えることができます。
If a NAT is detected, implementations need to handle transport mode TCP and UDP packet checksum fixup as defined for UDP encapsulation in [RFC3948].
NATが検出された場合、[RFC3948]でUDPカプセル化用に定義されているように、実装はトランスポートモードのTCPおよびUDPパケットチェックサム修正を処理する必要があります。
When an IKE session that has negotiated MOBIKE [RFC4555] is transitioning between networks, the Initiator of the transition may switch between using TCP encapsulation, UDP encapsulation, or no encapsulation. Implementations that implement both MOBIKE and TCP encapsulation MUST support dynamically enabling and disabling TCP encapsulation as interfaces change.
MOBIKE [RFC4555]をネゴシエートしたIKEセッションがネットワーク間で移行している場合、移行のイニシエーターは、TCPカプセル化、UDPカプセル化、または非カプセル化を使用して切り替えます。 MOBIKEとTCPの両方のカプセル化を実装する実装は、インターフェイスの変更に応じて、TCPカプセル化を動的に有効および無効にすることをサポートする必要があります。
When a MOBIKE-enabled Initiator changes networks, the UPDATE_SA_ADDRESSES notification SHOULD be sent out first over UDP before attempting over TCP. If there is a response to the UPDATE_SA_ADDRESSES notification sent over UDP, then the ESP packets should be sent directly over IP or over UDP port 4500 (depending on if a NAT was detected), regardless of if a connection on a previous network was using TCP encapsulation. Similarly, if the Responder only responds to the UPDATE_SA_ADDRESSES notification over TCP, then the ESP packets should be sent over the TCP connection, regardless of if a connection on a previous network did not use TCP encapsulation.
MOBIKE対応のイニシエーターがネットワークを変更するとき、UPDATE_SA_ADDRESSES通知は、TCP経由で試行する前に、まずUDP経由で送信する必要があります（SHOULD）。 UDP経由で送信されたUPDATE_SA_ADDRESSES通知への応答がある場合、前のネットワーク上の接続がTCPを使用していたかどうかに関係なく、ESPパケットはIPまたはUDPポート4500（NATが検出されたかどうかに応じて）経由で直接送信されます。カプセル化。同様に、ResponderがTCP経由でUPDATE_SA_ADDRESSES通知にのみ応答する場合、前のネットワーク上の接続がTCPカプセル化を使用していないかどうかに関係なく、ESPパケットはTCP接続経由で送信されます。
IKE message fragmentation [RFC7383] is not required when using TCP encapsulation, since a TCP stream already handles the fragmentation of its contents across packets. Since fragmentation is redundant in this case, implementations might choose to not negotiate IKE fragmentation. Even if fragmentation is negotiated, an implementation SHOULD NOT send fragments when going over a TCP connection, although it MUST support receiving fragments.
TCPストリームはすでにパケット全体のコンテンツの断片化を処理しているため、TCPカプセル化を使用する場合、IKEメッセージの断片化[RFC7383]は不要です。この場合、フラグメンテーションは冗長であるため、実装はIKEフラグメンテーションをネゴシエートしないことを選択する場合があります。断片化がネゴシエートされた場合でも、TCP接続を経由するときに、実装はフラグメントを送信してはなりません（SHOULD NOT）。
If an implementation supports both MOBIKE and IKE fragmentation, it SHOULD negotiate IKE fragmentation over a TCP-encapsulated session in case the session switches to UDP encapsulation on another network.
実装がMOBIKEとIKEの両方の断片化をサポートする場合、セッションが別のネットワークでUDPカプセル化に切り替わる場合に備えて、TCPカプセル化セッションを介してIKE断片化をネゴシエートする必要があります（SHOULD）。
Encapsulating IKE and IPsec inside of a TCP connection can impact the strategy that implementations use to detect peer liveness and to maintain middlebox port mappings. Peer liveness should be checked using IKE informational packets [RFC7296].
TCP接続内でIKEおよびIPsecをカプセル化すると、実装がピアの活性を検出し、ミドルボックスポートマッピングを維持するために使用する戦略に影響を与える可能性があります。ピアの活性は、IKE情報パケット[RFC7296]を使用してチェックする必要があります。
In general, TCP port mappings are maintained by NATs longer than UDP port mappings, so IPsec ESP NAT keep-alives [RFC3948] SHOULD NOT be sent when using TCP encapsulation. Any implementation using TCP encapsulation MUST silently drop incoming NAT keep-alive packets and not treat them as errors. NAT keep-alive packets over a TCP-encapsulated IPsec connection will be sent as an ESP message with a one-octet-long payload with the value 0xFF.
一般に、TCPポートマッピングはUDPポートマッピングよりも長いNATによって維持されるため、TCPカプセル化を使用する場合は、IPsec ESP NATキープアライブ[RFC3948]を送信しないでください。 TCPカプセル化を使用する実装はすべて、着信NATキープアライブパケットを警告なしにドロップし、それらをエラーとして扱わないようにする必要があります。 TCPカプセル化IPsec接続上のNATキープアライブパケットは、値が0xFFの1オクテット長のペイロードを持つESPメッセージとして送信されます。
Note that, depending on the configuration of TCP and TLS on the connection, TCP keep-alives [RFC1122] and TLS keep-alives [RFC6520] may be used. These MUST NOT be used as indications of IKE peer liveness.
接続のTCPとTLSの構成によっては、TCPキープアライブ[RFC1122]とTLSキープアライブ[RFC6520]が使用される場合があることに注意してください。これらは、IKEピアの活性の指標として使用してはなりません（MUST NOT）。
Many security networking devices, such as firewalls or intrusion prevention systems, network optimization/acceleration devices, and NAT devices, keep the state of sessions that traverse through them.
ファイアウォールや侵入防止システム、ネットワーク最適化/高速化デバイス、NATデバイスなどの多くのセキュリティネットワーキングデバイスは、それらを通過するセッションの状態を保持します。
These devices commonly track the transport-layer and/or application-layer data to drop traffic that is anomalous or malicious in nature. While many of these devices will be more likely to pass TCP-encapsulated traffic as opposed to UDP-encapsulated traffic, some may still block or interfere with TCP-encapsulated IKE and IPsec traffic.
これらのデバイスは通常、トランスポート層またはアプリケーション層のデータを追跡して、異常または悪意のあるトラフィックをドロップします。これらのデバイスの多くは、UDPカプセル化トラフィックとは対照的に、TCPカプセル化トラフィックを渡す可能性が高くなりますが、TCPカプセル化IKEおよびIPsecトラフィックをブロックまたは妨害するものもあります。
A network device that monitors the transport layer will track the state of TCP sessions, such as TCP sequence numbers. TCP encapsulation of IKE should therefore use standard TCP behaviors to avoid being dropped by middleboxes.
トランスポート層を監視するネットワークデバイスは、TCPシーケンス番号などのTCPセッションの状態を追跡します。したがって、IKEのTCPカプセル化では、標準のTCP動作を使用して、ミドルボックスによるドロップを回避する必要があります。
Several aspects of TCP encapsulation for IKE and IPsec packets may negatively impact the performance of connections within a tunnel-mode IPsec SA. Implementations should be aware of these performance impacts and take these into consideration when determining when to use TCP encapsulation. Implementations SHOULD favor using direct ESP or UDP encapsulation over TCP encapsulation whenever possible.
IKEおよびIPsecパケットのTCPカプセル化のいくつかの側面は、トンネルモードのIPsec SA内の接続のパフォーマンスに悪影響を及ぼす可能性があります。実装では、これらのパフォーマンスへの影響を認識し、TCPカプセル化をいつ使用するかを決定する際にこれらを考慮する必要があります。実装では、可能な場合は常に、TCPカプセル化よりも直接ESPまたはUDPカプセル化を使用することを推奨します。
If the outer connection between IKE peers is over TCP, inner TCP connections may suffer negative effects from using TCP within TCP. Running TCP within TCP is discouraged, since the TCP algorithms generally assume that they are running over an unreliable datagram layer.
IKEピア間の外部接続がTCPを介している場合、内部TCP接続はTCP内でTCPを使用することによる悪影響を受ける可能性があります。 TCPアルゴリズムは通常、信頼性の低いデータグラム層で実行されていると想定しているため、TCP内でTCPを実行することはお勧めしません。
If the outer (tunnel) TCP connection experiences packet loss, this loss will be hidden from any inner TCP connections, since the outer connection will retransmit to account for the losses. Since the outer TCP connection will deliver the inner messages in order, any messages after a lost packet may have to wait until the loss is recovered. This means that loss on the outer connection will be interpreted only as delay by inner connections. The burstiness of inner traffic can increase, since a large number of inner packets may be delivered across the tunnel at once. The inner TCP connection may interpret a long period of delay as a transmission problem, triggering a retransmission timeout, which will cause spurious retransmissions. The sending rate of the inner connection may be unnecessarily reduced if the retransmissions are not detected as spurious in time.
外部（トンネル）TCP接続でパケット損失が発生した場合、外部接続が損失を考慮して再送信するため、この損失は内部TCP接続から隠されます。外部TCP接続は内部メッセージを順番に配信するため、パケットが失われた後のメッセージは、損失が回復するまで待機する必要があります。つまり、外部接続での損失は、内部接続による遅延としてのみ解釈されます。大量の内部パケットがトンネルを介して一度に配信される可能性があるため、内部トラフィックのバースト性が増加する可能性があります。内部TCP接続は、長い遅延を送信の問題として解釈し、再送信タイムアウトを引き起こし、偽の再送信を引き起こす可能性があります。内部接続の送信速度は、再送信が誤って時間的に検出されない場合、不必要に低下する可能性があります。
The inner TCP connection's round-trip-time estimation will be affected by the burstiness of the outer TCP connection if there are long delays when packets are retransmitted by the outer TCP connection. This will make the congestion control loop of the inner TCP traffic less reactive, potentially permanently leading to a lower sending rate than the outer TCP would allow for.
パケットが外部TCP接続によって再送信されるときに長い遅延がある場合、内部TCP接続の往復時間の見積もりは、外部TCP接続のバースト性の影響を受けます。これにより、内部TCPトラフィックの輻輳制御ループの反応が鈍くなり、外部TCPが許容するよりも永続的に送信レートが低下する可能性があります。
TCP-in-TCP can also lead to increased buffering, or bufferbloat. This can occur when the window size of the outer TCP connection is reduced and becomes smaller than the window sizes of the inner TCP connections. This can lead to packets backing up in the outer TCP connection's send buffers. In order to limit this effect, the outer TCP connection should have limits on its send buffer size and on the rate at which it reduces its window size.
TCP-in-TCPは、バッファリングまたはbufferbloatの増加にもつながる可能性があります。これは、外部TCP接続のウィンドウサイズが縮小され、内部TCP接続のウィンドウサイズよりも小さくなると発生する可能性があります。これにより、外部TCP接続の送信バッファでパケットがバックアップされる可能性があります。この影響を制限するには、外部TCP接続の送信バッファーサイズと、ウィンドウサイズを縮小するレートに制限を設ける必要があります。
Note that any negative effects will be shared between all flows going through the outer TCP connection. This is of particular concern for any latency-sensitive or real-time applications using the tunnel. If such traffic is using a TCP-encapsulated IPsec connection, it is recommended that the number of inner connections sharing the tunnel be limited as much as possible.
負の影響はすべて、外部TCP接続を通過するすべてのフロー間で共有されることに注意してください。これは、トンネルを使用するレイテンシの影響を受けやすいアプリケーションやリアルタイムアプリケーションで特に懸念されます。そのようなトラフィックがTCPカプセル化IPsec接続を使用している場合は、トンネルを共有する内部接続の数をできるだけ制限することをお勧めします。
Since ESP is an unreliable protocol, transmitting ESP packets over a TCP connection will change the fundamental behavior of the packets. Some application-level protocols that prefer packet loss to delay (such as Voice over IP or other real-time protocols) may be negatively impacted if their packets are retransmitted by the TCP connection due to packet loss.
ESPは信頼性の低いプロトコルであるため、TCP接続を介してESPパケットを送信すると、パケットの基本的な動作が変わります。遅延よりもパケット損失を優先する一部のアプリケーションレベルのプロトコル（Voice over IPまたは他のリアルタイムプロトコルなど）は、パケット損失のためにTCP接続によってパケットが再送信されると、悪影響を受ける可能性があります。
Quality-of-Service (QoS) markings, such as the Differentiated Services Code Point (DSCP) and Traffic Class, should be used with care on TCP connections used for encapsulation. Individual packets SHOULD NOT use different markings than the rest of the connection, since packets with different priorities may be routed differently and cause unnecessary delays in the connection.
カプセル化に使用されるTCP接続では、Differentiated Services Code Point（DSCP）やトラフィッククラスなどのサービス品質（QoS）マーキングを注意して使用する必要があります。個々のパケットは、他の接続とは異なるマーキングを使用するべきではありません。異なる優先度のパケットは異なる方法でルーティングされ、接続に不必要な遅延を引き起こす可能性があるためです。
A TCP connection used for IKE encapsulation SHOULD negotiate its MSS in order to avoid unnecessary fragmentation of packets.
IKEカプセル化に使用されるTCP接続は、不必要なパケットの断片化を回避するために、MSSをネゴシエートする必要があります（SHOULD）。
Since there is not a one-to-one relationship between outer IP packets and inner ESP/IP messages when using TCP encapsulation, the markings for Explicit Congestion Notification (ECN) [RFC3168] cannot be simply mapped. However, any ECN Congestion Experienced (CE) marking on inner headers should be preserved through the tunnel.
TCPカプセル化を使用する場合、外部IPパケットと内部ESP / IPメッセージの間に1対1の関係がないため、明示的輻輳通知（ECN）[RFC3168]のマーキングを単純にマッピングすることはできません。ただし、内部ヘッダーのECN Congestion Experienced（CE）マーキングは、トンネルを通じて保持する必要があります。
Implementations SHOULD follow the ECN compatibility mode for tunnel ingress as described in [RFC6040]. In compatibility mode, the outer tunnel TCP connection marks its packet headers as not ECN-capable. If upon egress, the arriving outer header is marked with CE, the implementation will drop the inner packet, since there is not a distinct inner packet header onto which to translate the ECN markings.
[RFC6040]で説明されているように、実装はトンネル進入のECN互換モードに従う必要があります（SHOULD）。互換モードでは、外部トンネルTCP接続は、そのパケットヘッダーをECN対応ではないものとしてマークします。出力時に、到着する外部ヘッダーがCEでマークされている場合、ECNマーキングを変換する明確な内部パケットヘッダーがないため、実装は内部パケットをドロップします。
IKE Responders that support TCP encapsulation may become vulnerable to new Denial-of-Service (DoS) attacks that are specific to TCP, such as SYN-flooding attacks. TCP Responders should be aware of this additional attack surface.
TCPカプセル化をサポートするIKEレスポンダは、SYNフラッディング攻撃など、TCP固有の新しいサービス拒否（DoS）攻撃に対して脆弱になる可能性があります。 TCPレスポンダは、この追加の攻撃面に注意する必要があります。
TCP Responders should be careful to ensure that (1) the stream prefix "IKETCP" uniquely identifies incoming streams as streams that use the TCP encapsulation protocol and (2) they are not running any other protocols on the same listening port (to avoid potential conflicts).
TCPレスポンダは、（1）ストリームプレフィックス "IKETCP"が着信ストリームをTCPカプセル化プロトコルを使用するストリームとして一意に識別し、（2）同じリスニングポートで他のプロトコルを実行していないことを確認するように注意する必要があります（潜在的な競合を回避するため） ）。
Attackers may be able to disrupt the TCP connection by sending spurious TCP Reset packets. Therefore, implementations SHOULD make sure that IKE session state persists even if the underlying TCP connection is torn down.
攻撃者は、偽のTCPリセットパケットを送信することにより、TCP接続を妨害する可能性があります。したがって、実装では、基になるTCP接続が切断された場合でも、IKEセッション状態が持続するようにする必要があります（SHOULD）。
If MOBIKE is being used, all of the security considerations outlined for MOBIKE apply [RFC4555].
MOBIKEが使用されている場合、MOBIKEについて概説されているすべてのセキュリティの考慮事項が適用されます[RFC4555]。
Similarly to MOBIKE, TCP encapsulation requires a TCP Responder to handle changes to source address and port due to network or connection disruption. The successful delivery of valid IKE or ESP messages over a new TCP connection is used by the TCP Responder to determine where to send subsequent responses. If an attacker is able to send packets on a new TCP connection that pass the validation checks of the TCP Responder, it can influence which path future packets will take. For this reason, the validation of messages on the TCP Responder must include decryption, authentication, and replay checks.
MOBIKEと同様に、TCPカプセル化では、ネットワークまたは接続の中断による送信元アドレスとポートの変更を処理するためにTCPレスポンダが必要です。新しいTCP接続を介した有効なIKEまたはESPメッセージの配信の成功は、後続の応答の送信先を決定するためにTCPレスポンダによって使用されます。攻撃者がTCPレスポンダの検証チェックに合格した新しいTCP接続でパケットを送信できる場合、将来のパケットが通過する経路に影響を与える可能性があります。このため、TCPレスポンダでのメッセージの検証には、復号化、認証、および再生チェックを含める必要があります。
Since TCP provides reliable, in-order delivery of ESP messages, the ESP anti-replay window size SHOULD be set to 1. See [RFC4303] for a complete description of the ESP anti-replay window. This increases the protection of implementations against replay attacks.
TCPはESPメッセージの信頼できる順序どおりの配信を提供するため、ESPアンチリプレイウィンドウサイズは1に設定する必要があります（SHOULD）。ESPアンチリプレイウィンドウの詳細については、[RFC4303]を参照してください。これにより、リプレイ攻撃に対する実装の保護が強化されます。
TCP port 4500 is already allocated to IPsec for NAT traversal. This port SHOULD be used for TCP-encapsulated IKE and ESP as described in this document.
TCPポート4500は、NATトラバーサル用のIPsecにすでに割り当てられています。このドキュメントで説明されているように、このポートは、TCPカプセル化IKEおよびESPに使用する必要があります（SHOULD）。
This document updates the reference for TCP port 4500:
このドキュメントでは、TCPポート4500のリファレンスを更新しています。
Keyword Decimal Description Reference
----------- -------- ------------------- ---------
ipsec-nat-t 4500/tcp IPsec NAT-Traversal RFC 8229
Figure 4
図4
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, DOI 10.17487/RFC3948, January 2005, <http://www.rfc-editor.org/info/rfc3948>.
[RFC3948] Huttunen、A.、Swander、B.、Volpe、V.、DiBurro、L。、およびM. Stenberg、「IPsec ESPパケットのUDPカプセル化」、RFC 3948、DOI 10.17487 / RFC3948、2005年1月、<http ：//www.rfc-editor.org/info/rfc3948>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<http://www.rfc-editor.org/info/rfc4303>。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <http://www.rfc-editor.org/info/rfc6040>.
[RFC6040] Briscoe、B。、「Tunnelling of Explicit Congestion Notification」、RFC 6040、DOI 10.17487 / RFC6040、2010年11月、<http://www.rfc-editor.org/info/rfc6040>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「Internet Key Exchange Protocol Version 2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年10月、<http://www.rfc-editor.org/info/rfc7296>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「あいまいな大文字と小文字のRFC 2119キーワード」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<http://www.rfc-editor.org/info/ rfc8174>。
[IKE-over-TCP] Nir, Y., "A TCP transport for the Internet Key Exchange", Work in Progress, draft-ietf-ipsecme-ike-tcp-01, December 2012.
[IKE-over-TCP] Nir、Y。、「インターネットキー交換用のTCPトランスポート」、作業中、draft-ietf-ipsecme-ike-tcp-01、2012年12月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<http://www.rfc-editor.org/info/ rfc1122>。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, DOI 10.17487/RFC2817, May 2000, <http://www.rfc-editor.org/info/rfc2817>.
[RFC2817] Khare、R。およびS. Lawrence、「HTTP / 1.1内のTLSへのアップグレード」、RFC 2817、DOI 10.17487 / RFC2817、2000年5月、<http://www.rfc-editor.org/info/rfc2817> 。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<http：// www。 rfc-editor.org/info/rfc3168>。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, <http://www.rfc-editor.org/info/rfc4555>.
[RFC4555] Eronen、P。、「IKEv2 Mobility and Multihoming Protocol（MOBIKE）」、RFC 4555、DOI 10.17487 / RFC4555、2006年6月、<http://www.rfc-editor.org/info/rfc4555>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, DOI 10.17487/RFC6520, February 2012, <http://www.rfc-editor.org/info/rfc6520>.
[RFC6520] Seggelmann、R.、Tuexen、M。、およびM. Williams、「Transport Layer Security（TLS）and Datagram Transport Layer Security（DTLS）Heartbeat Extension」、RFC 6520、DOI 10.17487 / RFC6520、2012年2月、<http ：//www.rfc-editor.org/info/rfc6520>。
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/RFC7383, November 2014, <http://www.rfc-editor.org/info/rfc7383>.
[RFC7383] Smyslov、V。、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）メッセージの断片化」、RFC 7383、DOI 10.17487 / RFC7383、2014年11月、<http://www.rfc-editor.org/info/rfc7383> 。
This section provides recommendations on how to use TLS in addition to TCP encapsulation.
このセクションでは、TCPカプセル化に加えてTLSの使用方法に関する推奨事項を提供します。
When using TCP encapsulation, implementations may choose to use TLS [RFC5246] on the TCP connection to be able to traverse middleboxes, which may otherwise block the traffic.
TCPカプセル化を使用する場合、実装はミドルボックスを通過できるようにTCP接続でTLS [RFC5246]を使用することを選択できます。そうしないと、トラフィックがブロックされる可能性があります。
If a web proxy is applied to the ports used for the TCP connection and TLS is being used, the TCP Originator can send an HTTP CONNECT message to establish an SA through the proxy [RFC2817].
TCP接続に使用されるポートにWebプロキシが適用され、TLSが使用されている場合、TCP発信者はHTTP CONNECTメッセージを送信して、プロキシを介してSAを確立できます[RFC2817]。
The use of TLS should be configurable on the peers, and may be used as the default when using TCP encapsulation or may be used as a fallback when basic TCP encapsulation fails. The TCP Responder may expect to read encapsulated IKE and ESP packets directly from the TCP connection, or it may expect to read them from a stream of TLS data packets. The TCP Originator should be pre-configured to use TLS or not when communicating with a given port on the TCP Responder.
TLSの使用はピアで設定可能である必要があり、TCPカプセル化を使用する場合はデフォルトとして使用でき、基本的なTCPカプセル化が失敗した場合のフォールバックとして使用できます。 TCPレスポンダは、カプセル化されたIKEおよびESPパケットをTCP接続から直接読み取ることを期待するか、TLSデータパケットのストリームからそれらを読み取ることを期待する場合があります。 TCP発信者は、TCPレスポンダの特定のポートと通信するときにTLSを使用するかどうかを事前に設定する必要があります。
When new TCP connections are re-established due to a broken connection, TLS must be renegotiated. TLS session resumption is recommended to improve efficiency in this case.
接続が切断されたために新しいTCP接続が再確立された場合、TLSを再ネゴシエートする必要があります。この場合、効率を向上させるために、TLSセッションの再開をお勧めします。
The security of the IKE session is entirely derived from the IKE negotiation and key establishment and not from the TLS session (which in this context is only used for encapsulation purposes); therefore, when TLS is used on the TCP connection, both the TCP Originator and the TCP Responder SHOULD allow the NULL cipher to be selected for performance reasons.
IKEセッションのセキュリティは完全にIKEネゴシエーションとキーの確立から派生し、TLSセッションからは派生しません（このコンテキストではカプセル化の目的でのみ使用されます）。したがって、TCP接続でTLSが使用されている場合、TCP発信者とTCPレスポンダーの両方で、パフォーマンス上の理由からNULL暗号を選択できるようにする必要があります（SHOULD）。
Implementations should be aware that the use of TLS introduces another layer of overhead requiring more bytes to transmit a given IKE and IPsec packet. For this reason, direct ESP, UDP encapsulation, or TCP encapsulation without TLS should be preferred in situations in which TLS is not required in order to traverse middleboxes.
実装では、TLSを使用すると、所定のIKEおよびIPsecパケットを送信するためにより多くのバイト数を必要とする別のオーバーヘッド層が導入されることに注意する必要があります。このため、ミドルボックスを通過するためにTLSが不要な状況では、TLSを使用しない直接ESP、UDPカプセル化、またはTCPカプセル化をお勧めします。
Client Server
---------- ----------
1) -------------------- TCP Connection -------------------
(IP_I:Port_I -> IP_R:Port_R)
TcpSyn ---------->
<---------- TcpSyn,Ack
TcpAck ---------->
2) --------------------- TLS Session ---------------------
ClientHello ---------->
ServerHello
Certificate*
ServerKeyExchange*
<---------- ServerHelloDone
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished ---------->
[ChangeCipherSpec]
<---------- Finished
3) ---------------------- Stream Prefix --------------------
"IKETCP" ---------->
4) ----------------------- IKE Session ---------------------
Length + Non-ESP Marker ---------->
IKE_SA_INIT
HDR, SAi1, KEi, Ni,
[N(NAT_DETECTION_*_IP)]
<------ Length + Non-ESP Marker
IKE_SA_INIT
HDR, SAr1, KEr, Nr,
[N(NAT_DETECTION_*_IP)]
Length + Non-ESP Marker ---------->
first IKE_AUTH
HDR, SK {IDi, [CERTREQ]
CP(CFG_REQUEST), IDr,
SAi2, TSi, TSr, ...}
<------ Length + Non-ESP Marker
first IKE_AUTH
HDR, SK {IDr, [CERT], AUTH,
EAP, SAr2, TSi, TSr}
Length + Non-ESP Marker ---------->
IKE_AUTH + EAP
repeat 1..N times
<------ Length + Non-ESP Marker
IKE_AUTH + EAP
Length + Non-ESP Marker ---------->
final IKE_AUTH
HDR, SK {AUTH}
<------ Length + Non-ESP Marker
final IKE_AUTH
HDR, SK {AUTH, CP(CFG_REPLY),
SA, TSi, TSr, ...}
-------------- IKE and IPsec SAs Established ------------
Length + ESP Frame ---------->
Figure 5
図5
1. The client establishes a TCP connection with the server on port 4500 or on an alternate pre-configured port that the server is listening on.
1. クライアントは、ポート4500またはサーバーがリッスンしている代替の構成済みポートでサーバーとのTCP接続を確立します。
2. If configured to use TLS, the client initiates a TLS handshake. During the TLS handshake, the server SHOULD NOT request the client's certificate, since authentication is handled as part of IKE negotiation.
2. TLSを使用するように構成されている場合、クライアントはTLSハンドシェイクを開始します。 TLSハンドシェイクの間、認証はIKEネゴシエーションの一部として処理されるため、サーバーはクライアントの証明書を要求しないでください。
3. The client sends the stream prefix for TCP-encapsulated IKE (Section 4) traffic to signal the beginning of IKE negotiation.
3. クライアントは、TCPカプセル化IKE（セクション4）トラフィックのストリームプレフィックスを送信して、IKEネゴシエーションの開始を知らせます。
4. The client and server establish an IKE connection. This example shows EAP-based authentication, although any authentication type may be used.
4. クライアントとサーバーはIKE接続を確立します。この例はEAPベースの認証を示していますが、任意の認証タイプを使用できます。
Client Server
---------- ----------
1) ----------------------- IKE Session ---------------------
Length + Non-ESP Marker ---------->
INFORMATIONAL
HDR, SK {[N,] [D,]
[CP,] ...}
<------ Length + Non-ESP Marker
INFORMATIONAL
HDR, SK {[N,] [D,]
[CP], ...}
2) --------------------- TLS Session ---------------------
close_notify ---------->
<---------- close_notify
3) -------------------- TCP Connection -------------------
TcpFin ---------->
<---------- Ack
<---------- TcpFin
Ack ---------->
-------------------- IKE SA Deleted -------------------
Figure 6
図6
1. The client and server exchange informational messages to notify IKE SA deletion.
1. クライアントとサーバーは情報メッセージを交換して、IKE SAの削除を通知します。
2. The client and server negotiate TLS session deletion using TLS CLOSE_NOTIFY.
2. クライアントとサーバーは、TLS CLOSE_NOTIFYを使用してTLSセッションの削除をネゴシエートします。
3. The TCP connection is torn down.
3. TCP接続が切断されます。
The deletion of the IKE SA should lead to the disposal of the underlying TLS and TCP state.
IKE SAを削除すると、基になるTLSおよびTCP状態が破棄されます。
Client Server
---------- ----------
1) -------------------- TCP Connection -------------------
(IP_I:Port_I -> IP_R:Port_R)
TcpSyn ---------->
<---------- TcpSyn,Ack
TcpAck ---------->
2) --------------------- TLS Session ---------------------
ClientHello ---------->
<---------- ServerHello
[ChangeCipherSpec]
Finished
[ChangeCipherSpec] ---------->
Finished
3) ---------------------- Stream Prefix --------------------
"IKETCP" ---------->
4) <---------------------> IKE/ESP Flow <------------------>
Length + ESP Frame ---------->
Figure 7
図7
1. If a previous TCP connection was broken (for example, due to a TCP Reset), the client is responsible for re-initiating the TCP connection. The TCP Originator's address and port (IP_I and Port_I) may be different from the previous connection's address and port.
1. 以前のTCP接続が切断された場合（たとえば、TCPリセットが原因で）、クライアントはTCP接続を再開始する必要があります。 TCP発信元のアドレスとポート（IP_IおよびPort_I）は、以前の接続のアドレスとポートと異なる場合があります。
2. In the ClientHello TLS message, the client SHOULD send the session ID it received in the previous TLS handshake if available. It is up to the server to perform either an abbreviated handshake or a full handshake based on the session ID match.
2. ClientHello TLSメッセージでは、クライアントは、可能であれば、前のTLSハンドシェイクで受信したセッションIDを送信する必要があります（SHOULD）。セッションIDの一致に基づいて省略されたハンドシェイクまたは完全なハンドシェイクを実行するかどうかは、サーバーに依存します。
3. After TCP and TLS are complete, the client sends the stream prefix for TCP-encapsulated IKE traffic (Section 4).
3. TCPとTLSが完了すると、クライアントはTCPカプセル化IKEトラフィックのストリームプレフィックスを送信します（セクション4）。
4. The IKE and ESP packet flow can resume. If MOBIKE is being used, the Initiator SHOULD send an UPDATE_SA_ADDRESSES message.
4. IKEおよびESPパケットフローを再開できます。 MOBIKEが使用されている場合、イニシエーターはUPDATE_SA_ADDRESSESメッセージを送信する必要があります（SHOULD）。
Client Server
---------- ----------
(IP_I1:UDP500 -> IP_R:UDP500)
1) ----------------- IKE_SA_INIT Exchange -----------------
(IP_I1:UDP4500 -> IP_R:UDP4500)
Non-ESP Marker ----------->
Initial IKE_AUTH
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) }
<----------- Non-ESP Marker
Initial IKE_AUTH
HDR, SK { IDr, CERT, AUTH,
EAP, SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED) }
<------------------ IKE SA Establishment --------------->
2) ------------ MOBIKE Attempt on New Network --------------
(IP_I2:UDP4500 -> IP_R:UDP4500)
Non-ESP Marker ----------->
INFORMATIONAL
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
3) -------------------- TCP Connection -------------------
(IP_I2:Port_I -> IP_R:Port_R)
TcpSyn ----------->
<----------- TcpSyn,Ack
TcpAck ----------->
4) --------------------- TLS Session ---------------------
ClientHello ----------->
ServerHello
Certificate*
ServerKeyExchange*
<----------- ServerHelloDone
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished ----------->
[ChangeCipherSpec]
<----------- Finished
5) ---------------------- Stream Prefix --------------------
"IKETCP" ---------->
6) ----------------------- IKE Session ---------------------
Length + Non-ESP Marker ----------->
INFORMATIONAL (Same as step 2)
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
<------- Length + Non-ESP Marker
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
7) <----------------- IKE/ESP Data Flow ------------------->
Figure 8
図8
1. During the IKE_SA_INIT exchange, the client and server exchange MOBIKE_SUPPORTED notify payloads to indicate support for MOBIKE.
1. IKE_SA_INIT交換中に、クライアントとサーバーはMOBIKE_SUPPORTED通知ペイロードを交換して、MOBIKEのサポートを示します。
2. The client changes its point of attachment to the network and receives a new IP address. The client attempts to re-establish the IKE session using the UPDATE_SA_ADDRESSES notify payload, but the server does not respond because the network blocks UDP traffic.
2. クライアントは、ネットワークへの接続ポイントを変更し、新しいIPアドレスを受け取ります。クライアントはUPDATE_SA_ADDRESSES通知ペイロードを使用してIKEセッションを再確立しようとしますが、ネットワークがUDPトラフィックをブロックしているため、サーバーは応答しません。
3. The client brings up a TCP connection to the server in order to use TCP encapsulation.
3. クライアントは、TCPカプセル化を使用するために、サーバーへのTCP接続を開始します。
4. The client initiates a TLS handshake with the server.
4. クライアントはサーバーとのTLSハンドシェイクを開始します。
5. The client sends the stream prefix for TCP-encapsulated IKE traffic (Section 4).
5. クライアントは、TCPカプセル化IKEトラフィックのストリームプレフィックスを送信します（セクション4）。
6. The client sends the UPDATE_SA_ADDRESSES notify payload on the TCP-encapsulated connection. Note that this IKE message is the same as the one sent over UDP in step 2; it should have the same message ID and contents.
6. クライアントは、TCPカプセル化接続でUPDATE_SA_ADDRESSES通知ペイロードを送信します。このIKEメッセージは、手順2でUDPを介して送信されたものと同じであることに注意してください。メッセージIDと内容は同じである必要があります。
7. The IKE and ESP packet flow can resume.
7. IKEおよびESPパケットフローを再開できます。
Acknowledgments
謝辞
The authors would like to acknowledge the input and advice of Stuart Cheshire, Delziel Fernandes, Yoav Nir, Christoph Paasch, Yaron Sheffer, David Schinazi, Graham Bartlett, Byju Pularikkal, March Wu, Kingwel Xie, Valery Smyslov, Jun Hu, and Tero Kivinen. Special thanks to Eric Kinnear for his implementation work.
著者は、スチュアートチェシャー、デルジエルフェルナンデス、ヨアフニル、クリストフパーシュ、ヤロンシェファー、デビッドシナジ、グラハムバートレット、ビジュプラリカル、マーチウー、キングウェルシェ、ヴァレリースミスロフ、ジュンヒュー、およびテロキビネンの入力とアドバイスを認めたい。 Eric Kinnear氏の実装作業に特に感謝します。
Authors' Addresses
著者のアドレス
Tommy Pauly Apple Inc. 1 Infinite Loop Cupertino, California 95014 United States of America
トミーポーリーアップル社1無限ループクパチーノ、カリフォルニア95014アメリカ合衆国
Email: tpauly@apple.com
Samy Touati Ericsson 2755 Augustine Santa Clara, California 95054 United States of America
Samy Touati Ericsson 2755オーガスティンサンタクララ、カリフォルニア95054アメリカ合衆国
Email: samy.touati@ericsson.com
Ravi Mantha Cisco Systems SEZ, Embassy Tech Village Panathur, Bangalore 560 037 India
Ravi Mantha Cisco Systems SEZ、Embassy Tech Village Panathur、Bangalore 560 037 India
Email: ramantha@cisco.com