[要約] RFC 7413は、TCP Fast Open（TFO）プロトコルに関する仕様を定めたものであり、TCP接続の初期ハンドシェイクを省略し、接続の高速化を実現することを目的としています。
Internet Engineering Task Force (IETF) Y. Cheng
Request for Comments: 7413 J. Chu
Category: Experimental S. Radhakrishnan
ISSN: 2070-1721 A. Jain
Google
December 2014
TCP Fast Open
TCP高速オープン
Abstract
概要
This document describes an experimental TCP mechanism called TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section.
このドキュメントでは、TCP Fast Open（TFO）と呼ばれる実験的なTCPメカニズムについて説明します。 TFOは、データがSYNおよびSYN-ACKパケットで運ばれ、初期接続ハンドシェイク中に受信側で消費されることを可能にし、標準のTCPと比較して最大1つの完全なラウンドトリップ時間（RTT）を節約します。データを交換する前に完了する方法ハンドシェイク（3WHS）。ただし、SYNのデータがまれな状況でアプリケーションに再生される可能性があるため、TFOは標準のTCPセマンティクスから逸脱しています。 「適用性」セクションで詳述されているように、この問題を許容できる場合を除き、アプリケーションはTFOを使用しないでください。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション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/rfc7413.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7413で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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. Terminology ................................................4
2. Data in SYN .....................................................4
2.1. Relaxing TCP Semantics on Duplicated SYNs ..................4
2.2. SYNs with Spoofed IP Addresses .............................5
3. Protocol Overview ...............................................5
4. Protocol Details ................................................7
4.1. Fast Open Cookie ...........................................7
4.1.1. Fast Open Option ....................................8
4.1.2. Server Cookie Handling ..............................8
4.1.3. Client Cookie Handling ..............................9
4.1.3.1. Client Caching Negative Responses .........10
4.2. Fast Open Protocol ........................................11
4.2.1. Fast Open Cookie Request ...........................11
4.2.2. TCP Fast Open ......................................12
5. Security Considerations ........................................14
5.1. Resource Exhaustion Attack by SYN Flood with Valid
Cookies ...................................................14
5.1.1. Attacks from behind Shared Public IPs (NATs) .......15
5.2. Amplified Reflection Attack to Random Host ................16
6. TFO Applicability ..............................................17
6.1. Duplicate Data in SYNs ....................................17
6.2. Potential Performance Improvement .........................17
6.3. Example: Web Clients and Servers ..........................18
6.3.1. HTTP Request Replay ................................18
6.3.2. HTTP over TLS (HTTPS) ..............................18
6.3.3. Comparison with HTTP Persistent Connections ........18
6.3.4. Load Balancers and Server Farms ....................19
7. Open Areas for Experimentation .................................19
7.1. Performance Impact Due to Middleboxes and NAT .............19
7.2. Impact on Congestion Control ..............................20
7.3. Cookie-less Fast Open .....................................20
8. Related Work ...................................................20
8.1. T/TCP .....................................................20
8.2. Common Defenses against SYN Flood Attacks .................21
8.3. Speculative Connections by the Applications ...............21
8.4. Fast Open Cookie-in-FIN ...................................21
8.5. TCP Cookie Transaction (TCPCT) ............................21
9. IANA Considerations ............................................22
10. References ....................................................22
10.1. Normative References .....................................22
10.2. Informative References ...................................23
Appendix A. Example Socket API Changes to Support TFO .............25
A.1. Active Open .................................................25
A.2. Passive Open ................................................25
Acknowledgments ...................................................26
Authors' Addresses ................................................26
TCP Fast Open (TFO) is an experimental update to TCP that enables data to be exchanged safely during TCP's connection handshake. This document describes a design that enables applications to save a round trip while avoiding severe security ramifications. At the core of TFO is a security cookie used by the server side to authenticate a client initiating a TFO connection. This document covers the details of exchanging data during TCP's initial handshake, the protocol for TFO cookies, potential new security vulnerabilities and their mitigation, and the new socket API.
TCP Fast Open（TFO）は、TCPの実験的なアップデートであり、TCPの接続ハンドシェイク中にデータを安全に交換できるようにします。このドキュメントでは、深刻なセキュリティの影響を回避しながら、アプリケーションがラウンドトリップを節約できるようにする設計について説明します。 TFOの中核は、TFO接続を開始するクライアントを認証するためにサーバー側で使用されるセキュリティCookieです。このドキュメントでは、TCPの初期ハンドシェイク中のデータ交換の詳細、TFO Cookieのプロトコル、潜在的な新しいセキュリティの脆弱性とその緩和策、および新しいソケットAPIについて説明します。
TFO is motivated by the performance needs of today's Web applications. Current TCP only permits data exchange after the three-way handshake (3WHS) [RFC793], which adds one RTT to network latency. For short Web transfers this additional RTT is a significant portion of overall network latency, even when HTTP persistent connection is widely used. For example, the Chrome browser [Chrome] keeps TCP connections idle for up to 5 minutes, but 35% of HTTP requests are made on new TCP connections [RCCJR11]. For such Web and Web-like applications, placing data in the SYN can yield significant latency improvements. Next we describe how we resolve the challenges that arise upon doing so.
TFOは、今日のWebアプリケーションのパフォーマンスニーズに動機付けられています。現在のTCPは、ネットワーク遅延に1つのRTTを追加する3ウェイハンドシェイク（3WHS）[RFC793]の後のデータ交換のみを許可します。短いWeb転送の場合、HTTP永続接続が広く使用されている場合でも、この追加のRTTはネットワーク遅延全体のかなりの部分を占めます。たとえば、Chromeブラウザ[Chrome]はTCP接続を最大5分間アイドル状態に保ちますが、HTTPリクエストの35％は新しいTCP接続[RCCJR11]で行われます。このようなWebおよびWebのようなアプリケーションの場合、SYNにデータを配置すると、レイテンシが大幅に改善されます。次に、その際に発生する課題をどのように解決するかについて説明します。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
"TFO" refers to TCP Fast Open. "Client" refers to TCP's active open side, and "server" refers to TCP's passive open side.
「TFO」はTCP Fast Openを指します。 「クライアント」はTCPのアクティブなオープンサイドを指し、「サーバー」はTCPのパッシブオープンサイドを指します。
Standard TCP already allows data to be carried in SYN packets ([RFC793], Section 3.4) but forbids the receiver from delivering it to the application until the 3WHS is completed. This is because TCP's initial handshake serves to capture old or duplicate SYNs.
標準TCPではすでにSYNパケットでデータを伝送することが許可されていますが（[RFC793]、セクション3.4）、3WHSが完了するまで受信者がアプリケーションにデータを配信することは禁止されています。これは、TCPの初期ハンドシェイクが古いまたは重複したSYNをキャプチャするために機能するためです。
To enable applications to exchange data in a TCP handshake, TFO removes the constraint and allows data in SYN packets to be delivered to the application. This change to TCP semantic raises two issues (discussed in the following subsections) that make TFO unsuitable for certain applications.
アプリケーションがTCPハンドシェイクでデータを交換できるようにするために、TFOは制約を削除し、SYNパケット内のデータをアプリケーションに配信できるようにします。このTCPセマンティックへの変更により、TFOが特定のアプリケーションに不適切になる2つの問題（次のサブセクションで説明）が発生します。
Therefore, TCP implementations MUST NOT use TFO by default, but only use TFO if requested explicitly by the application on a per-service-port basis. Applications need to evaluate TFO applicability as described in Section 6 before using TFO.
したがって、TCP実装はデフォルトでTFOを使用してはならず（MUST NOT）、サービスポートごとにアプリケーションによって明示的に要求された場合にのみTFOを使用します。アプリケーションは、TFOを使用する前に、セクション6で説明されているようにTFOの適用性を評価する必要があります。
TFO allows data to be delivered to the application before the 3WHS is completed, thus opening itself to a data integrity issue in either of the two cases below:
TFOを使用すると、3WHSが完了する前にデータをアプリケーションに配信できるため、以下の2つのケースのいずれかでデータの整合性の問題が発生します。
a) the receiver host receives data in a duplicate SYN after it has forgotten it received the original SYN (e.g., due to a reboot);
a) 受信側ホストは、元のSYNの受信を忘れた後（たとえば、再起動のため）、重複するSYNでデータを受信します。
b) the duplicate is received after the connection created by the original SYN has been closed and the close was initiated by the sender (so the receiver will not be protected by the TIME-WAIT 2 MSL state).
b) 複製は、元のSYNによって作成された接続が閉じられ、送信者によって閉じられた後に受信されます（したがって、受信者はTIME-WAIT 2 MSL状態によって保護されません）。
The now obsoleted T/TCP [RFC1644] (obsoleted by [RFC6247]) attempted to address these issues. It was not successful and not deployed due to various vulnerabilities as described in Section 8, "Related Work". Rather than trying to capture all dubious SYN packets to make TFO 100% compatible with TCP semantics, we made a design decision early on to accept old SYN packets with data, i.e., to restrict TFO use to a class of applications (Section 6) that are tolerant of duplicate SYN packets with data. We believe this is the right design trade-off: balancing complexity with usefulness.
現在廃止されたT / TCP [RFC1644]（[RFC6247]により廃止）は、これらの問題に対処しようとしました。第8章「関連作業」で説明されているように、さまざまな脆弱性のため、成功せず、展開されませんでした。疑わしいSYNパケットをすべてキャプチャしてTFOをTCPセマンティクスと100％互換にするのではなく、データを含む古いSYNパケットを受け入れるように設計上の決定を下しました。つまり、TFOの使用をアプリケーションのクラスに制限します（セクション6）。データとの重複したSYNパケットを許容します。これは正しい設計のトレードオフであると私たちは信じています。
Standard TCP suffers from the SYN flood attack [RFC4987] because SYN packets with spoofed source IP addresses can easily fill up a listener's small queue, causing a service port to be blocked completely.
標準のTCPはSYNフラッド攻撃[RFC4987]の影響を受けます。これは、スプーフィングされたソースIPアドレスを持つSYNパケットがリスナーの小さなキューを簡単にいっぱいにし、サービスポートが完全にブロックされるためです。
TFO goes one step further to allow server-side TCP to send up data to the application layer before the 3WHS is completed. This opens up serious new vulnerabilities. Applications serving ports that have TFO enabled may waste lots of CPU and memory resources processing the requests and producing the responses. If the response is much larger than the request, the attacker can further mount an amplified reflection attack against victims of choice beyond the TFO server itself.
TFOはさらに一歩進んで、3WHSが完了する前にサーバー側のTCPがアプリケーション層にデータを送信できるようにします。これは深刻な新しい脆弱性をもたらします。 TFOが有効になっているポートにサービスを提供するアプリケーションは、要求を処理して応答を生成する多くのCPUおよびメモリリソースを浪費する可能性があります。応答が要求よりもはるかに大きい場合、攻撃者はTFOサーバー自体を超えて、選択した犠牲者に対する増幅反射攻撃をさらに行うことができます。
Numerous mitigation techniques against regular SYN flood attacks exist and have been well documented [RFC4987]. Unfortunately, none are applicable to TFO. We propose a server-supplied cookie to mitigate these new vulnerabilities in Section 3 and evaluate the effectiveness of the defense in Section 7.
定期的なSYNフラッド攻撃に対する多数の緩和技術が存在し、十分に文書化されています[RFC4987]。残念ながら、TFOには該当しません。セクション3でこれらの新しい脆弱性を緩和し、セクション7で防御の有効性を評価するために、サーバー提供のCookieを提案します。
The key component of TFO is the Fast Open Cookie (cookie), a message authentication code (MAC) tag generated by the server. The client requests a cookie in one regular TCP connection, then uses it for future TCP connections to exchange data during the 3WHS:
TFOの主要なコンポーネントは、サーバーによって生成されるメッセージ認証コード（MAC）タグであるFast Open Cookie（Cookie）です。クライアントは1つの通常のTCP接続でCookieを要求し、それを将来のTCP接続に使用して3WHS中にデータを交換します。
Requesting a Fast Open Cookie:
高速オープンCookieの要求：
1. The client sends a SYN with a Fast Open option with an empty cookie field to request a cookie.
1. クライアントは、Cookieを要求するために空のCookieフィールドを指定してFast Openオプションを指定したSYNを送信します。
2. The server generates a cookie and sends it through the Fast Open option of a SYN-ACK packet.
2. サーバーはCookieを生成し、SYN-ACKパケットのFast Openオプションを介してそれを送信します。
3. The client caches the cookie for future TCP Fast Open connections (see below).
3. クライアントは、将来のTCP Fast Open接続のためにCookieをキャッシュします（以下を参照）。
Performing TCP Fast Open:
TCP Fast Openの実行：
1. The client sends a SYN with data and the cookie in the Fast Open option.
1. クライアントは、高速オープンオプションでデータとCookieを含むSYNを送信します。
2. The server validates the cookie:
2. サーバーはCookieを検証します。
a. If the cookie is valid, the server sends a SYN-ACK acknowledging both the SYN and the data. The server then delivers the data to the application.
a. Cookieが有効な場合、サーバーはSYNとデータの両方を確認するSYN-ACKを送信します。次に、サーバーはデータをアプリケーションに配信します。
b. Otherwise, the server drops the data and sends a SYN-ACK acknowledging only the SYN sequence number.
b. それ以外の場合、サーバーはデータをドロップし、SYNシーケンス番号のみを確認するSYN-ACKを送信します。
3. If the server accepts the data in the SYN packet, it may send the response data before the handshake finishes. The maximum amount is governed by TCP's congestion control [RFC5681].
3. サーバーがSYNパケットのデータを受け入れる場合、ハンドシェイクが完了する前に応答データを送信することがあります。最大量は、TCPの輻輳制御[RFC5681]によって制御されます。
4. The client sends an ACK acknowledging the SYN and the server data. If the client's data is not acknowledged, the client retransmits the data in the ACK packet.
4. クライアントは、SYNとサーバーデータを確認するACKを送信します。クライアントのデータが確認されない場合、クライアントはACKパケットでデータを再送信します。
5. The rest of the connection proceeds like a normal TCP connection. The client can repeat many Fast Open operations once it acquires a cookie (until the cookie is expired by the server). Thus, TFO is useful for applications that have temporal locality on client and server connections.
5. 残りの接続は、通常のTCP接続と同様に進行します。クライアントは、Cookieを取得すると（サーバーによってCookieが期限切れになるまで）多くのFast Open操作を繰り返すことができます。したがって、TFOは、クライアントとサーバーの接続に一時的な局所性があるアプリケーションに役立ちます。
Requesting Fast Open Cookie in connection 1:
接続1で高速オープンCookieを要求する：
TCP A (Client) TCP B (Server)
______________ ______________
CLOSED LISTEN
#1 SYN-SENT ----- <SYN,CookieOpt=NIL> ----------> SYN-RCVD
#2 ESTABLISHED <---- <SYN,ACK,CookieOpt=C> ---------- SYN-RCVD
(caches cookie C)
Performing TCP Fast Open in connection 2:
接続2でTCP Fast Openを実行する：
TCP A (Client) TCP B (Server)
______________ ______________
CLOSED LISTEN
#1 SYN-SENT ----- <SYN=x,CookieOpt=C,DATA_A> ----> SYN-RCVD
#2 ESTABLISHED <---- <SYN=y,ACK=x+len(DATA_A)+1> ---- SYN-RCVD
#3 ESTABLISHED <---- <ACK=x+len(DATA_A)+1,DATA_B>---- SYN-RCVD
#4 ESTABLISHED ----- <ACK=y+1>--------------------> ESTABLISHED
#5 ESTABLISHED --- <ACK=y+len(DATA_B)+1>----------> ESTABLISHED
The Fast Open Cookie is designed to mitigate new security vulnerabilities in order to enable data exchange during a handshake. The cookie is a MAC tag generated by the server and is opaque to the client; the client simply caches the cookie and passes it back on subsequent SYN packets to open new connections. The server can expire the cookie at any time to enhance security.
Fast Open Cookieは、ハンドシェイク中のデータ交換を可能にするために、新しいセキュリティの脆弱性を軽減するように設計されています。 Cookieはサーバーによって生成されたMACタグであり、クライアントに対しては不透明です。クライアントは単にCookieをキャッシュし、それを後続のSYNパケットに戻し、新しい接続を開きます。サーバーはいつでもCookieを期限切れにして、セキュリティを強化できます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kind 1 byte: value = 34 Length 1 byte: range 6 to 18 (bytes); limited by remaining space in the options field. The number MUST be even. Cookie 0, or 4 to 16 bytes (Length - 2)
種類1バイト：値= 34長さ1バイト：範囲6〜18（バイト）;オプションフィールドの残りのスペースによって制限されます。数は偶数でなければなりません。 Cookie 0、または4〜16バイト（長さ-2）
The Fast Open option is used to request or to send a Fast Open Cookie. When a cookie is not present or is empty, the option is used by the client to request a cookie from the server. When the cookie is present, the option is used to pass the cookie from the server to the client or from the client back to the server (to perform a Fast Open).
Fast Openオプションは、Fast Open Cookieを要求または送信するために使用されます。 Cookieが存在しないか空の場合、クライアントはこのオプションを使用して、サーバーにCookieを要求します。 Cookieが存在する場合、このオプションを使用して、Cookieをサーバーからクライアントに、またはクライアントからサーバーに戻します（高速オープンを実行するため）。
The minimum cookie size is 4 bytes. Although the diagram shows a cookie aligned on 32-bit boundaries, alignment is not required. Options with invalid Length values or without the SYN flag set MUST be ignored.
最小Cookieサイズは4バイトです。この図では、32ビット境界に配置されたCookieを示していますが、配置は必須ではありません。無効な長さの値があるオプション、またはSYNフラグが設定されていないオプションは無視する必要があります。
The server is in charge of cookie generation and authentication. The cookie SHOULD be a MAC tag with the following properties. We use "SHOULD" because, in some cases, the cookie may be trivially generated as discussed in Section 7.3.
サーバーはCookieの生成と認証を担当します。クッキーは以下のプロパティを持つMACタグであるべきです（SHOULD）。セクション7.3で説明したように、Cookieが簡単に生成される場合があるため、「SHOULD」を使用します。
1. The cookie authenticates the client's (source) IP address of the SYN packet. The IP address may be an IPv4 or IPv6 address.
1. Cookieは、SYNパケットのクライアント（ソース）IPアドレスを認証します。 IPアドレスはIPv4またはIPv6アドレスです。
2. The cookie can only be generated by the server and cannot be fabricated by any other parties, including the client.
2. Cookieはサーバーでのみ生成でき、クライアントを含む他の当事者が作成することはできません。
3. The generation and verification are fast relative to the rest of SYN and SYN-ACK processing.
3. 生成と検証は、残りのSYNおよびSYN-ACK処理に比べて高速です。
4. A server may encode other information in the cookie and accept more than one valid cookie per client at any given time. But this is server-implementation dependent and transparent to the client.
4. サーバーはCookie内の他の情報をエンコードし、クライアントごとに複数の有効なCookieをいつでも受け入れることができます。ただし、これはサーバー実装に依存し、クライアントに対して透過的です。
5. The cookie expires after a certain amount of time. The reason for cookie expiration is detailed in the "Security Considerations" section (Section 5). This can be done by either periodically changing the server key used to generate cookies or including a timestamp when generating the cookie.
5. Cookieは一定の時間が経過すると期限切れになります。 Cookieの有効期限の理由については、「セキュリティに関する考慮事項」セクション（セクション5）で詳しく説明しています。これは、Cookieの生成に使用されるサーバーキーを定期的に変更するか、Cookieの生成時にタイムスタンプを含めることで実行できます。
To gradually invalidate cookies over time, the server can implement key rotation to generate and verify cookies using multiple keys. This approach is useful for large-scale servers to retain Fast Open rolling key updates. We do not specify a particular mechanism because the implementation is server specific.
時間の経過とともにCookieを徐々に無効にするために、サーバーはキーローテーションを実装して、複数のキーを使用してCookieを生成および検証できます。このアプローチは、大規模サーバーがFast Openローリングキー更新を保持するのに役立ちます。実装はサーバー固有であるため、特定のメカニズムは指定しません。
The server supports the cookie-generation and verification operations:
サーバーは、Cookieの生成と検証の操作をサポートしています。
- GetCookie(IP_Address): returns a (new) cookie.
- GetCookie（IP_Address）：（新しい）Cookieを返します。
- IsCookieValid(IP_Address, Cookie): checks if the cookie is valid, i.e., it has not expired and the cookie authenticates the client IP address.
- IsCookieValid（IP_Address、Cookie）：Cookieが有効かどうか、つまり、有効期限が切れておらず、CookieがクライアントのIPアドレスを認証しているかどうかを確認します。
Example Implementation: a simple implementation is to use AES_128 to encrypt the IPv4 (with padding) or IPv6 address and truncate to 64 bits. The server can periodically update the key to expire the cookies. AES encryption on recent processors is fast and takes only a few hundred nanoseconds [RCCJR11].
実装例：単純な実装は、AES_128を使用してIPv4（パディング付き）またはIPv6アドレスを暗号化し、64ビットに切り捨てることです。サーバーは定期的にキーを更新してCookieを期限切れにすることができます。最近のプロセッサーのAES暗号化は高速で、数百ナノ秒しかかかりません[RCCJR11]。
If only one valid cookie is allowed per IP, and the server can regenerate the cookie independently, the best validation process is to simply regenerate a valid cookie and compare it against the incoming cookie. In that case, if the incoming cookie fails the check, a valid cookie is readily available to be sent to the client.
IPごとに1つの有効なCookieのみが許可されており、サーバーがCookieを個別に再生成できる場合、最適な検証プロセスは、有効なCookieを再生成して、着信Cookieと比較することです。その場合、着信Cookieがチェックに失敗すると、有効なCookieをすぐにクライアントに送信できます。
The client MUST cache cookies from servers for later Fast Open connections. For a multihomed client, the cookies are dependent on the client and server IP addresses. Hence, the client should cache at most one (most recently received) cookie per client and server IP address pair.
クライアントは、後の高速オープン接続のためにサーバーからのCookieをキャッシュする必要があります。マルチホームクライアントの場合、CookieはクライアントとサーバーのIPアドレスに依存します。したがって、クライアントは、クライアントとサーバーのIPアドレスのペアごとに最大で1つの（最近受信した）Cookieをキャッシュする必要があります。
When caching cookies, we recommend that the client also cache the Maximum Segment Size (MSS) advertised by the server. The client can cache the MSS advertised by the server in order to determine the maximum amount of data that the client can fit in the SYN packet in subsequent TFO connections. Caching the server MSS is useful because, with Fast Open, a client sends data in the SYN packet before the server announces its MSS in the SYN-ACK packet. If the client sends more data in the SYN packet than the server will accept, this will likely require the client to retransmit some or all of the data. Hence, caching the server MSS can enhance performance.
Cookieをキャッシュするときは、サーバーが通知する最大セグメントサイズ（MSS）もクライアントでキャッシュすることをお勧めします。クライアントは、クライアントが後続のTFO接続のSYNパケットに収めることができるデータの最大量を決定するために、サーバーによってアドバタイズされたMSSをキャッシュできます。 Fast Openでは、サーバーがSYN-ACKパケットでMSSをアナウンスする前にクライアントがSYNパケットでデータを送信するため、サーバーのMSSをキャッシュすることは有用です。クライアントがサーバーが受け入れるよりも多くのデータをSYNパケットで送信する場合、クライアントはデータの一部またはすべてを再送信する必要があります。したがって、サーバーMSSをキャッシュすると、パフォーマンスが向上します。
Without a cached server MSS, the amount of data in the SYN packet is limited to the default MSS of 536 bytes for IPv4 [RFC1122] and 1220 bytes for IPv6 [RFC2460]. Even if the client complies with this limit when sending the SYN, it is known that an IPv4 receiver advertising an MSS less than 536 bytes can receive a segment larger than it is expecting.
キャッシュされたサーバーMSSがない場合、SYNパケットのデータ量は、デフォルトのMSSであるIPv4 [RFC1122]では536バイト、IPv6 [RFC2460]では1220バイトに制限されます。 SYNを送信するときにクライアントがこの制限に準拠していても、MSSを536バイト未満にアドバタイズするIPv4レシーバーは、予想よりも大きなセグメントを受信できることがわかっています。
If the cached MSS is larger than the typical size (1460 bytes for IPv4 or 1440 bytes for IPv6), then the excess data in the SYN packet may cause problems that offset the performance benefit of Fast Open. For example, the unusually large SYN may trigger IP fragmentation and may confuse firewalls or middleboxes, causing SYN retransmission and other side effects. Therefore, the client MAY limit the cached MSS to 1460 bytes for IPv4 or 1440 for IPv6.
キャッシュされたMSSが通常のサイズ（IPv4の場合は1460バイトまたはIPv6の場合は1440バイト）より大きい場合、SYNパケット内の過剰なデータにより、Fast Openのパフォーマンス上の利点を相殺する問題が発生する可能性があります。たとえば、異常に大きいSYNはIPの断片化を引き起こし、ファイアウォールやミドルボックスを混乱させ、SYN再送信やその他の副作用を引き起こす可能性があります。したがって、クライアントはキャッシュされたMSSをIPv4の場合は1460バイトに、IPv6の場合は1440バイトに制限してもよい（MAY）。
The client MUST cache negative responses from the server in order to avoid potential connection failures. Negative responses include the server not acknowledging the data in the SYN, ICMP error messages, and (most importantly) no response (SYN-ACK) from the server at all, i.e., connection timeout. The last case is likely due to incompatible middleboxes or firewall blocking the connection completely after processing the SYN packet with data. If the client does not react to these negative responses and continues to retry Fast Open, the client may never be able to connect to the specific server.
潜在的な接続障害を回避するために、クライアントはサーバーからの否定応答をキャッシュする必要があります。否定応答には、サーバーがSYN、ICMPエラーメッセージのデータを確認しないこと、および（最も重要なこととして）サーバーからの応答がない（SYN-ACK）、つまり接続タイムアウトが含まれます。最後のケースは、互換性のないミドルボックスまたはファイアウォールが、SYNパケットをデータで処理した後、接続を完全にブロックしたことが原因である可能性があります。クライアントがこれらの否定的な応答に反応せず、高速オープンを再試行し続ける場合、クライアントは特定のサーバーに接続できない可能性があります。
For any negative responses, the client SHOULD disable Fast Open on the specific path (the source and destination IP addresses and ports) at least temporarily. Since TFO is enabled on a per-service-port basis, but cookies are independent of service ports, the client's cache should include remote port numbers, too.
否定的な応答の場合、クライアントは特定のパス（送信元と宛先のIPアドレスとポート）でFast Openを少なくとも一時的に無効にする必要があります（SHOULD）。 TFOはサービスポートごとに有効になっていますが、Cookieはサービスポートから独立しているため、クライアントのキャッシュにはリモートポート番号も含める必要があります。
One predominant requirement of TFO is to be fully compatible with existing TCP implementations, on both the client and server sides.
TFOの主な要件の1つは、クライアント側とサーバー側の両方で、既存のTCP実装と完全に互換性があることです。
The server keeps two variables per listening socket (IP address and port):
サーバーは、リスニングソケットごとに2つの変数（IPアドレスとポート）を保持します。
FastOpenEnabled: default is off. It MUST be turned on explicitly by the application. When this flag is off, the server does not perform any TFO-related operations and MUST ignore all cookie options.
FastOpenEnabled：デフォルトはオフです。アプリケーションで明示的にオンにする必要があります。このフラグがオフの場合、サーバーはTFO関連の操作を実行せず、すべてのCookieオプションを無視する必要があります。
PendingFastOpenRequests: tracks the number of TFO connections in SYN-RCVD state. If this variable goes over a preset system limit, the server MUST disable TFO for all new connection requests until PendingFastOpenRequests drops below the system limit. This variable is used for defending some vulnerabilities discussed in the "Security Considerations" section (Section 5).
PendingFastOpenRequests：SYN-RCVD状態のTFO接続の数を追跡します。この変数が事前設定されたシステム制限を超える場合、サーバーは、PendingFastOpenRequestsがシステム制限を下回るまで、すべての新しい接続要求に対してTFOを無効にする必要があります。この変数は、「セキュリティに関する考慮事項」セクション（セクション5）で説明されている一部の脆弱性を防御するために使用されます。
The server keeps a FastOpened flag per connection to mark if a connection has successfully performed a TFO.
サーバーは、接続ごとにFastOpenedフラグを保持して、接続がTFOを正常に実行したかどうかをマークします。
Any client attempting TFO MUST first request a cookie from the server with the following steps:
TFOを試みるクライアントは、最初に次の手順でサーバーにCookieを要求する必要があります。
1. The client sends a SYN packet with a Fast Open option with a Length field of 0 (empty cookie field).
1. クライアントは、長さフィールドが0（空のcookieフィールド）の高速オープンオプションでSYNパケットを送信します。
2. The server responds with a SYN-ACK based on the procedures in the "Server Cookie Handling" section (Section 4.1.2). This SYN-ACK may contain a Fast Open option if the server currently supports TFO for this listener port.
2. サーバーは、「サーバーCookieの処理」セクション（セクション4.1.2）の手順に基づいてSYN-ACKで応答します。サーバーが現在このリスナーポートのTFOをサポートしている場合、このSYN-ACKにはFast Openオプションが含まれる場合があります。
3. If the SYN-ACK has a Fast Open option with a cookie, the client replaces the cookie and other information as described in the "Client Cookie Handling" section (Section 4.1.3). Otherwise, if the SYN-ACK is first seen and not a (spurious) retransmission, the client MAY remove the server information from the cookie cache. If the SYN-ACK is a spurious retransmission, the client does nothing to the cookie cache for the reasons below.
3. SYN-ACKにCookieを含む高速オープンオプションがある場合、クライアントは、「クライアントのCookieの処理」セクション（セクション4.1.3）で説明されているように、Cookieとその他の情報を置き換えます。それ以外の場合、SYN-ACKが最初に確認され、（偽の）再送信ではない場合、クライアントはCookieキャッシュからサーバー情報を削除できます（MAY）。 SYN-ACKが偽の再送信である場合、クライアントは以下の理由によりCookieキャッシュに対して何もしません。
The network or servers may drop the SYN or SYN-ACK packets with the new cookie options, which will cause SYN or SYN-ACK timeouts. We RECOMMEND both the client and the server to retransmit SYN and SYN-ACK packets without the cookie options on timeouts. This ensures the connections of cookie requests will go through and lowers the latency penalty (of dropped SYN/SYN-ACK packets). The obvious downside for maximum compatibility is that any regular SYN drop will fail the cookie (although one can argue the delay in the data transmission until after the 3WHS is justified if the SYN drop is due to network congestion). The next section describes a heuristic to detect such drops when the client receives the SYN-ACK.
ネットワークまたはサーバーは、新しいCookieオプションを使用してSYNまたはSYN-ACKパケットをドロップする場合があり、SYNまたはSYN-ACKタイムアウトが発生します。タイムアウトのCookieオプションなしでSYNおよびSYN-ACKパケットを再送信することをクライアントとサーバーの両方に推奨します。これにより、Cookie要求の接続が確実に通過し、（ドロップされたSYN / SYN-ACKパケットの）待ち時間のペナルティが低下します。最大の互換性の明らかな欠点は、通常のSYNドロップがcookieに失敗することです（ただし、SYNドロップがネットワークの輻輳が原因である場合は、3WHSが正当化されるまでデータ転送の遅延を主張できます）。次のセクションでは、クライアントがSYN-ACKを受信したときにそのようなドロップを検出するヒューリスティックについて説明します。
We also RECOMMEND the client to record the set of servers that failed to respond to cookie requests and only attempt another cookie request after a certain period.
また、Cookieリクエストへの応答に失敗したサーバーのセットを記録し、特定の期間が経過した後にのみ別のCookieリクエストを試行することもクライアントに推奨します。
Once the client obtains the cookie from the target server, it can perform subsequent TFO connections until the cookie is expired by the server.
クライアントがターゲットサーバーからCookieを取得すると、サーバーによってCookieの有効期限が切れるまで、後続のTFO接続を実行できます。
Client: Sending SYN
クライアント：SYNの送信
To open a TFO connection, the client MUST have obtained a cookie from the server:
TFO接続を開くには、クライアントがサーバーからCookieを取得している必要があります。
1. Send a SYN packet.
1. SYNパケットを送信します。
a. If the SYN packet does not have enough option space for the Fast Open option, abort TFO and fall back to the regular 3WHS.
a. SYNパケットにFast Openオプション用の十分なオプションスペースがない場合は、TFOを中止して、通常の3WHSにフォールバックします。
b. Otherwise, include the Fast Open option with the cookie of the server. Include any data up to the cached server MSS or default 536 bytes.
b. それ以外の場合は、サーバーのCookieにFast Openオプションを含めます。キャッシュされたサーバーのMSSまたはデフォルトの536バイトまでのデータを含めます。
2. Advance to SYN-SENT state and update SND.NXT to include the data accordingly.
2. SYN-SENT状態に進み、SND.NXTを更新して、それに応じてデータを含めます。
To deal with network or servers dropping SYN packets with payload or unknown options, when the SYN timer fires, the client SHOULD retransmit a SYN packet without data and Fast Open options.
ペイロードまたは不明なオプションを含むSYNパケットをドロップするネットワークまたはサーバーに対処するために、SYNタイマーが起動すると、クライアントはデータおよび高速オープンオプションなしでSYNパケットを再送信する必要があります（SHOULD）。
Server: Receiving SYN and responding with SYN-ACK
サーバー：SYNを受信し、SYN-ACKで応答する
Upon receiving the SYN packet with Fast Open option:
Fast OpenオプションでSYNパケットを受信すると：
1. Initialize and reset a local FastOpened flag. If FastOpenEnabled is false, go to step 5.
1. ローカルのFastOpenedフラグを初期化してリセットします。 FastOpenEnabledがfalseの場合は、手順5に進みます。
2. If PendingFastOpenRequests is over the system limit, go to step 5.
2. PendingFastOpenRequestsがシステム制限を超えている場合は、手順5に進みます。
3. If IsCookieValid() (in Section 4.1.2) returns false, go to step 5.
3. IsCookieValid()（セクション4.1.2）がfalseを返す場合は、手順5に進みます。
4. Buffer the data and notify the application. Set the FastOpened flag and increment PendingFastOpenRequests.
4. データをバッファリングし、アプリケーションに通知します。 FastOpenedフラグを設定し、PendingFastOpenRequestsを増分します。
5. Send the SYN-ACK packet. The packet MAY include a Fast Open option. If the FastOpened flag is set, the packet acknowledges the SYN and data sequence. Otherwise, it acknowledges only the SYN sequence. The server MAY include data in the SYN-ACK packet if the response data is readily available. Some applications may favor delaying the SYN-ACK, allowing the application to process the request in order to produce a response, but this is left up to the implementation.
5. SYN-ACKパケットを送信します。パケットには、高速オープンオプションが含まれる場合があります。 FastOpenedフラグが設定されている場合、パケットはSYNおよびデータシーケンスを確認します。それ以外の場合は、SYNシーケンスのみを確認します。応答データがすぐに利用できる場合、サーバーはSYN-ACKパケットにデータを含めることができます。一部のアプリケーションはSYN-ACKの遅延を優先し、アプリケーションが応答を生成するために要求を処理できるようにしますが、これは実装に任されています。
6. Advance to the SYN-RCVD state. If the FastOpened flag is set, the server MUST follow [RFC5681] (based on [RFC3390]) to set the initial congestion window for sending more data packets.
6. SYN-RCVD状態に進みます。 FastOpenedフラグが設定されている場合、サーバーは[RFC5681]（[RFC3390]に基づく）に従って、より多くのデータパケットを送信するための初期の輻輳ウィンドウを設定する必要があります。
If the SYN-ACK timer fires, the server SHOULD retransmit a SYN-ACK segment with neither data nor Fast Open options for compatibility reasons.
SYN-ACKタイマーが作動した場合、サーバーは、互換性の理由から、データオプションも高速オープンオプションも含まないSYN-ACKセグメントを再送信する必要があります（SHOULD）。
A special case is simultaneous open where the SYN receiver is a client in SYN-SENT state. The protocol remains the same because [RFC793] already supports both data in the SYN and simultaneous open. But the client's socket may have data available to read before it's connected. This document does not cover the corresponding API change.
特別なケースは、SYN受信側がSYN-SENT状態のクライアントである同時オープンです。 [RFC793]はすでにSYNのデータと同時オープンの両方をサポートしているため、プロトコルは同じです。ただし、クライアントのソケットには、接続前に読み取ることができるデータがある場合があります。このドキュメントでは、対応するAPIの変更については説明していません。
Client: Receiving SYN-ACK
クライアント：SYN-ACKの受信
The client SHOULD perform the following steps upon receiving the SYN-ACK:
クライアントは、SYN-ACKを受信すると、次の手順を実行する必要があります（SHOULD）。
1. If the SYN-ACK has a Fast Open option, an MSS option, or both, update the corresponding cookie and MSS information in the cookie cache.
1. SYN-ACKにFast Openオプション、MSSオプション、またはその両方がある場合、対応するCookieとCookieキャッシュ内のMSS情報を更新します。
2. Send an ACK packet. Set acknowledgment number to RCV.NXT and include the data after SND.UNA if data is available.
2. ACKパケットを送信します。確認番号をRCV.NXTに設定し、データが利用可能な場合はSND.UNAの後にデータを含めます。
3. Advance to the ESTABLISHED state.
3. ESTABLISHED状態に進みます。
Note there is no latency penalty if the server does not acknowledge the data in the original SYN packet. The client SHOULD retransmit any unacknowledged data in the first ACK packet in step 2. The data exchange will start after the handshake like a regular TCP connection.
サーバーが元のSYNパケットのデータを確認応答しない場合、待ち時間のペナルティはないことに注意してください。クライアントは、ステップ2の最初のACKパケットで未確認のデータを再送信する必要があります（SHOULD）。データ交換は、通常のTCP接続のようにハンドシェイクの後に開始されます。
If the client has timed out and retransmitted only regular SYN packets, it can heuristically detect paths that intentionally drop SYNs with the Fast Open option or data. If the SYN-ACK acknowledges only the initial sequence and does not carry a Fast Open cookie option, presumably it is triggered by a retransmitted (regular) SYN and the original SYN or the corresponding SYN-ACK was lost.
クライアントがタイムアウトし、通常のSYNパケットのみを再送信した場合、高速オープンオプションまたはデータを使用して意図的にSYNをドロップするパスを発見的に検出できます。 SYN-ACKが初期シーケンスのみを確認し、Fast Open cookieオプションを運ばない場合、おそらくそれは再送信された（通常の）SYNによってトリガーされ、元のSYNまたは対応するSYN-ACKが失われました。
Server: Receiving ACK
サーバー：ACKを受信しています
Upon receiving an ACK acknowledging the SYN sequence, the server decrements PendingFastOpenRequests and advances to the ESTABLISHED state. No special handling is required further.
SYNシーケンスを確認するACKを受信すると、サーバーはPendingFastOpenRequestsをデクリメントし、ESTABLISHED状態に進みます。さらに特別な処理は必要ありません。
The Fast Open Cookie stops an attacker from trivially flooding spoofed SYN packets with data to burn server resources or to mount an amplified reflection attack on random hosts. The server can defend against spoofed SYN floods with invalid cookies using existing techniques [RFC4987]. We note that although generating bogus cookies is cost free, the cost of validating the cookies, inherent to any authentication scheme, may be substantial compared to processing a regular SYN packet. We describe these new vulnerabilities of TFO and the countermeasures in detail below.
Fast Open Cookieは、攻撃者がデータで偽装されたSYNパケットをあふれさせてサーバーリソースを焼き付けたり、ランダムなホストに増幅反射攻撃を仕掛けたりするのを防ぎます。サーバーは、既存の手法[RFC4987]を使用して、無効なCookieでスプーフィングされたSYNフラッドを防御できます。偽のCookieの生成は無料ですが、認証スキームに固有のCookieを検証するコストは、通常のSYNパケットの処理に比べてかなり高くなる可能性があります。以下では、TFOのこれらの新しい脆弱性とその対策について詳しく説明します。
An attacker may still obtain cookies from some compromised hosts, then flood spoofed SYN packets with data and "valid" cookies (from these hosts or other vantage points). Like regular TCP handshakes, TFO is vulnerable to such an attack. But the potential damage can be much more severe. Besides causing temporary disruption to service ports under attack, it may exhaust server CPU and memory resources. Such an attack will show up on application server logs as an application-level DoS from botnets, triggering other defenses and alerts.
攻撃者は引き続き、侵害された一部のホストからCookieを取得し、スプーフィングされたSYNパケットにデータと「有効な」Cookieを（これらのホストまたは他の視点から）フラッディングします。通常のTCPハンドシェイクと同様に、TFOはこのような攻撃に対して脆弱です。しかし、潜在的な被害ははるかに深刻になる可能性があります。攻撃を受けているサービスポートに一時的な混乱を引き起こすだけでなく、サーバーのCPUおよびメモリリソースを使い果たす可能性があります。このような攻撃は、ボットネットからのアプリケーションレベルのDoSとしてアプリケーションサーバーログに表示され、他の防御やアラートをトリガーします。
To protect the server, it is important to limit the maximum number of total pending TFO connection requests, i.e., PendingFastOpenRequests (Section 4.2). When the limit is exceeded, the server temporarily disables TFO entirely as described in "Server Cookie Handling" (Section 4.1.2). Then, subsequent TFO requests will be downgraded to regular connection requests, i.e., with the data dropped and only SYNs acknowledged. This allows regular SYN flood defense techniques [RFC4987] like SYN cookies to kick in and prevent further service disruption.
サーバーを保護するには、保留中のTFO接続リクエストの総数、つまりPendingFastOpenRequests（セクション4.2）の最大数を制限することが重要です。この制限を超えると、「サーバーのCookieの処理」（セクション4.1.2）で説明されているように、サーバーは一時的にTFOを完全に無効にします。その後、後続のTFOリクエストは通常の接続リクエストにダウングレードされます。つまり、データが削除され、SYNのみが確認されます。これにより、SYN Cookieのような定期的なSYNフラッド防御技術[RFC4987]が起動し、サービスの中断を防ぐことができます。
The main impact of SYN floods against the standard TCP stack is not directly from the floods themselves costing TCP processing overhead or host memory, but rather from the spoofed SYN packets filling up the often small listener's queue.
標準のTCPスタックに対するSYNフラッドの主な影響は、TCP処理のオーバーヘッドやホストメモリを消費するフラッド自体から直接ではなく、スプーフィングされたSYNパケットが小さなリスナーのキューをいっぱいにすることによるものです。
On the other hand, TFO SYN floods can cause damage directly if admitted without limit into the stack. The reset (RST) packets from the spoofed host will fuel rather than defeat the SYN floods as compared to the non-TFO case, because the attacker can flood more SYNs with data and incur more cost in terms of data processing resources. For this reason, a TFO server needs to monitor the connections in SYN-RCVD being reset in addition to imposing a reasonable max queue length. Implementations may combine the two, e.g., by continuing to account for those connection requests that have just been reset against the listener's PendingFastOpenRequests until a timeout period has passed.
一方、スタックへの制限なしで許可された場合、TFO SYNフラッドは直接損傷を引き起こす可能性があります。スプーフィングされたホストからのリセット（RST）パケットは、非TFOの場合と比較して、SYNフラッドを回避するのではなく、燃料を供給します。これは、攻撃者がより多くのSYNをデータでフラッディングし、データ処理リソースのコストを増やす可能性があるためです。このため、TFOサーバーは、適切な最大キュー長を課すことに加えて、リセットされるSYN-RCVDの接続を監視する必要があります。実装では、たとえば、タイムアウト期間が経過するまでリスナーのPendingFastOpenRequestsに対してリセットされたばかりの接続要求を引き続き説明することにより、2つを組み合わせることができます。
Limiting the maximum number of pending TFO connection requests does make it easy for an attacker to overflow the queue, causing TFO to be disabled. We argue that causing TFO to be disabled is unlikely to be of interest to attackers because the service will remain intact without TFO; hence, there is hardly any real damage.
保留中のTFO接続要求の最大数を制限すると、攻撃者がキューをオーバーフローしやすくなり、TFOが無効になります。 TFOを無効にしてもサービスはTFOがなくても影響を受けないため、攻撃者が関心を持つ可能性は低いと私たちは主張します。したがって、実際の損傷はほとんどありません。
An attacker behind a NAT can easily obtain valid cookies to launch the above attack to hurt other clients that share the path. [BRISCOE12] suggested that the server can extend cookie generation to include the TCP timestamp -- GetCookie(IP_Address, Timestamp) -- and implement it by encrypting the concatenation of the two values to generate the cookie. The client stores both the cookie and its corresponding timestamp, and it echoes both in the SYN. The server then implements IsCookieValid(IP_Address, Timestamp, Cookie) by encrypting the IP and timestamp data and comparing it with the cookie value.
NATの背後にいる攻撃者は、有効なCookieを簡単に取得して上記の攻撃を開始し、パスを共有する他のクライアントを傷つけることができます。 [BRISCOE12]は、サーバーがCookieの生成を拡張してTCPタイムスタンプ-GetCookie（IP_Address、Timestamp）-を含め、2つの値の連結を暗号化してCookieを生成することで実装することを提案しました。クライアントはCookieとそれに対応するタイムスタンプの両方を保存し、両方をSYNにエコーします。次に、サーバーはIPおよびタイムスタンプデータを暗号化し、それをCookie値と比較することにより、IsCookieValid（IP_Address、Timestamp、Cookie）を実装します。
This enables the server to issue different cookies to clients that share the same IP address; hence, it can selectively discard those misused cookies from the attacker. However, the attacker can simply repeat the attack with new cookies. The server would eventually need to throttle all requests from the IP address just like the current approach. Moreover, this approach requires modifying [RFC1323] (obsoleted by [RFC7323]) to send a non-zero Timestamp Echo Reply in the SYN, potentially causing firewall issues. Therefore, we believe the benefit does not outweigh the drawbacks.
これにより、サーバーは同じIPアドレスを共有するクライアントに異なるCookieを発行できます。したがって、悪用されたCookieを攻撃者から選択的に破棄できます。ただし、攻撃者は新しいCookieで攻撃を繰り返すだけです。サーバーは最終的に、現在のアプローチと同様に、IPアドレスからのすべての要求を抑制する必要があります。さらに、このアプローチでは、SYNでゼロ以外のタイムスタンプエコー応答を送信するように[RFC1323]（[RFC7323]で廃止）を変更する必要があり、ファイアウォールの問題を引き起こす可能性があります。したがって、利点は欠点を上回らないと考えています。
Limiting PendingFastOpenRequests with a system limit can be done without Fast Open cookies and would protect the server from resource exhaustion. It would also limit how much damage an attacker can cause through an amplified reflection attack from that server. However, it would still be vulnerable to an amplified reflection attack from a large number of servers. An attacker can easily cause damage by tricking many servers to respond with data packets at once to any spoofed victim IP address of choice.
PendingFastOpenRequestsをシステム制限で制限することは、Fast Open Cookieなしで実行でき、サーバーをリソースの枯渇から保護します。また、そのサーバーからの増幅されたリフレクション攻撃によって攻撃者が引き起こす可能性のあるダメージを制限します。ただし、それでも多数のサーバーからの増幅されたリフレクション攻撃に対して脆弱です。攻撃者は、多くのサーバーをだまして、選択したなりすましの被害者IPアドレスに一度にデータパケットで応答するように仕向けることで、簡単に被害を与えることができます。
With the use of Fast Open cookies, the attacker would first have to steal a valid cookie from its target victim. This likely requires the attacker to compromise the victim host or network first. But, in some cases, it may be relatively easy.
攻撃者は、Fast Open Cookieを使用して、最初にターゲットの犠牲者から有効なCookieを盗む必要があります。このため、攻撃者はまず被害者のホストまたはネットワークを侵害する必要があります。ただし、比較的簡単な場合もあります。
The attacker here has little interest in mounting an attack on the victim host that has already been compromised. But it may be motivated to disrupt the victim's network. Since a stolen cookie is only valid for a single server, it has to steal valid cookies from a large number of servers and use them before they expire to cause sufficient damage without triggering the defense.
ここでの攻撃者は、すでに侵害された被害者のホストに攻撃を仕掛けることにはほとんど関心がありません。しかし、被害者のネットワークを混乱させる動機になる可能性があります。盗まれたCookieは単一のサーバーでのみ有効であるため、多数のサーバーから有効なCookieを盗み、有効期限が切れる前にそれらを使用して、防御をトリガーすることなく十分なダメージを与える必要があります。
One can argue that if the attacker has compromised the target network or hosts, it could perform a similar but simpler attack by injecting bits directly. The degree of damage will be identical, but a TFO-specific attack allows the attacker to remain anonymous and disguises the attack as from other servers.
攻撃者が標的のネットワークまたはホストに危害を加えた場合、ビットを直接注入することにより、同様の簡単な攻撃を実行できると主張することができます。被害の程度は同じですが、TFO固有の攻撃により、攻撃者は匿名のままで他のサーバーからのように偽装できます。
For example, with DHCP, an attacker can obtain cookies when he (or the host he has compromised) owns a particular IP address by performing regular Fast Open to servers supporting TFO and he can collect valid cookies. Then, the attacker actively or passively releases his IP address. When the IP address is reassigned to another host (victim) via DHCP, the attacker then floods spoofed Fast Open requests with valid cookies to the servers. Since the cookies are valid, these servers accept the requests and respond with a SYN-ACK plus data packets to the victim instead of the attacker. Thus, the attacker is able to launch amplified reflection attacks to other hosts that share IP addresses.
たとえば、DHCPを使用すると、攻撃者は、攻撃者（または侵入したホスト）がTFOをサポートするサーバーに対して定期的なFast Openを実行することによって特定のIPアドレスを所有している場合にCookieを取得し、有効なCookieを収集できます。次に、攻撃者は自分のIPアドレスをアクティブまたはパッシブに解放します。 IPアドレスがDHCP経由で別のホスト（被害者）に再割り当てされると、攻撃者はスプーフィングされたFast Open要求を有効なCookieでサーバーにフラッディングします。 Cookieは有効であるため、これらのサーバーは要求を受け入れ、SYN-ACKとデータパケットで攻撃者ではなく被害者に応答します。したがって、攻撃者は、IPアドレスを共有する他のホストに対して増幅されたリフレクション攻撃を開始することができます。
The best defense is for the server not to respond with data until the handshake finishes. In this case, the risk of an amplification reflection attack is completely eliminated. But the potential latency saving from TFO may diminish if the server application produces responses earlier before the handshake completes.
最善の防御策は、ハンドシェイクが完了するまでサーバーがデータで応答しないことです。この場合、増幅反射攻撃のリスクは完全に排除されます。ただし、サーバーアプリケーションがハンドシェイクの完了前に応答を生成すると、TFOによる潜在的なレイテンシ節約が減少する可能性があります。
This section is to help applications considering TFO to evaluate TFO's benefits and drawbacks using the Web client and server applications as an example throughout. Applications here refer specifically to the process that writes data into the socket -- for example, a JavaScript process that sends data to the server. A proposed socket API change is provided in the Appendix.
このセクションは、TFOを検討しているアプリケーションが、Webクライアントおよびサーバーアプリケーションを例として使用して、TFOの利点と欠点を評価するのに役立ちます。ここでのアプリケーションとは、特にデータをサーバーに送信するJavaScriptプロセスなど、ソケットにデータを書き込むプロセスを指します。提案されたソケットAPIの変更は、付録に記載されています。
It is possible that using TFO results in the first data written to a socket to be delivered more than once to the application on the remote host (Section 2.1). This replay potential only applies to data in the SYN but not subsequent data exchanges.
TFOを使用すると、最初のデータがソケットに書き込まれ、リモートホスト上のアプリケーションに複数回配信される可能性があります（セクション2.1）。この再生の可能性は、SYNのデータにのみ適用され、その後のデータ交換には適用されません。
Empirically, [JIDKT07] showed the packet duplication on a Tier-1 network is rare. Since the replay only happens specifically when the SYN data packet is duplicated and also the duplicate arrives after the receiver has cleared the original SYN's connection state, the replay is thought to be uncommon in practice. Nevertheless, a client that cannot handle receiving the same SYN data more than once MUST NOT enable TFO to send data in a SYN. Similarly, a server that cannot accept receiving the same SYN data more than once MUST NOT enable TFO to receive data in a SYN. Further investigation is needed to judge the probability of receiving duplicated SYN or SYN-ACK packets with data in networks that are not Tier 1.
経験的に、[JIDKT07]は、Tier-1ネットワークでのパケットの重複はまれであることを示しました。特にSYNデータパケットが複製され、受信者が元のSYNの接続状態をクリアした後に複製が到着した場合にのみ、再生が発生するため、実際には再生は一般的ではないと考えられています。それでも、同じSYNデータの受信を複数回処理できないクライアントは、TFOがSYNでデータを送信できるようにしてはなりません（MUST NOT）。同様に、同じSYNデータの受信を2回以上受け入れることができないサーバーは、TFOがSYNでデータを受信できるようにしてはなりません（MUST NOT）。 Tier 1以外のネットワークでデータと重複したSYNまたはSYN-ACKパケットを受信する可能性を判断するには、さらに調査が必要です。
TFO is designed for latency-conscious applications that are sensitive to TCP's initial connection setup delay. To benefit from TFO, the first application data unit (e.g., an HTTP request) needs to be no more than TCP's maximum segment size (minus options used in the SYN). Otherwise, the remote server can only process the client's application data unit once the rest of it is delivered after the initial handshake, diminishing TFO's benefit.
TFOは、TCPの初期接続セットアップの遅延に影響されやすい遅延を重視するアプリケーション向けに設計されています。 TFOを活用するには、最初のアプリケーションデータユニット（HTTPリクエストなど）がTCPの最大セグメントサイズ（SYNで使用されるオプションを除く）を超えないようにする必要があります。それ以外の場合、リモートサーバーがクライアントのアプリケーションデータユニットを処理できるのは、最初のハンドシェイク後に残りのデータデータユニットが配信された後のみであり、TFOの利点は減少します。
To the extent possible, applications SHOULD reuse the connection to take advantage of TCP's built-in congestion control and reduce connection setup overhead. An application that employs too many short-lived connections will negatively impact network stability, as these connections often exit before TCP's congestion control algorithm takes effect.
アプリケーションは、可能な限り、接続を再利用して、TCPの組み込みの輻輳制御を利用し、接続設定のオーバーヘッドを削減する必要があります。 TCPの輻輳制御アルゴリズムが有効になる前にこれらの接続が終了することが多いため、短期間の接続を多く使用しているアプリケーションは、ネットワークの安定性に悪影響を及ぼします。
While TFO is motivated by Web applications, the browser should not use TFO to send requests in SYNs if those requests cannot tolerate replays. One example is POST requests without application-layer transaction protection (e.g., a unique identifier in the request header).
TFOはWebアプリケーションによって動機付けられますが、ブラウザがTFOを使用してSYNで要求を送信することはできません。 1つの例は、アプリケーションレイヤートランザクション保護なしのPOSTリクエストです（リクエストヘッダー内の一意の識別子など）。
On the other hand, TFO is particularly useful for GET requests. GET request replay could happen across striped TCP connections: after a server receives an HTTP request but before the ACKs of the requests reach the browser, the browser may time out and retry the same request on another (possibly new) TCP connection. This differs from a TFO replay only in that the replay is initiated by the browser, not by the TCP stack.
一方、TFOはGETリクエストに特に役立ちます。 GETリクエストの再生は、ストライプ化されたTCP接続で発生する可能性があります。サーバーがHTTPリクエストを受信した後、リクエストのACKがブラウザに到達する前に、ブラウザがタイムアウトして、別の（おそらく新しい）TCP接続で同じリクエストを再試行する場合があります。これは、再生がTCPスタックではなくブラウザによって開始されるという点でのみTFO再生とは異なります。
For Transport Layer Security (TLS) over TCP, it is safe and useful to include a TLS client_hello in the SYN packet to save one RTT in the TLS handshake. There is no concern about violating idempotency. In particular, it can be used alone with the speculative connection above.
TCP上のトランスポート層セキュリティ（TLS）の場合、SYNパケットにTLS client_helloを含めて、TLSハンドシェイクに1つのRTTを保存することは安全で便利です。べき等の違反についての心配はありません。特に、上記の投機的接続と組み合わせて単独で使用できます。
Is TFO useful given the wide deployment of HTTP persistent connections? The short answer is yes. Studies ([RCCJR11] [AERG11]) show that the average number of transactions per connection is between 2 and 4, based on large-scale measurements from both servers and clients. In these studies, the servers and clients both kept idle connections up to several minutes, well into "human think" time.
HTTP永続的接続の幅広い展開を考えると、TFOは役に立ちますか？短い答えはイエスです。調査（[RCCJR11] [AERG11]）は、サーバーとクライアントの両方からの大規模な測定に基づいて、接続ごとのトランザクションの平均数が2〜4であることを示しています。これらの調査では、サーバーとクライアントの両方が数分までアイドル接続を維持し、「人間の思考」時間にまで達しました。
Keeping connections open and idle even longer risks a greater performance penalty. [HNESSK10] and [MQXMZ11] show that the majority of home routers and ISPs fail to meet the 124-minute idle timeout mandated in [RFC5382]. In [MQXMZ11], 35% of mobile ISPs silently time out idle connections within 30 minutes. End hosts, unaware of silent middlebox timeouts, suffer multi-minute TCP timeouts upon using those long-idle connections.
接続を開いたままアイドル状態にしておくと、パフォーマンスがさらに低下するおそれがあります。 [HNESSK10]と[MQXMZ11]は、ホームルーターとISPの大部分が、[RFC5382]で義務付けられている124分のアイドルタイムアウトを満たすことができないことを示しています。 [MQXMZ11]では、モバイルISPの35％がアイドル接続を30分以内に警告なしにタイムアウトします。サイレントミドルボックスタイムアウトを認識しないエンドホストは、これらの長いアイドル接続を使用すると、数分のTCPタイムアウトが発生します。
To circumvent this problem, some applications send frequent TCP keep-alive probes. However, this technique drains power on mobile devices [MQXMZ11]. In fact, power has become such a prominent issue in modern Long Term Evolution (LTE) devices that mobile browsers close HTTP connections within seconds or even immediately [SOUDERS11].
この問題を回避するために、一部のアプリケーションは頻繁にTCPキープアライブプローブを送信します。ただし、この手法はモバイルデバイスの電力を消耗します[MQXMZ11]。実際、最近のLong Term Evolution（LTE）デバイスでは、モバイルブラウザが数秒以内に、またはすぐにさえHTTP接続を閉じるという、電力が非常に大きな問題になっています[SOUDERS11]。
[RCCJR11] studied the performance of the Chrome browser [Chrome] based on 28 days of global statistics. The Chrome browser keeps idle HTTP persistent connections for 5 to 10 minutes. However, the average number of the transactions per connection is only 3.3, and the TCP 3WHS accounts for up to 25% of the HTTP transaction network latency. The authors estimated that TFO improves page load time by 10% to 40% on selected popular Web sites.
[RCCJR11]は、28日間のグローバル統計に基づいてChromeブラウザ[Chrome]のパフォーマンスを調査しました。 Chromeブラウザは、アイドル状態のHTTP持続接続を5〜10分間保持します。ただし、接続ごとのトランザクションの平均数は3.3にすぎず、TCP 3WHSはHTTPトランザクションネットワーク遅延の最大25％を占めます。著者は、TFOが選択された人気のあるWebサイトでページの読み込み時間を10％から40％改善すると推定しました。
Servers behind load balancers that accept connection requests to the same server IP address should use the same key such that they generate identical Fast Open cookies for a particular client IP address. Otherwise, a client may get different cookies across connections; its Fast Open attempts would fall back to the regular 3WHS.
同じサーバーIPアドレスへの接続要求を受け入れるロードバランサーの背後にあるサーバーは、同じキーを使用して、特定のクライアントIPアドレスに対して同一のFast Open Cookieを生成する必要があります。そうしないと、クライアントは接続全体で異なるCookieを取得する可能性があります。その高速オープンの試みは、通常の3WHSにフォールバックします。
We now outline some areas that need experimentation in the Internet and under different network scenarios. These experiments should help evaluate Fast Open benefits and risks and its related protocols.
次に、インターネットおよびさまざまなネットワークシナリオでの実験が必要ないくつかの領域について説明します。これらの実験は、Fast Openのメリットとリスク、およびその関連プロトコルの評価に役立ちます。
[MAF04] found that some middleboxes and end hosts may drop packets with unknown TCP options. Studies ([LANGLEY06] [HNRGHT11]) have found that 6% of the probed paths on the Internet drop SYN packets with data or with unknown TCP options. The TFO protocol deals with this problem by falling back to the regular TCP handshake and retransmitting the SYN without data or cookie options after the initial SYN timeout. Moreover, the implementation is recommended to negatively cache such incidents to avoid recurring timeouts. Further study is required to evaluate the performance impact of these drop behaviors.
[MAF04]は、いくつかのミドルボックスとエンドホストが未知のTCPオプションでパケットをドロップするかもしれないことを発見しました。調査（[LANGLEY06] [HNRGHT11]）により、インターネット上のプローブされたパスの6％が、データまたは未知のTCPオプションを持つSYNパケットをドロップすることがわかりました。 TFOプロトコルは、通常のTCPハンドシェイクにフォールバックし、最初のSYNタイムアウト後にデータまたはCookieオプションなしでSYNを再送信することにより、この問題に対処します。さらに、このようなインシデントをネガティブにキャッシュして、タイムアウトの繰り返しを回避することをお勧めします。これらのドロップ動作のパフォーマンスへの影響を評価するには、さらに調査が必要です。
Another interesting study is the loss of TFO performance benefit behind certain Carrier-Grade NAT (CGN). Typically, hosts behind a NAT sharing the same IP address will get the same cookie for the same server. This will not prevent TFO from working. But, on some CGN configurations where every new TCP connection from the same physical host uses a different public IP address, TFO does not provide latency benefits. However, there is no performance penalty either, as described in the "Client: Receiving SYN-ACK" text in Section 4.2.2.
別の興味深い研究は、特定のキャリアグレードNAT（CGN）の背後にあるTFOパフォーマンスの利点の喪失です。通常、同じIPアドレスを共有するNATの背後にあるホストは、同じサーバーに対して同じCookieを取得します。これはTFOの動作を妨げません。ただし、同じ物理ホストからのすべての新しいTCP接続が異なるパブリックIPアドレスを使用する一部のCGN構成では、TFOはレイテンシの利点を提供しません。ただし、4.2.2項の「クライアント：SYN-ACKの受信」テキストで説明されているように、パフォーマンスの低下もありません。
Although TFO does not directly change TCP's congestion control, there are subtle cases where it could do so. When a SYN-ACK times out, regular TCP reduces the initial congestion window before sending any data [RFC5681]. However, in TFO, the server may have already sent up to an initial window of data.
TFOはTCPの輻輳制御を直接変更しませんが、変更できる微妙なケースがあります。 SYN-ACKがタイムアウトすると、通常のTCPはデータを送信する前に初期の輻輳ウィンドウを減らします[RFC5681]。ただし、TFOでは、サーバーはすでにデータの初期ウィンドウまで送信している場合があります。
If the server serves mostly short connections, then the losses of SYN-ACKs are not as effective as regular TCP on reducing the congestion window. This could result in an unstable network condition. The connections that experience losses may attempt again and add more load under congestion. A potential solution is to temporarily disable Fast Open if the server observes many SYN-ACK or data losses during the handshake across connections. Further experimentation regarding the congestion control impact will be useful.
サーバーが主に短い接続を提供する場合、SYN-ACKの損失は、輻輳ウィンドウの削減に関して通常のTCPほど効果的ではありません。これにより、ネットワークの状態が不安定になる可能性があります。損失が発生した接続は、再試行して、輻輳時にさらに負荷を追加する場合があります。可能性のある解決策は、サーバーが接続間のハンドシェイク中に多くのSYN-ACKまたはデータ損失を観察する場合、Fast Openを一時的に無効にすることです。輻輳制御の影響に関するさらなる実験が役立つでしょう。
The cookie mechanism mitigates resource exhaustion and amplification attacks. However, cookies are not necessary if the server has application-level protection or is immune to these attacks. For example, a Web server that only replies with a simple HTTP redirect response that fits in the SYN-ACK packet may not care about resource exhaustion.
Cookieメカニズムは、リソースの枯渇と増幅攻撃を軽減します。ただし、サーバーにアプリケーションレベルの保護がある場合や、これらの攻撃の影響を受けない場合は、Cookieは必要ありません。たとえば、SYN-ACKパケットに収まる単純なHTTPリダイレクト応答でのみ応答するWebサーバーは、リソースの枯渇を気にしない場合があります。
For such applications the server may choose to generate a trivial or even a zero-length cookie to improve performance by avoiding the cookie generation and verification. If the server believes it's under a DoS attack through other defense mechanisms, it can switch to regular Fast Open for listener sockets.
このようなアプリケーションの場合、サーバーは、Cookieの生成と検証を回避することでパフォーマンスを向上させるために、ささいな、または長さがゼロのCookieを生成することを選択できます。サーバーが他の防御メカニズムによるDoS攻撃を受けているとサーバーが判断した場合、サーバーはリスナーソケットを通常のFast Openに切り替えることができます。
TCP Extensions for Transactions [RFC1644] attempted to bypass the 3WHS, among other things; hence, it shared the same goal but also the same set of issues as TFO. It focused most of its effort battling old or duplicate SYNs, but paid no attention to security vulnerabilities it introduced when bypassing the 3WHS [PHRACK98].
トランザクションのTCP拡張[RFC1644]は、とりわけ3WHSをバイパスしようとしました。したがって、TFOと同じ目標を共有しましたが、問題のセットも同じでした。古いSYNや重複したSYNと戦う努力のほとんどに焦点を当てましたが、3WHS [PHRACK98]をバイパスするときに導入されたセキュリティの脆弱性に注意を払いませんでした。
As stated earlier, we take a practical approach to focus TFO on the security aspect, while allowing old, duplicate SYN packets with data after recognizing that 100% TCP semantics is likely infeasible. We believe this approach strikes the right trade-off and makes TFO much simpler and more appealing to TCP implementers and users.
前に述べたように、TFOをセキュリティの側面に焦点を合わせる実用的なアプローチを採用しながら、100％TCPセマンティクスは実現不可能である可能性が高いことを認識した上で、古い重複したSYNパケットとデータを許可します。このアプローチは適切なトレードオフを実現し、TFOをTCPの実装者とユーザーにとってはるかにシンプルで魅力的なものにすると信じています。
[RFC4987] studies the mitigation of attacks from regular SYN floods, i.e., SYNs without data. But from the stateless SYN cookies to the stateful SYN Cache, none can preserve data sent with SYNs safely while still providing an effective defense.
[RFC4987]は、通常のSYNフラッド、つまりデータのないSYNからの攻撃の緩和を調査します。ただし、ステートレスSYN CookieからステートフルSYNキャッシュまで、効果的な防御を提供しながら、SYNで送信されたデータを安全に保存できるものはありません。
The best defense may be simply to disable TFO when a host is suspected to be under a SYN flood attack, e.g., the SYN backlog is filled. Once TFO is disabled, normal SYN flood defenses can be applied. The "Security Considerations" section (Section 5) contains a thorough discussion on this topic.
最善の防御策は、ホストがSYNフラッド攻撃を受けている疑いがある場合、たとえば、SYNバックログがいっぱいになった場合に、TFOを無効にすることです。 TFOが無効になると、通常のSYNフラッド防御を適用できます。 「セキュリティに関する考慮事項」セクション（セクション5）には、このトピックに関する詳細な説明が含まれています。
Some Web browsers maintain a history of the domains for frequently visited Web pages. The browsers then speculatively pre-open TCP connections to these domains before the user initiates any requests for them [BELSHE11]. While this technique also saves the handshake latency, it wastes server and network resources by initiating and maintaining idle connections.
一部のWebブラウザーは、頻繁にアクセスされるWebページのドメインの履歴を保持しています。次に、ブラウザは、ユーザーがドメインへのリクエストを開始する前に、これらのドメインへのTCP接続を投機的に事前に開きます[BELSHE11]。この手法はハンドシェイクの待ち時間も節約しますが、アイドル接続を開始および維持することにより、サーバーおよびネットワークリソースを浪費します。
An alternate proposal is to request a TFO cookie in the FIN instead, since FIN-drop by incompatible middleboxes does not affect latency. However, paths that block SYN cookies may be more likely to drop a later SYN packet with data, and many applications close a connection with RST instead anyway.
代わりの提案は、互換性のないミドルボックスによるFINドロップが待ち時間に影響しないため、代わりにFINでTFO Cookieを要求することです。ただし、SYN Cookieをブロックするパスは、データを含む後のSYNパケットをドロップする可能性が高く、多くのアプリケーションは、代わりにRSTとの接続を閉じます。
Although cookie-in-FIN may not improve robustness, it would give clients using a single connection a latency advantage over clients opening multiple parallel connections. If experiments with TFO find that it leads to increased connection-sharding, cookie-in-FIN may prove to be a useful alternative.
cookie-in-FINは堅牢性を向上させない場合がありますが、単一の接続を使用するクライアントに、複数の並列接続を開くクライアントよりもレイテンシの利点があります。 TFOを使用した実験で接続シャーディングの増加につながることが判明した場合、FIN内のCookieが有用な代替手段になる可能性があります。
TCPCT [RFC6013] eliminates server state during the initial handshake and defends spoofing DoS attacks. Like TFO, TCPCT allows SYN and SYN-ACK packets to carry data. But the server can only send up to MSS bytes of data during the handshake instead of the initial congestion window, unlike TFO. Therefore, the latency of applications (e.g., Web applications) may be worse than with TFO.
TCPCT [RFC6013]は、初期ハンドシェイク中のサーバー状態を排除し、スプーフィングDoS攻撃を防御します。 TFOと同様に、TCPCTではSYNおよびSYN-ACKパケットでデータを伝送できます。ただし、サーバーは、TFOとは異なり、初期の輻輳ウィンドウではなく、ハンドシェイク中に最大MSSバイトのデータしか送信できません。したがって、アプリケーション（Webアプリケーションなど）のレイテンシはTFOの場合よりも劣る可能性があります。
IANA has allocated one value, 34, in the "TCP Option Kind Numbers" registry. See Section 4.1.1. The length of this new TCP option is variable, and the Meaning as shown in the "TCP Option Kind Numbers" registry is set to "TCP Fast Open Cookie". Current and new implementations SHOULD use option (34). Existing implementations that are using experimental option 254 per [RFC6994] with magic number 0xF989 (16 bits) as allocated in the IANA "TCP Experimental Option Experiment Identifiers (TCP ExIDs)" registry by this document, SHOULD migrate to use this new option (34) by default.
IANAは、「TCP Option Kind Numbers」レジストリに1つの値34を割り当てています。セクション4.1.1を参照してください。この新しいTCPオプションの長さは可変であり、「TCPオプションの種類番号」レジストリに表示される意味は「TCP Fast Open Cookie」に設定されています。現在および新しい実装では、オプション（34）を使用する必要があります（SHOULD）。このドキュメントでIANA "TCP実験オプション実験識別子（TCP ExIDs）"レジストリに割り当てられているマジック番号0xF989（16ビット）の実験オプション254 [RFC6994]を使用している既存の実装では、この新しいオプション（34 ）デフォルトで。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月、<http://www.rfc-editor.org/info/rfc793>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R.、Ed。、 "Requirements for Internet Hosts-Communication Layers"、STD 3、RFC 1122、October 1989、<http://www.rfc-editor.org/info/rfc1122>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002, <http://www.rfc-editor.org/info/rfc3390>.
[RFC3390] Allman、M.、Floyd、S。、およびC. Partridge、「Increeasing TCP's Initial Window」、RFC 3390、2002年10月、<http://www.rfc-editor.org/info/rfc3390>。
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008, <http://www.rfc-editor.org/info/rfc5382>.
[RFC5382] Guha、S.、Ed。、Biswas、K.、Ford、B.、Sivakumar、S.、and P. Srisuresh、 "NAT Behavioral Requirements for TCP"、BCP 142、RFC 5382、October 2008、<http ：//www.rfc-editor.org/info/rfc5382>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009, <http://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、2009年9月、<http://www.rfc-editor.org/info/rfc5681>。
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, August 2013, <http://www.rfc-editor.org/info/rfc6994>.
[RFC6994] Touch、J。、「Shared Use of Experimental TCP Options」、RFC 6994、2013年8月、<http://www.rfc-editor.org/info/rfc6994>。
[AERG11] Al-Fares, M., Elmeleegy, K., Reed, B., and I. Gashinsky, "Overclocking the Yahoo! CDN for Faster Web Page Loads", in Proceedings of Internet Measurement Conference, November 2011.
[AERG11] Al-Fares、M.、Elmeleegy、K.、Reed、B。、およびI. Gashinsky、「インターネットページの読み込みを高速化するためのYahoo! CDNのオーバークロック」、2011年11月のインターネット測定会議の議事録。
[BELSHE11] Belshe, M., "The Era of Browser Preconnect", February 2011, <http://www.belshe.com/2011/02/10/ the-era-of-browser-preconnect/>.
[BELSHE11] Belshe、M。、「The Browser of Era of Browser Preconnect」、2011年2月、<http://www.belshe.com/2011/02/10/ the-era-of-browser-preconnect />。
[BRISCOE12] Briscoe, B., "Some ideas building on draft-ietf-tcpm-fastopen-01", message to the tcpm mailing list, July 2012, <http://www.ietf.org/mail-archive/ web/tcpm/current/msg07192.html>.
[BRISCOE12] Briscoe、B。、「draft-ietf-tcpm-fastopen-01に基づくいくつかのアイデア」、tcpmメーリングリストへのメッセージ、2012年7月、<http://www.ietf.org/mail-archive/ web /tcpm/current/msg07192.html>。
[Chrome] Google Chrome, <https://www.google.com/intl/en-US/chrome/browser/>.
[Chrome] Google Chrome、<https://www.google.com/intl/en-US/chrome/browser/>。
[HNESSK10] Haetoenen, S., Nyrhinen, A., Eggert, L., Strowes, S., Sarolahti, P., and M. Kojo, "An Experimental Study of Home Gateway Characteristics", in Proceedings of Internet Measurement Conference, October 2010.
[HNESSK10] Haetoenen、S.、Nyrhinen、A.、Eggert、L.、Strowes、S.、Sarolahti、P。、およびM. Kojo、「ホームゲートウェイ特性の実験的研究」、インターネット測定会議の議事録、 2010年10月。
[HNRGHT11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M., and H. Tokuda, "Is it Still Possible to Extend TCP?", in Proceedings of Internet Measurement Conference, November 2011.
[HNRGHT11]本田雅夫、西田陽一、ライチウC.、グリーンハルグA.、Handley、M。、およびH.徳田、「TCPを拡張することはまだ可能ですか？」、インターネット測定会議の議事録、2011年11月。
[JIDKT07] Jaiswal, S., Iannaccone, G., Diot, C., Kurose, J., and D. Towsley, "Measurement and Classification of Out-of-Sequence Packets in a Tier-1 IP Backbone" IEEE/ACM Transactions on Networking (TON), Volume 15, Issue 1, pp 54-66.
[JIDKT07] Jaiswal、S.、Iannaccone、G.、Diot、C.、Kurose、J。、およびD. Towsley、「Tier-1 IPバックボーンのシーケンス外パケットの測定と分類」IEEE / ACM Transactions on Networking（TON）、Volume 15、Issue 1、54-66ページ。
[LANGLEY06] Langley, A., "Probing the viability of TCP extensions", <http://www.imperialviolet.org/binary/ecntest.pdf>.
[LANGLEY06] Langley、A。、「Probing the viability of TCP extensions」、<http://www.imperialviolet.org/binary/ecntest.pdf>。
[MAF04] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", in Proceedings of Internet Measurement Conference, October 2004.
[MAF04] Medina、A.、Allman、M。、およびS. Floyd、「Measureing Interactions between Transport Protocols and Middleboxes」、Proceedings of Internet Measurement Conference、2004年10月。
[MQXMZ11] Wang, Z., Qian, Z., Xu, Q., Mao, Z., and M. Zhang, "An Untold Story of Middleboxes in Cellular Networks", in Proceedings of SIGCOMM, August 2011.
[MQXMZ11] Wang、Z.、Qian、Z.、Xu、Q.、Mao、Z。、およびM. Zhang、「An Cellor Networks in Middleboxes in Cellular Networks」、Proceedings of SIGCOMM、2011年8月。
[PHRACK98] "T/TCP vulnerabilities", Phrack Magazine, Volume 8, Issue 53, Article 6, July 8, 1998, <http://www.phrack.com/issues.html?issue=53&id=6>.
[PHRACK98]「T / TCPの脆弱性」、Phrack Magazine、Volume 8、Issue 53、Article 6、7月8、1998、<http://www.phrack.com/issues.html?issue=53&id=6>。
[RCCJR11] Radhakrishnan, S., Cheng, Y., Chu, J., Jain, A., and B. Raghavan, "TCP Fast Open", in Proceedings of the 7th ACM CoNEXT Conference, December 2011.
[RCCJR11] Radhakrishnan、S.、Cheng、Y.、Chu、J.、Jain、A。、およびB. Raghavan、「TCP Fast Open」、第7回ACM CoNEXT会議の議事録、2011年12月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992, <http://www.rfc-editor.org/info/rfc1323>.
[RFC1323] Jacobson、V.、Braden、R。、およびD. Borman、「TCP Extensions for High Performance」、RFC 1323、1992年5月、<http://www.rfc-editor.org/info/rfc1323>。
[RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994, <http://www.rfc-editor.org/info/rfc1644>.
[RFC1644] Braden、R。、「T / TCP-TCP Extensions for Transactions Functional Specification」、RFC 1644、1994年7月、<http://www.rfc-editor.org/info/rfc1644>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月、<http://www.rfc-editor.org/info/rfc2460>。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007, <http://www.rfc-editor.org/info/rfc4987>.
[RFC4987] Eddy、W。、「TCP SYN Flooding Attacks and Common Mitigations」、RFC 4987、2007年8月、<http://www.rfc-editor.org/info/rfc4987>。
[RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC 6013, January 2011, <http://www.rfc-editor.org/info/rfc6013>.
[RFC6013] Simpson、W。、「TCP Cookie Transactions（TCPCT）」、RFC 6013、2011年1月、<http://www.rfc-editor.org/info/rfc6013>。
[RFC6247] Eggert, L., "Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status", RFC 6247, May 2011, <http://www.rfc-editor.org/info/rfc6247>.
[RFC6247] Eggert、L。、「Undeployed TCP Extensions RFC 1072、RFC 1106、RFC 1110、RFC 1145、RFC 1146、RFC 1379、RFC 1644、およびRFC 1693を履歴ステータスに移動」、RFC 6247、2011年5月、< http://www.rfc-editor.org/info/rfc6247>。
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, September 2014, <http://www.rfc-editor.org/info/rfc7323>.
[RFC7323] Borman、D.、Braden、B.、Jacobson、V.、and R. Scheffenegger、Ed。、 "TCP Extensions for High Performance"、RFC 7323、September 2014、<http：//www.rfc-editor .org / info / rfc7323>。
[SOUDERS11] Souders, S., "Making A Mobile Connection", <http://www.stevesouders.com/blog/2011/09/21/ making-a-mobile-connection/>.
[SOUDERS11] Souders、S。、「Making A Mobile Connection」、<http://www.stevesouders.com/blog/2011/09/21/making-a-mobile-connection/>。
The active open side involves changing or replacing the connect() call, which does not take a user data buffer argument. We recommend replacing the connect() call to minimize API changes, and, hence, applications to reduce the deployment hurdle.
アクティブなオープン側には、ユーザーデータバッファー引数をとらないconnect()呼び出しの変更または置換が含まれます。 connect()呼び出しを置き換えることで、APIの変更を最小限に抑えることをお勧めします。これにより、アプリケーションがデプロイメントのハードルを減らすことができます。
One solution implemented in Linux 3.7 is introducing a new flag, MSG_FASTOPEN, for sendto() or sendmsg(). MSG_FASTOPEN marks the attempt to send data in the SYN like a combination of connect() and sendto(), by performing an implicit connect() operation. It blocks until the handshake has completed and the data is buffered.
Linux 3.7に実装されたソリューションの1つは、sendto()またはsendmsg()に新しいフラグMSG_FASTOPENを導入することです。 MSG_FASTOPENは、暗黙的なconnect()操作を実行することにより、connect()とsendto()の組み合わせのように、SYNでデータを送信する試みをマークします。ハンドシェイクが完了してデータがバッファリングされるまでブロックします。
For a non-blocking socket, it returns the number of bytes buffered and sent in the SYN packet. If the cookie is not available locally, it returns -1 with errno EINPROGRESS, and sends a SYN with a TFO cookie request automatically. The caller needs to write the data again when the socket is connected. On errors, it returns the same errno as connect() if the handshake fails.
非ブロッキングソケットの場合、バッファリングされ、SYNパケットで送信されたバイト数を返します。 Cookieがローカルで使用できない場合は、errno EINPROGRESSで-1が返され、TFO Cookie要求とともにSYNが自動的に送信されます。ソケットが接続されている場合、呼び出し元はデータを再度書き込む必要があります。エラーの場合、ハンドシェイクが失敗すると、connect()と同じerrnoを返します。
An implementation may prefer not to change the sendmsg() call because TFO is a TCP-specific feature. A solution is to add a new socket option, TCP_FASTOPEN, for TCP sockets. When the option is enabled before a connect() operation, sendmsg() or sendto() will perform a Fast Open operation similar to the MSG_FASTOPEN flag described above. This approach, however, requires an extra setsockopt() system call.
TFOはTCP固有の機能であるため、実装ではsendmsg()呼び出しを変更しない方がよい場合があります。解決策は、TCPソケット用の新しいソケットオプションTCP_FASTOPENを追加することです。 connect()操作の前にこのオプションを有効にすると、sendmsg()またはsendto()は、上記のMSG_FASTOPENフラグと同様の高速オープン操作を実行します。ただし、この方法では、追加のsetsockopt()システムコールが必要です。
The passive open side change is simpler compared to the active open side. The application only needs to enable the reception of Fast Open requests via a new TCP_FASTOPEN setsockopt() socket option before listen().
パッシブオープンサイドの変更は、アクティブオープンサイドに比べて簡単です。アプリケーションは、listen()の前に新しいTCP_FASTOPEN setsockopt()ソケットオプションを介してFast Openリクエストの受信を有効にするだけで済みます。
The option enables Fast Open on the listener socket. The option value specifies the PendingFastOpenRequests threshold, i.e., the maximum length of pending SYNs with data payload. Once enabled, the TCP implementation will respond with TFO cookies per request.
このオプションは、リスナーソケットでFast Openを有効にします。オプションの値は、PendingFastOpenRequestsしきい値、つまりデータペイロードを持つ保留中のSYNの最大長を指定します。有効にすると、TCP実装はリクエストごとにTFO Cookieで応答します。
Traditionally, accept() returns only after a socket is connected. But, for a Fast Open connection, accept() returns upon receiving a SYN with a valid Fast Open cookie and data, and the data is available to be read through, e.g., recvmsg(), read().
従来、accept()は、ソケットが接続された後にのみ戻ります。ただし、Fast Open接続の場合、accept()は、有効なFast Open Cookieとデータを含むSYNを受信すると戻り、recvmsg()、read()などのデータを読み取ることができます。
Acknowledgments
謝辞
We thank Bob Briscoe, Michael Scharf, Gorry Fairhurst, Rick Jones, Roberto Peon, William Chan, Adam Langley, Neal Cardwell, Eric Dumazet, and Matt Mathis for their feedback. We especially thank Barath Raghavan for his contribution on the security design of Fast Open and proofreading this document numerous times.
ボブ・ブリスコ、マイケル・シャーフ、ゴーリー・フェアハースト、リック・ジョーンズ、ロベルト・ペオン、ウィリアム・チャン、アダム・ラングレー、ニール・カードウェル、エリック・デュマゼット、マット・マティスのフィードバックに感謝します。 Fast Openのセキュリティ設計への貢献とこのドキュメントの何度も校正を行ってくれたBarath Raghavanに特に感謝します。
Authors' Addresses
著者のアドレス
Yuchung Cheng Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
Yuchung Cheng Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
EMail: ycheng@google.com
Jerry Chu Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
Jerry Chu Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
EMail: hkchu@google.com
Sivasankar Radhakrishnan Department of Computer Science and Engineering University of California, San Diego 9500 Gilman Drive La Jolla, CA 92093-0404 United States
Sivasankar Radhakrishnanカリフォルニア大学サンディエゴ校コンピュータサイエンスおよびエンジニアリング部9500 Gilman Drive La Jolla、CA 92093-0404アメリカ合衆国
EMail: sivasankar@cs.ucsd.edu
Arvind Jain Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
Arvind Jain Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
EMail: arvind@google.com