TCPM D. Borman Internet-Draft Quantum Corporation Intended Status: Standards Track October 14, 2014 File: draft-borman-tcp4way-00.txt Expires: April 14, 2015 TCP Four-Way Handshake Abstract One of the limitations of TCP is that it has limited space for TCP options, only 54 bytes. Many mechanisms have been proposed for for extending the TCP option space, but the biggest challenge has been to get additional option space in the initial SYN packet. This memo presents a optional four-way TCP handshake to allow extended option space to be used in SYN packets in both directions. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet- Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 14, 2015. Copyright Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal 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 TCPM Expires April 14, 2015 [Page 1] Internet-Draft TCP Four-Way Handshake October 2014 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. Table of Contents 1. Introduction 2 2. Motivation For this Approach 3 3. TCP Four-Way Handshake 4 3.1 Overview 4 3.2 Changes to the TCP state diagram 5 3.3 Three-Way or Four-Way Handshake? 6 3.3.1 Non Four-Way Client Sets 4WAY bit 6 3.3.2 Non Four-Way Server Sets 4WAY bit 6 3.4 RTT Costs of the Four-Way Handshake 7 4. Negotiating Non-directional vs. Directional TCP Options 8 5. TCP Connection State Diagram 9 6. IANA Considerations 11 7. Security Considerations 11 8. References 11 8.1 Normative References 11 8.2 Informative References 11 Appendix A. First Response of the Four-Way Handshake 12 Appendix B. Communicating Four-Way Handshake Support 14 Acknowledgments 14 Contributors 14 Author's Address 14 1. Introduction The TCP packet format has 54 bytes for adding TCP options. The most common method to extend TCP is to define new options, but the limited TCP option space can make that difficult as the number of potential options grow. Support for various TCP options is typically negotiated during the three-way handshake, in the packets that contain the SYN. If both sides send and receive a given option in a packet with the SYN bit set, then both sides know that the option is supported. The majority of TCP sessions begin with three-way handshake, the exception to that is a simultaneous open. The ideas presented in this memo were first hinted at in a message to the TCPM mailing list [Borman14]. TCPM Expires April 14, 2015 [Page 2] Internet-Draft TCP Four-Way Handshake October 2014 2. Motivation For this Approach The problem of expanding the TCP option space in the initial SYN packet has vexed designers for years. The main issue is maintaining compatibility with legacy TCP implementations, which don't understand the expanded TCP option space. When the initial SYN is sent, there is no knowledge as to whether or not the remote side can understand the extended option space. Various approaches have been considered: 1) Send dual SYNs, with and without the extended options, and arrange that the extended SYN will be considered invalid and dropped by legacy implementations. [Yourtchenko11] [Briscoe14] 2) Send an additional out of band packet along with the SYN to contain additional options. [Touch14] 3) Send additional options that didn't fit into the SYN in additional packets using a new TCP option. [Eddy08] 4) Send an initial SYN with extended options that a legacy server will fail, and then fall back to a new SYN without extended options. [Kohler04] [Ramaiah12] contains additional analysis of proposed ways to expand the TCP option space. Expanding the TCP option space in the initial SYN is a case of the more general issue: How can you change the fixed TCP header in the initial SYN packet and still maintain compatibility with legacy implementations? The TCP Window Scale option [RFC7323] redefined the Window field, but only in non-SYN packets. In the case of expanding the TCP option space, it involves redefining or overriding the Data Offset (DO) field. The most straight forward method for dealing with modifying the initial SYN packet is to add an initial packet exchange so that the client can find out what the server supports, and then it knows, for example, if the server supports extended TCP option space. The problem with this approach is that it adds an additional RTT to connection startup, and most people are looking for ways to shorten, not lengthen, the initial connection setup, for example "TCP Fast Open" [TFO]. Though to be clear, the extra RTT is really not a concern about connection setup, but about when data can be first delivered to the application. An alternative is to send the additional data in the initial SYN such that a legacy TCP will ignore it. This is most commonly done by sending the information in a TCP option, which legacy TCP would ignore. But the TCP option space is only 54 bytes, and by definition an expanded TCP option space won't fit in the legacy TCP option space. So, the additional data needs to be sent by some other mechanism, e.g. in a second SYN or in an additional non-SYN packet. Challenges with this approach include the SYNs being routed to TCPM Expires April 14, 2015 [Page 3] Internet-Draft TCP Four-Way Handshake October 2014 different destination machines, the order of the packets being reversed, as well as a server needing to wait some amount of time to decide whether or not the additional packet will be arriving. The goal of this proposal is to integrate discovery of server capabilities into the connection setup, while still allowing for data to be delivered in a timely manner. 3. TCP Four-Way Handshake 3.1 Overview For a connection with ISS (Initial Send Sequence) values of ISSA from the client and ISSB from the server, the normal three-way TCP handshake is: Enter SYN-SENT SYN(seq=ISSA) -> Enter SYN-RECEIVED <- SYN(seq=ISSB)/ACK(ISSA) Enter ESTABLISHED ACK(ISSB) -> Enter ESTABLISHED A simultaneous open is: Enter SYN-SENT Enter SYN-SENT SYN(seq=ISSA) -> <- SYN(seq=ISSB) Enter SYN-RECEIVED Enter SYN-RECEIVED SYN(seq=ISSA)/ACK(ISSB) -> <- SYN(seq=ISSB)/ACK(ISSA) Enter ESTABLISHED Enter ESTABLISHED See [RFC793] page 68 and [RFC1122] page 86. The normal scenario for the proposed four-way handshake is: Enter SYN-SENT SYN(seq=ISSA) -> Enter SYN-SENT <- SYN(seq=ISSB)/ACK(ISSA) Enter SYN-RECEIVED SYN(seq=ISSA)/ACK(ISSB) -> Enter ESTABLISHED <- ACK(ISSA) Enter ESTABLISHED There are other options for the initial server response in the four- way handshake. Those are discussed in Appendix A as well as the TCPM Expires April 14, 2015 [Page 4] Internet-Draft TCP Four-Way Handshake October 2014 reasons they weren't chosen. 3.2 Changes to the TCP state diagram The changes can be described entirely as new new state transitions and some additional decisions: LISTEN -> rcv SYN, if (allow4way) passive4way=1, snd SYN,ACK -> SYN-SENT else passive4way=0, snd SND,ACK -> SYN-RCVD SYN-SENT -> rcv ACK if (passive4way == 1) -> ESTABLISHED else normal error processing CLOSED -> active OPEN, create TCB, snd SYN, active4way=1 -> SYN-SENT SYN-SENT -> rcv SYN,ACK if (active4way == 1 && (continue4way)) snd SYN,ACK -> SYN-RCVD else snd ACK -> ESTABLISHED The "allow4way" and "continue4way" decisions are based on the contents of the inbound packet. Instead of overloading the SYN-SENT state and burying the decisions in the existing LISTEN and SYN-SENT states, the state diagram could be expanded with one new state, SYN-ACK-SENT, and two transitional states, ALLOW-4WAY and CONTINUE-4WAY. These *-4WAY states are transitional because once entered, an immediate decision is made and then they are immediately exited to a new state. The LISTEN -> SYN-RCVD transition is replaced by: LISTEN -> rcv SYN -> ALLOW-4WAY ALLOW-4WAY(YES) -> snd SYN,ACK -> SYN-ACK-SENT ALLOW-4WAY(NO) -> snd SYN,ACK -> SYN-RCVD SYN-ACK-SENT -> rcv SYN,ACK, snd ACK -> ESTABLISHED SYN-ACK-SENT -> rcv ACK of SYN, x -> ESTABLISHED TCPM Expires April 14, 2015 [Page 5] Internet-Draft TCP Four-Way Handshake October 2014 and the SYN-SENT -> ESTABLISHED transition is replace by: SYN-SENT -> rcv SYN,ACK -> CONTINUE-4WAY CONTINUE-4WAY(YES) -> snd SYN,ACK -> SYN-RCVD CONTINUE-4WAY(NO) -> snd ACK -> ESTABLISHED 3.3 Three-Way or Four-Way Handshake? There are two new decision points for for handling a four-way handshake. First, when a connection in LISTEN state receives a SYN packet, it has to decide based on the contents of that packet whether or not the remote side understands the four-way handshake. This is accomplished through the allocation of one of the unused bits in the TCP header, the 4WAY bit. Note: Other ways to convey support for the four-way handshake were considered, these are discussed in Appendix B. The client sets the 4WAY bit in the initial SYN. If the server receives a 4WAY bit in the initial SYN, then it will set the 4WAY bit in the SYN/ACK. If the client recieves a SYN/ACK without the 4WAY bit set, it proceeds with the normal three-way handshake. If it receives a SYN/ACK with the 4WAY bit set, then based on the options in the SYN/ACK it can chose to either proceed with the normal three- way handshake, or to continue with the four-way handshake. If a packet is received with the 4WAY bit set, but not the SYN bit, the 4WAY bit is ignored. When sending a packet without the SYN bit set, the 4WAY bit must not be set. [RFC3168] notes TCP interoperability issues with the CWR and ECE bits, but the 4WAY bit does not have the same issues. 3.3.1 Non Four-Way Client Sets 4WAY bit In this case, the server might enter SYN-ACK-SENT state. It will respond with a SYN-ACK. Because this looks like the same ACK generated in SYN-RCVD state, it will look to the client like a normal SYN/ACK packet, other than the 4WAY bit, and it will respond with a normal ACK, and the connection will complete with the normal three- way handshake. 3.3.2 Non Four-Way Server Sets 4WAY bit If the client decides to not continue a four-way handshake, then it will respond with an ACK and complete the normal three-way handshake. If the client decides that it does want to continue with a four-way exchange, it'll send a SYN/ACK. When the server receives the packet, the normal TCP processing will strip off the SYN, and continue TCPM Expires April 14, 2015 [Page 6] Internet-Draft TCP Four-Way Handshake October 2014 processing as a normal three-way handshake. 3.4 RTT Costs of the Four-Way Handshake When compared to the three-way handshake, the four-way handshake adds an additional 0.5 RTT before both sides enter ESTABLISHED state. But the more important question is how does the four-way handshake affect the delivery of initial data to the application? This is best answered by looking at some specific cases, comparing the three-way handshake with the four-way handshake. Data can be sent on a SYN packet, but it cannot be delivered to the application until entering ESTABLISHED state. Three-way handshake with data sent once in ESTABLISHED: 0.0) SYN -> 0.5) <- SYN/ACK 1.0) Client enters ESTABLISHED ACK w/client data -> 1.5) Server enters ESTABLISHED, delivers client data. <- Server data 2.0) Client delivers server data Four-way handshake with data sent once in ESTABLISHED: 0.0) SYN -> 0.5) <- SYN 1.0) SYN/ACK-> 1.5) Server enters ESTABLISHED state ACK w/Server data 2.0) Client enters ESTABLISHED state Client delivers server data ACK w/client data -> 2.5) Server delivers client data So in both cases, the server data is delivered at the client after 2 RTTs, and for the four-way the client's data is delivered to the server at 2.5 RTT instead of 1.5 RTT, so 1 RTT later. Now, let's look at both cases with data in the SYN/ACK: Three-way handshake: 0.0) SYN -> 0.5) <- SYN/ACK w/server-data 1.0) Client enters ESTABLISHED Client delivers server-data ACK w/client data -> 1.5) Server enters ESTABLISHED TCPM Expires April 14, 2015 [Page 7] Internet-Draft TCP Four-Way Handshake October 2014 Server delivers client-data. Four-way handshake: 0.0) SYN -> 0.5) <- SYN 1.0) SYN/ACK with client-data -> 1.5) Server enters ESTABLISHED Server delivers client-data <- ACK w/server data 2.0) Client enters ESTABLISHED Client delivers server-data. You get the same differences, but reversed. The client's data is delivered after 1.5 RTTs in both cases, and the servers data is delivered 1 RTT later, at 2.0 RTT instead of 1.0 RTT. If you put the data with the bare SYN, the initial data doesn't get delivered any sooner, because you still have to wait for the ACK of the SYN to deliver the data. 4. Negotiating Non-directional vs. Directional TCP Options TCP options that are negotiated in the initial SYN exchange can be classified as either non-directional or directional. An example of a non-directional option is the TCP Window Scale option. Negotiating a non-directional TCP option falls naturally into the Four-Way handshake, but allows for more options to be negotiated than will fit into the initial SYN packet when using expanded TCP option space. In order to allow this, the SYN/ACK from the server, with the TCP Extended Data option (EDO) [EDO], can contain initial negotiation for TCP options that weren't received in the initial SYN, which the client can then acknowledge in its SYN/ACK, using the EDO option. Because the options are non-directional, it doesn't matter which side presents it first. Directional options do not fall as cleanly into the extended four-way handshake. A directional option is one which is originated in the initial SYN, and the servers response in the SYN/ACK is determined in direct response to the inbound option. For example, assume an option FOO that has 100 variants, where servers typically have support for all 100 variants, but clients usually only a small number. The client sends option FOO with a short list of variants that it supports, and then the server chooses which one of those to use, and responds with that variant. If instead the server initiates the the option in the SYN/ACK, it'd have to include all 100 variants and let the client choose from that list. In the future, new TCP options would need to be designed to work in the context of the four-way handshake. For existing directional options, it would not be unreasonable to require that they be included in the initial SYN, and TCPM Expires April 14, 2015 [Page 8] Internet-Draft TCP Four-Way Handshake October 2014 other non-directional options would be deferred and negotiated in the SYN/ACK exchange. 5. TCP Connection State Diagram The following diagram is modified from the diagram in RFC 793 [RFC793]. In addition to adding the "ALLOW 4WAY?", "CONTINUE 4WAY?" and "SYN-ACK SENT" states, it also includes the three changes listed in RFC 1122 [RFC1122]: "(a) The arrow from SYN-SENT to SYN-RCVD should be labeled with "snd SYN,ACK", to agree with the text on page 68 and with Figure 8. (b) There could be an arrow from SYN-RCVD state to LISTEN state, conditioned on receiving a RST after a passive open (see text page 70). (c) It is possible to go directly from FIN-WAIT-1 to the TIME-WAIT state (see page 75 of the spec)." TCPM Expires April 14, 2015 [Page 9] Internet-Draft TCP Four-Way Handshake October 2014 TCP Connection State Diagram +--------+ --------\ | CLOSED |<------\ \ active OPEN +--------+ \ \ ----------- passive OPEN | ^ CLOSE \ \ create TCB ------------ | | ---------- \ \ snd SYN create TCB V | delete TCB \ \ +--------+ \ \ rcv SYN | LISTEN | CLOSE \ \ ------- +--------+ ---------- \ | +-------------+ x / ^ | SEND delete TCB | V | ALLOW 4WAY? |<------------- | | ------- +---------+ | |------------ | \ snd SYN | | +-------------+ YES \ | ------------------>| SYN | | NO ----------- | | ---------------| SENT | | ----------- snd SYN,ACK | \ / rcv SYN | | | snd SYN,ACK V \ | ----------- | | | +--------------+ \ | snd SYN,ACK +---------+ | | SYN-ACK SENT | \ | rcv SYN,ACK | | +--------------+ | | ----------- | | rcv SYN,ACK | | rcv ACK of SYN | | x V | ----------- | | -------------- | | +----------------+ | snd ACK | \ x | | | CONTINUE 4WAY? | V \ ----------- | | -----| | +---------+ ----------- \ | | / +----------------+ | | rcv RST \ | / | | YES | NO | SYN |----------------------)-)- / | ----------- | ------- | RCVD |<---------------------)-)--- / snd SYN,ACK | snd ACK | |<---------------------)-)------ / | |------------------ | | ------------------- +---------+ rcv ACK of SYN \ | | / | CLOSE -------------- V V V V | ------- x CLOSE +-------------+ rcv FIN V snd FIN ------- | ESTABLISHED | ------- +---------+ +--------+ snd FIN | | snd ACK | CLOSE | | FIN |<------------------| |-------------->| WAIT | | WAIT-1 |----------------- +-------------+ | | | |-------- \ +---------+ +--------+ \ ------------------+ rcv FIN CLOSE | | rcv ACK of FIN | | ------- ------- | | -------------- | rcv FIN,ACK of FIN V snd ACK snd FIN V V x | ------------------ +---------+ +----------+ +-----------+ | x | CLOSING | | LAST-ACK | | FINWAIT-2 | | +---------+ +----------+ +-----------+ | rcv ACK of FIN | rcv ACK of FIN | | rcv FIN | -------------- | -------------- | | ------- \ x V x V \ snd ACK --------->+-----------+ Timeout=2MSL +--------+ --------------------------->| TIME WAIT |-------------->| CLOSED | +-----------+ delete TCB +--------+ TCPM Expires April 14, 2015 [Page 10] Internet-Draft TCP Four-Way Handshake October 2014 6. IANA Considerations TBD 7. Security Considerations TBD 8. References 8.1 Normative References [RFC793] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989, . 8.2 Informative References [Borman14] Borman, D., "Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt", message to the TCPM mailing list, 22 May 2014, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001, . [RFC7323] Borman, D., Braden, R., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extension for High Performance", RFC 7323, September 2014, . [TFO] Cheng, Y., Jhu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", Work in Progress, draft-ietf-tcpm-fastopen-10.txt, September 2014. TCPM Expires April 14, 2015 [Page 11] Internet-Draft TCP Four-Way Handshake October 2014 [EDO] Joe Touch, J., and W. Eddy, "TCP Extended Data Offset Option", Work in Progress, draft-ietf-tcpm-tcp-edo-01.txt, October 2014. [Kohler04] Kohler, E, "Extended Option Space for TCP" Work in Progress, draft-kohler-tcpm-extopt-00.txt, September 2004. [Touch14] Touch, J., Briscoe, B., and T. Faber, "TCP SYN Extended Option Space in the Payload of a Supplementary Segment", Work in Progress, draft-touch-tcpm-tcp-syn-ext-opt-01.txt, September 2014. [Eddy08] Eddy, W., and A. Langley, "Extending the Space Available for TCP Options", Work in Progress, draft-eddy-tcp-loo-04, July 2008. [Yourtchenko11] Yourtchenko, A., "Introducing TCP Long Options by Invalid Checksum", Work in Progress, draft-yourtchenko- tcp-loic-00.txt, April 2011. [Ramaiah12] Ramaiah, A., "TCP option space extension", Work in Progress, draft-ananth-tcpm-tcpoptext-00.txt, March 2012. [Briscoe14] Briscoe, B., "Extended TCP Option Space in the Payload of an Alternative SYN", Work in Progress, draft-briscoe-tcpm- syn-op-sis-02, September 2014. Appendix A. First Response of the Four-Way Handshake For a connection with ISS values of ISSA from the client and ISSB from the server, three different options for the first server response were considered: (1) SYN(seq=ISSB) (2) SYN(seq=ISSB)/ACK(seq=ISSA-1) (3) SYN(Seq=ISSB)/ACK(seq=ISSA) SYN(seq=ISSB) The original idea for the four-way handshake was to have the server do a simple turn-around of the TCP three-way handshake, by TCPM Expires April 14, 2015 [Page 12] Internet-Draft TCP Four-Way Handshake October 2014 responding to the initial SYN with another bare SYN. Because it had already received a SYN and knows that the client supports the four-way handshake, it could respond with a plain SYN, making use of header modifying options that the client had indicated it supported. This is similar to a a simultaneous open, except the server is able to transition from SYN-SENT to ESTABLISHED instead of going through SYN-RECEIVED state. Enter SYN-SENT SYN(seq=ISSA) -> Enter SYN-SENT <- SYN(seq=ISSB) Enter SYN-RECEIVED SYN(seq=ISSA)/ACK(ISSB) -> Enter ESTABLISHED <- ACK(ISSA) Enter ESTABLISHED The problems with this approach are that it forces the full four- way handshake, and a middle-box in the path might block the returning bare SYN. SYN(seq=ISSB)/ACK(seq=ISSA-1) This response also turns the three-way handshake into something that looks a lot like a simultaneous open, since the ACK does not acknowledge the SYN. The disadvantage is that it also forces a full four-way handshake, since it does not acknowledge the initial SYN. However, this should work better for getting through a middle-box since it is not a bare SYN. But if the middle-box is digging into the TCP packet and tries to verify the ACK field, it might still block this packet since it is not the expected ACK field of the normal three-way handshake. SYN(seq=ISSB)/ACK(seq=ISSA) This response looks like the normal three-way handshake response, which gives the client the ability to choose whether to complete the three-way handshake by sending an ACK(ISSB), or continue the four-way handshake by responding with SYN(seq=ISSA)/ACK(ISSB). The advantage of this option is that it doesn't always force the four-way handshake, and to a middle-box the packets look like the normal TCP packets that it expects to see. The third option offers the least possibility that middle-boxes will block the packets, and also leaves the flexibility for deciding on a three-way or four-way handshake up to the client. Because it is to the client's benefit to have a four-way handshake, it should be the one to decide whether or not the four-way handshake is needed for a TCPM Expires April 14, 2015 [Page 13] Internet-Draft TCP Four-Way Handshake October 2014 particular handshake. Appendix B. Communicating Four-Way Handshake Support Besides allocating a 4WAY bit in the TCP header, two other options were considered for communicating support for the four-way handshake: Create a new 4WAY TCP option This does not have the interoperability issues that the 4WAY TCP bit has, because it is assumed that connections will not send unknown TCP options. The disadvantage of this is that it requires two more bytes out of the TCP option space. Implied support by other TCP options The primary motivation for the four-way handshake is to give the client a second chance to send TCP options in a SYN. This is intended for use with the new TCP EDO option, and the presence of the EDO option could imply support for the four-way handshake. This allows the client to send additional TCP options using the TCP EDO option in a SYN/ACK packet. Acknowledgments TBD Contributors TBD Author's Address David Borman Quantum Corporation 1155 Centre Pointe Drive, Suite 1 Mendota Heights, MN 55120 Phone: (651) 688-4394 Email: david.borman@quantum.com TCPM Expires April 14, 2015 [Page 14]