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/