[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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,
              <http://www.rfc-editor.org/info/rfc1122>.


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, <http://www.ietf.org/mail-
              archive/web/tcpm/current/msg08804.html>.


   [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
              Explicit Congestion Notification (ECN) to IP", RFC 3168,
              September 2001, <http://www.rfc-editor.org/info/rfc3168>.


   [RFC7323] Borman, D., Braden, R., Jacobson, V., and R. Scheffenegger,
              Ed., "TCP Extension for High Performance", RFC 7323,
              September 2014, <http://www.rfc-editor.org/info/rfc7323>.


   [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]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/