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/