idnits 2.17.1 draft-borman-tcp4way-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 14 form feeds but 68 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 14, 2014) is 3476 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-03) exists of draft-touch-tcpm-tcp-edo-01 == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcp-edo-01 == Outdated reference: A later version (-12) exists of draft-touch-tcpm-tcp-syn-ext-opt-01 == Outdated reference: A later version (-03) exists of draft-briscoe-tcpm-syn-op-sis-02 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCPM D. Borman 3 Internet-Draft Quantum Corporation 4 Intended Status: Standards Track October 14, 2014 5 File: draft-borman-tcp4way-00.txt 6 Expires: April 14, 2015 8 TCP Four-Way Handshake 10 Abstract 12 One of the limitations of TCP is that it has limited space for TCP 13 options, only 54 bytes. Many mechanisms have been proposed for for 14 extending the TCP option space, but the biggest challenge has been to 15 get additional option space in the initial SYN packet. 17 This memo presents a optional four-way TCP handshake to allow 18 extended option space to be used in SYN packets in both directions. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF). Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. The list of current Internet-Drafts is at 27 http://datatracker.ietf.org/drafts/current. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 14, 2015. 36 Copyright 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction 2 54 2. Motivation For this Approach 3 55 3. TCP Four-Way Handshake 4 56 3.1 Overview 4 57 3.2 Changes to the TCP state diagram 5 58 3.3 Three-Way or Four-Way Handshake? 6 59 3.3.1 Non Four-Way Client Sets 4WAY bit 6 60 3.3.2 Non Four-Way Server Sets 4WAY bit 6 61 3.4 RTT Costs of the Four-Way Handshake 7 62 4. Negotiating Non-directional vs. Directional TCP Options 8 63 5. TCP Connection State Diagram 9 64 6. IANA Considerations 11 65 7. Security Considerations 11 66 8. References 11 67 8.1 Normative References 11 68 8.2 Informative References 11 69 Appendix A. First Response of the Four-Way Handshake 12 70 Appendix B. Communicating Four-Way Handshake Support 14 72 Acknowledgments 14 73 Contributors 14 74 Author's Address 14 76 1. Introduction 78 The TCP packet format has 54 bytes for adding TCP options. The most 79 common method to extend TCP is to define new options, but the limited 80 TCP option space can make that difficult as the number of potential 81 options grow. Support for various TCP options is typically 82 negotiated during the three-way handshake, in the packets that 83 contain the SYN. If both sides send and receive a given option in a 84 packet with the SYN bit set, then both sides know that the option is 85 supported. 87 The majority of TCP sessions begin with three-way handshake, the 88 exception to that is a simultaneous open. 90 The ideas presented in this memo were first hinted at in a message to 91 the TCPM mailing list [Borman14]. 93 2. Motivation For this Approach 95 The problem of expanding the TCP option space in the initial SYN 96 packet has vexed designers for years. The main issue is maintaining 97 compatibility with legacy TCP implementations, which don't understand 98 the expanded TCP option space. When the initial SYN is sent, there 99 is no knowledge as to whether or not the remote side can understand 100 the extended option space. Various approaches have been considered: 102 1) Send dual SYNs, with and without the extended options, and 103 arrange that the extended SYN will be considered invalid and 104 dropped by legacy implementations. [Yourtchenko11] [Briscoe14] 105 2) Send an additional out of band packet along with the SYN to 106 contain additional options. [Touch14] 107 3) Send additional options that didn't fit into the SYN in 108 additional packets using a new TCP option. [Eddy08] 109 4) Send an initial SYN with extended options that a legacy server 110 will fail, and then fall back to a new SYN without extended 111 options. [Kohler04] 113 [Ramaiah12] contains additional analysis of proposed ways to 114 expand the TCP option space. 116 Expanding the TCP option space in the initial SYN is a case of the 117 more general issue: How can you change the fixed TCP header in the 118 initial SYN packet and still maintain compatibility with legacy 119 implementations? The TCP Window Scale option [RFC7323] redefined the 120 Window field, but only in non-SYN packets. In the case of expanding 121 the TCP option space, it involves redefining or overriding the Data 122 Offset (DO) field. 124 The most straight forward method for dealing with modifying the 125 initial SYN packet is to add an initial packet exchange so that the 126 client can find out what the server supports, and then it knows, for 127 example, if the server supports extended TCP option space. The 128 problem with this approach is that it adds an additional RTT to 129 connection startup, and most people are looking for ways to shorten, 130 not lengthen, the initial connection setup, for example "TCP Fast 131 Open" [TFO]. Though to be clear, the extra RTT is really not a 132 concern about connection setup, but about when data can be first 133 delivered to the application. 135 An alternative is to send the additional data in the initial SYN such 136 that a legacy TCP will ignore it. This is most commonly done by 137 sending the information in a TCP option, which legacy TCP would 138 ignore. But the TCP option space is only 54 bytes, and by definition 139 an expanded TCP option space won't fit in the legacy TCP option 140 space. So, the additional data needs to be sent by some other 141 mechanism, e.g. in a second SYN or in an additional non-SYN packet. 142 Challenges with this approach include the SYNs being routed to 143 different destination machines, the order of the packets being 144 reversed, as well as a server needing to wait some amount of time to 145 decide whether or not the additional packet will be arriving. 147 The goal of this proposal is to integrate discovery of server 148 capabilities into the connection setup, while still allowing for data 149 to be delivered in a timely manner. 151 3. TCP Four-Way Handshake 153 3.1 Overview 155 For a connection with ISS (Initial Send Sequence) values of ISSA from 156 the client and ISSB from the server, the normal three-way TCP 157 handshake is: 159 Enter SYN-SENT 160 SYN(seq=ISSA) -> 161 Enter SYN-RECEIVED 162 <- SYN(seq=ISSB)/ACK(ISSA) 163 Enter ESTABLISHED 164 ACK(ISSB) -> 165 Enter ESTABLISHED 167 A simultaneous open is: 169 Enter SYN-SENT Enter SYN-SENT 170 SYN(seq=ISSA) -> <- SYN(seq=ISSB) 172 Enter SYN-RECEIVED Enter SYN-RECEIVED 173 SYN(seq=ISSA)/ACK(ISSB) -> <- SYN(seq=ISSB)/ACK(ISSA) 175 Enter ESTABLISHED Enter ESTABLISHED 177 See [RFC793] page 68 and [RFC1122] page 86. 179 The normal scenario for the proposed four-way handshake is: 181 Enter SYN-SENT 182 SYN(seq=ISSA) -> 183 Enter SYN-SENT 184 <- SYN(seq=ISSB)/ACK(ISSA) 185 Enter SYN-RECEIVED 186 SYN(seq=ISSA)/ACK(ISSB) -> 187 Enter ESTABLISHED 188 <- ACK(ISSA) 189 Enter ESTABLISHED 191 There are other options for the initial server response in the four- 192 way handshake. Those are discussed in Appendix A as well as the 193 reasons they weren't chosen. 195 3.2 Changes to the TCP state diagram 197 The changes can be described entirely as new new state transitions 198 and some additional decisions: 200 LISTEN -> rcv SYN, 201 if (allow4way) 202 passive4way=1, snd SYN,ACK -> SYN-SENT 203 else 204 passive4way=0, snd SND,ACK -> SYN-RCVD 205 SYN-SENT -> rcv ACK 206 if (passive4way == 1) 207 -> ESTABLISHED 208 else 209 normal error processing 211 CLOSED -> active OPEN, create TCB, snd SYN, 212 active4way=1 -> SYN-SENT 214 SYN-SENT -> rcv SYN,ACK 215 if (active4way == 1 && (continue4way)) 216 snd SYN,ACK -> SYN-RCVD 217 else 218 snd ACK -> ESTABLISHED 220 The "allow4way" and "continue4way" decisions are based on the 221 contents of the inbound packet. 223 Instead of overloading the SYN-SENT state and burying the decisions 224 in the existing LISTEN and SYN-SENT states, the state diagram could 225 be expanded with one new state, SYN-ACK-SENT, and two transitional 226 states, ALLOW-4WAY and CONTINUE-4WAY. These *-4WAY states are 227 transitional because once entered, an immediate decision is made and 228 then they are immediately exited to a new state. 230 The LISTEN -> SYN-RCVD transition is replaced by: 232 LISTEN -> rcv SYN -> ALLOW-4WAY 234 ALLOW-4WAY(YES) -> snd SYN,ACK -> SYN-ACK-SENT 235 ALLOW-4WAY(NO) -> snd SYN,ACK -> SYN-RCVD 237 SYN-ACK-SENT -> rcv SYN,ACK, snd ACK -> ESTABLISHED 238 SYN-ACK-SENT -> rcv ACK of SYN, x -> ESTABLISHED 240 and the SYN-SENT -> ESTABLISHED transition is replace by: 242 SYN-SENT -> rcv SYN,ACK -> CONTINUE-4WAY 244 CONTINUE-4WAY(YES) -> snd SYN,ACK -> SYN-RCVD 245 CONTINUE-4WAY(NO) -> snd ACK -> ESTABLISHED 247 3.3 Three-Way or Four-Way Handshake? 249 There are two new decision points for for handling a four-way 250 handshake. First, when a connection in LISTEN state receives a SYN 251 packet, it has to decide based on the contents of that packet whether 252 or not the remote side understands the four-way handshake. This is 253 accomplished through the allocation of one of the unused bits in the 254 TCP header, the 4WAY bit. 256 Note: Other ways to convey support for the four-way handshake were 257 considered, these are discussed in Appendix B. 259 The client sets the 4WAY bit in the initial SYN. If the server 260 receives a 4WAY bit in the initial SYN, then it will set the 4WAY bit 261 in the SYN/ACK. If the client recieves a SYN/ACK without the 4WAY 262 bit set, it proceeds with the normal three-way handshake. If it 263 receives a SYN/ACK with the 4WAY bit set, then based on the options 264 in the SYN/ACK it can chose to either proceed with the normal three- 265 way handshake, or to continue with the four-way handshake. 267 If a packet is received with the 4WAY bit set, but not the SYN bit, 268 the 4WAY bit is ignored. When sending a packet without the SYN bit 269 set, the 4WAY bit must not be set. 271 [RFC3168] notes TCP interoperability issues with the CWR and ECE 272 bits, but the 4WAY bit does not have the same issues. 274 3.3.1 Non Four-Way Client Sets 4WAY bit 276 In this case, the server might enter SYN-ACK-SENT state. It will 277 respond with a SYN-ACK. Because this looks like the same ACK 278 generated in SYN-RCVD state, it will look to the client like a normal 279 SYN/ACK packet, other than the 4WAY bit, and it will respond with a 280 normal ACK, and the connection will complete with the normal three- 281 way handshake. 283 3.3.2 Non Four-Way Server Sets 4WAY bit 285 If the client decides to not continue a four-way handshake, then it 286 will respond with an ACK and complete the normal three-way handshake. 287 If the client decides that it does want to continue with a four-way 288 exchange, it'll send a SYN/ACK. When the server receives the packet, 289 the normal TCP processing will strip off the SYN, and continue 290 processing as a normal three-way handshake. 292 3.4 RTT Costs of the Four-Way Handshake 294 When compared to the three-way handshake, the four-way handshake adds 295 an additional 0.5 RTT before both sides enter ESTABLISHED state. But 296 the more important question is how does the four-way handshake affect 297 the delivery of initial data to the application? This is best 298 answered by looking at some specific cases, comparing the three-way 299 handshake with the four-way handshake. 301 Data can be sent on a SYN packet, but it cannot be delivered to the 302 application until entering ESTABLISHED state. 304 Three-way handshake with data sent once in ESTABLISHED: 306 0.0) SYN -> 307 0.5) <- SYN/ACK 308 1.0) Client enters ESTABLISHED 309 ACK w/client data -> 310 1.5) Server enters ESTABLISHED, delivers client data. 311 <- Server data 312 2.0) Client delivers server data 314 Four-way handshake with data sent once in ESTABLISHED: 316 0.0) SYN -> 317 0.5) <- SYN 318 1.0) SYN/ACK-> 319 1.5) Server enters ESTABLISHED state 320 ACK w/Server data 321 2.0) Client enters ESTABLISHED state 322 Client delivers server data 323 ACK w/client data -> 324 2.5) Server delivers client data 326 So in both cases, the server data is delivered at the client after 2 327 RTTs, and for the four-way the client's data is delivered to the 328 server at 2.5 RTT instead of 1.5 RTT, so 1 RTT later. 330 Now, let's look at both cases with data in the SYN/ACK: 332 Three-way handshake: 334 0.0) SYN -> 335 0.5) <- SYN/ACK w/server-data 336 1.0) Client enters ESTABLISHED 337 Client delivers server-data 338 ACK w/client data -> 339 1.5) Server enters ESTABLISHED 340 Server delivers client-data. 342 Four-way handshake: 344 0.0) SYN -> 345 0.5) <- SYN 346 1.0) SYN/ACK with client-data -> 347 1.5) Server enters ESTABLISHED 348 Server delivers client-data 349 <- ACK w/server data 350 2.0) Client enters ESTABLISHED 351 Client delivers server-data. 353 You get the same differences, but reversed. The client's data is 354 delivered after 1.5 RTTs in both cases, and the servers data is 355 delivered 1 RTT later, at 2.0 RTT instead of 1.0 RTT. 357 If you put the data with the bare SYN, the initial data doesn't get 358 delivered any sooner, because you still have to wait for the ACK of 359 the SYN to deliver the data. 361 4. Negotiating Non-directional vs. Directional TCP Options 363 TCP options that are negotiated in the initial SYN exchange can be 364 classified as either non-directional or directional. An example of a 365 non-directional option is the TCP Window Scale option. Negotiating a 366 non-directional TCP option falls naturally into the Four-Way 367 handshake, but allows for more options to be negotiated than will fit 368 into the initial SYN packet when using expanded TCP option space. In 369 order to allow this, the SYN/ACK from the server, with the TCP 370 Extended Data option (EDO) [EDO], can contain initial negotiation for 371 TCP options that weren't received in the initial SYN, which the 372 client can then acknowledge in its SYN/ACK, using the EDO option. 373 Because the options are non-directional, it doesn't matter which side 374 presents it first. 376 Directional options do not fall as cleanly into the extended four-way 377 handshake. A directional option is one which is originated in the 378 initial SYN, and the servers response in the SYN/ACK is determined in 379 direct response to the inbound option. For example, assume an option 380 FOO that has 100 variants, where servers typically have support for 381 all 100 variants, but clients usually only a small number. The 382 client sends option FOO with a short list of variants that it 383 supports, and then the server chooses which one of those to use, and 384 responds with that variant. If instead the server initiates the the 385 option in the SYN/ACK, it'd have to include all 100 variants and let 386 the client choose from that list. In the future, new TCP options 387 would need to be designed to work in the context of the four-way 388 handshake. For existing directional options, it would not be 389 unreasonable to require that they be included in the initial SYN, and 390 other non-directional options would be deferred and negotiated in the 391 SYN/ACK exchange. 393 5. TCP Connection State Diagram 395 The following diagram is modified from the diagram in RFC 793 396 [RFC793]. In addition to adding the "ALLOW 4WAY?", "CONTINUE 4WAY?" 397 and "SYN-ACK SENT" states, it also includes the three changes listed 398 in RFC 1122 [RFC1122]: 400 "(a) The arrow from SYN-SENT to SYN-RCVD should be labeled 401 and with Figure 8. 403 (b) There could be an arrow from SYN-RCVD state to LISTEN 404 state, conditioned on receiving a RST after a passive 405 open (see text page 70). 407 (c) It is possible to go directly from FIN-WAIT-1 to the 408 TIME-WAIT state (see page 75 of the spec)." 410 TCP Connection State Diagram 411 +--------+ --------\ 412 | CLOSED |<------\ \ active OPEN 413 +--------+ \ \ ----------- 414 passive OPEN | ^ CLOSE \ \ create TCB 415 ------------ | | ---------- \ \ snd SYN 416 create TCB V | delete TCB \ \ 417 +--------+ \ \ 418 rcv SYN | LISTEN | CLOSE \ \ 419 ------- +--------+ ---------- \ | 420 +-------------+ x / ^ | SEND delete TCB | V 421 | ALLOW 4WAY? |<------------- | | ------- +---------+ 422 | |------------ | \ snd SYN | | 423 +-------------+ YES \ | ------------------>| SYN | 424 | NO ----------- | | ---------------| SENT | 425 | ----------- snd SYN,ACK | \ / rcv SYN | | 426 | snd SYN,ACK V \ | ----------- | | 427 | +--------------+ \ | snd SYN,ACK +---------+ 428 | | SYN-ACK SENT | \ | rcv SYN,ACK | 429 | +--------------+ | | ----------- | 430 | rcv SYN,ACK | | rcv ACK of SYN | | x V 431 | ----------- | | -------------- | | +----------------+ 432 | snd ACK | \ x | | | CONTINUE 4WAY? | 433 V \ ----------- | | -----| | 434 +---------+ ----------- \ | | / +----------------+ 435 | | rcv RST \ | / | | YES | NO 436 | SYN |----------------------)-)- / | ----------- | ------- 437 | RCVD |<---------------------)-)--- / snd SYN,ACK | snd ACK 438 | |<---------------------)-)------ / 439 | |------------------ | | ------------------- 440 +---------+ rcv ACK of SYN \ | | / 441 | CLOSE -------------- V V V V 442 | ------- x CLOSE +-------------+ rcv FIN 443 V snd FIN ------- | ESTABLISHED | ------- +---------+ 444 +--------+ snd FIN | | snd ACK | CLOSE | 445 | FIN |<------------------| |-------------->| WAIT | 446 | WAIT-1 |----------------- +-------------+ | | 447 | |-------- \ +---------+ 448 +--------+ \ ------------------+ rcv FIN CLOSE | 449 | rcv ACK of FIN | | ------- ------- | 450 | -------------- | rcv FIN,ACK of FIN V snd ACK snd FIN V 451 V x | ------------------ +---------+ +----------+ 452 +-----------+ | x | CLOSING | | LAST-ACK | 453 | FINWAIT-2 | | +---------+ +----------+ 454 +-----------+ | rcv ACK of FIN | rcv ACK of FIN | 455 | rcv FIN | -------------- | -------------- | 456 | ------- \ x V x V 457 \ snd ACK --------->+-----------+ Timeout=2MSL +--------+ 458 --------------------------->| TIME WAIT |-------------->| CLOSED | 459 +-----------+ delete TCB +--------+ 461 6. IANA Considerations 463 TBD 465 7. Security Considerations 467 TBD 469 8. References 471 8.1 Normative References 473 [RFC793] Postel, J., "Transmission Control Protocol - DARPA Internet 474 Program Protocol Specification", RFC 793, DARPA, September 475 1981. 477 [RFC1122] Braden, R., "Requirements for Internet Hosts - 478 Communication Layers", STD 3, RFC 1122, October 1989, 479 . 481 8.2 Informative References 483 [Borman14] Borman, D., "Re: [tcpm] New Version Notification for 484 draft-touch-tcpm-tcp-edo-01.txt", message to the TCPM 485 mailing list, 22 May 2014, . 488 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of 489 Explicit Congestion Notification (ECN) to IP", RFC 3168, 490 September 2001, . 492 [RFC7323] Borman, D., Braden, R., Jacobson, V., and R. Scheffenegger, 493 Ed., "TCP Extension for High Performance", RFC 7323, 494 September 2014, . 496 [TFO] Cheng, Y., Jhu, J., Radhakrishnan, S., and A. Jain, "TCP Fast 497 Open", Work in Progress, draft-ietf-tcpm-fastopen-10.txt, 498 September 2014. 500 [EDO] Joe Touch, J., and W. Eddy, "TCP Extended Data Offset Option", 501 Work in Progress, draft-ietf-tcpm-tcp-edo-01.txt, October 502 2014. 504 [Kohler04] Kohler, E, "Extended Option Space for TCP" Work in 505 Progress, draft-kohler-tcpm-extopt-00.txt, September 2004. 507 [Touch14] Touch, J., Briscoe, B., and T. Faber, "TCP SYN Extended 508 Option Space in the Payload of a Supplementary Segment", 509 Work in Progress, draft-touch-tcpm-tcp-syn-ext-opt-01.txt, 510 September 2014. 512 [Eddy08] Eddy, W., and A. Langley, "Extending the Space Available for 513 TCP Options", Work in Progress, draft-eddy-tcp-loo-04, 514 July 2008. 516 [Yourtchenko11] Yourtchenko, A., "Introducing TCP Long Options by 517 Invalid Checksum", Work in Progress, draft-yourtchenko- 518 tcp-loic-00.txt, April 2011. 520 [Ramaiah12] Ramaiah, A., "TCP option space extension", Work in 521 Progress, draft-ananth-tcpm-tcpoptext-00.txt, March 2012. 523 [Briscoe14] Briscoe, B., "Extended TCP Option Space in the Payload of 524 an Alternative SYN", Work in Progress, draft-briscoe-tcpm- 525 syn-op-sis-02, September 2014. 527 Appendix A. First Response of the Four-Way Handshake 529 For a connection with ISS values of ISSA from the client and ISSB 530 from the server, three different options for the first server 531 response were considered: 533 (1) SYN(seq=ISSB) 534 (2) SYN(seq=ISSB)/ACK(seq=ISSA-1) 535 (3) SYN(Seq=ISSB)/ACK(seq=ISSA) 537 SYN(seq=ISSB) 539 The original idea for the four-way handshake was to have the 540 server do a simple turn-around of the TCP three-way handshake, by 541 responding to the initial SYN with another bare SYN. Because it 542 had already received a SYN and knows that the client supports the 543 four-way handshake, it could respond with a plain SYN, making use 544 of header modifying options that the client had indicated it 545 supported. This is similar to a a simultaneous open, except the 546 server is able to transition from SYN-SENT to ESTABLISHED instead 547 of going through SYN-RECEIVED state. 549 Enter SYN-SENT 550 SYN(seq=ISSA) -> 551 Enter SYN-SENT 552 <- SYN(seq=ISSB) 553 Enter SYN-RECEIVED 554 SYN(seq=ISSA)/ACK(ISSB) -> 555 Enter ESTABLISHED 556 <- ACK(ISSA) 557 Enter ESTABLISHED 559 The problems with this approach are that it forces the full four- 560 way handshake, and a middle-box in the path might block the 561 returning bare SYN. 563 SYN(seq=ISSB)/ACK(seq=ISSA-1) 565 This response also turns the three-way handshake into something 566 that looks a lot like a simultaneous open, since the ACK does not 567 acknowledge the SYN. The disadvantage is that it also forces a 568 full four-way handshake, since it does not acknowledge the initial 569 SYN. However, this should work better for getting through a 570 middle-box since it is not a bare SYN. But if the middle-box is 571 digging into the TCP packet and tries to verify the ACK field, it 572 might still block this packet since it is not the expected ACK 573 field of the normal three-way handshake. 575 SYN(seq=ISSB)/ACK(seq=ISSA) 577 This response looks like the normal three-way handshake response, 578 which gives the client the ability to choose whether to complete 579 the three-way handshake by sending an ACK(ISSB), or continue the 580 four-way handshake by responding with SYN(seq=ISSA)/ACK(ISSB). 581 The advantage of this option is that it doesn't always force the 582 four-way handshake, and to a middle-box the packets look like the 583 normal TCP packets that it expects to see. 585 The third option offers the least possibility that middle-boxes will 586 block the packets, and also leaves the flexibility for deciding on a 587 three-way or four-way handshake up to the client. Because it is to 588 the client's benefit to have a four-way handshake, it should be the 589 one to decide whether or not the four-way handshake is needed for a 590 particular handshake. 592 Appendix B. Communicating Four-Way Handshake Support 594 Besides allocating a 4WAY bit in the TCP header, two other options 595 were considered for communicating support for the four-way handshake: 597 Create a new 4WAY TCP option 599 This does not have the interoperability issues that the 4WAY 600 TCP bit has, because it is assumed that connections will not 601 send unknown TCP options. The disadvantage of this is that it 602 requires two more bytes out of the TCP option space. 604 Implied support by other TCP options 606 The primary motivation for the four-way handshake is to give 607 the client a second chance to send TCP options in a SYN. This 608 is intended for use with the new TCP EDO option, and the 609 presence of the EDO option could imply support for the four-way 610 handshake. This allows the client to send additional TCP 611 options using the TCP EDO option in a SYN/ACK packet. 613 Acknowledgments 615 TBD 617 Contributors 619 TBD 621 Author's Address 623 David Borman 624 Quantum Corporation 625 1155 Centre Pointe Drive, Suite 1 626 Mendota Heights, MN 55120 628 Phone: (651) 688-4394 629 Email: david.borman@quantum.com