draft-ietf-tcpm-fastopen-05.txt		draft-ietf-tcpm-fastopen-06.txt
	Internet Draft Y. Cheng		Internet Draft Y. Cheng
	draft-ietf-tcpm-fastopen-05.txt J. Chu		draft-ietf-tcpm-fastopen-06.txt J. Chu
	Intended status: Experimental S. Radhakrishnan		Intended status: Experimental S. Radhakrishnan
	Expiration date: February, 2014 A. Jain		Expiration date: February, 2014 A. Jain
	Google, Inc.		Google, Inc.
	October 14, 2013		January 26, 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 1, line 36		skipping to change at page 1, line 36
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	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		TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK
	packets and consumed by the receiving end during the initial		packets and consumed by the receiving end during the initial
	connection handshake, thus saving up to one full round trip time		connection handshake, thus saving up to one full round trip time
	(RTT) compared to the standard TCP, which requires a three-way		(RTT) compared to the standard TCP, which requires a three-way
	handshake (3WHS) to complete before data can be exchanged. However		handshake (3WHS) to complete before data can be exchanged. However
	TFO deviates from the standard TCP semantics; the data in the SYN		TFO deviates from the standard TCP semantics the data in the SYN
	could be replayed to an application in some rare circumstances.		could be replayed to an application in some rare circumstances.
	Applications should not use TFO unless they can tolerate this issue		Applications should not use TFO unless they can tolerate this issue
	detailed in the Applicability section.		detailed in the Applicability section.
	Terminology		Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	TFO refers to TCP Fast Open. Client refers to the TCP's active open		TFO refers to TCP Fast Open. Client refers to the TCP's active open
	skipping to change at page 2, line 34		skipping to change at page 2, line 34
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Data In SYN . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Data In SYN . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1 Relaxing TCP Semantics on Duplicated SYNs . . . . . . . . . 4		2.1 Relaxing TCP Semantics on Duplicated SYNs . . . . . . . . . 4
	2.2. SYNs with Spoofed IP Addresses . . . . . . . . . . . . . . 4		2.2. SYNs with Spoofed IP Addresses . . . . . . . . . . . . . . 4
	3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 5		3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7		4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 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.2. Fast Open Protocol . . . . . . . . . . . . . . . . . . . . 9		4.2. Fast Open Protocol . . . . . . . . . . . . . . . . . . . . 9
	4.2.1. Fast Open Cookie Request . . . . . . . . . . . . . . . 10		4.2.1. Fast Open Cookie Request . . . . . . . . . . . . . . . 10
	4.2.2. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . 11		4.2.2. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 13		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 13
	5.1. Resource Exhaustion Attack by SYN Flood with Valid		5.1. Resource Exhaustion Attack by SYN Flood with Valid
	Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 13		Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.1.1 Attacks from behind 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 . . . . . . . . . . . . . 16
	6.3.1. HTTP Request Replay . . . . . . . . . . . . . . . . . . 16		6.3.1. HTTP Request Replay . . . . . . . . . . . . . . . . . . 16
	6.3.2. Speculative Connections by the Applications . . . . . . 17		6.3.2. Speculative Connections by the Applications . . . . . . 17
	6.3.2. HTTP over TLS (HTTPS) . . . . . . . . . . . . . . . . . 17		6.3.3. HTTP over TLS (HTTPS) . . . . . . . . . . . . . . . . . 17
	6.3.3. 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 . . . . . . . . . . . . . . . . . . . 18
			7.3 Impact on congestion control . . . . . . . . . . . . . . . . 19
	8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 19		8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 19
	8.1. T/TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 19		8.1. T/TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	8.2. Common Defenses Against SYN Flood Attacks . . . . . . . . . 19		8.2. Common Defenses Against SYN Flood Attacks . . . . . . . . . 19
	8.3. TCP Cookie Transaction (TCPCT) . . . . . . . . . . . . . . 19		8.3. TCP Cookie Transaction (TCPCT) . . . . . . . . . . . . . . 20
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20
	10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20		10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 20		11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
	11.2. Informative References . . . . . . . . . . . . . . . . . . 20		11.2. Informative References . . . . . . . . . . . . . . . . . . 21
	Appendix A. Example Socket API Changes to support TFO . . . . . . 22		Appendix A. Example Socket API Changes to support TFO . . . . . . 22
			A.1 Active Open . . . . . . . . . . . . . . . . . . . . . . . . 22
			A.2 Passive Open . . . . . . . . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	TCP Fast Open (TFO) enables data to be exchanged safely during TCP's		TCP Fast Open (TFO) enables data to be exchanged safely during TCP's
	connection handshake. This document describes a design that enables		connection handshake. This document describes a design that enables
	applications to save a round trip while avoiding severe security		applications to save a round trip while avoiding severe security
	ramifications. At the core of TFO is a security cookie used by the		ramifications. At the core of TFO is a security cookie used by the
	server side to authenticate a client initiating a TFO connection.		server side to authenticate a client initiating a TFO connection.
	This document covers the details of exchanging data during TCP's		This document covers the details of exchanging data during TCP's
	skipping to change at page 5, line 6		skipping to change at page 5, line 9
	the application layer before 3WHS is completed. This opens up serious		the application layer before 3WHS is completed. This opens up serious
	new vulnerabilities. Applications serving ports that have TFO enabled		new vulnerabilities. Applications serving ports that have TFO enabled
	may waste lots of CPU and memory resources processing the requests		may waste lots of CPU and memory resources processing the requests
	and producing the responses. If the response is much larger than the		and producing the responses. If the response is much larger than the
	request, the attacker can further mount an amplified reflection		request, the attacker can further mount an amplified reflection
	attack against victims of choice beyond the TFO server itself.		attack against victims of choice beyond the TFO server itself.
	Numerous mitigation techniques against regular SYN flood attacks		Numerous mitigation techniques against regular SYN flood attacks
	exist and have been well documented [RFC4987]. Unfortunately none are		exist and have been well documented [RFC4987]. Unfortunately none are
	applicable to TFO. We propose a server-supplied cookie to mitigate		applicable to TFO. We propose a server-supplied cookie to mitigate
	these new vulnerabilities in the next Section and evaluate the		these new vulnerabilities in Section 3 and evaluate the effectiveness
	effectiveness of the defense in Section 7.		of the defense in Section 7.
	3. Protocol Overview		3. Protocol Overview
	The key component of TFO is the Fast Open Cookie (cookie), a message		The key component of TFO is the Fast Open Cookie (cookie), a message
	authentication code (MAC) tag generated by the server. The client		authentication code (MAC) tag generated by the server. The client
	requests a cookie in one regular TCP connection, then uses it for		requests a cookie in one regular TCP connection, then uses it for
	future TCP connections to exchange data during 3WHS:		future TCP connections to exchange data during 3WHS:
	Requesting a Fast Open Cookie:		Requesting a Fast Open Cookie:
	skipping to change at page 9, line 16		skipping to change at page 9, line 16
	If only one valid cookie is allowed per-IP and the server can		If only one valid cookie is allowed per-IP and the server can
	regenerate the cookie independently, the best validation process is		regenerate the cookie independently, the best validation process is
	to simply regenerate a valid cookie and compare it against the		to simply regenerate a valid cookie and compare it against the
	incoming cookie. In that case if the incoming cookie fails the check,		incoming cookie. In that case if the incoming cookie fails the check,
	a valid cookie is readily available to be sent to the client.		a valid cookie is readily available to be sent to the client.
	4.1.3. Client Cookie Handling		4.1.3. Client Cookie Handling
	The client MUST cache cookies from servers for later Fast Open		The client MUST cache cookies from servers for later Fast Open
	connections. For a multi-homed client, the cookies are both client		connections. For a multi-homed client, the cookies are both client
	and server IP dependent. Beside the cookie, we RECOMMEND that the		and server IP dependent. Beside the cookie we RECOMMEND that the
	client caches the MSS and RTT to the server to enhance performance.		client caches the MSS to the server to enhance performance.
	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]. The client SHOULD update the cache MSS value		bytes [RFC1122]. In particular it's known IPv4 receiver advertised
	whenever it discovers new MSS value, e.g., through path MTU		MSS less than 536 bytes would result in transmission of an unexpected
	discovery.		large segment. If the cache MSS is larger than the typical 1460
			bytes, the extra large data in SYN segment may have issues that
			offsets the performance benefit of Fast Open. For examples, the
			super-size SYN may trigger IP fragmentation and confuses firewall or
			middle-boxes. Therefore the client MAY limit the cached MSS to 1460
			bytes.
	Caching RTT allows seeding a more accurate SYN timeout than the		4.1.3.1 Client Caching Negative Responses
	default value [RFC6298]. This lowers the performance penalty if the
	network or the server drops the SYN packets with data or the cookie
	options.
	The cache replacement algorithm is not specified and is left to the		The client MUST cache negative responses from the server in order to
	implementations.		avoid potential connection failures. Negative responses include
			server not acknowledging the data in SYN, ICMP error messages, and
			most importantly no response (SYN/ACK) from the server at all, i.e,
			connection timeout. The last case is likely due to incompatible
			middle-boxes or firewall blocking the connection completely after it
			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
			able to connect to the specific server.
	Note that before TFO sees wide deployment, clients SHOULD cache		For any negative responses, the client SHOULD disables Fast Open on
	negative responses from servers in order to reduce the amount of		the specific path and port, at least temporarily. Since TFO is
	futile TFO attempts. Since TFO is enabled on a per-service port basis		enabled on a per-service port basis but cookies are independent of
	but cookies are independent of service ports, clients' cache should		service ports, clients' cache should include remote port numbers too.
	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 12, line 20		skipping to change at page 12, line 29
	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], in particular
	the initial congestion window [RFC3390], to send more data		the initial congestion window [RFC3390], to send more data
	packets.		packets.
	Note that if SYN-ACK is lost, regular TCP reduces the initial
	congestion window before sending any data. In this case TFO is
	slightly more aggressive in the first data round trip even though
	it does not change the congestion control.
	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 16, line 52		skipping to change at page 16, line 52
	6.3.1. HTTP Request Replay		6.3.1. HTTP Request Replay
	While TFO is motivated by Web applications, the browser should not		While TFO is motivated by Web applications, the browser should not
	use TFO to send requests in SYNs if those requests cannot tolerate		use TFO to send requests in SYNs if those requests cannot tolerate
	replays. One example is POST requests without application-layer		replays. One example is POST requests without application-layer
	transaction protection (e.g., a unique identifier in the request		transaction protection (e.g., a unique identifier in the request
	header).		header).
	On the other hand, TFO is particularly useful for GET requests.		On the other hand, TFO is particularly useful for GET requests.
	Although not all GET requests are idempotent, GETs are frequently		Although not all GET requests are idem-potent, GETs are frequently
	replayed today across striped TCP connections: after a server		replayed today across striped TCP connections: after a server
	receives an HTTP request but before the ACKs of the requests reach		receives an HTTP request but before the ACKs of the requests reach
	the browser, the browser may timeout and retry the same request on		the browser, the browser may timeout and retry the same request on
	another (possibly new) TCP connection. This differs from a TFO replay		another (possibly new) TCP connection. This differs from a TFO replay
	only in that the replay is initiated by the browser, not by the TCP		only in that the replay is initiated by the browser, not by the TCP
	stack.		stack.
	6.3.2. Speculative Connections by the Applications		6.3.2. Speculative Connections by the Applications
	Some Web browsers maintain a history of the domains for frequently		Some Web browsers maintain a history of the domains for frequently
	visited web pages. The browsers then speculatively pre-open TCP		visited web pages. The browsers then speculatively pre-open TCP
	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.2. 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 idempotency. 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. While HTTPS adoption is still low,
	it will increase over time (especially given the context of recent		it will increase over time (especially given the context of recent
	revelations). Thus the potential importance of TCP Fast Open in		revelations). Thus the potential importance of TCP Fast Open in
	decreasing user perceived latency in HTTPS.		decreasing user perceived latency in HTTPS.
	6.3.3. 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
	skipping to change at page 18, line 9		skipping to change at page 18, line 9
	To circumvent this problem, some applications send frequent TCP keep-		To circumvent this problem, some applications send frequent TCP keep-
	alive probes. However, this technique drains power on mobile devices		alive probes. However, this technique drains power on mobile devices
	[MQXMZ11]. In fact, power has become such a prominent issue in modern		[MQXMZ11]. In fact, power has become such a prominent issue in modern
	LTE devices that mobile browsers close HTTP connections within		LTE devices that mobile browsers close HTTP connections within
	seconds or even immediately [SOUDERS11].		seconds or even immediately [SOUDERS11].
	[RCCJR11] studied Chrome browser performance based on 28 days of		[RCCJR11] studied Chrome browser performance based on 28 days of
	global statistics. The Chrome browser keeps idle HTTP persistent		global statistics. The Chrome browser keeps idle HTTP persistent
	connections for 5 to 10 minutes. However the average number of the		connections for 5 to 10 minutes. However the average number of the
	transactions per connection is only 3.3 and TCP 3WHS accounts for up		transactions per connection is only 3.3 and TCP 3WHS accounts for up
	to 25% of the HTTP transaction network latency. The authors estimated		to 25% of the HTTP transaction network latency. The authors
	that TFO TFO improves page load time by 10% to 40% on selected		estimated that TFO improves page load time by 10% to 40% on selected
	popular Web sites.		popular 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
	problem by falling back to regular TCP handshake and re-transmitting		problem by falling back to regular TCP handshake and re-transmitting
	SYN without data or cookie options after the initial SYN timeout.		SYN without data or cookie options after the initial SYN timeout.
	Moreover the implementation is recommended to negatively cache such		Moreover the implementation is recommended to negatively cache such
	incidents to avoid recurring timeouts. Further study is required to		incidents to avoid recurring timeouts. Further study is required to
	evaluate the performance impact of these malicious drop behaviors.		evaluate the performance impact of these malicious drop behaviors.
	Another interesting study is the (loss of) TFO performance benefit		Another interesting study is the (loss of) TFO performance benefit
	behind certain carrier-grade NAT. Typically hosts behind a NAT		behind certain carrier-grade NAT. Typically hosts behind a NAT
	sharing the same IP address will get the same cookie for the same		sharing the same IP address will get the same cookie for the same
	server. This will not prevent TFO from working. But on some carrier-		server. This will not prevent TFO from working. But on some carrier-
	grade NAT configurations where every new TCP connection from the same		grade NAT configurations where every new TCP connection from the same
	physical host uses a different public IP address, TFO does not		physical host uses a different public IP address, TFO does not
	provide latency benefits. However, there is no performance penalty		provide latency benefits. However, there is no performance penalty
	either, as described in Section "Client: Receiving SYN-ACK".		either, as described in Section "Client: Receiving SYN-ACK".
	skipping to change at page 19, line 18		skipping to change at page 19, line 18
	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
	believes it's under a DoS attack through other defense mechanisms, it		believes it's under a DoS attack through other defense mechanisms, it
	can switch to regular Fast Open for listener sockets.		can switch to regular Fast Open for listener sockets.
			7.3 Impact on congestion control
			Although TFO does not directly change the congestion control, there
			are subtle cases that it may. When SYN-ACK times out, regular TCP
			reduces the initial congestion window before sending any data
			[RFC5681]. However in TFO the server may have already sent up to an
			initial window of data.
			If the server serves mostly short connections then the losses of SYN-
			ACKs are not as effective as regular TCP on reducing the congestion
			window. This could result in an unstable network condition. The
			connections that experience losses may attempt again and add more
			load under congestion. A potential solution is to temporarily disable
			Fast Open if the server observes many SYN-ACK or data losses during
			the handshake across connections.
	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 19		skipping to change at page 20, line 36
	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 Rick Jones, Bob Briscoe, Adam Langley, Matt Mathis, Neal		We thank Bob Briscoe, Michael Scharf, Gorry Fairhurst, Rick Jones,
	Cardwell, Roberto Peon, William Chan, Eric Dumazet, and Tom Herbert		Roberto Peon, William Chan, Adam Langley, Neal Cardwell, Eric
	for their feedbacks. We especially thank Barath Raghavan for his		Dumazet, and Matt Mathis for their feedbacks. We especially thank
	contribution on the security design of Fast Open and proofreading		Barath Raghavan for his contribution on the security design of Fast
	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
	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",
	RFC 6694, August 2013.		RFC6994, August 2013.
	11.2. Informative References		11.2. Informative References
	[AERG11] M. Al-Fares, K. Elmeleegy, B. Reed, and I. Gashinsky,		[AERG11] M. Al-Fares, K. Elmeleegy, B. Reed, and I. Gashinsky,
	"Overclocking the Yahoo! CDN for Faster Web Page Loads". In		"Overclocking the Yahoo! CDN for Faster Web Page Loads". In
	Proceedings of Internet Measurement Conference, November		Proceedings of Internet Measurement Conference, November
	2011.		2011.
	[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
	skipping to change at page 22, line 20		skipping to change at page 22, line 35
	fastopen-01", tcpm list,		fastopen-01", tcpm list,
	http://www.ietf.org/mail-archive/web/tcpm/current/		http://www.ietf.org/mail-archive/web/tcpm/current/
	January 16, 2014msg07192.html		January 16, 2014msg07192.html
	[BELSHE12] Belshe, M., "The era of browser preconnect.",		[BELSHE12] Belshe, M., "The era of browser preconnect.",
	http://www.belshe.com/2011/02/10/		http://www.belshe.com/2011/02/10/
	the-era-of-browser-preconnect/		the-era-of-browser-preconnect/
	Appendix A. Example Socket API Changes to support TFO		Appendix A. Example Socket API Changes to support TFO
	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
	skipping to change at page 22, line 47		skipping to change at page 23, line 14
	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.
	An implementation may prefer not to change the sendmsg() because TFO		An implementation may prefer not to change the sendmsg() because TFO
	is a TCP specific feature. A solution is to add a new socket option		is a TCP specific feature. A solution is to add a new socket option
	TCP_FASTOPEN for TCP sockets. When the option is enabled before a		TCP_FASTOPEN for TCP sockets. When the option is enabled before a
	connect operation, sendmsg() or sendto() will perform Fast Open		connect operation, sendmsg() or sendto() will perform Fast Open
	operation similar to the MSG_FASTOPEN flag described above. This		operation similar to the MSG_FASTOPEN flag described above. This
	approach however requires an extra setsockopt() system call.		approach however requires an extra setsockopt() system call.
	A.2 Passive Open		A.2 Passive Open
	The passive open side change is simpler compared to active open side.		The passive open side change is simpler compared to active open side.
	The application only needs to enable the reception of Fast Open		The application only needs to enable the reception of Fast Open
	requests via a new TCP_FASTOPEN setsockopt() socket option before		requests via a new TCP_FASTOPEN setsockopt() socket option before
	listen().		listen().
	The option enables Fast Open on the listener socket. The option value		The option enables Fast Open on the listener socket. The option value
	specifies the PendingFastOpenRequests threshold, i.e., the maximum		specifies the PendingFastOpenRequests threshold, i.e., the maximum
	length of pending SYNs with data payload. Once enabled, the TCP		length of pending SYNs with data payload. Once enabled, the TCP
	implementation will respond with TFO cookies per request.		implementation will respond with TFO cookies per request.
End of changes. 30 change blocks.
	48 lines changed or deleted		70 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/