idnits 2.17.1 draft-cheng-tcpm-fastopen-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 64, but not defined == Missing Reference: 'RFC3390' is mentioned on line 448, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) -- Obsolete informational reference (is this intentional?): RFC 1644 (Obsoleted by RFC 6247) -- Obsolete informational reference (is this intentional?): RFC 6013 (Obsoleted by RFC 7805) == Outdated reference: A later version (-08) exists of draft-ietf-tcpm-initcwnd-00 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Y. Cheng 3 draft-cheng-tcpm-fastopen-00.txt J. Chu 4 Intended status: Experimental S. Radhakrishnan 5 Creation date: March 7, 2011 A. Jain 6 Expiration date: September 8, 2011 Google, Inc. 8 TCP Fast Open 10 Status of this Memo 12 Distribution of this memo is unlimited. 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on September 8, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 TCP Fast Open (TFO) allows data to be carried in the SYN or SYN-ACK 52 packets and consumed by the receiving end during the initial 53 connection handshake, thus providing a saving of up to one full round 54 trip time (RTT) compared to standard TCP requiring a three-way 55 handshake (3WHS) to complete before data can be exchanged. 57 Terminology 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [RFC2119]. 62 TFO refers to TCP Fast Open. Client refers to the TCP's active open 63 side and server refers to the TCP's passive open side. 65 1. Introduction 67 TCP Fast Open (TFO) enables data to be exchanged safely during TCP 68 connection handshake. 70 This document describes a design that enables qualified applications 71 to attain a round trip saving while avoiding severe security 72 ramifications. At the core of TFO is a security cookie used by the 73 server side to authenticate a client initiating a TFO connection. The 74 document covers the details of exchanging data during TCP's initial 75 handshake, the protocol for TFO cookies, and potential new security 76 vulnerabilities and their mitigation. It also includes discussions on 77 deployment issues and related proposals. TFO requires extensions to 78 the existing socket API, which will be covered in a separate 79 document. 81 TFO is motivated by the performance need of today's web applications. 82 Network latency is determined by the round-trip time (RTT) and the 83 number of round trips required to transfer application data. RTT 84 consists of transmission delay and propagation delay. Network 85 bandwidth has grown substantially over the past two decades, much 86 reducing the transmission delay, while propagation delay is largely 87 constrained by the speed of light and has remained unchanged. 88 Therefore reducing the number of round trips has become the most 89 effective way to improve the latency of web applications [CDCM10]. 91 Standard TCP only permits data exchange after 3WHS [RFC793], which 92 introduces one RTT delay to the network latency. For short transfers, 93 e.g., web objects, this additional RTT becomes a significant portion 94 of the network latency [THK98]. One widely deployed solution is HTTP 95 persistent connections. However, this solution is limited since hosts 96 and middle boxes terminate idle TCP connections due to resource 97 constraints. E.g., the Chrome browser keeps TCP connections idle up 98 to 4 minutes but 35% of Chrome HTTP requests are made on new TCP 99 connections. 101 2. Data In SYN 103 [RFC793] (section 3.4) already allows data in SYN packets but forbids 104 the receiver to deliver the data to the application until 3WHS is 105 completed. This is because TCP's initial handshake serves to capture 107 - Old or duplicate SYNs 109 - SYNs with spoofed IP addresses 111 TFO allows data to be delivered to the application before 3WHS is 112 completed, thus opening itself to a possible data integrity problem 113 caused by the dubious SYN packets above. 115 2.1. TCP Semantics and Duplicate SYNs 117 A past proposal called T/TCP employs a new TCP "TAO" option and 118 connection count to guard against old or duplicate SYNs [RFC1644]. 119 The solution is complex, involving state tracking on per remote peer 120 basis, and is vulnerable to IP spoofing attack. Moreover, it has been 121 shown that even with all the complexity, T/TCP is still not 100% 122 bullet proof. Old or duplicate SYNs may still slip through and get 123 accepted by a T/TCP server [PHRACK98]. 125 Rather than trying to capture all the dubious SYN packets to make TFO 126 100% compatible with TCP semantics, we've made a design decision 127 early on to accept old SYN packets with data, i.e., to allow TFO for 128 a class of applications that are tolerant of duplicate SYN packets 129 with data, e.g., idempotent or query type transactions. We believe 130 this is the right design trade-off balancing complexity with 131 usefulness. There is a large class of applications that can tolerate 132 dubious transaction requests. 134 For this reason, TFO MUST be disabled by default, and only enabled 135 explicitly by applications on a per service port basis. 137 2.2. SYNs with spoofed IP addresses 139 Standard TCP suffers from the SYN flood attack [RFC4987] because 140 bogus SYN packets, i.e., SYN packets with spoofed source IP addresses 141 can easily fill up a listener's small queue, causing a service port 142 to be blocked completely until timeouts. Secondary damage comes from 143 faked SYN requests taking up memory space. This is normally not an 144 issue today with typical servers having plenty of memory. 146 TFO goes one step further to allow server side TCP to process and 147 send up data to the application layer before 3WHS is completed. This 148 opens up much more serious new vulnerabilities. Applications serving 149 ports that have TFO enabled may waste lots of CPU and memory 150 resources processing the requests and producing the responses. If the 151 response is much larger than the request, the attacker can mount an 152 amplified reflection attack against victims of choice beyond the TFO 153 server itself. 155 Numerous mitigation techniques against the regular SYN flood attack 156 exist and have been well documented [RFC4987]. Unfortunately none are 157 applicable to TFO. We propose a server supplied cookie to mitigate 158 most of the security risks introduced by TFO. A more thorough 159 discussion on SYN flood attack against TFO is deferred to the 160 "Security Considerations" section. 162 3. Protocol Overview 164 The key component of TFO is the Fast Open Cookie (cookie), a message 165 authentication code (MAC) tag generated by the server. The client 166 requests a cookie in one regular TCP connection, then uses it for 167 future TCP connections to exchange data during 3WHS: 169 Requesting Fast Open Cookie: 171 1. The client sends a SYN with a Fast Open Cookie Request option. 172 2. The server generates a cookie and sends it through the Fast Open 173 Cookie option of a SYN-ACK packet. 174 3. The client caches the cookie for future TCP Fast Open connections 175 (see below). 177 Performing TCP Fast Open: 179 1. The client sends a SYN with Fast Open Cookie option and data. 180 2. The server validates the cookie: 181 a. If the cookie is valid, the server sends a SYN-ACK 182 acknowledging both the SYN and the data. The server then delivers 183 the data to the application. 184 b. Otherwise, the server drops the data and sends a SYN-ACK 185 acknowledging only the SYN sequence number. 186 3. If the server accepts the data in the SYN packet, it may send the 187 response data before the handshake finishes. The max amount is 188 governed by the TCP's congestion control [RFC5681]. 189 4. The client sends an ACK acknowledging the SYN and the server data. 190 If the client's data is not acknowledged, the client retransmits 191 the data in the ACK packet. 192 5. The rest of the connection proceeds like a normal TCP connection. 194 The client can perform many TFO operations once it acquires a cookie 195 until the cookie is expired by the server. Thus TFO is useful for 196 applications that have temporal locality on client and server 197 connections. 199 Requesting Fast Open Cookie in connection 1: 201 TCP A (Client) TCP B(Server) 202 ______________ _____________ 203 CLOSED LISTEN 205 #1 SYN-SENT ----- ----------> SYN-RCVD 207 #2 ESTABLISHED <---- ---------- SYN-RCVD 208 (caches cookie C) 210 Performing TCP Fast Open in connection 2: 212 TCP A (Client) TCP B(Server) 213 ______________ _____________ 214 CLOSED LISTEN 216 #1 SYN-SENT ----- ----> SYN-RCVD 218 #2 ESTABLISHED <---- ---- SYN-RCVD 220 #3 ESTABLISHED <---- ---- SYN-RCVD 222 #4 ESTABLISHED ----- --------------------> ESTABLISHED 224 #5 ESTABLISHED --- ----------> ESTABLISHED 226 4. Protocol Details 228 4.1. Fast Open Cookie 230 The Fast Open Cookie is invented to mitigate new security 231 vulnerabilities in order to enable data exchange during handshake. 232 The cookie is a message authentication code tag generated by the 233 server and is opaque to the client; the client simply caches the 234 cookie and passes it back on subsequent SYN packets to open new 235 connections. The server can expire the cookie at any time to enhance 236 security. 238 4.1.1. TCP Options 240 Fast Open Cookie Option 242 The server uses this option to grant a cookie to the client in the 243 SYN-ACK packet; the client uses it to pass the cookie back to the 244 server in the SYN packet. 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Kind | Length | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | 250 ~ Cookie ~ 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Kind 1 byte: constant TBD (assigned by IANA) 255 Length 1 byte: range 6 to 18 (bytes); limited by 256 remaining space in the options field. 257 The number MUST be even. 258 Cookie 4 to 16 bytes (Length - 2) 260 Options with invalid Length values or without SYN flag set MUST be 261 ignored. The minimum Cookie size is 4 bytes. Although the diagram 262 shows a cookie aligned on 32-bit boundaries, that is not required. 264 Fast Open Cookie Request Option 266 The client uses this option in the SYN packet to request a cookie 267 from a TFO-enabled server 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Kind | Length | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Kind 1 byte: same as the Fast Open Cookie option 273 Length 1 byte: constant 2. This distinguishes the option from 274 the Fast Open cookie option. 276 Options with invalid Length values, without SYN flag set, or with ACK 277 flag set MUST be ignored. 279 4.1.2. Server Cookie Handling 281 The server is in charge of cookie generation and authentication. The 282 cookie SHOULD be a message authentication code tag with the following 283 properties: 285 1. The cookie authenticates the client's (source) IP address of the 286 SYN packet. The IP address can be an IPv4 or IPv6 address. 288 2. The cookie can only be generated by the server and can not be 289 fabricated by any other parties including the client. 291 3. The cookie expires after a certain amount of time. The reason is 292 detailed in the "Security Consideration" section. This can be 293 done by either periodically changing the server key used to 294 generate cookies or including a timestamp in the cookie. 296 4. The generation and verification are fast relative to the rest of 297 SYN and SYN-ACK processing. 299 5. A server may encode other information in the cookie, and allow 300 more than one valid cookie per client at any given time. But this 301 is all server implementation dependent and transparent to the 302 client. A client only needs to remember one valid cookie per 303 server IP. 305 The server supports the cookie generation and verification 306 operations: 308 - GetCookie(IP_Address): returns a (new) cookie 310 - IsCookieValid(IP_Address, Cookie): checks if the cookie is valid, 311 i.e., it has not expired and it authenticates the client IP address. 313 Example Implementation: a simple implementation is to use AES_128 to 314 encrypt the IPv4 (with padding) or IPv6 address and truncate to 64 315 bits. The server can periodically update the key to expire the 316 cookies. AES encryption on recent processors is fast and takes only a 317 few hundred nanoseconds. 319 4.1.3. Client Cookie Handling 320 The client MUST cache cookies from different servers for later Fast 321 Open connections. For a multi-homed client, the cookies are both 322 client and server IP dependent. Beside the cookie, we RECOMMEND that 323 the client caches the MSS and RTT to the server to enhance 324 performance. 326 The MSS advertised by the server is stored in the cache to determine 327 the maximum amount of data that can be supported in the SYN packet. 328 This information is needed because data is sent before the server 329 announces its MSS in the SYN-ACK packet. Without this information, 330 the data size in the SYN packet is limited to the default MSS of 536 331 bytes [RFC1122]. 333 Caching RTT allows seeding a more accurate SYN timeout than the 334 default value [RFC2988]. This lowers the performance penalty if the 335 network or the server drops the SYN packets with data or the cookie 336 options (See "Reliability and Deployment Issues" section below). 338 The cache replacement algorithm is not specified and is left for the 339 implementations. 341 4.2. Fast Open Protocol 343 One predominant requirement of TFO is to be fully compatible with 344 existing TCP implementations, both on the client and the server 345 sides. 347 The server keeps two variables per listening port: 349 FastOpenEnabled: default is off. It MUST be turned on explicitly by 350 the application. When this flag is off, the server does not perform 351 any TFO related operations and MUST ignore all cookie options. 353 PendingFastOpenRequests: tracks number of TFO connections in SYN-RCVD 354 state. If this variable goes over the system limit, the server 355 SHOULD set FastOpenEnabled off. This variable is used for defending 356 some vulnerabilities discussed in the "Security Considerations" 357 section. 359 The server keeps a FastOpened flag per TCB to mark if a connection 360 has successfully performed a TFO. 362 4.2.1. Fast Open Cookie Request 364 Any client attempting TFO MUST first request a cookie from the server 365 with the following steps: 367 1. The client sends a SYN packet with a Fast Open Cookie Request 368 option. 370 2. The server SHOULD respond with a SYN-ACK based on the procedures 371 in the "Server Cookie Handling" section. This SYN-ACK SHOULD 372 contain a Fast Open Cookie option if the server currently 373 supports TFO for this listener port. 375 3. If the SYN-ACK contains a valid Fast Open Cookie option, the 376 client replaces the cookie and other information as described in 377 the "Client Cookie Handling" section. Otherwise, if the SYN-ACK 378 is first seen, i.e.,not a (spurious) retransmission, the client 379 MAY remove the server information from the cookie cache. If the 380 SYN-ACK is a spurious retransmission without valid Fast Open 381 Cookie Option, the client does nothing to the cookie cache for 382 the reasons below. 384 The network or servers may drop the SYN or SYN-ACK packets with the 385 new cookie options which causes SYN or SYN-ACK timeouts. We RECOMMEND 386 both the client and the server retransmit SYN and SYN-ACK without the 387 cookie options on timeouts. This ensures the connections of cookie 388 requests will go through and lowers the latency penalties (of dropped 389 SYN/SYN-ACK packets). The obvious downside for maximum compatibility 390 is that any regular SYN drop will fail the cookie. We also RECOMMEND 391 the client to record servers that failed to respond to cookie 392 requests and only attempt another cookie request after certain 393 period. 395 4.2.2. TCP Fast Open 397 Once the client obtains the cookie from the target server, the client 398 can perform subsequent TFO connections until the cookie is expired by 399 the server. The nature of TCP sequencing makes the TFO specific 400 changes relatively small in addition to [RFC793]. 402 Client: Sending SYN 404 To open a TFO connection, the client MUST have obtained the cookie 405 from the server: 407 1. Send a SYN packet. 409 a. If the SYN packet does not have enough option space for the 410 Fast Open Cookie option, abort TFO and fall back to regular 3WHS. 412 b. Otherwise, include the Fast Open Cookie option with the cookie 413 of the server.Include any data up to the cached server MSS or 414 default 536 bytes. 416 2. Advance to SYN-SENT state and update SND.NXT to include the data 417 accordingly. 419 3. If RTT is available from the cache, seed SYN timer according to 420 [RFC2988]. 422 To deal with network or servers dropping SYN packets with payload or 423 unknown options, when the SYN timer fires, the client SHOULD 424 retransmit a SYN packet without data and Fast Open Cookie options. 426 Server: Receiving SYN and responding with SYN-ACK 428 Upon receiving the SYN packet with Fast Open Cookie option: 430 1. If the cookie is invalid, i.e., the cookie does not authenticate 431 the source IP address of the SYN packet, send a SYN-ACK packet 432 acknowledging only the SYN sequence. In addition, include a Fast 433 Open Cookie Option with a new cookie. Go to step 7. 435 2. If PendingFastOpenRequests is over the system limit, reset 436 FastOpenEnabled flag and send a SYN-ACK acknowledging only the 437 SYN sequence. Go to step 7. 439 3. Send the SYN-ACK packet acknowledging the SYN and data sequence. 440 The server MAY include data in the SYN-ACK packet. 442 4. Buffer the data and notify the application. 444 5. Set FastOpened flag and increment PendingFastOpenRequests. 446 6. The server MAY send more data packets before the handshake 447 completes. The maximum amount is ruled by the initial congestion 448 window and the receiver window [RFC3390]. 450 7. Advance to the SYN-RCVD state. 452 If the SYN-ACK timer fires, the server SHOULD retransmit a SYN-ACK 453 packet without data and Fast Open Cookie options for compatibility 454 reasons. 456 Client: Receiving SYN-ACK 458 The client SHOULD perform the following steps upon receiving the SYN- 459 ACK: 460 1. Update the cookie cache if the SYN-ACK has a Fast Open Cookie 461 Option. 463 2. Send an ACK packet. Set acknowledgment number to RCV.NXT and 464 include the data after SND.UNA if data is available 466 3. Advance to the ESTABLISHED state 468 Note there is no latency penalty if the server does not acknowledge 469 the data in the original SYN packet. The client will retransmit it in 470 the ACK packet. The data exchange will start after the handshake like 471 a regular TCP connection. 473 Server: Receiving ACK 475 Upon receiving an ACK acknowledging the SYN sequence, the server 476 decrements PendingFastOpenRequests and advances to the ESTABLISHED 477 state. No special handling is required further. 479 5. Reliability and Deployment Issues 481 Network or Hosts Dropping SYN packets with data or unknown options 483 A study [MAF04] found that some middle-boxes and end-hosts may drop 484 packets with unknown TCP options incorrectly. Another study 485 [LANGLEY06] found that 6% of the probed paths on the Internet drop 486 SYN packets with data. The TFO protocol deals with this problem by 487 retransmitting SYN without data or cookie options and we recommend 488 tracking these servers in the client. 490 Server Farms 492 A common server-farm setup is to have many physical hosts behind a 493 load-balancer sharing the same server IP. The load-balancer forwards 494 new TCP connections to different physical hosts based on certain 495 load-balancing algorithms. For TFO to work, the physical hosts need 496 to share the same key and update the key at about the same time. 498 Network Address Translation (NAT) 500 The hosts behind NAT sharing same IP address will get the same cookie 501 to the same server. This will not prevent TFO from working. But on 502 some carrier-grade NAT configurations where every new TCP connection 503 from the same physical host uses a different public IP address, TFO 504 does not provide latency benefit. However, there is no performance 505 penalty either as described in Section "Client receiving SYN-ACK". 507 6. Security Considerations 509 The Fast Open cookie stops an attacker from trivially flooding 510 spoofed SYN packets with data to burn server resources or to mount an 511 amplified reflection attack on random hosts. The server can defend 512 against spoofed SYN floods with invalid cookies using existing 513 techniques [RFC4987]. 515 However, the attacker may still obtain cookies from some compromised 516 hosts, then flood spoofed SYN with data and "valid" cookies (from 517 these hosts or other vantage points). With DHCP, it's possible to 518 obtain cookies of past IP addresses without compromising any host. 519 Below we identify two new vulnerabilities of TFO and describe the 520 countermeasures. 522 6.1. Server Resource Exhaustion Attack by SYN Flood with Valid Cookies 524 Like regular TCP handshakes, TFO is vulnerable to such an attack. But 525 the potential damage can be much more severe. Besides causing 526 temporary disruption to service ports under attack, it may exhaust 527 server CPU and memory resources. 529 For this reason it is crucial for the TFO server to limit the maximum 530 number of total pending TFO connection requests, i.e., 531 PendingFastOpenRequests. When the limit is exceeded, the server 532 temporarily disables TFO entirely as described in "Server Cookie 533 Handling". Then subsequent TFO requests will be downgraded to regular 534 connection requests, i.e., with the data dropped and only SYN 535 acknowledged. This allows regular SYN flood defense techniques 536 [RFC4987] like SYN-cookies to kick in and prevent further service 537 disruption. 539 There are other subtle but important differences in the vulnerability 540 between TFO and regular TCP handshake. Before the SYN flood attack 541 broke out in the late '90s, typical listener's max qlen was small, 542 enough to sustain the highest expected new connection rate and the 543 average RTT for the SYN-ACK packets to be acknowledged in time. E.g., 544 if a server is designed to handle at most 100 connection requests per 545 second, and the average RTT is 100ms, a max qlen on the order of 10 546 will be sufficient. 548 This small max qlen made it very easy for any attacker, even equipped 549 with just a dailup modem to the Internet, to cause major disruptions 550 to a web site by simply throwing a handful of "SYN bombs" at its 551 victim of choice. But for this attack scheme to work, the attacker 552 must pick a non-responsive source IP address to spoof with. Otherwise 553 the SYN-ACK packet will trigger TCP RST from the host whose IP 554 address has been spoofed, causing corresponding connection to be 555 removed from the server's listener queue hence defeating the attack. 556 In other words, the main damage of SYN bombs against the standard TCP 557 stack is not directly from the bombs themselves costing TCP 558 processing overhead or host memory, but rather from the spoofed SYN 559 packets filling up the often small listener's queue. 561 On the other hand, TFO SYN bombs can cause damage directly if 562 admitted without limit into the stack. The RST packets from the 563 spoofed host will fuel rather than defeat the SYN bombs as compared 564 to the non-TFO case, because the attacker can flood more SYNs with 565 data to cost more data processing resources. For this reason, a TFO 566 server needs to monitor the connections in SYN-RCVD being reset in 567 addition to imposing a reasonable max qlen. Implementations may 568 combine the two, e.g., by continuing to account for those connection 569 requests that have just been reset against the listener's 570 PendingFastOpenRequests until a timeout period has passed. 572 Limiting the maximum number of pending TFO connection requests does 573 make it easy for an attacker to overflow the queue, causing TFO to be 574 disabled. We argue that causing TFO to be disabled is unlikely to be 575 of interest to attackers because the service will remain intact 576 without TFO hence there is hardly any real damage. 578 6.2. Amplified Reflection Attack to Random Host 580 Limiting PendingFastOpenRequests with a system limit can be done 581 without Fast Open Cookies and would protect the server from resource 582 exhaustion. It would also limit how much damage an attacker can cause 583 through an amplified reflection attack from that server. However, it 584 would still be vulnerable to an amplified reflection attack from a 585 large number of servers. An attacker can easily cause damage by 586 tricking many servers to respond with data packets at once to any 587 spoofed victim IP address of choice. 589 With the use of Fast Open Cookies, the attacker would first have to 590 steal a valid cookie from its target victim. This likely requires the 591 attacker to compromise the victim host or network first. 593 The attacker here has little interest in mounting an attack on the 594 victim host that has already been compromised. But she may be 595 motivated to disrupt the victim's network. Since a stolen cookie is 596 only valid for a single server, she has to steal valid cookies from a 597 large number of servers and use them before they expire to cause 598 sufficient damage without triggering the defense in the previous 599 section. 601 One can argue that if the attacker has compromised the target network 602 or hosts, she could perform a similar but simpler attack by injecting 603 bits directly. The degree of damage will be identical, but TFO- 604 specific attack allows the attacker to remain anonymous and disguises 605 the attack as from other servers. 607 The best defense is for the server to not respond with data until 608 handshake finishes, i.e., disallow step 6 in "Server receiving SYN- 609 ACK" section. In this case the risk of amplification reflection 610 attack is completely eliminated, but the potential latency saving 611 from TFO may diminish if the server application produces responses 612 earlier before the handshake completes. 614 7. Related Work 616 7.1. T/TCP 618 TCP Extensions for Transactions [RFC1644] attempted to bypass the 619 three-way handshake, among other things, hence shared the same goal 620 but also the same set of issues as TFO. It focused most of its effort 621 battling old or duplicate SYNs, but paid no attention to security 622 vulnerabilities it introduced when bypassing 3WHS. Its TAO option and 623 connection count, besides adding complexity, require the server to 624 keep state per remote host, while still leaving it wide open for 625 attacks. It is trivial for an attacker to fake a CC value that will 626 pass the TAO test. Unfortunately, in the end its scheme is still not 627 100% bullet proof as pointed out by [PHRACK98]. 629 As stated earlier, we take a practical approach to focus TFO on the 630 security aspect, while allowing old, duplicate SYN packets with data 631 after recognizing that 100% TCP semantics is likely infeasible. We 632 believe this approach strikes the right tradeoff, and makes TFO much 633 simpler and more appealing to TCP implementers and users. 635 7.2. Common Defenses Against SYN Flood Attacks 637 TFO is still vulnerable to SYN flood attacks just like normal TCP 638 handshakes, but the damage may be much worse, thus deserves a careful 639 thought. 641 There have been plenty of studies on how to mitigate attacks from 642 regular SYN flood, i.e., SYN without data [RFC4987]. But from the 643 stateless SYN-cookies to the stateful SYN Cache, none can preserve 644 data sent with SYN safely while still providing an effective defense. 646 The best defense may be to simply disable TFO when a host is 647 suspected to be under a SYN flood attack, e.g., the SYN backlog is 648 filled. Once TFO is disabled, normal SYN flood defenses can be 649 applied. The "Security Consideration" section contains a thorough 650 discussion on this topic. 652 7.3. TCP Cookie Transaction (TCPCT) 654 TCPCT [RFC6013] eliminates server state during initial handshake and 655 defends spoofing DoS attacks. Like TFO, TCPCT allows SYN and SYN-ACK 656 packets to carry data. However, TCPCT and TFO are designed for 657 different goals and they are not compatible. 659 The TCPCT server does not keep any connection state during the 660 handshake, therefore the server application needs to consume the data 661 in SYN and (immediately) produce the data in SYN-ACK before sending 662 SYN-ACK. Otherwise the application's response has to wait until 663 handshake completes. In contrary, TFO allows server to respond data 664 during handshake. Therefore for many request-response style 665 applications, TCPCT may not achieve same latency benefit as TFO. 667 Without state kept on the server side, TCPCP relies on the client 668 side to retransmit the SYN request with data in order to recover from 669 possible loss of packet from server response. This may cause a lot 670 more dubious connection requests. It also limits the response to only 671 one packet, to fit completely within the SYN-ACK packet. For some TCP 672 applications, in particular web applications, this does not provide 673 enough latency benefit by sending one data packet one RTT earlier. 675 8. IANA Considerations 677 The Fast Open Cookie Option and Fast Open Cookie Request Option 678 define no new namespace. The options require IANA allocate one value 679 from the TCP option Kind namespace. 681 9. Acknowledgements 683 The authors would like to thank Tom Herbert, Adam Langley, Roberto 684 Peon, Mathew Mathis, and Barath Raghavan for their insightful 685 comments. 687 10. References 689 10.1. Normative References 691 [RFC793] Postel, J. "Transmission Control Protocol", RFC 793, 692 September 1981. 694 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 695 Communication Layers", STD 3, RFC 1122, October 1989. 697 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 698 Timer", RFC 2988, November 2000. 700 [RFC5681] Allman, M., Paxson, V. and E. Blanton, "TCP Congestion 701 Control", RFC 5681, September 2009. 703 10.2. Informative References 705 [RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions 706 Functional Specification", RFC 1644, July 1994. 708 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 709 Mitigations", RFC 4987, August 2007. 711 [RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC6013, 712 January 2011. 714 [CDCM10] Chu, J., Dukkipati, N., Cheng, Y. and M. Mathis, "Increasing 715 TCP's Initial Window", Internet-Draft draft-ietf-tcpm- 716 initcwnd-00.txt (work in progress), October 2010. 718 [THK98] Touch, J., Heidemann, J., Obraczka, K., "Analysis of HTTP 719 Performance", USC/ISI Research Report 98-463. December 720 1998. 722 [PHRACK98] "T/TCP vulnerabilities", Phrack Magazine, Volume 8, Issue 723 53 artical 6. July 8, 1998. URL 724 http://www.phrack.com/issues.html?issue=53&id=6 726 [MAF04] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions 727 Between Transport Protocols and Middleboxes", Proceedings 728 4th ACM SIGCOMM/USENIX Conference on Internet Measurement, 729 October 2004. 731 [LANGLEY06] Langley, A, "Probing the viability of TCP extensions", 732 URL http://www.imperialviolet.org/binary/ecntest.pdf 734 Author's Addresses 736 Yuchung Cheng 737 Google, Inc. 738 1600 Amphitheatre Parkway 739 Mountain View, CA 94043, USA 740 EMail: ycheng@google.com 742 H.K. Jerry Chu 743 Google, Inc. 744 1600 Amphitheatre Parkway 745 Mountain View, CA 94043, USA 746 EMail: hkchu@google.com 748 Sivasankar Radhakrishnan 749 Google, Inc. 750 1600 Amphitheatre Parkway 751 Mountain View, CA 94043, USA 752 EMail: sivasankar@google.com 754 Arvind Jain 755 Google, Inc. 756 1600 Amphitheatre Parkway 757 Mountain View, CA 94043, USA 758 EMail: arvind@google.com 760 Acknowledgement 762 Funding for the RFC Editor function is currently provided by the 763 Internet Society.