draft-ietf-tcpm-fastopen-09.txt   draft-ietf-tcpm-fastopen-10.txt 
Internet Draft Y. Cheng Internet Draft Y. Cheng
draft-ietf-tcpm-fastopen-09.txt J. Chu draft-ietf-tcpm-fastopen-10.txt J. Chu
Intended status: Experimental S. Radhakrishnan Intended status: Experimental S. Radhakrishnan
Expiration date: January, 2015 A. Jain Expiration date: April, 2015 A. Jain
Google, Inc. Google
June 30, 2014 September 29, 2014
TCP Fast Open TCP Fast Open
Abstract Abstract
This document describes an experimental TCP mechanism TCP Fast Open This document describes an experimental TCP mechanism TCP Fast Open
(TFO). TFO allows data to be carried in the SYN and SYN-ACK packets (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets
and consumed by the receiving end during the initial connection and consumed by the receiving end during the initial connection
handshake, thus saving up to one full round trip time (RTT) compared handshake, and saves up to one full round trip time (RTT) compared to
to the standard TCP, which requires a three-way handshake (3WHS) to the standard TCP, which requires a three-way handshake (3WHS) to
complete before data can be exchanged. However TFO deviates from the complete before data can be exchanged. However TFO deviates from the
standard TCP semantics since the data in the SYN could be replayed to standard TCP semantics since the data in the SYN could be replayed to
an application in some rare circumstances. Applications should not an application in some rare circumstances. Applications should not
use TFO unless they can tolerate this issue detailed in the use TFO unless they can tolerate this issue detailed in the
Applicability section. Applicability section.
Status of this Memo Status of this Memo
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
skipping to change at page 2, line 18 skipping to change at page 2, line 18
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Data In SYN . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Data In SYN . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Relaxing TCP Semantics on Duplicated SYNs . . . . . . . . . 4 2.1 Relaxing TCP Semantics on Duplicated SYNs . . . . . . . . . 4
2.2. SYNs with Spoofed IP Addresses . . . . . . . . . . . . . . 4 2.2. SYNs with Spoofed IP Addresses . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Fast Open Cookie . . . . . . . . . . . . . . . . . . . . . 7 4.1. Fast Open Cookie . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. TCP Options . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Fast Open option . . . . . . . . . . . . . . . . . . . 7
4.1.2. Server Cookie Handling . . . . . . . . . . . . . . . . 8 4.1.2. Server Cookie Handling . . . . . . . . . . . . . . . . 7
4.1.3. Client Cookie Handling . . . . . . . . . . . . . . . . 9 4.1.3. Client Cookie Handling . . . . . . . . . . . . . . . . 8
4.1.3.1 Client Caching Negative Responses . . . . . . . . . 9 4.1.3.1 Client Caching Negative Responses . . . . . . . . . 9
4.2. Fast Open Protocol . . . . . . . . . . . . . . . . . . . . 11 4.2. Fast Open Protocol . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Fast Open Cookie Request . . . . . . . . . . . . . . . 11 4.2.1. Fast Open Cookie Request . . . . . . . . . . . . . . . 10
4.2.2. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . 12 4.2.2. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 13
5.1. Resource Exhaustion Attack by SYN Flood with Valid 5.1. Resource Exhaustion Attack by SYN Flood with Valid
Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1 Attacks from behind Shared Public IPs (NATs) . . . . . . 15 5.1.1 Attacks from behind Shared Public IPs (NATs) . . . . . . 14
5.2. Amplified Reflection Attack to Random Host . . . . . . . . 16 5.2. Amplified Reflection Attack to Random Host . . . . . . . . 14
6. TFO's Applicability . . . . . . . . . . . . . . . . . . . . . . 17 6. TFO's Applicability . . . . . . . . . . . . . . . . . . . . . . 15
6.1 Duplicate Data in SYNs . . . . . . . . . . . . . . . . . . . 17 6.1 Duplicate Data in SYNs . . . . . . . . . . . . . . . . . . . 15
6.2 Potential Performance Improvement . . . . . . . . . . . . . 17 6.2 Potential Performance Improvement . . . . . . . . . . . . . 16
6.3. Example: Web Clients and Servers . . . . . . . . . . . . . 18 6.3. Example: Web Clients and Servers . . . . . . . . . . . . . 16
6.3.1. HTTP Request Replay . . . . . . . . . . . . . . . . . . 18 6.3.1. HTTP Request Replay . . . . . . . . . . . . . . . . . . 16
6.3.2. Speculative Connections by the Applications . . . . . . 18 6.3.2. HTTP over TLS (HTTPS) . . . . . . . . . . . . . . . . . 16
6.3.3. HTTP over TLS (HTTPS) . . . . . . . . . . . . . . . . . 18 6.3.3. Comparison with HTTP Persistent Connections . . . . . . 17
6.3.4. Comparison with HTTP Persistent Connections . . . . . . 18 6.3.4. Load Balancers and Server farms . . . . . . . . . . . . 17
7. Open Areas for Experimentation . . . . . . . . . . . . . . . . 19 7. Open Areas for Experimentation . . . . . . . . . . . . . . . . 17
7.1. Performance impact due to middle-boxes and NAT . . . . . . 19 7.1. Performance impact due to middle-boxes and NAT . . . . . . 18
7.2. Cookie-less Fast Open . . . . . . . . . . . . . . . . . . . 20 7.2. Impact on congestion control . . . . . . . . . . . . . . . 18
7.3 Impact on congestion control . . . . . . . . . . . . . . . . 20 7.3. Cookie-less Fast Open . . . . . . . . . . . . . . . . . . . 18
8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. T/TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. T/TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Common Defenses Against SYN Flood Attacks . . . . . . . . . 21 8.2. Common Defenses Against SYN Flood Attacks . . . . . . . . . 19
8.3. TCP Cookie Transaction (TCPCT) . . . . . . . . . . . . . . 21 8.3. Speculative Connections by the Applications . . . . . . . . 19
8.4. Fast Open Cookie in FIN . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21 8.5. TCP Cookie Transaction (TCPCT) . . . . . . . . . . . . . . 20
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
Appendix A. Example Socket API Changes to support TFO . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . . 21
A.1 Active Open . . . . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Example Socket API Changes to support TFO . . . . . . 22
A.2 Passive Open . . . . . . . . . . . . . . . . . . . . . . . . 25 A.1 Active Open . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 A.2 Passive Open . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
TCP Fast Open (TFO) is an experimental update to TCP that enables TCP Fast Open (TFO) is an experimental update to TCP that enables
data to be exchanged safely during TCP's connection handshake. This data to be exchanged safely during TCP's connection handshake. This
document describes a design that enables applications to save a round document describes a design that enables applications to save a round
trip while avoiding severe security ramifications. At the core of TFO trip while avoiding severe security ramifications. At the core of TFO
is a security cookie used by the server side to authenticate a client is a security cookie used by the server side to authenticate a client
initiating a TFO connection. This document covers the details of initiating a TFO connection. This document covers the details of
exchanging data during TCP's initial handshake, the protocol for TFO exchanging data during TCP's initial handshake, the protocol for TFO
skipping to change at page 3, line 39 skipping to change at page 3, line 40
handshake (3WHS)[RFC793], which adds one RTT to network latency. For handshake (3WHS)[RFC793], which adds one RTT to network latency. For
short Web transfers this additional RTT is a significant portion of short Web transfers this additional RTT is a significant portion of
overall network latency, even when HTTP persistent connection is overall network latency, even when HTTP persistent connection is
widely used. For example, the Chrome browser [Chrome] keeps TCP widely used. For example, the Chrome browser [Chrome] keeps TCP
connections idle for up to 5 minutes but 35% of HTTP requests are 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 made on new TCP connections [RCCJR11]. For such Web and Web-like
applications placing data in the SYN can yield significant latency applications placing data in the SYN can yield significant latency
improvements. Next we describe how we resolve the challenges that improvements. Next we describe how we resolve the challenges that
arise upon doing so. arise upon doing so.
1.1 Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
TFO refers to TCP Fast Open. Client refers to the TCP's active open TFO refers to TCP Fast Open. Client refers to the TCP's active open
side and server refers to the TCP's passive open side. side and server refers to the TCP's passive open side.
2. Data In SYN 2. Data In SYN
Standard TCP already allows data to be carried in SYN packets Standard TCP already allows data to be carried in SYN packets
([RFC793], section 3.4) but forbids the receiver from delivering it ([RFC793], section 3.4) but forbids the receiver from delivering it
to the application until 3WHS is completed. This is because TCP's to the application until 3WHS is completed. This is because TCP's
initial handshake serves to capture old or duplicate SYNs. initial handshake serves to capture old or duplicate SYNs.
To enable applications exchange data in TCP handshake, TFO removes To enable applications exchange data in TCP handshake, TFO removes
the constraint and allows data in SYN packets to be delivered to the the constraint and allows data in SYN packets to be delivered to the
application. This change of TCP semantic raises two issues discussed application. This change of TCP semantic raises two issues discussed
in the following subsections, making TFO unsuitable for certain in the following subsections, making TFO unsuitable for certain
applications. applications.
skipping to change at page 5, line 28 skipping to change at page 5, line 26
3. Protocol Overview 3. Protocol Overview
The key component of TFO is the Fast Open Cookie (cookie), a message The key component of TFO is the Fast Open Cookie (cookie), a message
authentication code (MAC) tag generated by the server. The client authentication code (MAC) tag generated by the server. The client
requests a cookie in one regular TCP connection, then uses it for requests a cookie in one regular TCP connection, then uses it for
future TCP connections to exchange data during 3WHS: future TCP connections to exchange data during 3WHS:
Requesting a Fast Open Cookie: Requesting a Fast Open Cookie:
1. The client sends a SYN with a Fast Open Cookie Request option. 1. The client sends a SYN with a Fast Open option with an empty
cookie field to request a cookie.
2. The server generates a cookie and sends it through the Fast Open 2. The server generates a cookie and sends it through the Fast Open
Cookie option of a SYN-ACK packet. option of a SYN-ACK packet.
3. The client caches the cookie for future TCP Fast Open connections 3. The client caches the cookie for future TCP Fast Open connections
(see below). (see below).
Performing TCP Fast Open: Performing TCP Fast Open:
1. The client sends a SYN with Fast Open Cookie option and data. 1. The client sends a SYN with data and the cookie in the Fast Open
option.
2. The server validates the cookie: 2. The server validates the cookie:
a. If the cookie is valid, the server sends a SYN-ACK a. If the cookie is valid, the server sends a SYN-ACK
acknowledging both the SYN and the data. The server then acknowledging both the SYN and the data. The server then
delivers the data to the application. delivers the data to the application.
b. Otherwise, the server drops the data and sends a SYN-ACK b. Otherwise, the server drops the data and sends a SYN-ACK
acknowledging only the SYN sequence number. acknowledging only the SYN sequence number.
3. If the server accepts the data in the SYN packet, it may send the 3. If the server accepts the data in the SYN packet, it may send the
skipping to change at page 7, line 17 skipping to change at page 7, line 6
4.1. Fast Open Cookie 4.1. Fast Open Cookie
The Fast Open Cookie is designed to mitigate new security The Fast Open Cookie is designed to mitigate new security
vulnerabilities in order to enable data exchange during handshake. vulnerabilities in order to enable data exchange during handshake.
The cookie is a message authentication code tag generated by the The cookie is a message authentication code tag generated by the
server and is opaque to the client; the client simply caches 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 cookie and passes it back on subsequent SYN packets to open new
connections. The server can expire the cookie at any time to enhance connections. The server can expire the cookie at any time to enhance
security. security.
4.1.1. TCP Options 4.1.1. Fast Open option
Fast Open Cookie Option
The server uses this option to grant a cookie to the client in the
SYN-ACK packet; the client uses it to pass the cookie back to the
server in subsequent SYN packets.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length | | Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Cookie ~ ~ Cookie ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kind 1 byte: constant-TBD (to be assigned by IANA) Kind 1 byte: constant-TBD (to be assigned by IANA)
Length 1 byte: range 6 to 18 (bytes); limited by Length 1 byte: range 6 to 18 (bytes); limited by
remaining space in the options field. remaining space in the options field.
The number MUST be even. The number MUST be even.
Cookie 4 to 16 bytes (Length - 2) Cookie 0, or 4 to 16 bytes (Length - 2)
Options with invalid Length values or without SYN flag set MUST be
ignored. The minimum Cookie size is 4 bytes. Although the diagram
shows a cookie aligned on 32-bit boundaries, alignment is not
required.
Fast Open Cookie Request Option
The client uses this option in the SYN packet to request a cookie
from a TFO-enabled server
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kind 1 byte: constant-TBD (same value as the Fast Open The Fast Open option is used to request or to send a Fast Open
Cookie option) Cookie. When cookie is not present or 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).
Length 1 byte: constant 2. This distinguishes the option The minimum Cookie size is 4 bytes. Although the diagram shows a
from the Fast Open cookie option. cookie aligned on 32-bit boundaries, alignment is not required.
Options with invalid Length values, without SYN flag set, or with ACK Options with invalid Length values or without SYN flag set MUST be
flag set MUST be ignored. ignored.
4.1.2. Server Cookie Handling 4.1.2. Server Cookie Handling
The server is in charge of cookie generation and authentication. The The server is in charge of cookie generation and authentication. The
cookie SHOULD be a message authentication code tag with the following cookie SHOULD be a message authentication code tag with the following
properties: properties. We use SHOULD because in some cases the cookie may be
trivially generated as discussed in Section 7.3.
1. The cookie authenticates the client's (source) IP address of the 1. The cookie authenticates the client's (source) IP address of the
SYN packet. The IP address may be an IPv4 or IPv6 address. SYN packet. The IP address may be an IPv4 or IPv6 address.
2. The cookie can only be generated by the server and can not be 2. The cookie can only be generated by the server and can not be
fabricated by any other parties including the client. fabricated by any other parties including the client.
3. The generation and verification are fast relative to the rest of 3. The generation and verification are fast relative to the rest of
SYN and SYN-ACK processing. SYN and SYN-ACK processing.
4. A server may encode other information in the cookie, and accept 4. A server may encode other information in the cookie, and accept
skipping to change at page 9, line 21 skipping to change at page 8, line 48
a valid cookie is readily available to be sent to the client. a valid cookie is readily available to be sent to the client.
4.1.3. Client Cookie Handling 4.1.3. Client Cookie Handling
The client MUST cache cookies from servers for later Fast Open The client MUST cache cookies from servers for later Fast Open
connections. For a multi-homed client, the cookies are dependent on connections. For a multi-homed client, the cookies are dependent on
the client and server IP addresses. Hence the client should cache at the client and server IP addresses. Hence the client should cache at
most one (most recently received) cookie per client and server IP most one (most recently received) cookie per client and server IP
addresses pair. addresses pair.
Beside the cookie we RECOMMEND that the client caches the MSS to the When caching cookies, we recommend that the client also cache the
server to enhance performance. The MSS advertised by the server is Maximum Segment Size (MSS) advertised by the server. The client can
stored in the cache to determine the maximum amount of data that can cache the MSS advertised by the server in order to determine the
be supported in the SYN packet. This information is needed because maximum amount of data that the client can fit in the SYN packet in
data is sent before the server announces its MSS in the SYN-ACK subsequent TFO connections. Caching the server MSS is useful because
packet. Without this information, the data size in the SYN packet is 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.
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 1240 limited to the default MSS of 536 bytes for IPv4 [RFC1122] and 1240
bytes for IPv6 [RFC2460]. In particular it's known an IPv4 receiver bytes for IPv6 [RFC2460]. Even if the client complies with this limit
advertised MSS less than 536 bytes would result in transmission of an when sending the SYN, it is known that an IPv4 receiver advertising
unexpected large segment. If the cache MSS is larger than the typical an MSS less than 536 bytes can receive a segment larger than it is
1460 bytes, the extra large data in SYN segment may have issues that expecting.
offsets the performance benefit of Fast Open. For examples, the
super-size SYN may trigger IP fragmentation and may confuse firewall If the cached MSS is larger than the typical size (1460 bytes for
or middle-boxes, causing SYN retransmission and other side-effects. IPv4, or 1440 bytes for IPv6), then the excess data in the SYN packet
Therefore the client MAY limit the cached MSS to 1460 bytes. 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.
4.1.3.1 Client Caching Negative Responses 4.1.3.1 Client Caching Negative Responses
The client MUST cache negative responses from the server in order to The client MUST cache negative responses from the server in order to
avoid potential connection failures. Negative responses include avoid potential connection failures. Negative responses include
server not acknowledging the data in SYN, ICMP error messages, and server not acknowledging the data in SYN, ICMP error messages, and
most importantly no response (SYN/ACK) from the server at all, i.e., most importantly no response (SYN/ACK) from the server at all, i.e.,
connection timeout. The last case is likely due to incompatible connection timeout. The last case is likely due to incompatible
middle-boxes or firewall blocking the connection completely after it middle-boxes or firewall blocking the connection completely after it
sees data in SYN. If the client does not react to these negative sees data in SYN. If the client does not react to these negative
skipping to change at page 11, line 33 skipping to change at page 10, line 24
Considerations" section. Considerations" section.
The server keeps a FastOpened flag per connection to mark if a The server keeps a FastOpened flag per connection to mark if a
connection has successfully performed a TFO. connection has successfully performed a TFO.
4.2.1. Fast Open Cookie Request 4.2.1. Fast Open Cookie Request
Any client attempting TFO MUST first request a cookie from the server Any client attempting TFO MUST first request a cookie from the server
with the following steps: with the following steps:
1. The client sends a SYN packet with a Fast Open Cookie Request 1. The client sends a SYN packet with a Fast Open option with a
option. length field of 0 (empty cookie field).
2. The server SHOULD respond with a SYN-ACK based on the procedures 2. The server responds with a SYN-ACK based on the procedures
in the "Server Cookie Handling" section. This SYN-ACK SHOULD in the "Server Cookie Handling" section. This SYN-ACK may
contain a Fast Open Cookie option if the server currently supports contain a Fast Open option if the server currently supports
TFO for this listener port. TFO for this listener port.
3. If the SYN-ACK contains a Fast Open Cookie option, the client 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 replaces the cookie and other information as described in the
"Client Cookie Handling" section. Otherwise, if the SYN-ACK is "Client Cookie Handling" section. Otherwise, if the SYN-ACK is
first seen, i.e., not a (spurious) retransmission, the client MAY first seen, i.e., not a (spurious) retransmission, the client MAY
remove the server information from the cookie cache. If the SYN- remove the server information from the cookie cache. If the
ACK is a spurious retransmission without valid Fast Open Cookie SYN-ACK is a spurious retransmission, the client does nothing to
Option, the client does nothing to the cookie cache for the the cookie cache for the reasons below.
reasons below.
The network or servers may drop the SYN or SYN-ACK packets with the 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 new cookie options, which will cause SYN or SYN-ACK timeouts. We
RECOMMEND both the client and the server to retransmit SYN and SYN- RECOMMEND both the client and the server to retransmit SYN and SYN-
ACK without the cookie options on timeouts. This ensures the ACK without the cookie options on timeouts. This ensures the
connections of cookie requests will go through and lowers the latency connections of cookie requests will go through and lowers the latency
penalty (of dropped SYN/SYN-ACK packets). The obvious downside for penalty (of dropped SYN/SYN-ACK packets). The obvious downside for
maximum compatibility is that any regular SYN drop will fail the maximum compatibility is that any regular SYN drop will fail the
cookie (although one can argue the delay in the data transmission cookie (although one can argue the delay in the data transmission
till after 3WHS is justified if the SYN drop is due to network till after 3WHS is justified if the SYN drop is due to network
congestion). The next section describes a heuristic to detect such congestion). The next section describes a heuristic to detect such
drops when the client receives the SYN-ACK. drops when the client receives the SYN-ACK.
We also RECOMMEND the client to record the set of servers that failed We also RECOMMEND the client to record the set of servers that failed
to respond to cookie requests and only attempt another cookie request to respond to cookie requests and only attempt another cookie request
after certain period. after certain period.
An alternate proposal is to request a TFO cookie in the FIN instead,
since FIN-drop by incompatible middle-boxes 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.
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.
4.2.2. TCP Fast Open 4.2.2. TCP Fast Open
Once the client obtains the cookie from the target server, it can Once the client obtains the cookie from the target server, it can
perform subsequent TFO connections until the cookie is expired by the perform subsequent TFO connections until the cookie is expired by the
server. server.
Client: Sending SYN Client: Sending SYN
To open a TFO connection, the client MUST have obtained a cookie from To open a TFO connection, the client MUST have obtained a cookie from
the server: the server:
1. Send a SYN packet. 1. Send a SYN packet.
a. If the SYN packet does not have enough option space for the a. If the SYN packet does not have enough option space for the
Fast Open Cookie option, abort TFO and fall back to regular 3WHS. Fast Open option, abort TFO and fall back to regular 3WHS.
b. Otherwise, include the Fast Open Cookie option with the cookie b. Otherwise, include the Fast Open option with the cookie
of the server. Include any data up to the cached server MSS or of the server. Include any data up to the cached server MSS or
default 536 bytes. default 536 bytes.
2. Advance to SYN-SENT state and update SND.NXT to include the data 2. Advance to SYN-SENT state and update SND.NXT to include the data
accordingly. accordingly.
To deal with network or servers dropping SYN packets with payload or To deal with network or servers dropping SYN packets with payload or
unknown options, when the SYN timer fires, the client SHOULD unknown options, when the SYN timer fires, the client SHOULD
retransmit a SYN packet without data and Fast Open Cookie options. retransmit a SYN packet without data and Fast Open options.
Server: Receiving SYN and responding with SYN-ACK Server: Receiving SYN and responding with SYN-ACK
Upon receiving the SYN packet with Fast Open Cookie option: Upon receiving the SYN packet with Fast Open option:
1. Initialize and reset a local FastOpened flag. If FastOpenEnabled 1. Initialize and reset a local FastOpened flag. If FastOpenEnabled
is false, go to step 5. is false, go to step 5.
2. If PendingFastOpenRequests is over the system limit, go to step 5. 2. If PendingFastOpenRequests is over the system limit, go to step 5.
3. If IsCookieValid() in section 4.1.2 returns false, go to step 5. 3. If IsCookieValid() in section 4.1.2 returns false, go to step 5.
4. Buffer the data and notify the application. Set FastOpened flag 4. Buffer the data and notify the application. Set FastOpened flag
and increment PendingFastOpenRequests. and increment PendingFastOpenRequests.
skipping to change at page 13, line 37 skipping to change at page 12, line 17
response data is readily available. Some application may favor response data is readily available. Some application may favor
delaying the SYN-ACK, allowing the application to process the delaying the SYN-ACK, allowing the application to process the
request in order to produce a response, but this is left up to the request in order to produce a response, but this is left up to the
implementation. implementation.
6. Advance to the SYN-RCVD state. If the FastOpened flag is set, the 6. Advance to the SYN-RCVD state. If the FastOpened flag is set, the
server MUST follow [RFC5681] (based on [RFC3390]) to set the server MUST follow [RFC5681] (based on [RFC3390]) to set the
initial congestion window for sending more data packets. initial congestion window for sending more data packets.
If the SYN-ACK timer fires, the server SHOULD retransmit a SYN-ACK If the SYN-ACK timer fires, the server SHOULD retransmit a SYN-ACK
segment with neither data nor Fast Open Cookie options for segment with neither data nor Fast Open options for compatibility
compatibility reasons. reasons.
A special case is simultaneous open where the SYN receiver is a A special case is simultaneous open where the SYN receiver is a
client in SYN-SENT state. The protocol remains the same because client in SYN-SENT state. The protocol remains the same because
[RFC793] already supports both data in SYN and simultaneous open. But [RFC793] already supports both data in SYN and simultaneous open. But
the client's socket may have data available to read before it's the client's socket may have data available to read before it's
connected. This document does not cover the corresponding API change. connected. This document does not cover the corresponding API change.
Client: Receiving SYN-ACK Client: Receiving SYN-ACK
The client SHOULD perform the following steps upon receiving the SYN- The client SHOULD perform the following steps upon receiving the SYN-
ACK: ACK:
1. If the SYN-ACK has a Fast Open Cookie Option or MSS option or both, 1. If the SYN-ACK has a Fast Open option or MSS option or
update the corresponding cookie and MSS information in the cookie cache. both, update the corresponding cookie and MSS information in the
cookie cache.
2. Send an ACK packet. Set acknowledgment number to RCV.NXT and 2. Send an ACK packet. Set acknowledgment number to RCV.NXT and
include the data after SND.UNA if data is available. include the data after SND.UNA if data is available.
3. Advance to the ESTABLISHED state. 3. Advance to the ESTABLISHED state.
Note there is no latency penalty if the server does not acknowledge Note there is no latency penalty if the server does not acknowledge
the data in the original SYN packet. The client SHOULD retransmit any the data in the original SYN packet. The client SHOULD retransmit any
unacknowledged data in the first ACK packet in step 2. The data unacknowledged data in the first ACK packet in step 2. The data
exchange will start after the handshake like a regular TCP exchange will start after the handshake like a regular TCP
skipping to change at page 14, line 50 skipping to change at page 13, line 32
the countermeasures in detail below. the countermeasures in detail below.
5.1. Resource Exhaustion Attack by SYN Flood with Valid Cookies 5.1. Resource Exhaustion Attack by SYN Flood with Valid Cookies
An attacker may still obtain cookies from some compromised hosts, An attacker may still obtain cookies from some compromised hosts,
then flood spoofed SYN with data and "valid" cookies (from these then flood spoofed SYN with data and "valid" cookies (from these
hosts or other vantage points). Like regular TCP handshakes, TFO is hosts or other vantage points). Like regular TCP handshakes, TFO is
vulnerable to such an attack. But the potential damage can be much vulnerable to such an attack. But the potential damage can be much
more severe. Besides causing temporary disruption to service ports more severe. Besides causing temporary disruption to service ports
under attack, it may exhaust server CPU and memory resources. Such an under attack, it may exhaust server CPU and memory resources. Such an
attack will show up on application server logs as a application level attack will show up on application server logs as an application
DoS from Bot-nets, triggering other defenses and alerts. level DoS from Bot-nets, triggering other defenses and alerts.
To protect the server it is important to limit the maximum number of To protect the server it is important to limit the maximum number of
total pending TFO connection requests, i.e., PendingFastOpenRequests total pending TFO connection requests, i.e., PendingFastOpenRequests
(Section 4.2). When the limit is exceeded, the server temporarily (Section 4.2). When the limit is exceeded, the server temporarily
disables TFO entirely as described in "Server Cookie Handling". Then disables TFO entirely as described in "Server Cookie Handling". Then
subsequent TFO requests will be downgraded to regular connection subsequent TFO requests will be downgraded to regular connection
requests, i.e., with the data dropped and only SYN acknowledged. This requests, i.e., with the data dropped and only SYN acknowledged. This
allows regular SYN flood defense techniques [RFC4987] like SYN- allows regular SYN flood defense techniques [RFC4987] like SYN-
cookies to kick in and prevent further service disruption. cookies to kick in and prevent further service disruption.
skipping to change at page 16, line 5 skipping to change at page 14, line 36
corresponding timestamp, and echoes both in the SYN. The server then corresponding timestamp, and echoes both in the SYN. The server then
implements IsCookieValid(IP_Address, Timestamp, Cookie) by encrypting implements IsCookieValid(IP_Address, Timestamp, Cookie) by encrypting
the IP and timestamp data and comparing it with the cookie value. the IP and timestamp data and comparing it with the cookie value.
This enables the server to issue different cookies to clients that This enables the server to issue different cookies to clients that
share the same IP address, hence can selectively discard those share the same IP address, hence can selectively discard those
misused cookies from the attacker. However the attacker can simply misused cookies from the attacker. However the attacker can simply
repeat the attack with new cookies. The server would eventually need repeat the attack with new cookies. The server would eventually need
to throttle all requests from the IP address just like the current to throttle all requests from the IP address just like the current
approach. Moreover this approach requires modifying [RFC1323] to send approach. Moreover this approach requires modifying [RFC1323] to send
non-zero Timestamp Echo Reply in SYN, potentially cause firewall non-zero Timestamp Echo Reply in SYN, potentially causing firewall
issues. Therefore we believe the benefit does not outweigh the issues. Therefore we believe the benefit does not outweigh the
drawbacks. drawbacks.
5.2. Amplified Reflection Attack to Random Host 5.2. Amplified Reflection Attack to Random Host
Limiting PendingFastOpenRequests with a system limit can be done Limiting PendingFastOpenRequests with a system limit can be done
without Fast Open Cookies and would protect the server from resource without Fast Open Cookies and would protect the server from resource
exhaustion. It would also limit how much damage an attacker can cause exhaustion. It would also limit how much damage an attacker can cause
through an amplified reflection attack from that server. However, it through an amplified reflection attack from that server. However, it
would still be vulnerable to an amplified reflection attack from a would still be vulnerable to an amplified reflection attack from a
large number of servers. An attacker can easily cause damage by large number of servers. An attacker can easily cause damage by
tricking many servers to respond with data packets at once to any tricking many servers to respond with data packets at once to any
spoofed victim IP address of choice. spoofed victim IP address of choice.
With the use of Fast Open Cookies, the attacker would first have to 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 steal a valid cookie from its target victim. This likely requires the
attacker to compromise the victim host or network first. But in some attacker to compromise the victim host or network first. But in some
case it may be relatively easy. cases it may be relatively easy.
The attacker here has little interest in mounting an attack on the The attacker here has little interest in mounting an attack on the
victim host that has already been compromised. But it may be victim host that has already been compromised. But it may be
motivated to disrupt the victim's network. Since a stolen cookie is 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 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 large number of servers and use them before they expire to cause
sufficient damage without triggering the defense. sufficient damage without triggering the defense.
One can argue that if the attacker has compromised the target network One can argue that if the attacker has compromised the target network
or hosts, it could perform a similar but simpler attack by injecting or hosts, it could perform a similar but simpler attack by injecting
skipping to change at page 17, line 10 skipping to change at page 15, line 40
handshake finishes. In this case the risk of amplification reflection handshake finishes. In this case the risk of amplification reflection
attack is completely eliminated. But the potential latency saving attack is completely eliminated. But the potential latency saving
from TFO may diminish if the server application produces responses from TFO may diminish if the server application produces responses
earlier before the handshake completes. earlier before the handshake completes.
6. TFO's Applicability 6. TFO's Applicability
This section is to help applications considering TFO to evaluate This section is to help applications considering TFO to evaluate
TFO's benefits and drawbacks using the Web client and server TFO's benefits and drawbacks using the Web client and server
applications as an example throughout. Applications here refer applications as an example throughout. Applications here refer
specifically to the process that writes data into the socket, i.e., a specifically to the process that writes data into the socket. For
JavaScript process that sends data to the server. A proposed socket example a JavaScript process that sends data to the server. A
API change is in the Appendix. proposed socket API change is in the Appendix.
6.1 Duplicate Data in SYNs 6.1 Duplicate Data in SYNs
It is possible that using TFO results in the first data written to a 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 socket to be delivered more than once to the application on the
remote host (Section 2.1). This replay potential only applies to data remote host (Section 2.1). This replay potential only applies to data
in the SYN but not subsequent data exchanges. in the SYN but not subsequent data exchanges.
Empirically [JIDKT07] showed the packet duplication on a Tier-1 Empirically [JIDKT07] showed the packet duplication on a Tier-1
network is rare. Since the replay only happens specifically when the network is rare. Since the replay only happens specifically when the
SYN data packet is duplicated and also the duplicate arrives after SYN data packet is duplicated and also the duplicate arrives after
the receiver has cleared the original SYN's connection state, the the receiver has cleared the original SYN's connection state, the
replay is thought to be uncommon in practice. Neverthless a client replay is thought to be uncommon in practice. Nevertheless a client
that cannot handle receiving the same SYN data more than once MUST 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 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 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 to receive data in a SYN. Further investigation is needed to judge
about the probability of receiving duplicated SYN or SYN-ACK with about the probability of receiving duplicated SYN or SYN-ACK with
data in non-Tier 1 networks. data in non-Tier 1 networks.
6.2 Potential Performance Improvement 6.2 Potential Performance Improvement
TFO is designed for latency-conscious applications that are sensitive TFO is designed for latency-conscious applications that are sensitive
skipping to change at page 18, line 15 skipping to change at page 16, line 42
6.3. Example: Web Clients and Servers 6.3. Example: Web Clients and Servers
6.3.1. HTTP Request Replay 6.3.1. HTTP Request Replay
While TFO is motivated by Web applications, the browser should not While TFO is motivated by Web applications, the browser should not
use TFO to send requests in SYNs if those requests cannot tolerate use TFO to send requests in SYNs if those requests cannot tolerate
replays. One example is POST requests without application-layer replays. One example is POST requests without application-layer
transaction protection (e.g., a unique identifier in the request transaction protection (e.g., a unique identifier in the request
header). header).
On the other hand, TFO is particularly useful for GET requests. On the other hand, TFO is particularly useful for GET requests. GET
Although not all GET requests are idem-potent, GETs are frequently requests replay could happen across striped TCP connections: after a
replayed today across striped TCP connections: after a server server receives an HTTP request but before the ACKs of the requests
receives an HTTP request but before the ACKs of the requests reach reach the browser, the browser may timeout and retry the same request
the browser, the browser may timeout and retry the same request on on another (possibly new) TCP connection. This differs from a TFO
another (possibly new) TCP connection. This differs from a TFO replay replay only in that the replay is initiated by the browser, not by
only in that the replay is initiated by the browser, not by the TCP the TCP stack.
stack.
6.3.2. Speculative Connections by the Applications
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.
6.3.3. HTTP over TLS (HTTPS)
6.3.2. HTTP over TLS (HTTPS)
For TLS over TCP, it is safe and useful to include TLS CLIENT_HELLO For TLS over TCP, it is safe and useful to include TLS CLIENT_HELLO
in the SYN packet to save one RTT in TLS handshake. There is no in the SYN packet to save one RTT in TLS handshake. There is no
concern about violating idem-potency. In particular it can be used concern about violating idem-potency. In particular it can be used
alone with the speculative connection above. alone with the speculative connection above.
6.3.4. Comparison with HTTP Persistent Connections 6.3.3. Comparison with HTTP Persistent Connections
Is TFO useful given the wide deployment of HTTP persistent Is TFO useful given the wide deployment of HTTP persistent
connections? The short answer is yes. Studies [RCCJR11][AERG11] show connections? The short answer is yes. Studies [RCCJR11][AERG11] show
that the average number of transactions per connection is between 2 that the average number of transactions per connection is between 2
and 4, based on large-scale measurements from both servers and and 4, based on large-scale measurements from both servers and
clients. In these studies, the servers and clients both kept idle clients. In these studies, the servers and clients both kept idle
connections up to several minutes, well into "human think" time. connections up to several minutes, well into "human think" time.
Keeping connections open and idle even longer risks a greater Keeping connections open and idle even longer risks a greater
performance penalty. [HNESSK10][MQXMZ11] show that the majority of performance penalty. [HNESSK10][MQXMZ11] show that the majority of
home routers and ISPs fail to meet the the 124-minute idle timeout home routers and ISPs fail to meet the 124-minute idle timeout
mandated in [RFC5382]. In [MQXMZ11], 35% of mobile ISPs silently mandated in [RFC5382]. In [MQXMZ11], 35% of mobile ISPs silently
timeout idle connections within 30 minutes. End hosts, unaware of timeout idle connections within 30 minutes. End hosts, unaware of
silent middle-box timeouts, suffer multi-minute TCP timeouts upon silent middle-box timeouts, suffer multi-minute TCP timeouts upon
using those long-idle connections. using those long-idle connections.
To circumvent this problem, some applications send frequent TCP keep- To circumvent this problem, some applications send frequent TCP keep-
alive probes. However, this technique drains power on mobile devices alive probes. However, this technique drains power on mobile devices
[MQXMZ11]. In fact, power has become such a prominent issue in modern [MQXMZ11]. In fact, power has become such a prominent issue in modern
LTE devices that mobile browsers close HTTP connections within LTE devices that mobile browsers close HTTP connections within
seconds or even immediately [SOUDERS11]. seconds or even immediately [SOUDERS11].
[RCCJR11] studied Chrome browser [Chrome] performance based on 28 [RCCJR11] studied Chrome browser [Chrome] performance based on 28
days of global statistics. The Chrome browser keeps idle HTTP days of global statistics. The Chrome browser keeps idle HTTP
persistent connections for 5 to 10 minutes. However the average persistent connections for 5 to 10 minutes. However the average
number of the transactions per connection is only 3.3 and TCP 3WHS number of the transactions per connection is only 3.3 and TCP 3WHS
accounts for up to 25% of the HTTP transaction network latency. The 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 authors estimated that TFO improves page load time by 10% to 40% on
selected popular Web sites. selected popular Web sites.
6.3.4. Load Balancers and Server farms
Servers behind a 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 regular 3WHS.
7. Open Areas for Experimentation 7. Open Areas for Experimentation
We now outline some areas that need experimentation in the Internet We now outline some areas that need experimentation in the Internet
and under different network scenarios. These experiments should help and under different network scenarios. These experiments should help
the community evaluate Fast Open benefits and risks towards further the community evaluate Fast Open benefits and risks towards further
standardization and implementation of Fast Open and its related standardization and implementation of Fast Open and its related
protocols. protocols.
7.1. Performance impact due to middle-boxes and NAT 7.1. Performance impact due to middle-boxes and NAT
[MAF04] found that some middle-boxes and end-hosts may drop packets [MAF04] found that some middle-boxes and end-hosts may drop packets
with unknown TCP options. Studies [LANGLEY06, HNRGHT11] both found with unknown TCP options. Studies [LANGLEY06, HNRGHT11] both found
that 6% of the probed paths on the Internet drop SYN packets with 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 data or with unknown TCP options. The TFO protocol deals with this
problem by falling back to regular TCP handshake and re-transmitting problem by falling back to regular TCP handshake and re-transmitting
SYN without data or cookie options after the initial SYN timeout. SYN without data or cookie options after the initial SYN timeout.
Moreover the implementation is recommended to negatively cache such Moreover the implementation is recommended to negatively cache such
incidents to avoid recurring timeouts. Further study is required to incidents to avoid recurring timeouts. Further study is required to
evaluate the performance impact of these malicious drop behaviors. evaluate the performance impact of these drop behaviors.
Another interesting study is the (loss of) TFO performance benefit Another interesting study is the loss of TFO performance benefit
behind certain carrier-grade NAT. Typically hosts behind a NAT behind certain carrier-grade NAT. Typically hosts behind a NAT
sharing the same IP address will get the same cookie for the same sharing the same IP address will get the same cookie for the same
server. This will not prevent TFO from working. But on some carrier- server. This will not prevent TFO from working. But on some carrier-
grade NAT configurations where every new TCP connection from the same grade NAT configurations where every new TCP connection from the same
physical host uses a different public IP address, TFO does not physical host uses a different public IP address, TFO does not
provide latency benefits. However, there is no performance penalty provide latency benefits. However, there is no performance penalty
either, as described in Section "Client: Receiving SYN-ACK". either, as described in Section "Client: Receiving SYN-ACK".
7.2. Cookie-less Fast Open 7.2. Impact on congestion control
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. For such an application, the server could decide to
disable TFO cookie checks.
Disabling cookies (i.e., no Fast Open TCP options in SYN and SYN/ACK)
simplifies both the client and the server, as the client no longer
needs to request a cookie and the server no longer needs to check or
generate cookies. Disabling cookies also potentially simplifies
configuration, as the server no longer needs a key. It may be
preferable to enable SYN cookies and disable TFO [RFC4987] when a
server is overloaded by a large-scale Bot-net attack.
Careful experimentation is necessary to evaluate if cookie-less TFO
is practical. The implementation can provide an experimental feature
to allow zero length, or null, cookies as opposed to the minimum 4
bytes cookies. Thus the server may return a null cookie and the
client will send data in SYN with it subsequently. If the server
believes it's under a DoS attack through other defense mechanisms, it
can switch to regular Fast Open for listener sockets.
7.3 Impact on congestion control
Although TFO does not directly change the congestion control, there Although TFO does not directly change the congestion control, there
are subtle cases that it may. When SYN-ACK times out, regular TCP are subtle cases that it may. When SYN-ACK times out, regular TCP
reduces the initial congestion window before sending any data reduces the initial congestion window before sending any data
[RFC5681]. However in TFO the server may have already sent up to an [RFC5681]. However in TFO the server may have already sent up to an
initial window of data. initial window of data.
If the server serves mostly short connections then the losses of SYN- If the server serves mostly short connections then the losses of SYN-
ACKs are not as effective as regular TCP on reducing the congestion ACKs are not as effective as regular TCP on reducing the congestion
window. This could result in an unstable network condition. The window. This could result in an unstable network condition. The
connections that experience losses may attempt again and add more connections that experience losses may attempt again and add more
load under congestion. A potential solution is to temporarily disable load under congestion. A potential solution is to temporarily disable
Fast Open if the server observes many SYN-ACK or data losses during Fast Open if the server observes many SYN-ACK or data losses during
the handshake across connections. Further experimentation regarding the handshake across connections. Further experimentation regarding
the congestion control impact will be useful. the congestion control impact will be useful.
7.3. Cookie-less 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.
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.
8. Related Work 8. Related Work
8.1. T/TCP 8.1. T/TCP
TCP Extensions for Transactions [RFC1644] attempted to bypass the TCP Extensions for Transactions [RFC1644] attempted to bypass the
three-way handshake, among other things, hence shared the same goal three-way handshake, among other things, hence shared the same goal
but also the same set of issues as TFO. It focused most of its effort 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 battling old or duplicate SYNs, but paid no attention to security
vulnerabilities it introduced when bypassing 3WHS [PHRACK98]. vulnerabilities it introduced when bypassing 3WHS [PHRACK98].
skipping to change at page 21, line 34 skipping to change at page 19, line 42
SYN without data. But from the stateless SYN-cookies to the stateful SYN without data. But from the stateless SYN-cookies to the stateful
SYN Cache, none can preserve data sent with SYN safely while still SYN Cache, none can preserve data sent with SYN safely while still
providing an effective defense. providing an effective defense.
The best defense may be to simply disable TFO when a host is The best defense may be to simply disable TFO when a host is
suspected to be under a SYN flood attack, e.g., the SYN backlog 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 filled. Once TFO is disabled, normal SYN flood defenses can be
applied. The "Security Consideration" section contains a thorough applied. The "Security Consideration" section contains a thorough
discussion on this topic. discussion on this topic.
8.3. TCP Cookie Transaction (TCPCT) 8.3. Speculative Connections by the Applications
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.
8.4. Fast Open Cookie in FIN
An alternate proposal is to request a TFO cookie in the FIN instead,
since FIN-drop by incompatible middle-boxes 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.
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.
8.5. TCP Cookie Transaction (TCPCT)
TCPCT [RFC6013] eliminates server state during initial handshake and TCPCT [RFC6013] eliminates server state during initial handshake and
defends spoofing DoS attacks. Like TFO, TCPCT allows SYN and SYN-ACK 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 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 of data during the handshake instead of the initial congestion window
unlike TFO. Therefore the latency of applications such as Web may be unlike TFO. Therefore the latency of applications such as Web may be
worse than with TFO. worse than with TFO.
9. IANA Considerations 9. IANA Considerations
IANA is requested to allocate one value from the TCP Option Kind IANA is requested to allocate one value from the TCP Option Kind
Numbers: The constant-TBD in Section Section 4.1.1 has to be replaced Numbers: The constant-TBD in Section 4.1.1 has to be replaced with
with the newly assigned value. The length of the new TCP option Kind the newly assigned value. The length of the new TCP option Kind is
is variable and the Meaning should be set to "TCP Fast Open Cookie". variable and the Meaning should be set to "TCP Fast Open Cookie".
Early implementation before the IANA allocation SHOULD follow Early implementation before the IANA allocation SHOULD follow
[RFC6994] and use experimental option 254 and magic number 0xF989 (16 [RFC6994] and use experimental option 254 and magic number 0xF989 (16
bits), then migrate to the new option after the allocation bits), then migrate to the new option after the allocation
accordingly. accordingly.
10. Acknowledgement 10. Acknowledgement
We thank Bob Briscoe, Michael Scharf, Gorry Fairhurst, Rick Jones, We thank Bob Briscoe, Michael Scharf, Gorry Fairhurst, Rick Jones,
Roberto Peon, William Chan, Adam Langley, Neal Cardwell, Eric Roberto Peon, William Chan, Adam Langley, Neal Cardwell, Eric
Dumazet, and Matt Mathis for their feedbacks. We especially thank Dumazet, and Matt Mathis for their feedbacks. We especially thank
skipping to change at page 25, line 11 skipping to change at page 22, line 43
[BELSHE11] Belshe, M., "The era of browser preconnect.", [BELSHE11] Belshe, M., "The era of browser preconnect.",
http://www.belshe.com/2011/02/10/ http://www.belshe.com/2011/02/10/
the-era-of-browser-preconnect/ the-era-of-browser-preconnect/
[JIDKT07] Jaiswal, S., Iannaccone, G., Diot, C., Kurose, J., [JIDKT07] Jaiswal, S., Iannaccone, G., Diot, C., Kurose, J.,
Towsley, D., "Measurement and classification of Towsley, D., "Measurement and classification of
out-of-sequence packets in a tier-1 IP backbone.". out-of-sequence packets in a tier-1 IP backbone.".
IEEE/ACM Transactions on Networking (TON), 15(1), 54-66. IEEE/ACM Transactions on Networking (TON), 15(1), 54-66.
[Chrome] Chrome Browser. https://www.google.com/intl/en-US/chrome/browser/ [Chrome] Chrome. https://www.google.com/intl/en-US/chrome/browser/
Appendix A. Example Socket API Changes to support TFO Appendix A. Example Socket API Changes to support TFO
A.1 Active Open A.1 Active Open
The active open side involves changing or replacing the connect() The active open side involves changing or replacing the connect()
call, which does not take a user data buffer argument. We recommend call, which does not take a user data buffer argument. We recommend
replacing connect() call to minimize API changes and hence replacing connect() call to minimize API changes and hence
applications to reduce the deployment hurdle. applications to reduce the deployment hurdle.
 End of changes. 47 change blocks. 
187 lines changed or deleted 183 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/