TCP SYN Extended Option Space in the Payload of a Supplementary Segment
draft-touch-tcpm-tcp-syn-ext-opt-00

TCPM WG                                                        J. Touch
Internet Draft                                                  USC/ISI
Intended status: Experimental                                B. Briscoe
Expires: January 2015                                                BT
                                                               T. Faber
                                                                USC/ISI
                                                          July 20, 2014

                       TCP SYN Extended Option Space
                 in the Payload of a Supplementary Segment
                  draft-touch-tcpm-tcp-syn-ext-opt-00.txt

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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on January 20, 2015.

Copyright Notice

   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

Touch                  Expires January 20, 2015                [Page 1]
Internet-Draft   TCP SYN Extended Offset Space Option         July 2014

   carefully, as they describe your rights and restrictions with
   respect to this document.

Abstract

   This document describes an experimental method to extend the option
   space for connection parameters within the initial TCP SYN segment,
   at the start of a TCP connection. This method effectively extends
   the option space of an initial SYN by using an additional coupled
   segment. It complements the proposed Extended Data Offset (EDO)
   option that is applicable only after the initial segment.

Table of Contents

   1. Introduction...................................................3
   2. Conventions used in this document..............................3
   3. Experiment Goals...............................................3
   4. Using Multiple Segments to Establish a Connection..............4
   5. The TCP SYN-EOS Option.........................................5
      5.1. SYN-EOS OOB...............................................6
      5.2. SYN-EOS DS................................................7
      5.3. Interaction with EDO.....................................12
   6. Issues........................................................12
      6.1. Common Issues............................................12
         6.1.1. Option processing order and duplication:............13
      6.2. OOB Issues...............................................14
      6.3. DS Issues................................................14
      6.4. Meddlebox Transit Issues ;-).............................15
   7. TCP SYN-EOS Interaction with TCP..............................15
      7.1. TCP User Interface.......................................15
      7.2. TCP States and Transitions...............................15
      7.3. TCP Segment Processing...................................16
      7.4. Impact on TCP Header Size................................16
   8. Connectionless Resets.........................................16
      8.1. ICMP Handling............................................16
   9. Interactions with Middleboxes.................................16
   10. Security Considerations......................................16
   11. IANA Considerations..........................................16
   12. References...................................................16
      12.1. Normative References....................................16
      12.2. Informative References..................................17
   13. Acknowledgments..............................................17

Touch                  Expires January 20, 2015                [Page 2]
Internet-Draft   TCP SYN Extended Offset Space Option         July 2014

1. Introduction

   This document describes a method to extend the option space
   available in the initial SYN segment of a TCP connection (e.g., SYN
   set and ACK not set) [RFC793]. This extension is required to support
   some combinations of TCP options, notably large ones such as TCP AO
   [RFC5925], Multipath TCP [RFC6824], and TCP Fast Open [Ch14] with
   other options already typically used in most TCP connections. This
   document specifies this TCP SYN Extended Offset Space (SYN-EOS)
   option, and is independent of (and thus compatible with) IPv4 and
   IPv6. SYN-EOS complements the proposed TCP Extended Data Offset
   (EDO) option, which increases the space available for options in all
   segments except the initial SYN [To14].

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

   In this document, the characters ">>" preceding an indented line(s)
   indicates a compliance requirement statement using the key words
   listed above. This convention aids reviewers in quickly identifying
   or finding the explicit compliance requirements of this RFC.

3. Experiment Goals

   TCP is critical to the robust functioning of the Internet, therefore
   any proposed modifications to TCP need to be thoroughly tested.  The
   present specification describes an experimental protocol that
   initiates a connection using two coupled segments instead of the
   traditional single one. The intention is to specify the protocol
   sufficiently so that more than one implementation can be built in
   order to test its function, robustness, and interoperability with
   itself, with other variants of TCP and with common network
   equipment, whether standardized or not.

   The following describe the criteria that define success for this
   experiment and its expected duration.

   Success criteria: The experimental protocol will be considered
   successful if, in the consensus opinion of the IETF, it functions
   correctly in a sufficiently wide scope to be useful and it does no

Touch                  Expires January 20, 2015                [Page 3]
Internet-Draft   TCP SYN Extended Offset Space Option         July 2014

   harm, which implies that it ought to introduce minimal additional
   delay or load to either updated or existing implementations and it
   introduces no new security vulnerabilities. It is also required not
   to be unduly difficult or complex to implement correctly, so that it
   is not likely to lead to additional bugs or vulnerabilities.

   Duration: To be credible, the experiment will need to last at least
   12 months from publication of the present specification.  At that
   time, a report on the experiment will be written up.  If successful,
   it would then be appropriate to work on a standards track
   specification.

4. Using Multiple Segments to Establish a Connection

   The basis of SYN-EOS is the use of multiple TCP segments to initiate
   a TCP connection. It is also possible to extend initial SYN option
   space using context established from prior connections or using
   separate TCP connections (e.g., using the FTP control channel), this
   document focuses on mechanisms that apply to any connection
   (including the first between two hosts) and do not require prior or
   established concurrent TCP connections.

   There are four examples of approaches:

   o  Send a primary SYN and an extension SYN (LOIC [Yo11])

   o  Send a primary SYN and extension non-SYN data (LO/SLO [Ed08])

   o  Send dual-SYNs: a primary SYN on one port pair and an extension
      SYN on a separate port pair (Dual-SYN or DS, this document)

   o  Send a primary SYN and an extension out-of-band segment (OOB,
      this document)

   All four approaches extend the space available in the initial SYN by
   sending an additional segment during the first phase of the three-
   way handshake. The Long Options by Invalid Checksum (LOIC) approach
   differentiates the two SYNs by using an invalid TCP checksum in the
   extension SYN [Yo11], which thus cannot traverse NAT/NAPT devices
   [RFC3234].

   The LO/SLO approach extends the three-way handshake into a five-way
   handshake to include extra options during the third segment, so the
   traditional SYN/ACK does not complete the active connection [Ed08].
   In current implementations, the client TCP state machine transitions
   to the ESTABLISHED state upon receipt of the SYN/ACK (including
   transmission of the resulting ACK). In SLO, additional options sent

Touch                  Expires January 20, 2015                [Page 4]
Internet-Draft   TCP SYN Extended Offset Space Option         July 2014

   during the third segment are treated as part of the initial SYN and
   the fourth segment with responses to these options is treated as
   part of the conventional SYN/ACK. As with conventional TCP, data can
   be sent during this handshake as part of any segment, but this data
   needs to wait for the entire handshake to complete before being
   forwarded to the application to ensure that all options have been
   negotiated successfully. This adds an additional round trip of
   latency which is undesirable in many cases. Connection-splitting
   middleboxes that merge these segments might also cause long options
   to be interpreted as data.

   The remainder of this document presents the DS and OOB approaches,
   both of which are believed overcome these limitations.

5. The TCP SYN-EOS Option

   >>>>>>>> WG NOTE:

   The SYN-EOS mechanism can rely on either the DS or OOB approaches.
   As a result, both are presented here until the TCPM WG makes a
   decision whether one is preferred or both should be part of the
   experiment for different environments.

   <<<<<<<< END WG NOTE.

   The SYN-EOS OOB approach uses a primary conventional SYN and an
   additional out-of-band data segment, the latter being a non-SYN
   packet with the ACK flag not set.

   The SYN-EOS DS approach uses two separate conventional SYNs using
   the same IP addresses and destination port, in which the particular
   option indicates which is primary and which is supplemental to
   provide additional option space.

   Additional options are placed in payload of the supplementary
   segment. This offers the following advantages:

   1. It provide expansion space for options on a SYN, limited only by
      the default maximum segment size (535 payload bytes for IPv4);

   2. It reduces the chances that middleboxes will alter the extra
      options, given there is a higher bar to altering the payload than
      header fields.

   3. It allows for future structured ways to hide extra options from
      middleboxes and/or to protect them from being altered.

Touch                  Expires January 20, 2015                [Page 5]
Internet-Draft   TCP SYN Extended Offset Space Option         July 2014

   Behaviors common to both approaches are described after the aspects
   that are unique to each approach.

5.1. SYN-EOS OOB

   A client initiating a TCP connection (i.e., issuing an active open)
   uses the SYN-EOS out-of-band (OOB) option flag to indicate the
   presence of the extended option space (Figure 1). This follows the
   TCP option format, where Kind is SYN-EOS-OPT and Length is 2.

                            +--------+--------+
                            |  Kind  | Length |
                            +--------+--------+

                      Figure 1 TCP SYN-EOS OOB option

   An upgraded client supporting this feature uses this option only
   when the space needed for options in the initial SYN exceeds that of
   legacy TCP. When needed, the client sends the SYN-EOS OOB option in
   the initial SYN, together with whatever other options are intended
   for connections to legacy servers (i.e., passive listeners). A
   legacy server would respond with a SYN/ACK without the SYN-EOS OOB
   option, while also confirming other supported options, and the
   connection would proceed without the SYN-EOS extension.

   The upgraded client that sends the initial SYN using this option
   also sends an out-of-band (OOB) data segment with the same option to
   the same source and destination addresses and ports as the initial
   SYN. An OOB data segment is herein defined as a TCP segment in which
   neither SYN nor ACK flag is set. In particular, this looks like a
   conventional data segment with the ACK field cleared. Current TCP
   requirements allow the ACK field to be cleared for only the initial
   SYN, so this segment looks like a data segment that has been
   transmitted 'out-of-band', before a connection has been established.
   The entire payload of the segment is used for additional options.

   Upgraded servers that receive the TCP SYN with the SYN-EOS OOB
   option wait for the corresponding OOB segment and treat the entire
   set of options in both segments as if they arrived with the initial
   SYN. Once both have arrived, the server first processes TCP options
   placed before each SYN-EOS OOB option, applying them solely to their
   own individual segment. Then the server marshals together all the
   TCP options placed after each SYN-EOS OOB option. It applies them to
   the initial SYN only, as if they had all been concatenated after the
   SYN-EOS OOB option.

Touch                  Expires January 20, 2015                [Page 6]
Internet-Draft   TCP SYN Extended Offset Space Option         July 2014

   >> The server MUST process the options placed after each SYN-EOS OOB
   option in the following order:

   1. Those in the option space of the initial SYN

   2. Those in the option space of the OOB segment

   3. Those in the payload space of the OOB segment

   The upgraded server proceeds with the remainder of the connection as
   if the SYN-EOS OOB option were a also EDO request option [To14] in
   the SYN.

   >> The SYN/ACK MUST include the SYN-EOS OOB option to confirm the
   server's support for both the SUN-EOS and EDO capabilities and to
   confirm receipt of both the SYN and OOB segment. The server MAY also
   extend the options space of the SYN/ACK using the EDO option if
   needed.

   >> Any host that supports SYN-EOS OOB MUST also thus support EDO.

   >> The OOB segment MUST use the same sequence number as the initial
   SYN.

   >> The client MUST NOT send multiple different OOB segments. If the
   server receives more than one OOB segment for the same connection it
   MUST solely use the first.

5.2. SYN-EOS DS

   The SYN-EOS dual-SYN (DS) option operates nearly identically to the
   OOB option, with two important differences:

   1. Instead of the client using an OOB data segment, it uses a second
      SYN for additional option space, sent using the same source and
      destination IP addresses and destination port but with a
      different source port.

   2. Instead of using a simple option flag, an additional
      Connection_ID field is required to correlate the two SYNs.

   The two SYNs of the SYN-EOS DS option are defined as:

   o  SYN-D: the initial SYN that initiates the TCP (data) connection

   o  SYN-C: the SYN with (control) options in its payload that that
      augment the option space in SYN-D

Touch                  Expires January 20, 2015                [Page 7]
Internet-Draft   TCP SYN Extended Offset Space Option         July 2014

   The SYN-EOS DS option appears in both the SYN-D and SYN-C segments,
   and its structure is shown in Figure 2. The length of the
   Connection_ID (CID) field is shown as 23 bits [NOTE: this has not
   yet been decided]. It needs to be sufficient to pair corresponding
   SYNs using this option. Given there are at most 65K possible
   concurrent connections using the same address pair and destination
   port (e.g., that vary in only source port), one possible lower bound
   on the CID is 16 bits, but longer CIDs might be preferred to protect
   against false positives.

                   +--------+--------+--------+--------+
                   |  Kind  | Length |C| Connection ID |
                   +--------+--------+--------+--------+
                   | con't  |
                   +--------+

                      Figure 2 TCP SYN-EOS DS option

   >> The client MUST write the same Connection-ID within each of the
   coupled SYNs (SYN-C and SYN-D). The client sets the control (C) flag
   on a SYN-C and clears the C flag on a SYN-D to distinguish the two.

   >> The initiating client MUST NOT include any option in the header
   of SYN-C that could cause a legacy server to pass the payload to the
   application (e.g. a TCP Fast-Open cookie to resume a connection).

   Upgraded servers that receive a SYN-D or SYN-C with the SYN-EOS DS
   option wait for the corresponding coupled SYN. Once both have
   arrived, the server first processes TCP options placed before each
   SYN-EOS DS option, applying them solely to their own individual
   segment. Then the server marshals together all the TCP options
   placed after each SYN-EOS DS option. It applies them to the SYN-D
   only, as if they had all been concatenated after the SYN-EOS DS
   option. This order is the same as that for the OOB variant, where
   the SYN-C corresponds to the OOB segment.

   >> The server MUST process the options placed after each SYN-EOS DS
   option in the following order:

   1. Those in the option space of SYN-D

   2. Those in the option space of SYN-C

   3. Those in the payload of the SYN-C

   An upgraded server distinguishes SYN-D from SYN-C by the C flag of
   the SYN-EOS TCP option. It responds to the SYN-D with a single

Touch                  Expires January 20, 2015                [Page 8]
Internet-Draft   TCP SYN Extended Offset Space Option         July 2014

   SYN/ACK that addresses the options in both SYNs, so it does not
   respond explicitly to the SYN-C.

   >> An upgraded server MUST NOT create or hold any connection state
   based on SYN-C, but SHOULD cache SYN-C segments that arrive before
   their corresponding SYN-D segment unless under memory constraints.

   An upgraded server proceeds with the remainder of the connection as
   if the SYN-EOS DS option were also an EDO request option [To14] on
   SYN-D.

   >> The server MUST include the SYN-EOS DS option on the SYN/ACK to
   confirm its support for both the SYN-EOS and the EDO capability and
   to acknowledge receipt of both SYNs. It MAY also extend the option
   space of the SYN/ACK using the EDO option if needed.

   >> A host that supports SYN-EOS DS MUST also support EDO.

   >> A client MUST NOT send send multiple different SYN-C segments. If
   the server receives more than one valid SYN-C segment associated
   with one SYN-D, it MUST solely use the first.

   A legacy server that does not support SYN-EOS will respond to both
   SYNs with two independent SYN-ACKs.

   >> The SYN-EOS client MUST respond to the SYN/ACK corresponding to
   the C-SYN with a connection reset (RST). It responds to the other
   SYN/ACK as normal and proceeds with that connection.

   It might be naively considered that the two SYNs could use the same
   initial sequence number, which would serve the role of a Connection
   ID. However, this approach has not been followed because it would
   not traverse certain middleboxes that do not preserve TCP sequence
   numbers end-to-end.

5.3. Reliable Delivery of Lone Initial Segments

   In both the OOB and the DS cases, the server acknowledges the
   initial segment and the additional initial segment together by using
   a SYN/ACK that carries the appropriate SYN-EOS option. The following
   subsections describe how the server acknowledges initial segments
   after a certain time if only one has arrived.

5.3.1. Reliable Delivery of a lone SYN-EOS OOB

   If an upgraded server has received only a SYN with the SYN-EOS OOB
   option but no corresponding OOB segment, after a certain time it

Touch                  Expires January 20, 2015                [Page 9]
Internet-Draft   TCP SYN Extended Offset Space Option         July 2014

   MUST proceed with the connection as if the SYN had been received
   without the SYN-EOS OOB option. I.e. it processes all other TCP
   options and responds with a SYN/ACK without the SYN-EOS OOB option.

   A client will not be able to tell whether this SYN/ACK is from a
   legacy server or an upgraded server. How the client proceeds on
   receipt of such a SYN/ACK depends on whether it wishes to retry
   sending the TCP options in the OOB segment or to proceed without
   them (e.g. for latency reasons):

   o  >> If the client chooses to proceed without the OOB segment, it
      MUST proceed as if the SYN-EOS OOB option had never been used, by
      sending an ACK to complete the three-way handshake.

   o  >> If the client chooses to retry, it MUST retransmit the OOB
      segment with the same sequence number as the ISN of the SYN, so
      it is still out-of-band. However, this time it sets the ACK flag
      and it sets the acknowledgement number to one greater than the
      sequence number of the SYN/ACK. This effectively acknowledges
      receipt of the SYN/ACK, but requests a fuller SYN/ACK that also
      covers the OOB segment. At this stage a client that has chosen to
      retry the OOB segment MUST NOT send the ACK that would normally
      complete the three-way handshake.

   >> If an upgraded server receives such a retransmitted OOB segment,
   it MUST process the additional TCP options as if they were placed
   after those in the initial SYN. Then it MUST send a SYN/ACK
   containing the SYN-EOS OOB option, as if it had not sent the earlier
   SYN/ACK .

   On receipt of this SYN/ACK, the client sends an ACK to complete the
   handshake.

   >> If an upgraded server receives an ACK to complete the handshake,
   then later receives an OOB segment, it MUST discard the late OOB
   segment.

   >> If a server, whether upgraded or not, receives only an OOB
   segment and no corresponding SYN, it MUST discard it and it MUST NOT
   ever respond (see Security Considerations).

5.3.2. Reliable Delivery of a Lone SYN-D

   >> If an upgraded server has received only a SYN-D with the SYN-EOS
   DS option but no corresponding SYN-C, after a certain time it MUST
   proceed with the connection as if the SYN-D had been received
   without the SYN-EOS DS option. I.e. it processes any TCP options

Touch                  Expires January 20, 2015               [Page 10]
Internet-Draft   TCP SYN Extended Offset Space Option         July 2014

   after the SYN-EOS DS option and responds to the SYN-D with a SYN/ACK
   without the SYN-EOS DS option (to the source port of the SYN-D).

   A client will not be able to tell whether this SYN/ACK is from a
   legacy server or an upgraded server. How the client proceeds on
   receipt of such a SYN/ACK depends on whether it wishes to retry
   sending the TCP options in the SYN-C or to proceed without them
   (e.g. for latency reasons):

   o  >> If the client chooses to proceed without the DS segment, it
      MUST proceed as if the SYN-EOS DS option had never been used, by
      sending an ACK (from the same port as the SYN-D) to complete the
      three-way handshake.

   o  >> If the client chooses to retry, it MUST retransmit the SYN-C
      from the same port and with the same flags and the same initial
      sequence number as it used before . This requests a fuller
      SYN/ACK that also covers the SYN-C. At this stage a client that
      has chosen to retry the SYN-C segment MUST NOT send the ACK that
      would normally complete the three-way handshake.

   >> If an upgraded server receives such a retransmitted SYN-C, it
   MUST process the additional TCP options as if they were placed after
   those in the SYN-D. Then it MUST send a SYN/ACK containing the SYN-
   EOS DS option, as if it had not sent the earlier SYN/ACK.

   On receipt of this SYN/ACK, the client sends an ACK to complete the
   handshake.

   >> If an upgraded server receives an ACK to complete the handshake,
   then later receives a SYN-C, it MUST discard the late SYN-C.

5.3.3. Reliable Delivery of a Lone SYN-C

   >> If an upgraded server receives only a SYN-C and no corresponding
   SYN-D, after a certain time it MUST acknowledge the SYN-C alone to
   elicit a fast retransmission of the SYN-D, because it cannot proceed
   without the SYN-D. It MUST NOT process any of the options after the
   SYN-EOS DS option in the SYN-C. Instead, it MUST send a SYN/ACK with
   the SYN-EOS DS option (to the source port of the SYN-C).

   >> On receipt of such a SYN/ACK on the SYN-C port, if the client has
   not received a SYN/ACK for the SYN-D, it MUST retransmit the SYN-D
   unchanged.

Touch                  Expires January 20, 2015               [Page 11]
Internet-Draft   TCP SYN Extended Offset Space Option         July 2014

   >> If an upgraded server receives such a retransmitted SYN-D, it
   MUST proceed as if the original SYN-D had arrived, and as if it had
   not sent the earlier SYN/ACK.

5.4. Interaction with EDO

   Successful negotiation of either SYN-EOS option has the same effect
   as EDO. Successful SYN-EOS negotiation enables EDO for the remainder
   of the connection.

   >> Segments after the initial SYN MAY use the EDO option.

   Note that a failure to negotiate SYN-EOS has also fails to
   automatically negotiate EDO for endpoints that support EDO but not
   SYN-EOS. As a consequence:

   >> If EDO is desired when SYN-EOS fails, the initial SYN options
   MUST include a separate EDO request option.

   If SYN-EOS is sent in the initial SYN and confirmed in the SYN/ACK,
   EDO is available for the remainder of the connection. Segments that
   need to extend their option space would then include EDO.

   >> If SYN-EOS and EDO are sent in the initial SYN and received by
   SYN-EOS capable server, the server MUST include SYN-EOS in the
   SYN/ACK, and MAY also include EDO also needed to provide additional
   option space.

   >> If the server agrees to EDO but cannot support SYN-EOS, the
   SYN/ACK MUST include EDO as per [To14] to confirm the capability.

6. Issues

   The following issues are known.

6.1. Common Issues

   Caching is required because it is unlikely that both segments
   involved in initiating a SYN-EOS connection will arrive at the same
   time:

   >> Servers supporting SYN-EOS SHOULD cache received initial SYNs
   with the SYN-EOS option. Servers MAY decline to cache received
   initial SYNs if they are under memory constraints.

   >> Servers supporting SYN-EOS SHOULD cache received SYN-C segments
   with the SYN-EOS option. Servers MAY cache received OOB segments but

Touch                  Expires January 20, 2015               [Page 12]
Internet-Draft   TCP SYN Extended Offset Space Option         July 2014

   MUST NOT examine or process them further in any way until their
   corresponding SYN segment arrives.

   Similarly, clients need to be able to retransmit supplements to
   ensure their delivery:

   >> Clients MUST retransmit the supplemental segment any time they
   retransmit the initial SYN segment.

   Should this be a new option or just a variant of EDO, and if so, how
   would it change EDO?

   SYN Cookies: An updated server can achieve the same outcome as SYN
   cookies by putting all the necessary connection state in TCP options
   in the SYN/ACK (using EDO if extra space is needed). It would then
   discard its own copy of this state, which it could recover from the
   TCP options in the final ACK of the 3WHS sent by the client. New TCP
   options complementary to SYN-EOS might need to be defined to achieve
   this for some types of TCP option (TBA). A legacy server will not
   understand the SYN-EOS option whether it uses SYN cookies or not, so
   it will provide the same legacy service whether or not it uses SYN
   cookies.

6.1.1. Option processing order

   TCP options before the EOS-SYN on initial SYN segments are
   necessarily processed individually when each segment arrives. When
   both segments of an EOS-SYN connection establishment arrive, the
   remaining options are processed in the following sequence:

   1. Initial SYN options

   2. Supplement options

   3. Supplement payload

   *** NOTE TO THE WG:

   There are two other constraints that might be applied to the
   supplement options:

   >> I. Supplement options MUST exactly match initial SYN options.

   >> II. Supplement options MUST contain only the SYN-EOS option.

   If either of these is chosen, the supplement options are NOT
   processed again (i.e., they are discarded).

Touch                  Expires January 20, 2015               [Page 13]
Internet-Draft   TCP SYN Extended Offset Space Option         July 2014

   The former constraint helps the supplement segment share the same
   fate as the initial SYN. The latter recognizes that the supplement
   option space is not needed given the supplement payload, because the
   option space is created from the payload space anyway.

   *** END NOTE

6.2. OOB Issues

   Useful to send SYN, wait shortly, then send OOB

   OOB traversal concerns

6.3. DS Issues

   Connection IDs, which could lead to spoof control options being
   applied to a connection.

   Fate sharing Disjoint paths: To network devices, the two SYNs appear
   as if they belong to separate connections. Therefore network
   equipment is more likely to forward them over disjoint paths than
   packets belonging to the same flow. Traversing different paths might
   lead to unpredictably different treatments (e.g., different firewall
   blocking policies, etc.)

   Legacy load balancers could direct the two SYNs to physically
   separate servers. Therefore a site deploying SYN-EOS DS would have
   to either a) upgrade its load balancers to understand the new
   protocol or b) arrange for its servers to redirect coupled SYNs to a
   common server.

   Stack Implementation: Even once both SYNs are directed to the same
   physical stack, the implementation would have to pass information
   between connections, which would run counter to the structure of
   some implementations.

   Impact on connection rate: A server (whether legacy or upgraded)
   will receive (1+p) times as many SYNs, where p is the proportion of
   its clients that have upgraded to use SYN-EOS.

   o  An upgraded server does not create or hold connection state for
      any C-SYN, so its performance impact is limited to the (1+p)
      processing and bandwidth capacity needed, with extra memory only
      required for transient storage during actual processing.

Touch                  Expires January 20, 2015               [Page 14]
Internet-Draft   TCP SYN Extended Offset Space Option         July 2014

   o  A legacy server will usually receive a reset after 1 RTT for the
      additional proportion p of connections, for which it will never
      have entered the established state. Any legacy server
      experiencing a reduction in its ability to serve new connections
      with its given hardware can always upgrade its stack software to
      support SYN-EOS, so at least it will not need to invest in
      upgrading its memory hardware.

6.4. Middlebox Transit Issues

   NB: this variant will require an additional 1-byte field on the SYN-
   EOS option for the EOO field.

   Traversal of middleboxes that ensure the payload matches the
   destination port number. It would be possible to include the
   facility for either the SYN-EOS OOB or the SYN-EOS DS TCP option to
   include an Extra Option Offset (EOO) field. A client setting EOO to
   a non-zero value would offset the start of the additional TCP
   options by this number of 4-byte words from the start of the
   payload.

   >> An upgraded SYN-EOS server MUST start reading the additional TCP
   options from a point within the payload that is offset by this
   number of 4-byte words from the start of the payload. An upgraded
   SYN-EOS server MUST ignore all data in the payload up to this point.

   The client would then be free to include fake data at the start of
   the payload consistent with what a middlebox might expect for the
   destination port in use. The data to use would be application and
   implementation dependent, and is not determined in the present
   specification.

7. TCP SYN-EOS Interaction with TCP

   The following subsections describe how SYN-EOS interacts with the
   TCP specification [RFC793].

7.1. TCP User Interface

   TBD.

7.2. TCP States and Transitions

   TBD.

Touch                  Expires January 20, 2015               [Page 15]
Internet-Draft   TCP SYN Extended Offset Space Option         July 2014

7.3. TCP Segment Processing

   TBD.

7.4. Impact on TCP Header Size

   TBD.

8. Connectionless Resets

   TBD.

8.1. ICMP Handling

   TBD [RFC792].

9. Interactions with Middleboxes

   TBD.

10. Security Considerations

   >> By default, a SYN-EOS OOB server must not cache an OOB segment
   and MUST NOT respond to an OOB segment if it arrives before the
   corresponding SYN segment, because many legacy firewalls will allow
   OOB segments into private networks. Caching of OOB segments MAY be
   enabled explicitly on public servers.

   More TBD.

11. IANA Considerations

   TBD.

   This section is to be removed prior to publication as an RFC.

12. References

12.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
             793, September 1981.

Touch                  Expires January 20, 2015               [Page 16]
Internet-Draft   TCP SYN Extended Offset Space Option         July 2014

   [To14]    Touch, J., W. Eddy, "TCP Extended Data Offset Option",
             draft-touch-tcpm-tcp-edo-03 (work in progress), July 2014.

12.2. Informative References

   [Ch14]    Cheng, Y., Chu, J., and A. Jain, "TCP Fast Open", draft-
             ietf-tcpm-fastopen-09, June 2014.

   [Ed08]    Eddy, W. and A. Langley, "Extending the Space Available
             for TCP Options", draft-eddy-tcp-loo-04 (work in
             progress), July 2008.

   [RFC792]  Postel, J., "Internet Control Message Protocol", RFC 792.

   [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
             Issues", RFC 3234, February 2002.

   [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
             Authentication Option", RFC 5925, June 2010.

   [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
             "TCP Extensions for Multipath Operation with Multiple
             Addresses", RFC 6824, January 2013.

   [Yo11]    Yourtchenko, A., "Introducing TCP Long Options by Invalid
             Checksum", draft-yourtchenko-tcp-loic-00 (work in
             progress), April 2011.

13. Acknowledgments

   The authors would like to thank the IETF TCPM WG for their feedback.

   Bob Briscoe is part-funded by the European Community under its
   Seventh Framework Programme through the Trilogy 2 project (ICT-
   317756). The views expressed here are solely those of the authors.

   This document was prepared using 2-Word-v2.0.template.dot.

Touch                  Expires January 20, 2015               [Page 17]
Internet-Draft   TCP SYN Extended Offset Space Option         July 2014

Authors' Addresses

   Joe Touch
   USC/ISI
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695 USA

   Phone: +1 (310) 448-9151
   Email: touch@isi.edu
   URI:   http://www.isi.edu/touch

   Bob Briscoe
   BT
   B54/77, Adastral Park
   Martlesham Heath
   Ipswich  IP5 3RE
   UK

   Phone: +44 1473 645196
   EMail: bob.briscoe@bt.com
   URI:   http://bobbriscoe.net/

   Ted Faber
   USC/ISI
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695 USA

   Phone: +1 (310) 448-9190
   Email: faber@isi.edu

Touch                  Expires January 20, 2015               [Page 18]