--- 1/draft-ietf-tcpm-fastopen-00.txt 2012-07-16 22:14:14.437342623 +0200 +++ 2/draft-ietf-tcpm-fastopen-01.txt 2012-07-16 22:14:14.473343043 +0200 @@ -1,17 +1,17 @@ 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 -Expiration date: August, 2012 A. Jain +Expiration date: Feburary, 2013 A. Jain Google, Inc. - February 16, 2012 + July 16, 2012 TCP Fast Open Status of this Memo Distribution of this memo is unlimited. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -404,21 +404,23 @@ reasons below. 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 both the client and the server retransmit SYN and SYN-ACK without the cookie options on timeouts. This ensures the connections of cookie requests will go through and lowers the latency penalties (of dropped SYN/SYN-ACK packets). The obvious downside for maximum compatibility 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 - 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 to cookie requests and only attempt another cookie request after certain period. 4.2.2. TCP Fast Open Once the client obtains the cookie from the target server, the client can perform subsequent TFO connections until the cookie is expired by the server. The nature of TCP sequencing makes the TFO specific @@ -478,48 +480,55 @@ If the SYN-ACK timer fires, the server SHOULD retransmit a SYN-ACK segment with neither data nor Fast Open Cookie options for compatibility reasons. Client: Receiving SYN-ACK The client SHOULD perform the following steps upon receiving the SYN- ACK: 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 include the data after SND.UNA if data is available. 3. Advance to the ESTABLISHED state. 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 first ACK packet in step 2. The data exchange will start after - the handshake like a regular TCP connection. + the data in the original SYN packet. The client SHOULD retransmit any + unacknowledged data in the first ACK packet in step 2. The data + 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 Upon receiving an ACK acknowledging the SYN sequence, the server decrements PendingFastOpenRequests and advances to the ESTABLISHED state. No special handling is required further. 5. Reliability and Deployment Issues - Network or Hosts Dropping SYN packets with data or unknown options A study [MAF04] found that some middle-boxes and end-hosts may drop - packets with unknown TCP options incorrectly. Another study - [LANGLEY06] found that 6% of the probed paths on the Internet drop - SYN packets with data. The TFO protocol deals with this problem by - retransmitting SYN without data or cookie options and we recommend - tracking these servers in the client. + packets with unknown TCP options incorrectly. Studies [LANGLEY06, + HNRGHT11] both found 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 problem by retransmitting SYN without data or cookie + options and we recommend tracking these servers in the client. Server Farms A common server-farm setup is to have many physical hosts behind a load-balancer sharing the same server IP. The load-balancer forwards new TCP connections to different physical hosts based on certain 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. Network Address Translation (NAT) @@ -530,21 +539,24 @@ from the same physical host uses a different public IP address, TFO does not provide latency benefit. However, there is no performance penalty either as described in Section "Client: Receiving SYN-ACK". 6. Security Considerations The Fast Open cookie stops an attacker from trivially flooding spoofed SYN packets with data to burn server resources or to mount an amplified reflection attack on random hosts. The server can defend 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 hosts, then flood spoofed SYN with data and "valid" cookies (from these hosts or other vantage points). With DHCP, it's possible to obtain cookies of past IP addresses without compromising any host. Below we identify two new vulnerabilities of TFO and describe the countermeasures. 6.1. Server Resource Exhaustion Attack by SYN Flood with Valid Cookies @@ -826,25 +838,30 @@ [AERG11] M. Al-Fares, K. Elmeleegy, B. Reed, and I. Gashinsky, "Overclocking the Yahoo! CDN for Faster Web Page Loads". In Proceedings of Internet Measurement Conference, November 2011. [CDCM11] Chu, J., Dukkipati, N., Cheng, Y. and M. Mathis, "Increasing TCP's Initial Window", Internet-Draft draft- ietf-tcpm- initcwnd-02.txt (work in progress), October 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 Characteristics". In Proceedings of Internet Measurement 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", URL http://www.imperialviolet.org/binary/ecntest.pdf [MAF04] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", In Proceedings of Internet Measurement Conference, October 2004. [MQXMZ11] Z. Mao, Z. Qian, Q. Xu, Z. Mao, M. Zhang. "An Untold Story @@ -874,21 +891,21 @@ Mitigations", RFC 4987, August 2007. [RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC6013, January 2011. [SIMPSON11] Simpson, W., "Tcp cookie transactions (tcpct) rapid restart", Internet draft draft-simpson-tcpct-rr-02.txt (work in progress), July 2011. [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/ [THK98] Touch, J., Heidemann, J., Obraczka, K., "Analysis of HTTP Performance", USC/ISI Research Report 98-463. December 1998. Author's Addresses Yuchung Cheng Google, Inc.