draft-ietf-tcpm-fastopen-04.txt   draft-ietf-tcpm-fastopen-05.txt 
Internet Draft Y. Cheng Internet Draft Y. Cheng
draft-ietf-tcpm-fastopen-04.txt J. Chu draft-ietf-tcpm-fastopen-05.txt J. Chu
Intended status: Experimental S. Radhakrishnan Intended status: Experimental S. Radhakrishnan
Expiration date: February, 2014 A. Jain Expiration date: February, 2014 A. Jain
Google, Inc. Google, Inc.
July 15, 2013 October 14, 2013
TCP Fast Open TCP Fast Open
Status of this Memo Status of this Memo
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 2, line 9 skipping to change at page 2, line 9
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.
Abstract Abstract
TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK
packets and consumed by the receiving end during the initial packets and consumed by the receiving end during the initial
connection handshake, thus saving up to one full round trip time connection handshake, thus saving up to one full round trip time
(RTT) compared to the standard TCP, which requires a three-way (RTT) compared to the standard TCP, which requires a three-way
handshake (3WHS) to complete before data can be exchanged. However handshake (3WHS) to complete before data can be exchanged. However
TFO deviates from the standard TCP semantics in that the data in the TFO deviates from the standard TCP semantics; the data in the SYN
SYN could be replayed to an application in some rare circumstances. could be replayed to an application in some rare circumstances.
Applications should not use TFO unless they can tolerate this issue, Applications should not use TFO unless they can tolerate this issue
which is detailed in the Applicability section. detailed in the Applicability section.
Terminology 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.
Table of Contents Table of Contents
skipping to change at page 2, line 40 skipping to change at page 2, line 40
4.1. Fast Open Cookie . . . . . . . . . . . . . . . . . . . . . 7 4.1. Fast Open Cookie . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. TCP Options . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. TCP Options . . . . . . . . . . . . . . . . . . . . . . 7
4.1.2. Server Cookie Handling . . . . . . . . . . . . . . . . 8 4.1.2. Server Cookie Handling . . . . . . . . . . . . . . . . 8
4.1.3. Client Cookie Handling . . . . . . . . . . . . . . . . 9 4.1.3. Client Cookie Handling . . . . . . . . . . . . . . . . 9
4.2. Fast Open Protocol . . . . . . . . . . . . . . . . . . . . 9 4.2. Fast Open Protocol . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Fast Open Cookie Request . . . . . . . . . . . . . . . 10 4.2.1. Fast Open Cookie Request . . . . . . . . . . . . . . . 10
4.2.2. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . 11 4.2.2. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1 Attacks from behind Sharing Public IPs (NATs) . . . . . 14 5.1.1 Attacks from behind Shared Public IPs (NATs) . . . . . . 14
5.2. Amplified Reflection Attack to Random Host . . . . . . . . 15 5.2. Amplified Reflection Attack to Random Host . . . . . . . . 15
6. TFO's Applicability . . . . . . . . . . . . . . . . . . . . . . 16 6. TFO's Applicability . . . . . . . . . . . . . . . . . . . . . . 16
6.1 Duplicate Data in SYNs . . . . . . . . . . . . . . . . . . . 16 6.1 Duplicate Data in SYNs . . . . . . . . . . . . . . . . . . . 16
6.2 Potential Performance Improvement . . . . . . . . . . . . . 16 6.2 Potential Performance Improvement . . . . . . . . . . . . . 16
6.3. Example: Web Clients and Servers . . . . . . . . . . . . . 16 6.3. Example: Web Clients and Servers . . . . . . . . . . . . . 16
6.3.1. HTTP Request Replay . . . . . . . . . . . . . . . . . . 16 6.3.1. HTTP Request Replay . . . . . . . . . . . . . . . . . . 16
6.3.2. Comparison with HTTP Persistent Connections . . . . . . 17 6.3.2. Speculative Connections by the Applications . . . . . . 17
7. Open Areas for Experimentation . . . . . . . . . . . . . . . . 17 6.3.2. HTTP over TLS (HTTPS) . . . . . . . . . . . . . . . . . 17
6.3.3. Comparison with HTTP Persistent Connections . . . . . . 17
7. Open Areas for Experimentation . . . . . . . . . . . . . . . . 18
7.1. Performance impact due to middle-boxes and NAT . . . . . . 18 7.1. Performance impact due to middle-boxes and NAT . . . . . . 18
7.2. Cookie-less Fast Open . . . . . . . . . . . . . . . . . . . 18 7.2. Cookie-less Fast Open . . . . . . . . . . . . . . . . . . . 18
8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. T/TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. T/TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Common Defenses Against SYN Flood Attacks . . . . . . . . . 19 8.2. Common Defenses Against SYN Flood Attacks . . . . . . . . . 19
8.3. TCP Cookie Transaction (TCPCT) . . . . . . . . . . . . . . 19 8.3. TCP Cookie Transaction (TCPCT) . . . . . . . . . . . . . . 19
8.4. Speculative Connections by the Applications . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Example Socket API Changes to support TFO . . . . . . 22 Appendix A. Example Socket API Changes to support TFO . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
TCP Fast Open (TFO) enables data to be exchanged safely during TCP's TCP Fast Open (TFO) enables data to be exchanged safely during TCP's
connection handshake. This document describes a design that enables connection handshake. This document describes a design that enables
applications to save a round trip while avoiding severe security applications to save a round trip while avoiding severe security
ramifications. At the core of TFO is a security cookie used by the ramifications. At the core of TFO is a security cookie used by the
server side to authenticate a client initiating a TFO connection. server side to authenticate a client initiating a TFO connection.
This document covers the details of exchanging data during TCP's This document covers the details of exchanging data during TCP's
initial handshake, the protocol for TFO cookies, potential new initial handshake, the protocol for TFO cookies, potential new
security vulnerabilities and their mitigation, and the new socket security vulnerabilities and their mitigation, and the new socket
API. API.
TFO is motivated by the performance needs of today's Web TFO is motivated by the performance needs of today's Web
applications. Current TCP only permits data exchange after 3WHS applications. Current TCP only permits data exchange after 3WHS
[RFC793], which adds one RTT to network latency. For short Web [RFC793], which adds one RTT to network latency. For short Web
transfers this additional RTT is a significant portion of overall transfers this additional RTT is a significant portion of overall
network latency [THK98], even when HTTP persistent connection is network latency, even when HTTP persistent connection is widely used.
widely used. For example, the Chrome browser keeps TCP connections For example, the Chrome browser keeps TCP connections idle for up to
idle for up to 5 minutes but 35% of Chrome HTTP requests are made on 5 minutes but 35% of Chrome HTTP requests are made on new TCP
new TCP connections [RCCJR11]. For such Web and Web-like applications connections [RCCJR11]. For such Web and Web-like applications placing
placing data in the SYN can yield significant latency improvements. data in the SYN can yield significant latency improvements. Next we
Next we describe how we resolve the challenges that arise upon doing describe how we resolve the challenges that arise upon doing so.
so.
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.
Allowing data in SYN packets to be delivered raises two issues To enable applications exchange data in TCP handshake, TFO removes
discussed in the following subsections. These issues make TFO the constraint and allows data in SYN packets to be delivered to
unsuitable for certain applications. Therefore TCP implementations application. This change of TCP semantic raises two issues discussed
MUST NOT use TFO by default, but only use TFO if requested explicitly in the following subsections, making TFO unsuitable for certain
by the application on a per service port basis. Applications need to applications.
evaluate TFO applicability described in Section 6 before using TFO.
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 described
in Section 6 before using TFO.
2.1 Relaxing TCP Semantics on Duplicated SYNs 2.1 Relaxing TCP Semantics on Duplicated SYNs
TFO allows data to be delivered to the application before 3WHS is TFO allows data to be delivered to the application before 3WHS is
completed, thus opening itself to a data integrity issue in either of completed, thus opening itself to a data integrity issue in either of
the two cases below: the two cases below:
a) the receiver host receives data in a duplicate SYN after it has 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); forgotten it received the original SYN (e.g. due to a reboot);
b) the duplicate is received after the connection created by the b) the duplicate is received after the connection created by the
original SYN has been closed and the close was initiated by the original SYN has been closed and the close was initiated by the
sender (so the receiver will not be protected by the 2MSL TIMEWAIT sender (so the receiver will not be protected by the 2MSL TIMEWAIT
state). state).
The now obsoleted T/TCP [RFC1644] attempted to address these issues. The now obsoleted T/TCP [RFC1644] attempted to address these issues.
It is not successful and not deployed due to various vulnerabilities It is not successful and not deployed due to various vulnerabilities
[PHRACK98]. Rather than trying to capture all dubious SYN packets to as described in the Related Work section. Rather than trying to
make TFO 100% compatible with TCP semantics, we made a design capture all dubious SYN packets to make TFO 100% compatible with TCP
decision early on to accept old SYN packets with data, i.e., to semantics, we made a design decision early on to accept old SYN
restrict TFO use to a class of applications (Section 6) that are packets with data, i.e., to restrict TFO use to a class of
tolerant of duplicate SYN packets with data. We believe this is the applications (Section 6) that are tolerant of duplicate SYN packets
right design trade-off balancing complexity with usefulness. with data. We believe this is the right design trade-off balancing
complexity with usefulness.
2.2. SYNs with Spoofed IP Addresses 2.2. SYNs with Spoofed IP Addresses
Standard TCP suffers from the SYN flood attack [RFC4987] because Standard TCP suffers from the SYN flood attack [RFC4987] because SYN
bogus SYN packets, i.e., SYN packets with spoofed source IP addresses packets with spoofed source IP addresses can easily fill up a
can easily fill up a listener's small queue, causing a service port listener's small queue, causing a service port to be blocked
to be blocked completely until timeouts. Secondary damage comes from completely until timeouts.
these SYN requests taking up memory space. Though this is less of an
issue today as servers typically have plenty of memory.
TFO goes one step further to allow server-side TCP to send up data to TFO goes one step further to allow server-side TCP to send up data to
the application layer before 3WHS is completed. This opens up serious the application layer before 3WHS is completed. This opens up serious
new vulnerabilities. Applications serving ports that have TFO enabled new vulnerabilities. Applications serving ports that have TFO enabled
may waste lots of CPU and memory resources processing the requests may waste lots of CPU and memory resources processing the requests
and producing the responses. If the response is much larger than the and producing the responses. If the response is much larger than the
request, the attacker can further mount an amplified reflection request, the attacker can further mount an amplified reflection
attack against victims of choice beyond the TFO server itself. attack against victims of choice beyond the TFO server itself.
Numerous mitigation techniques against regular SYN flood attacks Numerous mitigation techniques against regular SYN flood attacks
exist and have been well documented [RFC4987]. Unfortunately none are exist and have been well documented [RFC4987]. Unfortunately none are
applicable to TFO. We propose a server-supplied cookie to mitigate applicable to TFO. We propose a server-supplied cookie to mitigate
these new vulnerabilities in Section 3 and evaluate the effectiveness these new vulnerabilities in the next Section and evaluate the
of the defense in Section 7. effectiveness of the defense in Section 7.
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:
skipping to change at page 10, line 39 skipping to change at page 10, line 39
3. If the SYN-ACK contains a Fast Open Cookie option, the client 3. If the SYN-ACK contains a Fast Open Cookie option, 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 SYN-
ACK is a spurious retransmission without valid Fast Open Cookie ACK is a spurious retransmission without valid Fast Open Cookie
Option, the client does nothing to the cookie cache for the Option, the client does nothing to 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 causes 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). Next section describes a heuristic to detect such drops congestion). Next section describes a heuristic to detect such drops
when the client receives the SYN-ACK. when the client receives the SYN-ACK.
skipping to change at page 14, line 30 skipping to change at page 14, line 30
may combine the two, e.g., by continuing to account for those may combine the two, e.g., by continuing to account for those
connection requests that have just been reset against the listener's connection requests that have just been reset against the listener's
PendingFastOpenRequests until a timeout period has passed. PendingFastOpenRequests until a timeout period has passed.
Limiting the maximum number of pending TFO connection requests does Limiting the maximum number of pending TFO connection requests does
make it easy for an attacker to overflow the queue, causing TFO to be 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 disabled. We argue that causing TFO to be disabled is unlikely to be
of interest to attackers because the service will remain intact of interest to attackers because the service will remain intact
without TFO hence there is hardly any real damage. without TFO hence there is hardly any real damage.
5.1.1 Attacks from behind Sharing Public IPs (NATs) 5.1.1 Attacks from behind Shared Public IPs (NATs)
An attacker behind NAT can easily obtain valid cookies to launch the An attacker behind NAT can easily obtain valid cookies to launch the
above attack to hurt other clients that share the path. [BRISCOE12] above attack to hurt other clients that share the path. [BRISCOE12]
suggested that the server can extend cookie generation to include the suggested that the server can extend cookie generation to include the
TCP timestamp---GetCookie(IP_Address, Timestamp)---and implement it TCP timestamp---GetCookie(IP_Address, Timestamp)---and implement it
by encrypting the concatenation of the two values to generate the by encrypting the concatenation of the two values to generate the
cookie. The client stores both the cookie and its corresponding cookie. The client stores both the cookie and its corresponding
timestamp, and echoes both in the SYN. The server then implements timestamp, and echoes both in the SYN. The server then implements
IsCookieValid(IP_Address, Timestamp, Cookie) by encrypting the IP and IsCookieValid(IP_Address, Timestamp, Cookie) by encrypting the IP and
timestamp data and comparing it with the cookie value. timestamp data and comparing it with the cookie value.
skipping to change at page 16, line 9 skipping to change at page 16, line 9
The best defense is for the server not to respond with data until The best defense is for the server not to respond with data until
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. A proposed socket API change applications as an example throughout. Applications here refer
is in the Appendix. specifically to the process that writes data into the socket, i.e., a
java script process that sends data to the server. A proposed socket
API change is in the Appendix.
6.1 Duplicate Data in SYNs 6.1 Duplicate Data in SYNs
It is possible, though uncommon, that using TFO results in the first It is possible, though uncommon, that using TFO results in the first
data written to a socket to be delivered more than once to the data written to a socket to be delivered more than once to the
application on the remote host(Section 2.1). This replay potential application on the remote host(Section 2.1). This replay potential
only applies to data in the SYN but not subsequent data exchanges. only applies to data in the SYN but not subsequent data exchanges.
The client MUST NOT use TFO to send data in the SYN, and the server The client MUST NOT use TFO to send data in the SYN, and the server
MUST NOT accept data in the SYN if it cannot handle receiving the MUST NOT accept data in the SYN if it cannot handle receiving the
same SYN data more than once, due to reasons described before. same SYN data more than once, due to reasons described before.
skipping to change at page 16, line 34 skipping to change at page 16, line 36
TFO is designed for latency-conscious applications that are sensitive TFO is designed for latency-conscious applications that are sensitive
to TCP's initial connection setup delay. To benefit from TFO, the 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 first application data unit (e.g., an HTTP request) needs to be no
more than TCP's maximum segment size (minus options used in SYN). more than TCP's maximum segment size (minus options used in SYN).
Otherwise the remote server can only process the client's application Otherwise the remote server can only process the client's application
data unit once the rest of it is delivered after the initial data unit once the rest of it is delivered after the initial
handshake, diminishing TFO's benefit. handshake, diminishing TFO's benefit.
To the extent possible, applications SHOULD reuse the connection to To the extent possible, applications SHOULD reuse the connection to
take advantage of TCP's built-in congestion control and reduce take advantage of TCP's built-in congestion control and reduce
connection setup overhead. An application employs too many short- connection setup overhead. An application that employs too many
lived connections will negatively impact network stability, as these short-lived connections will negatively impact network stability, as
connections often exit before TCP's congestion control algorithm these connections often exit before TCP's congestion control
takes effect. algorithm takes effect.
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).
TFO is particularly useful for GET requests. Even though not all GET On the other hand, TFO is particularly useful for GET requests.
requests are idempotent, GETs are frequently replayed today across Although not all GET requests are idempotent, GETs are frequently
striped TCP connections. After a server receives an HTTP request but replayed today across striped TCP connections: after a server
before the ACKs of the requests reach the browser, the browser may receives an HTTP request but before the ACKs of the requests reach
timeout and retry the same request on another (possibly new) TCP the browser, the browser may timeout and retry the same request on
connection. This differs from a TFO replay only in that the replay is another (possibly new) TCP connection. This differs from a TFO replay
initiated by the browser, not by the TCP stack. only in that the replay is initiated by the browser, not by the TCP
stack.
Finally, TFO is safe and useful for HTTPS requests because it saves 6.3.2. Speculative Connections by the Applications
the first SSL handshake RTT and the HTTP request is sent after the
connection establishes.
6.3.2. Comparison with HTTP Persistent Connections 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.2. HTTP over TLS (HTTPS)
For TLS over TCP, it is safe and useful to include TLS CLIENT_HELLO
in the SYN packet to save 1-RTT in TLS handshake. There is no concern
about violating idempotency. In particular it can be used alone with
the speculative connection above. While HTTPS adoption is still low,
it will increase over time (especially given the context of recent
revelations). Thus the potential importance of TCP Fast Open in
decreasing user perceived latency in HTTPS.
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
skipping to change at page 17, line 39 skipping to change at page 18, line 9
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 performance based on 28 days of [RCCJR11] studied Chrome browser performance based on 28 days of
global statistics. The Chrome browser keeps idle HTTP persistent global statistics. The Chrome browser keeps idle HTTP persistent
connections for 5 to 10 minutes. However the average number of the connections for 5 to 10 minutes. However the average number of the
transactions per connection is only 3.3 and TCP 3WHS accounts for up transactions per connection is only 3.3 and TCP 3WHS accounts for up
to 25% of the HTTP transaction network latency. The authors tested a to 25% of the HTTP transaction network latency. The authors estimated
Linux TFO implementation with TFO enabled Chrome browser on popular that TFO TFO improves page load time by 10% to 40% on selected
web sites in emulated environments such as residential broadband and popular Web sites.
mobile networks. They showed that TFO improves page load time by 10%
to 40%.
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 malicious 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".
skipping to change at page 19, line 40 skipping to change at page 20, line 8
8.3. TCP Cookie Transaction (TCPCT) 8.3. 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 applications like Web may not receive the unlike TFO. Therefore applications like Web may not receive the
latency benefit as TFO. latency benefit as TFO.
8.4. 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]. The downside of this approach is that it wastes
server and network resources by initiating and maintaining idle
connections; It is also subject to the NAT timeout issues described
in Section 6.3.2. TFO offers similar performance improvement without
the added overhead.
9. IANA Considerations 9. IANA Considerations
The Fast Open Cookie Option and Fast Open Cookie Request Option The Fast Open Cookie Option and Fast Open Cookie Request Option
define no new namespace. The options require IANA to allocate one define no new namespace. The options require IANA to allocate one
value from the TCP option Kind namespace. Early implementation before value from the TCP option Kind namespace. Early implementation before
the IANA allocation SHOULD follow [EXPOPT] and use experimental the IANA allocation SHOULD follow [RFC6994] and use experimental
option 254 and magic number 0xF989 (16 bits), then migrate to the new option 254 and magic number 0xF989 (16 bits), then migrate to the new
option after the allocation accordingly. option after the allocation accordingly.
10. Acknowledgement 10. Acknowledgement
We thank Rick Jones, Bob Briscoe, Adam Langley, Matt Mathis, Neal We thank Rick Jones, Bob Briscoe, Adam Langley, Matt Mathis, Neal
Cardwell, Roberto Peon, William Chan, Eric Dumazet, and Tom Herbert Cardwell, Roberto Peon, William Chan, Eric Dumazet, and Tom Herbert
for their feedbacks. We especially thank Barath Raghavan for his for their feedbacks. We especially thank Barath Raghavan for his
contribution on the security design of Fast Open and proofreading contribution on the security design of Fast Open and proofreading
this draft numerous times. this draft numerous times.
skipping to change at page 20, line 37 skipping to change at page 20, line 43
[RFC5382] S. Guha, Ed., Biswas, K., Ford B., Sivakumar S., Srisuresh, [RFC5382] S. Guha, Ed., Biswas, K., Ford B., Sivakumar S., Srisuresh,
P., "NAT Behavioral Requirements for TCP", RFC 5382 P., "NAT Behavioral Requirements for TCP", RFC 5382
[RFC5681] Allman, M., Paxson, V. and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V. and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009. Control", RFC 5681, September 2009.
[RFC6298] Paxson, V., Allman, M., Chu, J. and M. Sargent, "Computing [RFC6298] Paxson, V., Allman, M., Chu, J. and M. Sargent, "Computing
TCP's Retransmission Timer", RFC 6298, June 2011. TCP's Retransmission Timer", RFC 6298, June 2011.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y. and M. Mathis, [RFC6928] Chu, J., Dukkipati, N., Cheng, Y. and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928, April 2013. "Increasing TCP's Initial Window", RFC 6928, April 2013.
[RFC6994] Touch, Joe, "Shared Use of Experimental TCP Options",
RFC 6694, August 2013.
11.2. Informative References 11.2. Informative References
[AERG11] M. Al-Fares, K. Elmeleegy, B. Reed, and I. Gashinsky, [AERG11] M. Al-Fares, K. Elmeleegy, B. Reed, and I. Gashinsky,
"Overclocking the Yahoo! CDN for Faster Web Page Loads". In "Overclocking the Yahoo! CDN for Faster Web Page Loads". In
Proceedings of Internet Measurement Conference, November Proceedings of Internet Measurement Conference, November
2011. 2011.
[EXPOPT] Touch, Joe, "Shared Use of Experimental TCP Options",
Internet-Draft draft-ietf-tcpm-experimental-options (work
in progress), June 2013.
[HNESSK10] S. Haetoenen, A. Nyrhinen, L. Eggert, S. Strowes, P. [HNESSK10] S. Haetoenen, A. Nyrhinen, L. Eggert, S. Strowes, P.
Sarolahti, M. Kojo., "An Experimental Study of Home Gateway Sarolahti, M. Kojo., "An Experimental Study of Home Gateway
Characteristics". In Proceedings of Internet Measurement Characteristics". In Proceedings of Internet Measurement
Conference. Octobor 2010 Conference. Octobor 2010
[HNRGHT11] M. Honda, Y. Nishida, C. Raiciu, A. Greenhalgh, M. [HNRGHT11] M. Honda, Y. Nishida, C. Raiciu, A. Greenhalgh, M.
Handley, H. Tokuda, "Is it Still Possible to Extend TCP?". Handley, H. Tokuda, "Is it Still Possible to Extend TCP?".
In Proceedings of Internet Measurement Conference. November In Proceedings of Internet Measurement Conference. November
2011. 2011.
[LANGLEY06] Langley, A, "Probing the viability of TCP extensions", [LANGLEY06] Langley, A, "Probing the viability of TCP extensions",
skipping to change at page 21, line 52 skipping to change at page 22, line 9
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, August 2007. Mitigations", RFC 4987, August 2007.
[RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC6013, [RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC6013,
January 2011. January 2011.
[SOUDERS11] S. Souders. "Making A Mobile Connection". [SOUDERS11] S. Souders. "Making A Mobile Connection".
http://www.stevesouders.com/blog/2011/09/21/making-a- http://www.stevesouders.com/blog/2011/09/21/making-a-
mobile-connection/ mobile-connection/
[THK98] Touch, J., Heidemann, J., Obraczka, K., "Analysis of HTTP
Performance", USC/ISI Research Report 98-463. December
1998.
[BRISCOE12] Briscoe, B., "Some ideas building on draft-ietf-tcpm- [BRISCOE12] Briscoe, B., "Some ideas building on draft-ietf-tcpm-
fastopen-01", tcpm list, fastopen-01", tcpm list,
http://www.ietf.org/mail-archive/web/tcpm/current/ http://www.ietf.org/mail-archive/web/tcpm/current/
January 16, 2014msg07192.html January 16, 2014msg07192.html
[BELSHE12] Belshe, M., "The era of browser preconnect.", [BELSHE12] 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/
Appendix A. Example Socket API Changes to support TFO Appendix A. Example Socket API Changes to support TFO
The design rationale is to minimize changes to the socket API and A.1 Active Open
hence applications, in order to reduce the deployment hurdle. The
following changes have been implemented in Linux 3.7 or later
kernels.
A.1 MSG_FASTOPEN flag for sendto() or sendmsg() The active open side involves changing or replacing the connect()
call, which does not take a user data buffer argument. We recommend
replacing connect() call to minimize API changes and hence
applications to reduce the deployment hurdle.
MSG_FASTOPEN marks the attempt to send data in SYN like a combination One solution implemented in Linux 3.7 is introducing a new flag
of connect() and sendto(), by performing an implicit connect() MSG_FASTOPEN for sendto() or sendmsg(). MSG_FASTOPEN marks the
operation. It blocks until the handshake has completed and the data attempt to send data in SYN like a combination of connect() and
is buffered. sendto(), by performing an implicit connect() operation. It blocks
until the handshake has completed and the data is buffered.
For non-blocking socket it returns the number of bytes buffered and For non-blocking socket it returns the number of bytes buffered and
sent in the SYN packet. If the cookie is not available locally, it sent in the SYN packet. If the cookie is not available locally, it
returns -1 with errno EINPROGRESS, and sends a SYN with TFO cookie returns -1 with errno EINPROGRESS, and sends a SYN with TFO cookie
request automatically. The caller needs to write the data again when request automatically. The caller needs to write the data again when
the socket is connected. the socket is connected. On errors, it returns the same errno as
connect() if the handshake fails.
It returns the same errno as connect() if the handshake fails. An implementation may prefer not to change the sendmsg() 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 Fast Open
operation similar to the MSG_FASTOPEN flag described above. This
approach however requires an extra setsockopt() system call.
A.2 TCP_FASTOPEN setsockopt() Socket Option A.2 Passive Open
The passive open side change is simpler compared to 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().
The option enables Fast Open on the listener socket. The option value The option enables Fast Open on the listener socket. The option value
specifies the PendingFastOpenRequests threshold, i.e., the maximum specifies the PendingFastOpenRequests threshold, i.e., the maximum
length of pending SYNs with data payload. Once enabled, the TCP length of pending SYNs with data payload. Once enabled, the TCP
implementation will respond with TFO cookies per request. implementation will respond with TFO cookies per request.
Previously accept() returns only after a socket is connected. But for Traditionally accept() returns only after a socket is connected. But
a Fast Open connection, accept() returns upon receiving a SYN with a for a Fast Open connection, accept() returns upon receiving a SYN
valid Fast Open cookie and data, and the data is available to be read with a valid Fast Open cookie and data, and the data is available to
through, e.g., recvmsg(), read(). be read through, e.g., recvmsg(), read().
Authors' Addresses Authors' Addresses
Yuchung Cheng Google, Inc. 1600 Amphitheatre Parkway Mountain View,
CA 94043, USA EMail: ycheng@google.com
Jerry Chu Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA Yuchung Cheng
94043, USA EMail: hkchu@google.com Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043, USA
EMail: ycheng@google.com
Sivasankar Radhakrishnan Department of Computer Science and Jerry Chu
Engineering University of California, San Diego 9500 Gilman Dr La Google, Inc.
Jolla, CA 92093-0404 EMail: sivasankar@cs.ucsd.edu 1600 Amphitheatre Parkway
Mountain View, CA 94043, USA
EMail: hkchu@google.com
Arvind Jain Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA Sivasankar Radhakrishnan
94043, USA EMail: arvind@google.com Department of Computer Science and Engineering
University of California, San Diego
9500 Gilman Dr
La Jolla, CA 92093-0404
EMail: sivasankar@cs.ucsd.edu
Arvind Jain
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043, USA
EMail: arvind@google.com
 End of changes. 41 change blocks. 
110 lines changed or deleted 128 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/