draft-ietf-tcpm-fastopen-00.txt		draft-ietf-tcpm-fastopen-01.txt
	Internet Draft Y. Cheng		Internet Draft Y. Cheng
	draft-ietf-tcpm-fastopen-00.txt J. Chu		draft-ietf-tcpm-fastopen-01.txt J. Chu
	Intended status: Experimental S. Radhakrishnan		Intended status: Experimental S. Radhakrishnan
	Expiration date: August, 2012 A. Jain		Expiration date: Feburary, 2013 A. Jain
	Google, Inc.		Google, Inc.
	February 16, 2012		July 16, 2012
	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 9, line 51		skipping to change at page 9, line 51
	reasons below.		reasons below.
	The network or servers may drop the SYN or SYN-ACK packets with the		The network or servers may drop the SYN or SYN-ACK packets with the
	new cookie options which causes SYN or SYN-ACK timeouts. We RECOMMEND		new cookie options which causes SYN or SYN-ACK timeouts. We RECOMMEND
	both the client and the server retransmit SYN and SYN-ACK without the		both the client and the server retransmit SYN and SYN-ACK without the
	cookie options on timeouts. This ensures the connections of cookie		cookie options on timeouts. This ensures the connections of cookie
	requests will go through and lowers the latency penalties (of dropped		requests will go through and lowers the latency penalties (of dropped
	SYN/SYN-ACK packets). The obvious downside for maximum compatibility		SYN/SYN-ACK packets). The obvious downside for maximum compatibility
	is that any regular SYN drop will fail the cookie (although one can		is that any regular SYN drop will fail the cookie (although one can
	argue the delay in the data transmission till after 3WHS is justified		argue the delay in the data transmission till after 3WHS is justified
	if the SYN drop is due to network congestion).		if the SYN drop is due to network congestion). Next section
			describes a heuristic to detect such drops 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 servers that failed to respond
	to cookie requests and only attempt another cookie request after		to cookie requests and only attempt another cookie request after
	certain period.		certain period.
	4.2.2. TCP Fast Open		4.2.2. TCP Fast Open
	Once the client obtains the cookie from the target server, the client		Once the client obtains the cookie from the target server, the client
	can perform subsequent TFO connections until the cookie is expired by		can perform subsequent TFO connections until the cookie is expired by
	the server. The nature of TCP sequencing makes the TFO specific		the server. The nature of TCP sequencing makes the TFO specific
	skipping to change at page 12, line 24		skipping to change at page 12, line 24
	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.
	Client: Receiving SYN-ACK		Client: Receiving SYN-ACK
	The client SHOULD perform the following steps upon receiving the SYN-		The client SHOULD perform the following steps upon receiving the SYN-
	ACK:		ACK:
	1. Update the cookie cache if the SYN-ACK has a Fast Open Cookie		1. Update the cookie cache if the SYN-ACK has a Fast Open Cookie
	Option.		Option or MSS option or both.
	2. Send an ACK packet. Set acknowledgment number to RCV.NXT and		2. Send an ACK packet. Set acknowledgment number to RCV.NXT and
	include the data after SND.UNA if data is available.		include the data after SND.UNA if data is available.
	3. Advance to the ESTABLISHED state.		3. Advance to the ESTABLISHED state.
	Note there is no latency penalty if the server does not acknowledge		Note there is no latency penalty if the server does not acknowledge
	the data in the original SYN packet. The client can retransmit it in		the data in the original SYN packet. The client SHOULD retransmit any
	the first ACK packet in step 2. The data exchange will start after		unacknowledged data in the first ACK packet in step 2. The data
	the handshake like a regular TCP connection.		exchange will start after the handshake like a regular TCP
			connection.
			If the client has timed out and retransmitted only regular SYN
			packets, it can heuristically detect paths that intentionally drop
			SYN with Fast Open option or data. If the SYN-ACK acknowledges only
			the initial sequence and does not carry a Fast Open cookie option,
			presumably it is triggered by a retransmitted (regular) SYN and the
			original SYN or the corresponding SYN-ACK was lost.
	Server: Receiving ACK		Server: Receiving ACK
	Upon receiving an ACK acknowledging the SYN sequence, the server		Upon receiving an ACK acknowledging the SYN sequence, the server
	decrements PendingFastOpenRequests and advances to the ESTABLISHED		decrements PendingFastOpenRequests and advances to the ESTABLISHED
	state. No special handling is required further.		state. No special handling is required further.
	5. Reliability and Deployment Issues		5. Reliability and Deployment Issues
	Network or Hosts Dropping SYN packets with data or unknown options		Network or Hosts Dropping SYN packets with data or unknown options
	A study [MAF04] found that some middle-boxes and end-hosts may drop		A study [MAF04] found that some middle-boxes and end-hosts may drop
	packets with unknown TCP options incorrectly. Another study		packets with unknown TCP options incorrectly. Studies [LANGLEY06,
	[LANGLEY06] found that 6% of the probed paths on the Internet drop		HNRGHT11] both found that 6% of the probed paths on the Internet drop
	SYN packets with data. The TFO protocol deals with this problem by		SYN packets with data or with unknown TCP options. The TFO protocol
	retransmitting SYN without data or cookie options and we recommend		deals with this problem by retransmitting SYN without data or cookie
	tracking these servers in the client.		options and we recommend tracking these servers in the client.
	Server Farms		Server Farms
	A common server-farm setup is to have many physical hosts behind a		A common server-farm setup is to have many physical hosts behind a
	load-balancer sharing the same server IP. The load-balancer forwards		load-balancer sharing the same server IP. The load-balancer forwards
	new TCP connections to different physical hosts based on certain		new TCP connections to different physical hosts based on certain
	load-balancing algorithms. For TFO to work, the physical hosts need		load-balancing algorithms. For TFO to work, the physical hosts need
	to share the same key and update the key at about the same time.		to share the same key and update the key at about the same time.
	Network Address Translation (NAT)		Network Address Translation (NAT)
	skipping to change at page 13, line 28		skipping to change at page 13, line 36
	from the same physical host uses a different public IP address, TFO		from the same physical host uses a different public IP address, TFO
	does not provide latency benefit. However, there is no performance		does not provide latency benefit. However, there is no performance
	penalty either as described in Section "Client: Receiving SYN-ACK".		penalty either as described in Section "Client: Receiving SYN-ACK".
	6. Security Considerations		6. 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].		techniques [RFC4987]. We note that generating bogus cookies is
			usually cheaper than validating them. But the additional cost of
			validating the cookies, inherent to any authentication scheme, may
			not be substantial compared to processing a regular SYN packet.
	However, the attacker may still obtain cookies from some compromised		However, the attacker may still obtain cookies from some compromised
	hosts, then flood spoofed SYN with data and "valid" cookies (from		hosts, then flood spoofed SYN with data and "valid" cookies (from
	these hosts or other vantage points). With DHCP, it's possible to		these hosts or other vantage points). With DHCP, it's possible to
	obtain cookies of past IP addresses without compromising any host.		obtain cookies of past IP addresses without compromising any host.
	Below we identify two new vulnerabilities of TFO and describe the		Below we identify two new vulnerabilities of TFO and describe the
	countermeasures.		countermeasures.
	6.1. Server Resource Exhaustion Attack by SYN Flood with Valid Cookies		6.1. Server Resource Exhaustion Attack by SYN Flood with Valid Cookies
	skipping to change at page 19, line 36		skipping to change at page 20, line 36
	[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.
	[CDCM11] Chu, J., Dukkipati, N., Cheng, Y. and M. Mathis,		[CDCM11] Chu, J., Dukkipati, N., Cheng, Y. and M. Mathis,
	"Increasing TCP's Initial Window", Internet-Draft draft-		"Increasing TCP's Initial Window", Internet-Draft draft-
	ietf-tcpm- initcwnd-02.txt (work in progress), October		ietf-tcpm- initcwnd-02.txt (work in progress), October
	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.
			Handley, H. Tokuda, "Is it Still Possible to Extend TCP?".
			In Proceedings of Internet Measurement Conference. November
			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
	skipping to change at page 20, line 35		skipping to change at page 21, line 40
	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.
	[SIMPSON11] Simpson, W., "Tcp cookie transactions (tcpct) rapid		[SIMPSON11] Simpson, W., "Tcp cookie transactions (tcpct) rapid
	restart", Internet draft draft-simpson-tcpct-rr-02.txt		restart", Internet draft draft-simpson-tcpct-rr-02.txt
	(work in progress), July 2011.		(work in progress), July 2011.
	[SOUDERS11] S. Souders. "Making A Mobile Connection".		[SOUDERS11] S. Souders. "Making A Mobile Connection".
	http://www.stevesouders.com/blog/2011/09/21/making-a		http://www.stevesouders.com/blog/2011/09/21/making-a-
	mobile-connection/		mobile-connection/
	[THK98] Touch, J., Heidemann, J., Obraczka, K., "Analysis of HTTP		[THK98] Touch, J., Heidemann, J., Obraczka, K., "Analysis of HTTP
	Performance", USC/ISI Research Report 98-463. December		Performance", USC/ISI Research Report 98-463. December
	1998.		1998.
	Author's Addresses		Author's Addresses
	Yuchung Cheng		Yuchung Cheng
	Google, Inc.		Google, Inc.
End of changes. 12 change blocks.
	17 lines changed or deleted		34 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/