--- 1/draft-ietf-tcpm-fastopen-06.txt 2014-02-14 01:14:42.661146463 -0800 +++ 2/draft-ietf-tcpm-fastopen-07.txt 2014-02-14 01:14:42.709147632 -0800 @@ -1,17 +1,17 @@ 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 -Expiration date: February, 2014 A. Jain +Expiration date: August, 2014 A. Jain Google, Inc. - January 26, 2014 + February 14, 2014 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. @@ -39,107 +39,110 @@ Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract - 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 - connection handshake, thus saving up to one full round trip time - (RTT) compared to the standard TCP, which requires a three-way - handshake (3WHS) to complete before data can be exchanged. However - TFO deviates from the standard TCP semantics the data in the SYN - could be replayed to an application in some rare circumstances. - Applications should not use TFO unless they can tolerate this issue - detailed in the Applicability section. + This document describes an experimental TCP mechanism TCP Fast Open + (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets + and consumed by the receiving end during the initial connection + handshake, thus saving up to one full round trip time (RTT) compared + to the standard TCP, which requires a three-way handshake (3WHS) to + complete before data can be exchanged. However TFO deviates from the + standard TCP semantics the data in the SYN could be replayed to an + application in some rare circumstances. Applications should not use + TFO unless they can tolerate this issue detailed in the Applicability + section. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 side and server refers to the TCP's passive open side. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Data In SYN . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Data In SYN . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Relaxing TCP Semantics on Duplicated SYNs . . . . . . . . . 4 2.2. SYNs with Spoofed IP Addresses . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Fast Open Cookie . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. TCP Options . . . . . . . . . . . . . . . . . . . . . . 7 4.1.2. Server Cookie Handling . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Fast Open Cookie Request . . . . . . . . . . . . . . . 10 4.2.2. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 13 5.1. Resource Exhaustion Attack by SYN Flood with Valid Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1 Attacks from behind Shared Public IPs (NATs) . . . . . . 14 5.2. Amplified Reflection Attack to Random Host . . . . . . . . 15 6. TFO's Applicability . . . . . . . . . . . . . . . . . . . . . . 16 6.1 Duplicate Data in SYNs . . . . . . . . . . . . . . . . . . . 16 6.2 Potential Performance Improvement . . . . . . . . . . . . . 16 - 6.3. Example: Web Clients and Servers . . . . . . . . . . . . . 16 - 6.3.1. HTTP Request Replay . . . . . . . . . . . . . . . . . . 16 + 6.3. Example: Web Clients and Servers . . . . . . . . . . . . . 17 + 6.3.1. HTTP Request Replay . . . . . . . . . . . . . . . . . . 17 6.3.2. Speculative Connections by the Applications . . . . . . 17 6.3.3. HTTP over TLS (HTTPS) . . . . . . . . . . . . . . . . . 17 6.3.4. Comparison with HTTP Persistent Connections . . . . . . 17 + 7. Open Areas for Experimentation . . . . . . . . . . . . . . . . 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 - 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 8.1. T/TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 8.2. Common Defenses Against SYN Flood Attacks . . . . . . . . . 19 + 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 8.1. T/TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 8.2. Common Defenses Against SYN Flood Attacks . . . . . . . . . 20 8.3. TCP Cookie Transaction (TCPCT) . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20 - 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 - Appendix A. Example Socket API Changes to support TFO . . . . . . 22 - A.1 Active Open . . . . . . . . . . . . . . . . . . . . . . . . 22 + Appendix A. Example Socket API Changes to support TFO . . . . . . 23 + A.1 Active Open . . . . . . . . . . . . . . . . . . . . . . . . 23 A.2 Passive Open . . . . . . . . . . . . . . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction - TCP Fast Open (TFO) enables data to be exchanged safely during TCP's - connection handshake. This document describes a design that enables - applications to save a round trip while avoiding severe security - ramifications. At the core of TFO is a security cookie used by the - server side to authenticate a client initiating a TFO connection. - This document covers the details of exchanging data during TCP's - initial handshake, the protocol for TFO cookies, potential new - security vulnerabilities and their mitigation, and the new socket - API. + TCP Fast Open (TFO) is an experimental update to TCP that enables + data to be exchanged safely during TCP's connection handshake. This + document describes a design that enables applications to save a round + trip while avoiding severe security ramifications. At the core of TFO + is a security cookie used by the server side to authenticate a client + initiating a TFO connection. This document covers the details of + exchanging data during TCP's initial handshake, the protocol for TFO + cookies, potential new security vulnerabilities and their mitigation, + and the new socket API. TFO is motivated by the performance needs of today's Web - applications. Current TCP only permits data exchange after 3WHS - [RFC793], which adds one RTT to network latency. For short Web - transfers this additional RTT is a significant portion of overall - network latency, even when HTTP persistent connection is widely used. - For example, the Chrome browser keeps TCP connections idle for up to - 5 minutes but 35% of Chrome HTTP requests are made on new TCP - connections [RCCJR11]. For such Web and Web-like applications placing - data in the SYN can yield significant latency improvements. Next we - describe how we resolve the challenges that arise upon doing so. + applications. Current TCP only permits data exchange after the 3-way + handshake (3WHS)[RFC793], which adds one RTT to network latency. For + short Web transfers this additional RTT is a significant portion of + overall network latency, even when HTTP persistent connection is + widely used. For example, the Chrome browser keeps TCP connections + idle for up to 5 minutes but 35% of Chrome HTTP requests are made on + new TCP connections [RCCJR11]. For such Web and Web-like applications + placing data in the SYN can yield significant latency improvements. + Next we describe how we resolve the challenges that arise upon doing + so. 2. Data In SYN Standard TCP already allows data to be carried in SYN packets ([RFC793], section 3.4) but forbids the receiver from delivering it to the application until 3WHS is completed. This is because TCP's initial handshake serves to capture old or duplicate SYNs. To enable applications exchange data in TCP handshake, TFO removes the constraint and allows data in SYN packets to be delivered to @@ -147,34 +150,34 @@ in the following subsections, making TFO unsuitable for certain applications. Therefore TCP implementations MUST NOT use TFO by default, but only use TFO if requested explicitly by the application on a per service port basis. Applications need to evaluate TFO applicability described in Section 6 before using TFO. 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 the two cases below: 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); b) the duplicate is received after the connection created 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 state). 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 capture all dubious SYN packets to make TFO 100% compatible with TCP 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 applications (Section 6) that are tolerant of duplicate SYN packets with data. We believe this is the right design trade-off balancing complexity with usefulness. 2.2. SYNs with Spoofed IP Addresses @@ -328,21 +332,21 @@ 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 fabricated by any other parties including the client. 3. The generation and verification are fast relative to the rest of SYN and SYN-ACK processing. 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 - is all server implementation dependent and transparent to the + is server implementation dependent and transparent to the client. 5. The cookie expires after a certain amount of time. The reason for cookie expiration is detailed in the "Security Consideration" section. This can be done by either periodically changing the server key used to generate cookies or including a timestamp when generating the cookie. To gradually invalidate cookies over time, the server can implement key rotation to generate and verify cookies using @@ -381,42 +385,43 @@ 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. This information is needed because data is sent before the server 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 bytes [RFC1122]. In particular it's known IPv4 receiver advertised MSS less than 536 bytes would result in transmission of an unexpected 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. + super-size SYN may trigger IP fragmentation and may confuse firewall + or middle-boxes, causing SYN retransmission and other side-effects. + Therefore the client MAY limit the cached MSS to 1460 bytes. 4.1.3.1 Client Caching Negative Responses The client MUST cache negative responses from the server in order to 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, + 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. - 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 enabled on a per-service port basis but cookies are independent of service ports, clients' cache should include remote port numbers too. 4.2. Fast Open Protocol + One predominant requirement of TFO is to be fully compatible with existing TCP implementations, both on the client and the server sides. The server keeps two variables per listening port: FastOpenEnabled: default is off. It MUST be turned on explicitly by the application. When this flag is off, the server does not perform any TFO related operations and MUST ignore all cookie options. @@ -415,21 +420,21 @@ sides. The server keeps two variables per listening port: FastOpenEnabled: default is off. It MUST be turned on explicitly by the application. When this flag is off, the server does not perform any TFO related operations and MUST ignore all cookie options. PendingFastOpenRequests: tracks number of TFO connections in SYN-RCVD 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 is used for defending some vulnerabilities discussed in the "Security Considerations" section. The server keeps a FastOpened flag per TCB to mark if a connection has successfully performed a TFO. 4.2.1. Fast Open Cookie Request Any client attempting TFO MUST first request a cookie from the server @@ -457,27 +462,29 @@ RECOMMEND both the client and the server to 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 penalty (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). 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. An alternate proposal is to request cookie in FIN - instead since FIN-drop by incompatible middle-box does not affect - latency. However such 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. + We also RECOMMEND the client to record the set of servers that failed + to respond to cookie requests and only attempt another cookie request + after certain period. + + An alternate proposal is to request cookie in FIN instead since FIN- + drop by incompatible middle-box does not affect latency. However such + 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 Once the client obtains the cookie from the target server, it can perform subsequent TFO connections until the cookie is expired by the server. Client: Sending SYN To open a TFO connection, the client MUST have obtained a cookie from @@ -519,23 +526,22 @@ 5. Send the SYN-ACK packet. The packet MAY include a Fast Open Option. If FastOpened flag is set, the packet acknowledges the SYN and data sequence. Otherwise it acknowledges only the SYN sequence. The server MAY include data in the SYN-ACK packet if the response data is readily available. Some application may favor delaying the SYN-ACK, allowing the application to process the request in order to produce a response, but this is left up to the implementation. 6. Advance to the SYN-RCVD state. If the FastOpened flag is set, the - server MUST follow the congestion control [RFC5681], in particular - the initial congestion window [RFC3390], to send more data - packets. + server MUST follow the congestion control [RFC5681] to set the + initial congestion window [RFC3390], to send more data packets. 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. A special case is simultaneous open where the SYN receiver is a client in SYN-SENT state. The protocol remains the same because [RFC793] already supports both data in SYN and simultaneous open. But the client's socket may have data available to read before it's connected. This document does not cover the corresponding API change. @@ -573,48 +579,46 @@ state. No special handling is required further. 5. 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]. We note that although generating bogus cookies is cost-free, the cost of validating the cookies, inherent to any - authentication scheme, may not be substantial compared to processing - a regular SYN packet. + authentication scheme, may be substantial compared to processing a + regular SYN packet. 5.1. Resource Exhaustion Attack by SYN Flood with Valid Cookies - 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 new vulnerabilities of TFO and describe the - countermeasures. + An 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 new vulnerabilities of TFO and describe the countermeasures. Like regular TCP handshakes, TFO is vulnerable to such an attack. But the potential damage can be much more severe. Besides causing temporary disruption to service ports under attack, it may exhaust server CPU and memory resources. Such an attack will show up on application server logs as a application level DoS from Bot-nets, triggering other defenses and alerts. - For this reason it is crucial for the TFO server to limit the maximum - number of total pending TFO connection requests, i.e., - PendingFastOpenRequests. When the limit is exceeded, the server - temporarily disables TFO entirely as described in "Server Cookie - Handling". Then subsequent TFO requests will be downgraded to regular - connection requests, i.e., with the data dropped and only SYN - acknowledged. This allows regular SYN flood defense techniques - [RFC4987] like SYN-cookies to kick in and prevent further service - disruption. + To protect the server it is important to limit the maximum number of + total pending TFO connection requests, i.e., PendingFastOpenRequests + (Section 4.2). When the limit is exceeded, the server temporarily + disables TFO entirely as described in "Server Cookie Handling". Then + subsequent TFO requests will be downgraded to regular connection + requests, i.e., with the data dropped and only SYN acknowledged. This + allows regular SYN flood defense techniques [RFC4987] like SYN- + cookies to kick in and prevent further service disruption. The main impact of SYN floods against the standard TCP stack is not directly from the floods themselves costing TCP processing overhead or host memory, but rather from the spoofed SYN packets filling up the often small listener's queue. On the other hand, TFO SYN floods can cause damage directly if admitted without limit into the stack. The RST packets from the 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 @@ -626,29 +630,29 @@ PendingFastOpenRequests until a timeout period has passed. Limiting the maximum number of pending TFO connection requests does 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 of interest to attackers because the service will remain intact without TFO hence there is hardly any real damage. 5.1.1 Attacks from behind Shared Public IPs (NATs) - An attacker behind NAT can easily obtain valid cookies to launch the - above attack to hurt other clients that share the path. [BRISCOE12] - suggested that the server can extend cookie generation to include the - TCP timestamp---GetCookie(IP_Address, Timestamp)---and implement it - by encrypting the concatenation of the two values to generate the - cookie. The client stores both the cookie and its corresponding - timestamp, and echoes both in the SYN. The server then implements - IsCookieValid(IP_Address, Timestamp, Cookie) by encrypting the IP and - timestamp data and comparing it with the cookie value. + An attacker behind a NAT can easily obtain valid cookies to launch + the above attack to hurt other clients that share the path. + [BRISCOE12] suggested that the server can extend cookie generation to + include the TCP timestamp---GetCookie(IP_Address, Timestamp)---and + implement it by encrypting the concatenation of the two values to + generate the cookie. The client stores both the cookie and its + corresponding timestamp, and echoes both in the SYN. The server then + implements IsCookieValid(IP_Address, Timestamp, Cookie) by encrypting + the IP and timestamp data and comparing it with the cookie value. This enables the server to issue different cookies to clients that share the same IP address, hence can selectively discard those misused cookies from the attacker. However the attacker can simply repeat the attack with new cookies. The server would eventually need to throttle all requests from the IP address just like the current approach. Moreover this approach requires modifying [RFC 1323] to send non-zero Timestamp Echo Reply in SYN, potentially cause firewall issues. Therefore we believe the benefit does not outweigh the drawbacks. @@ -691,27 +695,34 @@ This section is to help applications considering TFO to evaluate TFO's benefits and drawbacks using the Web client and server applications as an example throughout. Applications here refer 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 API change is in the Appendix. 6.1 Duplicate Data in SYNs - It is possible, though uncommon, that using TFO results in the first - data written to a socket to be delivered more than once to the - application on the remote host(Section 2.1). This replay potential - only applies to data 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 - same SYN data more than once, due to reasons described before. + It is possible that using TFO results in the first data written to a + socket to be delivered more than once to the application on the + remote host(Section 2.1). This replay potential only applies to data + in the SYN but not subsequent data exchanges. + + Empirically [JIDKT07] showed the packet duplication on a Tier-1 + 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 TFO is designed for latency-conscious applications that are sensitive 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 more than TCP's maximum segment size (minus options used in SYN). Otherwise the remote server can only process the client's application data unit once the rest of it is delivered after the initial handshake, diminishing TFO's benefit. @@ -749,24 +760,21 @@ connections to these domains before the user initiates any requests for them [BELSHE11]. While this technique also saves the handshake latency, it wastes server and network resources by initiating and maintaining idle connections. 6.3.3. HTTP over TLS (HTTPS) 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 about violating idem-potency. In particular it can be used alone with - the speculative connection above. While HTTPS adoption is still low, - 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. + the speculative connection above. 6.3.4. Comparison with HTTP Persistent Connections Is TFO useful given the wide deployment of HTTP persistent connections? The short answer is yes. Studies [RCCJR11][AERG11] show that the average number of transactions per connection is between 2 and 4, based on large-scale measurements from both servers and clients. In these studies, the servers and clients both kept idle connections up to several minutes, well into "human think" time. @@ -781,23 +789,23 @@ To circumvent this problem, some applications send frequent TCP keep- alive probes. However, this technique drains power on mobile devices [MQXMZ11]. In fact, power has become such a prominent issue in modern LTE devices that mobile browsers close HTTP connections within seconds or even immediately [SOUDERS11]. [RCCJR11] studied Chrome browser performance based on 28 days of global statistics. The Chrome browser keeps idle HTTP persistent 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 - to 25% of the HTTP transaction network latency. The authors - estimated that TFO improves page load time by 10% to 40% on selected - popular Web sites. + to 25% of the HTTP transaction network latency. The authors estimated + that TFO improves page load time by 10% to 40% on selected popular + Web sites. 7. Open Areas for Experimentation We now outline some areas that need experimentation in the Internet and under different network scenarios. These experiments should help the community evaluate Fast Open benefits and risks towards further standardization and implementation of Fast Open and its related protocols. 7.1. Performance impact due to middle-boxes and NAT @@ -821,21 +829,22 @@ provide latency benefits. However, there is no performance penalty either, as described in Section "Client: Receiving SYN-ACK". 7.2. Cookie-less Fast Open The cookie mechanism mitigates resource exhaustion and amplification attacks. However cookies are not necessary if the server has application-level protection or is immune to these attacks. For 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 - 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 client no longer needs to request a cookie and the server no longer needs to check or generate cookies. Disabling cookies also potentially simplifies configuration, as the server no longer needs a key. It may be preferable to enable SYN cookies and disable TFO [RFC4987] when a server is overloaded by a large-scale Bot-net attack. Careful experimentation is necessary to evaluate if cookie-less TFO @@ -853,21 +862,22 @@ 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. + the handshake across connections. Further experimentation regarding + the congestion control impact are useful. 8. Related Work 8.1. T/TCP TCP Extensions for Transactions [RFC1644] attempted to bypass the 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 battling old or duplicate SYNs, but paid no attention to security vulnerabilities it introduced when bypassing 3WHS [PHRACK98]. @@ -934,20 +945,23 @@ [RFC6298] Paxson, V., Allman, M., Chu, J. and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011. [RFC6928] Chu, J., Dukkipati, N., Cheng, Y. and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, April 2013. [RFC6994] Touch, Joe, "Shared Use of Experimental TCP Options", RFC6994, August 2013. + [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's + Initial Window", RFC 3390, October 2002. + 11.2. Informative References [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. [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 @@ -998,20 +1012,25 @@ [BRISCOE12] Briscoe, B., "Some ideas building on draft-ietf-tcpm- fastopen-01", tcpm list, http://www.ietf.org/mail-archive/web/tcpm/current/ January 16, 2014msg07192.html [BELSHE12] Belshe, M., "The era of browser preconnect.", http://www.belshe.com/2011/02/10/ 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 A.1 Active Open The active open side involves changing or replacing the connect() call, which does not take a user data buffer argument. We recommend replacing connect() call to minimize API changes and hence applications to reduce the deployment hurdle. One solution implemented in Linux 3.7 is introducing a new flag