draft-ietf-tcpm-fastopen-06.txt   draft-ietf-tcpm-fastopen-07.txt 
Internet Draft Y. Cheng Internet Draft Y. Cheng
draft-ietf-tcpm-fastopen-06.txt J. Chu draft-ietf-tcpm-fastopen-07.txt J. Chu
Intended status: Experimental S. Radhakrishnan Intended status: Experimental S. Radhakrishnan
Expiration date: February, 2014 A. Jain Expiration date: August, 2014 A. Jain
Google, Inc. Google, Inc.
January 26, 2014 February 14, 2014
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 4 skipping to change at page 2, line 4
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
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.
Abstract Abstract
TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK This document describes an experimental TCP mechanism TCP Fast Open
packets and consumed by the receiving end during the initial (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets
connection handshake, thus saving up to one full round trip time and consumed by the receiving end during the initial connection
(RTT) compared to the standard TCP, which requires a three-way handshake, thus saving up to one full round trip time (RTT) compared
handshake (3WHS) to complete before data can be exchanged. However to the standard TCP, which requires a three-way handshake (3WHS) to
TFO deviates from the standard TCP semantics the data in the SYN complete before data can be exchanged. However TFO deviates from the
could be replayed to an application in some rare circumstances. standard TCP semantics the data in the SYN could be replayed to an
Applications should not use TFO unless they can tolerate this issue application in some rare circumstances. Applications should not use
detailed in the Applicability section. TFO unless they can tolerate this issue 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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Data In SYN . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Data In SYN . . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . . 7
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.1.3.1 Client Caching Negative Responses . . . . . . . . . 9 4.1.3.1 Client Caching Negative Responses . . . . . . . . . 9
4.2. Fast Open Protocol . . . . . . . . . . . . . . . . . . . . 9 4.2. Fast Open Protocol . . . . . . . . . . . . . . . . . . . . 10
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 Shared 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 . . . . . . . . . . . . . 17
6.3.1. HTTP Request Replay . . . . . . . . . . . . . . . . . . 16 6.3.1. HTTP Request Replay . . . . . . . . . . . . . . . . . . 17
6.3.2. Speculative Connections by the Applications . . . . . . 17 6.3.2. Speculative Connections by the Applications . . . . . . 17
6.3.3. HTTP over TLS (HTTPS) . . . . . . . . . . . . . . . . . 17 6.3.3. HTTP over TLS (HTTPS) . . . . . . . . . . . . . . . . . 17
6.3.4. Comparison with HTTP Persistent Connections . . . . . . 17 6.3.4. Comparison with HTTP Persistent Connections . . . . . . 17
7. Open Areas for Experimentation . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . 19
7.3 Impact on congestion control . . . . . . . . . . . . . . . . 19 7.3 Impact on congestion control . . . . . . . . . . . . . . . . 19
8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. T/TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. T/TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Common Defenses Against SYN Flood Attacks . . . . . . . . . 19 8.2. Common Defenses Against SYN Flood Attacks . . . . . . . . . 20
8.3. TCP Cookie Transaction (TCPCT) . . . . . . . . . . . . . . 20 8.3. TCP Cookie Transaction (TCPCT) . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Example Socket API Changes to support TFO . . . . . . 22 Appendix A. Example Socket API Changes to support TFO . . . . . . 23
A.1 Active Open . . . . . . . . . . . . . . . . . . . . . . . . 22 A.1 Active Open . . . . . . . . . . . . . . . . . . . . . . . . 23
A.2 Passive Open . . . . . . . . . . . . . . . . . . . . . . . . 23 A.2 Passive Open . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
TCP Fast Open (TFO) enables data to be exchanged safely during TCP's TCP Fast Open (TFO) is an experimental update to TCP that enables
connection handshake. This document describes a design that enables data to be exchanged safely during TCP's connection handshake. This
applications to save a round trip while avoiding severe security document describes a design that enables applications to save a round
ramifications. At the core of TFO is a security cookie used by the trip while avoiding severe security ramifications. At the core of TFO
server side to authenticate a client initiating a TFO connection. is a security cookie used by the server side to authenticate a client
This document covers the details of exchanging data during TCP's initiating a TFO connection. This document covers the details of
initial handshake, the protocol for TFO cookies, potential new exchanging data during TCP's initial handshake, the protocol for TFO
security vulnerabilities and their mitigation, and the new socket cookies, potential new security vulnerabilities and their mitigation,
API. and the new socket 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 the 3-way
[RFC793], which adds one RTT to network latency. For short Web handshake (3WHS)[RFC793], which adds one RTT to network latency. For
transfers this additional RTT is a significant portion of overall short Web transfers this additional RTT is a significant portion of
network latency, even when HTTP persistent connection is widely used. overall network latency, even when HTTP persistent connection is
For example, the Chrome browser keeps TCP connections idle for up to widely used. For example, the Chrome browser keeps TCP connections
5 minutes but 35% of Chrome HTTP requests are made on new TCP idle for up to 5 minutes but 35% of Chrome HTTP requests are made on
connections [RCCJR11]. For such Web and Web-like applications placing new TCP connections [RCCJR11]. For such Web and Web-like applications
data in the SYN can yield significant latency improvements. Next we placing data in the SYN can yield significant latency improvements.
describe how we resolve the challenges that arise upon doing so. Next we describe how we resolve the challenges that arise upon doing
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.
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 constraint and allows data in SYN packets to be delivered to
skipping to change at page 4, line 18 skipping to change at page 4, line 25
in the following subsections, making TFO unsuitable for certain in the following subsections, making TFO unsuitable for certain
applications. applications.
Therefore TCP implementations MUST NOT use TFO by default, but only Therefore TCP implementations MUST NOT use TFO by default, but only
use TFO if requested explicitly by the application on a per service use TFO if requested explicitly by the application on a per service
port basis. Applications need to evaluate TFO applicability described port basis. Applications need to evaluate TFO applicability described
in Section 6 before using TFO. 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 application before the 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 was not successful and not deployed due to various vulnerabilities
as described in the Related Work section. Rather than trying to as described in the Related Work section. Rather than trying to
capture all dubious SYN packets to make TFO 100% compatible with TCP capture all dubious SYN packets to make TFO 100% compatible with TCP
semantics, we made a design decision early on to accept old SYN semantics, we made a design decision early on to accept old SYN
packets with data, i.e., to restrict TFO use to a class of packets with data, i.e., to restrict TFO use to a class of
applications (Section 6) that are tolerant of duplicate SYN packets applications (Section 6) that are tolerant of duplicate SYN packets
with data. We believe this is the right design trade-off balancing with data. We believe this is the right design trade-off balancing
complexity with usefulness. complexity with usefulness.
2.2. SYNs with Spoofed IP Addresses 2.2. SYNs with Spoofed IP Addresses
skipping to change at page 6, line 9 skipping to change at page 6, line 16
the data in the ACK packet. the data in the ACK packet.
5. The rest of the connection proceeds like a normal TCP connection. 5. The rest of the connection proceeds like a normal TCP connection.
The client can repeat many Fast Open operations once it acquires a The client can repeat many Fast Open operations once it acquires a
cookie (until the cookie is expired by the server). Thus TFO is cookie (until the cookie is expired by the server). Thus TFO is
useful for applications that have temporal locality on client and useful for applications that have temporal locality on client and
server connections. server connections.
Requesting Fast Open Cookie in connection 1: Requesting Fast Open Cookie in connection 1:
TCP A (Client) TCP B(Server) TCP A (Client) TCP B(Server)
______________ _____________ ______________ _____________
CLOSED LISTEN CLOSED LISTEN
#1 SYN-SENT ----- <SYN,CookieOpt=NIL> ----------> SYN-RCVD #1 SYN-SENT ----- <SYN,CookieOpt=NIL> ----------> SYN-RCVD
#2 ESTABLISHED <---- <SYN,ACK,CookieOpt=C> ---------- SYN-RCVD #2 ESTABLISHED <---- <SYN,ACK,CookieOpt=C> ---------- SYN-RCVD
(caches cookie C) (caches cookie C)
Performing TCP Fast Open in connection 2: Performing TCP Fast Open in connection 2:
TCP A (Client) TCP B(Server) TCP A (Client) TCP B(Server)
______________ _____________ ______________ _____________
CLOSED LISTEN CLOSED LISTEN
#1 SYN-SENT ----- <SYN=x,CookieOpt=C,DATA_A> ----> SYN-RCVD #1 SYN-SENT ----- <SYN=x,CookieOpt=C,DATA_A> ----> SYN-RCVD
#2 ESTABLISHED <---- <SYN=y,ACK=x+len(DATA_A)+1> ---- SYN-RCVD #2 ESTABLISHED <---- <SYN=y,ACK=x+len(DATA_A)+1> ---- SYN-RCVD
#3 ESTABLISHED <---- <ACK=x+len(DATA_A)+1,DATA_B>---- SYN-RCVD #3 ESTABLISHED <---- <ACK=x+len(DATA_A)+1,DATA_B>---- SYN-RCVD
#4 ESTABLISHED ----- <ACK=y+1>--------------------> ESTABLISHED #4 ESTABLISHED ----- <ACK=y+1>--------------------> ESTABLISHED
#5 ESTABLISHED --- <ACK=y+len(DATA_B)+1>----------> ESTABLISHED #5 ESTABLISHED --- <ACK=y+len(DATA_B)+1>----------> ESTABLISHED
skipping to change at page 8, line 24 skipping to change at page 8, line 24
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
more than one valid cookie per client at any given time. But this more than one valid cookie per client at any given time. But this
is all server implementation dependent and transparent to the is server implementation dependent and transparent to the
client. client.
5. The cookie expires after a certain amount of time. The reason for 5. The cookie expires after a certain amount of time. The reason for
cookie expiration is detailed in the "Security Consideration" cookie expiration is detailed in the "Security Consideration"
section. This can be done by either periodically changing the section. This can be done by either periodically changing the
server key used to generate cookies or including a timestamp when server key used to generate cookies or including a timestamp when
generating the cookie. generating the cookie.
To gradually invalidate cookies over time, the server can To gradually invalidate cookies over time, the server can
implement key rotation to generate and verify cookies using implement key rotation to generate and verify cookies using
skipping to change at page 9, line 29 skipping to change at page 9, line 29
The MSS advertised by the server is stored in the cache to determine The MSS advertised by the server is stored in the cache to determine
the maximum amount of data that can be supported in the SYN packet. the maximum amount of data that can be supported in the SYN packet.
This information is needed because data is sent before the server This information is needed because data is sent before the server
announces its MSS in the SYN-ACK packet. Without this information, announces its MSS in the SYN-ACK packet. Without this information,
the data size in the SYN packet is limited to the default MSS of 536 the data size in the SYN packet is limited to the default MSS of 536
bytes [RFC1122]. In particular it's known IPv4 receiver advertised bytes [RFC1122]. In particular it's known IPv4 receiver advertised
MSS less than 536 bytes would result in transmission of an unexpected MSS less than 536 bytes would result in transmission of an unexpected
large segment. If the cache MSS is larger than the typical 1460 large segment. If the cache MSS is larger than the typical 1460
bytes, the extra large data in SYN segment may have issues that bytes, the extra large data in SYN segment may have issues that
offsets the performance benefit of Fast Open. For examples, the offsets the performance benefit of Fast Open. For examples, the
super-size SYN may trigger IP fragmentation and confuses firewall or super-size SYN may trigger IP fragmentation and may confuse firewall
middle-boxes. Therefore the client MAY limit the cached MSS to 1460 or middle-boxes, causing SYN retransmission and other side-effects.
bytes. Therefore the client MAY limit the cached MSS to 1460 bytes.
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
responses and continue to retry Fast Open, the client may never be responses and continue to retry Fast Open, the client may never be
able to connect to the specific server. able to connect to the specific server.
For any negative responses, the client SHOULD disables Fast Open on For any negative responses, the client SHOULD disable Fast Open on
the specific path and port, at least temporarily. Since TFO is the specific path and port, at least temporarily. Since TFO is
enabled on a per-service port basis but cookies are independent of enabled on a per-service port basis but cookies are independent of
service ports, clients' cache should include remote port numbers too. service ports, clients' cache should include remote port numbers too.
4.2. Fast Open Protocol 4.2. Fast Open Protocol
One predominant requirement of TFO is to be fully compatible with One predominant requirement of TFO is to be fully compatible with
existing TCP implementations, both on the client and the server existing TCP implementations, both on the client and the server
sides. sides.
The server keeps two variables per listening port: The server keeps two variables per listening port:
FastOpenEnabled: default is off. It MUST be turned on explicitly by FastOpenEnabled: default is off. It MUST be turned on explicitly by
the application. When this flag is off, the server does not perform the application. When this flag is off, the server does not perform
any TFO related operations and MUST ignore all cookie options. any TFO related operations and MUST ignore all cookie options.
skipping to change at page 10, line 16 skipping to change at page 10, line 19
sides. sides.
The server keeps two variables per listening port: The server keeps two variables per listening port:
FastOpenEnabled: default is off. It MUST be turned on explicitly by FastOpenEnabled: default is off. It MUST be turned on explicitly by
the application. When this flag is off, the server does not perform the application. When this flag is off, the server does not perform
any TFO related operations and MUST ignore all cookie options. any TFO related operations and MUST ignore all cookie options.
PendingFastOpenRequests: tracks number of TFO connections in SYN-RCVD PendingFastOpenRequests: tracks number of TFO connections in SYN-RCVD
state. If this variable goes over a preset system limit, the server state. If this variable goes over a preset system limit, the server
SHOULD disable TFO for all new connection requests until MUST disable TFO for all new connection requests until
PendingFastOpenRequests drops below the system limit. This variable PendingFastOpenRequests drops below the system limit. This variable
is used for defending some vulnerabilities discussed in the "Security is used for defending some vulnerabilities discussed in the "Security
Considerations" section. Considerations" section.
The server keeps a FastOpened flag per TCB to mark if a connection The server keeps a FastOpened flag per TCB to mark if a connection
has successfully performed a TFO. 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
skipping to change at page 11, line 10 skipping to change at page 11, line 12
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.
We also RECOMMEND the client to record servers that failed to respond We also RECOMMEND the client to record the set of servers that failed
to cookie requests and only attempt another cookie request after to respond to cookie requests and only attempt another cookie request
certain period. An alternate proposal is to request cookie in FIN after certain period.
instead since FIN-drop by incompatible middle-box does not affect
latency. However such paths are likely to drop SYN packet with data An alternate proposal is to request cookie in FIN instead since FIN-
later, and many applications close the connections with RST instead, drop by incompatible middle-box does not affect latency. However such
so the actual benefit of this approach is not clear. paths are likely to drop SYN packet with data later, and many
applications close the connections with RST instead, so the actual
benefit of this approach is not clear.
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
skipping to change at page 12, line 25 skipping to change at page 12, line 29
5. Send the SYN-ACK packet. The packet MAY include a Fast Open 5. Send the SYN-ACK packet. The packet MAY include a Fast Open
Option. If FastOpened flag is set, the packet acknowledges the SYN Option. If FastOpened flag is set, the packet acknowledges the SYN
and data sequence. Otherwise it acknowledges only the SYN and data sequence. Otherwise it acknowledges only the SYN
sequence. The server MAY include data in the SYN-ACK packet if the sequence. The server MAY include data in the SYN-ACK packet if the
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 the congestion control [RFC5681], in particular server MUST follow the congestion control [RFC5681] to set the
the initial congestion window [RFC3390], to send more data initial congestion window [RFC3390], to send more data packets.
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 Cookie options for
compatibility reasons. compatibility 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.
skipping to change at page 13, line 32 skipping to change at page 13, line 34
state. No special handling is required further. state. No special handling is required further.
5. Security Considerations 5. Security Considerations
The Fast Open cookie stops an attacker from trivially flooding The Fast Open cookie stops an attacker from trivially flooding
spoofed SYN packets with data to burn server resources or to mount an spoofed SYN packets with data to burn server resources or to mount an
amplified reflection attack on random hosts. The server can defend amplified reflection attack on random hosts. The server can defend
against spoofed SYN floods with invalid cookies using existing against spoofed SYN floods with invalid cookies using existing
techniques [RFC4987]. We note that although generating bogus cookies techniques [RFC4987]. We note that although generating bogus cookies
is cost-free, the cost of validating the cookies, inherent to any is cost-free, the cost of validating the cookies, inherent to any
authentication scheme, may not be substantial compared to processing authentication scheme, may be substantial compared to processing a
a regular SYN packet. regular SYN packet.
5.1. Resource Exhaustion Attack by SYN Flood with Valid Cookies 5.1. Resource Exhaustion Attack by SYN Flood with Valid Cookies
However, the attacker may still obtain cookies from some compromised An attacker may still obtain cookies from some compromised hosts,
hosts, then flood spoofed SYN with data and "valid" cookies (from then flood spoofed SYN with data and "valid" cookies (from these
these hosts or other vantage points). With DHCP, it's possible to hosts or other vantage points). With DHCP, it's possible to obtain
obtain cookies of past IP addresses without compromising any host. cookies of past IP addresses without compromising any host. Below we
Below we identify new vulnerabilities of TFO and describe the identify new vulnerabilities of TFO and describe the countermeasures.
countermeasures.
Like regular TCP handshakes, TFO is vulnerable to such an attack. But Like regular TCP handshakes, TFO is vulnerable to such an attack. But
the potential damage can be much more severe. Besides causing the potential damage can be much more severe. Besides causing
temporary disruption to service ports under attack, it may exhaust temporary disruption to service ports under attack, it may exhaust
server CPU and memory resources. Such an attack will show up on server CPU and memory resources. Such an attack will show up on
application server logs as a application level DoS from Bot-nets, application server logs as a application level DoS from Bot-nets,
triggering other defenses and alerts. triggering other defenses and alerts.
For this reason it is crucial for the TFO server to limit the maximum To protect the server it is important to limit the maximum number of
number of total pending TFO connection requests, i.e., total pending TFO connection requests, i.e., PendingFastOpenRequests
PendingFastOpenRequests. When the limit is exceeded, the server (Section 4.2). When the limit is exceeded, the server temporarily
temporarily disables TFO entirely as described in "Server Cookie disables TFO entirely as described in "Server Cookie Handling". Then
Handling". Then subsequent TFO requests will be downgraded to regular subsequent TFO requests will be downgraded to regular connection
connection requests, i.e., with the data dropped and only SYN requests, i.e., with the data dropped and only SYN acknowledged. This
acknowledged. This allows regular SYN flood defense techniques allows regular SYN flood defense techniques [RFC4987] like SYN-
[RFC4987] like SYN-cookies to kick in and prevent further service cookies to kick in and prevent further service disruption.
disruption.
The main impact of SYN floods against the standard TCP stack is not The main impact of SYN floods against the standard TCP stack is not
directly from the floods themselves costing TCP processing overhead directly from the floods themselves costing TCP processing overhead
or host memory, but rather from the spoofed SYN packets filling up or host memory, but rather from the spoofed SYN packets filling up
the often small listener's queue. the often small listener's queue.
On the other hand, TFO SYN floods can cause damage directly if On the other hand, TFO SYN floods can cause damage directly if
admitted without limit into the stack. The RST packets from the admitted without limit into the stack. The RST packets from the
spoofed host will fuel rather than defeat the SYN floods as compared spoofed host will fuel rather than defeat the SYN floods as compared
to the non-TFO case, because the attacker can flood more SYNs with to the non-TFO case, because the attacker can flood more SYNs with
skipping to change at page 14, line 36 skipping to change at page 14, line 36
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 Shared 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 a NAT can easily obtain valid cookies to launch
above attack to hurt other clients that share the path. [BRISCOE12] the above attack to hurt other clients that share the path.
suggested that the server can extend cookie generation to include the [BRISCOE12] suggested that the server can extend cookie generation to
TCP timestamp---GetCookie(IP_Address, Timestamp)---and implement it include the TCP timestamp---GetCookie(IP_Address, Timestamp)---and
by encrypting the concatenation of the two values to generate the implement it by encrypting the concatenation of the two values to
cookie. The client stores both the cookie and its corresponding generate the cookie. The client stores both the cookie and its
timestamp, and echoes both in the SYN. The server then implements corresponding timestamp, and echoes both in the SYN. The server then
IsCookieValid(IP_Address, Timestamp, Cookie) by encrypting the IP and implements IsCookieValid(IP_Address, Timestamp, Cookie) by encrypting
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 [RFC 1323] to approach. Moreover this approach requires modifying [RFC 1323] to
send non-zero Timestamp Echo Reply in SYN, potentially cause firewall send non-zero Timestamp Echo Reply in SYN, potentially cause firewall
issues. Therefore we believe the benefit does not outweigh the issues. Therefore we believe the benefit does not outweigh the
drawbacks. drawbacks.
skipping to change at page 16, line 16 skipping to change at page 16, line 16
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, i.e., a
java script process that sends data to the server. A proposed socket java script process that sends data to the server. A proposed socket
API change is in the Appendix. 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 that using TFO results in the first data written to a
data written to a socket to be delivered more than once to the socket to be delivered more than once to the application on the
application on the remote host(Section 2.1). This replay potential remote host(Section 2.1). This replay potential only applies to data
only applies to data in the SYN but not subsequent data exchanges. in the SYN but not subsequent data exchanges.
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 Empirically [JIDKT07] showed the packet duplication on a Tier-1
same SYN data more than once, due to reasons described before. network is rare. Since the replay only happens specifically when the
SYN data packet is duplicated and also the duplicate arrives after
the receiver has cleared the original SYN's connection state, the
replay is thought to be uncommon in practice. Neverthless a client
that cannot handle receiving the same SYN data more than once MUST
NOT enable TFO to send data in a SYN. Similarly a server that cannot
accept receiving the same SYN data more than once MUST NOT enable TFO
to receive data in a SYN.
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
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.
skipping to change at page 17, line 25 skipping to change at page 17, line 38
connections to these domains before the user initiates any requests connections to these domains before the user initiates any requests
for them [BELSHE11]. While this technique also saves the handshake for them [BELSHE11]. While this technique also saves the handshake
latency, it wastes server and network resources by initiating and latency, it wastes server and network resources by initiating and
maintaining idle connections. maintaining idle connections.
6.3.3. HTTP over TLS (HTTPS) 6.3.3. 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 1-RTT in TLS handshake. There is no concern in the SYN packet to save 1-RTT in TLS handshake. There is no concern
about violating idem-potency. In particular it can be used alone with about violating idem-potency. In particular it can be used alone with
the speculative connection above. While HTTPS adoption is still low, the speculative connection above.
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.4. Comparison with HTTP Persistent Connections 6.3.4. 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 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 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 to 25% of the HTTP transaction network latency. The authors estimated
estimated that TFO improves page load time by 10% to 40% on selected that TFO improves page load time by 10% to 40% on selected popular
popular Web sites. Web sites.
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
skipping to change at page 18, line 49 skipping to change at page 19, line 12
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. Cookie-less Fast Open
The cookie mechanism mitigates resource exhaustion and amplification The cookie mechanism mitigates resource exhaustion and amplification
attacks. However cookies are not necessary if the server has attacks. However cookies are not necessary if the server has
application-level protection or is immune to these attacks. For application-level protection or is immune to these attacks. For
example a Web server that only replies with a simple HTTP redirect 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 response that fits in the SYN-ACK packet may not care about resource
exhaustion. Such an application can safely disable TFO cookie checks. exhaustion. For such an application, the server could decide to
disable TFO cookie checks.
Disabling cookies simplifies both the client and the server, as the Disabling cookies simplifies both the client and the server, as the
client no longer needs to request a cookie and the server no longer client no longer needs to request a cookie and the server no longer
needs to check or generate cookies. Disabling cookies also needs to check or generate cookies. Disabling cookies also
potentially simplifies configuration, as the server no longer needs a potentially simplifies configuration, as the server no longer needs a
key. It may be preferable to enable SYN cookies and disable TFO key. It may be preferable to enable SYN cookies and disable TFO
[RFC4987] when a server is overloaded by a large-scale Bot-net [RFC4987] when a server is overloaded by a large-scale Bot-net
attack. attack.
Careful experimentation is necessary to evaluate if cookie-less TFO Careful experimentation is necessary to evaluate if cookie-less TFO
is practical. The implementation can provide an experimental feature is practical. The implementation can provide an experimental feature
to allow zero length, or null, cookies as opposed to the minimum 4 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 bytes cookies. Thus the server may return a null cookie and the
client will send data in SYN with it subsequently. If the server client will send data in SYN with it subsequently. If the server
skipping to change at page 19, line 32 skipping to change at page 19, line 45
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. the handshake across connections. Further experimentation regarding
the congestion control impact are useful.
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 20, line 37 skipping to change at page 21, line 8
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 [RFC6994] 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 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
Barath Raghavan for his contribution on the security design of Fast Barath Raghavan for his contribution on the security design of Fast
Open and proofreading this draft numerous times. Open and proofreading this draft numerous times.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC793] Postel, J. "Transmission Control Protocol", RFC 793, [RFC793] Postel, J. "Transmission Control Protocol", RFC 793,
September 1981. September 1981.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[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
skipping to change at page 21, line 11 skipping to change at page 21, line 32
[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", [RFC6994] Touch, Joe, "Shared Use of Experimental TCP Options",
RFC6994, August 2013. RFC6994, August 2013.
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
Initial Window", RFC 3390, October 2002.
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.
[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",
URL http://www.imperialviolet.org/binary/ecntest.pdf URL http://www.imperialviolet.org/binary/ecntest.pdf
[MAF04] Medina, A., Allman, M., and S. Floyd, "Measuring [MAF04] Medina, A., Allman, M., and S. Floyd, "Measuring
Interactions Between Transport Protocols and Middleboxes", Interactions Between Transport Protocols and Middleboxes",
In Proceedings of Internet Measurement Conference, October In Proceedings of Internet Measurement Conference, October
2004. 2004.
[MQXMZ11] Z. Mao, Z. Qian, Q. Xu, Z. Mao, M. Zhang. "An Untold Story [MQXMZ11] Z. Mao, Z. Qian, Q. Xu, Z. Mao, M. Zhang. "An Untold Story
of Middleboxes in Cellular Networks", In Proceedings of of Middleboxes in Cellular Networks", In Proceedings of
SIGCOMM. August 2011. SIGCOMM. August 2011.
[PHRACK98] "T/TCP vulnerabilities", Phrack Magazine, Volume 8, Issue [PHRACK98] "T/TCP vulnerabilities", Phrack Magazine, Volume 8, Issue
53 artical 6. July 8, 1998. URL 53 artical 6. July 8, 1998. URL
http://www.phrack.com/issues.html?issue=53&id=6 http://www.phrack.com/issues.html?issue=53&id=6
[QWGMSS11] F. Qian, Z. Wang, A. Gerber, Z. Mao, S. Sen, O. [QWGMSS11] F. Qian, Z. Wang, A. Gerber, Z. Mao, S. Sen, O.
Spatscheck. "Profiling Resource Usage for Mobile Spatscheck. "Profiling Resource Usage for Mobile
Applications: A Cross-layer Approach", In Proceedings of Applications: A Cross-layer Approach", In Proceedings of
International Conference on Mobile Systems. April 2011. International Conference on Mobile Systems. April 2011.
[RCCJR11] Radhakrishnan, S., Cheng, Y., Chu, J., Jain, A. and [RCCJR11] Radhakrishnan, S., Cheng, Y., Chu, J., Jain, A. and
Raghavan, B., "TCP Fast Open". In Proceedings of 7th ACM Raghavan, B., "TCP Fast Open". In Proceedings of 7th ACM
CoNEXT Conference, December 2011. CoNEXT Conference, December 2011.
[RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions [RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions
Functional Specification", RFC 1644, July 1994. Functional Specification", RFC 1644, July 1994.
[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/
[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/
[JIDKT07] Jaiswal, S., Iannaccone, G., Diot, C., Kurose, J., and
Towsley, D. "Measurement and classification of
out-of-sequence packets in a tier-1 IP backbone.",
IEEE/ACM Transactions on Networking (TON), 15(1), 54-66.
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.
One solution implemented in Linux 3.7 is introducing a new flag One solution implemented in Linux 3.7 is introducing a new flag
MSG_FASTOPEN for sendto() or sendmsg(). MSG_FASTOPEN marks the MSG_FASTOPEN for sendto() or sendmsg(). MSG_FASTOPEN marks the
attempt to send data in SYN like a combination of connect() and attempt to send data in SYN like a combination of connect() and
sendto(), by performing an implicit connect() operation. It blocks sendto(), by performing an implicit connect() operation. It blocks
until the handshake has completed and the data is buffered. 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. On errors, it returns the same errno as the socket is connected. On errors, it returns the same errno as
connect() if the handshake fails. connect() if the handshake fails.
 End of changes. 61 change blocks. 
162 lines changed or deleted 180 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/