One document matched: draft-briscoe-tcpm-syn-op-sis-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced. 
    An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC0793 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5925 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml">
<!ENTITY RFC6824 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6824.xml">
<!ENTITY RFC6994 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6994.xml">
<!ENTITY I-D.ietf-tcpm-fastopen SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tcpm-fastopen.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="exp" docName="draft-briscoe-tcpm-syn-op-sis-00"
     ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN" 
    they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
       full title is longer than 39 characters -->

    <title abbrev="Ext TCP Options in an Alt SYN Payload">Extended TCP Option
    Space in the Payload of an Alternative SYN</title>

    <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
      <organization>BT</organization>

      <address>
        <postal>
          <street>B54/77, Adastral Park</street>

          <street>Martlesham Heath</street>

          <city>Ipswich</city>

          <code>IP5 3RE</code>

          <country>UK</country>
        </postal>

        <phone>+44 1473 645196</phone>

        <email>bob.briscoe@bt.com</email>

        <uri>http://bobbriscoe.net/</uri>
      </address>
    </author>

    <date day="21" month="July" year="2014"/>

    <area>Transport</area>

    <workgroup>TCP Maintenance and Minor Extensions (tcpm)</workgroup>

    <keyword>Internet-Draft</keyword>

    <keyword>I-D</keyword>

    <abstract>
      <t>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. In this method the TCP client sends two
      alternative SYNs: one intended for legacy servers and one intended for
      upgraded servers. Once it establishes which type of server has
      responded, it continues the connection appropriate to that server type
      and aborts the other. The SYN intended for upgraded servers includes
      additional options at the end of the payload.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document describes an experimental method to extend the option
      space available in the initial SYN segment of a TCP connection (i.e. SYN
      set and ACK not set) <xref target="RFC0793"/>. This extension is
      required to support some combinations of TCP options, notably large ones
      such as TCP AO <xref target="RFC5925"/> (16B), Multipath TCP <xref
      target="RFC6824"/> (12B), and TCP Fast Open <xref
      target="I-D.ietf-tcpm-fastopen"/> (6-18B) as well as other options
      already typically used in TCP connections, such as SACK-ok (2B),
      Timestamp (10B), Window Scale (3B), MSS (4B) .</t>

      <t>In this method the TCP client sends two alternative SYNs: one
      intended for legacy servers and one intended for upgraded servers. Once
      it establishes which type of server has responded, it continues the
      connection appropriate to that server type and aborts the other. The SYN
      intended for upgraded servers includes additional options at the end of
      the payload.</t>

      <section title="Scope">
        <t>This experimental specification extends the TCP wire protocol. It
        is independent of the dynamic behaviour of TCP and it is independent
        of (and thus compatible with) any protocol that encapsulates TCP,
        including IPv4 and IPv6.</t>
      </section>

      <section anchor="accecn_Expt_Goals" title="Experiment Goals">
        <t>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 provides extra option space on the initial TCP SYN segment. 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 previous version of
        TCP, and with various commonly deployed middleboxes).</t>

        <t><list style="hanging">
            <t hangText="Success criteria: ">The experimental protocol will be
            considered successful if it satisfies the following requirements
            in the consensus opinion of the IETF tcpm working group. {ToDo:
            describe success criteria}</t>

            <t hangText="Duration: ">To be credible, the experiment will need
            to last at least 12 months from publication of the present
            specification. If successful, a report on the experiment will be
            written up. it would then be appropriate to work on a standards
            track specification, in which the experiment report may be
            included.</t>
          </list></t>
      </section>

      <section title="Terminology">
        <t>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 <xref
        target="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.</t>
      </section>
    </section>

    <section anchor="synopsis_Protocol_Spec" title="Protocol Specification">
      <t>In this method the TCP client sends two alternative SYNs: a regular
      SYN intended for legacy servers and SYN-U intended for upgraded servers.
      Once it establishes which type of server has responded, it continues the
      connection appropriate to that server type and aborts the other. The SYN
      intended for upgraded servers (SYN-U) includes additional options at the
      end of the payload.</t>

      <t><xref target="synopsis_tab_3whs-overview"/> summarises the TCP 3-way
      handshake exchange for each of the two SYNs between an upgraded TCP
      (active opening) client and either i) a legacy server or ii) an upgraded
      server.</t>

      <texttable anchor="synopsis_tab_3whs-overview"
                 title="Overview of 3-Way Handshakes for the Two Alternative SYNs in Two Server Scenarios">
        <ttcol/>

        <ttcol>Legacy Server</ttcol>

        <ttcol>Legacy Server</ttcol>

        <ttcol>Upgraded Server</ttcol>

        <ttcol>Upgraded Server</ttcol>

        <c>1</c>

        <c>SYN</c>

        <c>SYN-U</c>

        <c>SYN</c>

        <c>SYN-U</c>

        <c>2</c>

        <c>SYN/ACK</c>

        <c>SYN/ACK</c>

        <c>SYN/ACK</c>

        <c>SYN/ACK-U</c>

        <c>3</c>

        <c>ACK</c>

        <c>RST</c>

        <c>Wait for SYN/ACK-U</c>

        <c>ACK</c>

        <c>4</c>

        <c>Cont...</c>

        <c/>

        <c>RST</c>

        <c>Cont...</c>
      </texttable>

      <t>{ToDo: explain the table long-hand.} </t>

      <t>The SYN-U is structured as shown in <xref
      target="synopsis_SYN-U-stealth"/>. It can be seen that TCP options are
      placed at the end of the payload at an offset from the start of the
      payload defined using the Extra Options Offset (EOO) field. </t>

      <t>The EOO field is read from a new 'SYN-OP-SYS' TCP option defined in
      this specification. The SYN-OP-SIS TCP options MUST be the final TCP
      option right-aligned at the end of the payload (preceded by padding if
      necessary), so that the server can find it (using the length of the
      whole segment found in the main TCP header). </t>

      <figure align="center" anchor="synopsis_SYN-U-stealth"
              title="The Structure of a SYN-U segment">
        <artwork><![CDATA[                      | EOO     | EOO1      |
                      --------->----------->|
+---------+-----------+---------+-----------+-----------+------------+
| TCP hdr | TCP-Opt#2 | Payload | TCP-Opt#1 | TCP-Opt#3 | SYN-OP-SIS |
+---------+-----------+---------+-----------+-----------+------------+

]]></artwork>
      </figure>

      <t>In general, the SYN-OP-SIS TCP option can have different lengths for
      different purposes. However, in a SYN-U, the SYN-OP-SIS TCP option MUST
      have Length = 8, so that the server can find where it starts (8 octets
      before the end of the segment). The internal structure of the SYN-OP-SIS
      TCP option is defined in <xref
      target="synopsis_SYN-OP-SIS-stealth"/>.</t>

      <figure align="center" anchor="synopsis_SYN-OP-SIS-stealth"
              title="SYN-OP-SIS TCP Option for a SYN-U">
        <artwork><![CDATA[+---------------+---------------+-------------------------------+
| Kind=SYNOPSYS | Length=8      | Magic Number                  |
+---------------+---------------+---------------+---------------+
| Magic Number (cont)           | EOO           | EPOO          |
+---------------+---------------+---------------+---------------+

]]></artwork>
      </figure>

      <t>The SYN-OP-SYS TCP option has Kind SYN-OP-SIS, with a value (TBA)
      (See <xref target="IANA"/>) and Length = 8. The first 4 octets of the
      option contain a magic number (TBA) to reduce the chance that arbitrary
      data within the payload will be mistaken for a SYN-OP-SYS TCP
      option.</t>

      <t>It is recognised that it is potentially dangerous to use probability
      to determine whether TCP options are hidden within the payload. This
      approach has been taken to ensure that the SYN-U is largely
      indistinguishable from a regular SYN, in order to maximise the chances
      of traversing middleboxes. If this 'stealth' approach is not preferred,
      an alternative mode conventional protocol design is provided in <xref
      target="synopsis_Alt_Spec"/>.</t>

      <t>Two single octet offset fields are placed at the end of the TCP
      option:<list style="hanging">
          <t hangText="The Extra Options Offset (EOO):">The EOO field defines
          the offset in 4-octet words from the start of the payload to the
          start of the first extra TCP option at the end of the payload. If a
          payload is not required, EOO will be zero. </t>

          <t hangText="The Extra Prefix Options Offset:">The EPOO field
          defined an additional offset from the start of the extra TCP options
          in order to identify any extra TCP options that need to be processed
          before any regular TCP options in the SYN-U. The EPOO field defines
          this offset in 4-octet words.</t>
        </list></t>

      <t>An upgraded server processes the TCP options in a SYN-U in the
      following order:<list style="numbers">
          <t>The Prefix TCP options (TCP-Opt#1 in <xref
          target="synopsis_SYN-U-stealth"/>)</t>

          <t>The regular TCP options following the main header but before the
          payload (TCP-Opt#2 in <xref target="synopsis_SYN-U-stealth"/>);</t>

          <t> The Suffix TCP options (TCP-Opt#3 in <xref
          target="synopsis_SYN-U-stealth"/>)</t>
        </list></t>
    </section>

    <section title="Acknowledgements">
      <t>The idea of this approach grew out of discussions with Joe Touch
      while developing draft-touch-tcpm-syn-ext-opt, and with Janar Iyengar
      and Olivier Bonaventure.</t>

      <t>Bob Briscoe was 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.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo will include a request to IANA for a new TCP option kind
      SYNOPSIS.</t>

      <t>This specification requires IANA to allocate one value from the TCP
      option Kind name-space, against the name "Sister SYN Options
      (SYN-OP-SIS)"</t>

      <t>Early implementation before the IANA allocation MUST follow <xref
      target="RFC6994"/> and use experimental option 254 and magic number
      0xHHHH (16 bits) {ToDo TBA and register this with IANA}, then migrate to
      the new option after the allocation.</t>

      <t/>
    </section>

    <section anchor="Security" title="Security Considerations"/>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->

      &RFC0793;

      &RFC2119;

      &RFC6994;
    </references>

    <references title="Informative References">
      &RFC5925;

      &RFC6824;

      &I-D.ietf-tcpm-fastopen;
    </references>

    <section anchor="synopsis_Alt_Spec"
             title="Alternative (Deterministic) Protocol Specification">
      <t>This appendix is informative and will be deleted before publication.
      It documents an alternative protocol arrangement that may be considered
      instead of that in <xref target="synopsis_Protocol_Spec"/>. It is termed
      'deterministic' because it uses a more conventional approach for
      placement of the SYN-OP-SIS TCP option instead of the probabilistic
      approach in <xref target="synopsis_Protocol_Spec"/> However, it is
      likely to be less practical, given it uses TCP options in the clear,
      hoping that they will traverse middleboxes, which will not always be
      successful.</t>

      <t>This method is similar in structure to the more robust method in
      <xref target="synopsis_Protocol_Spec"/>. The TCP client still sends two
      alternative SYNs: SYN-L intended for legacy servers and SYN-UD intended
      for upgraded servers. Once the client establishes which type of server
      has responded, it continues the connection appropriate to that server
      type and aborts the other. The SYN intended for upgraded servers
      (SYN-UD) includes additional options at the end of the payload. </t>

      <t>Table <xref target="synopsis_tab_3whs-overview-naive"/> summarises
      the TCP 3-way handshake exchange for each of the two SYNs between an
      upgraded TCP (active opening) client and either i) a legacy server or
      ii) an upgraded server.</t>

      <texttable anchor="synopsis_tab_3whs-overview-naive"
                 title="Overview of 3-Way Handshakes for the Two Alternative SYNs in Two Server Scenarios">
        <ttcol/>

        <ttcol>Legacy Server</ttcol>

        <ttcol>Legacy Server</ttcol>

        <ttcol>Upgraded Server</ttcol>

        <ttcol>Upgraded Server</ttcol>

        <c>1</c>

        <c>SYN-L</c>

        <c>SYN-UD</c>

        <c>SYN-L</c>

        <c>SYN-UD</c>

        <c>2</c>

        <c>SYN/ACK</c>

        <c>SYN/ACK</c>

        <c>SYN/ACK-L; Discard state</c>

        <c>SYN/ACK-U</c>

        <c>3</c>

        <c>ACK</c>

        <c>RST</c>

        <c>Discard SYN/ACK-L</c>

        <c>ACK</c>

        <c>4</c>

        <c>Cont...</c>

        <c/>

        <c/>

        <c>Cont...</c>
      </texttable>

      <t>{ToDo: explain the table long-hand.}</t>

      <t>In contrast to the more robust method, the SYN intended for a legacy
      server is different from a regular SYN, hence it is called a SYN-L. The
      SYN-L is merely a SYN with with an extra SYN-OP-SIS flag option as shown
      in <xref target="synopsis_SYN-L"/>. It merely identifies that the SYN is
      from a client that supports SYN-OP-SIS TCP options. </t>

      <figure align="center" anchor="synopsis_SYN-L"
              title="A SYN-OP-SIS flag TCP option">
        <artwork><![CDATA[+---------------+---------------+
| Kind=SYNOPSYS | Length=2      |
+---------------+---------------+

]]></artwork>
      </figure>

      <t>The structure of a deterministic SYN-UD segment is more conventional
      than the the SYN-U in <xref target="synopsis_Protocol_Spec"/>, as shown
      in <xref target="synopsis_SYN-UD"/>. It can be seen that TCP options are
      placed at the end of the payload at an offset from the start of the
      payload defined using the Extra Options Offset (EOO) field.</t>

      <t>The EOO field is read from a new 'SYN-OP-SYS' TCP option defined in
      this specification. The SYN-OP-SIS TCP options is placed in the regular
      TCP option space of the SYN-UD.</t>

      <figure align="center" anchor="synopsis_SYN-UD"
              title="The Structure of an alternative (deterministic) SYN-UD segment">
        <artwork><![CDATA[                                               | EOO     |
                                               --------->|
+---------+-----------+------------+-----------+---------+-----------+
| TCP hdr | TCP-Opt#1 | SYN-OP-SIS | TCP-Opt#3 | Payload | TCP-Opt#2 |
+---------+-----------+------------+-----------+---------+-----------+

]]></artwork>
      </figure>

      <t>The SYN-OP-SYS TCP option for a SYN-UD segment MUST have Kind
      SYN-OP-SIS, with a value (TBA) (See <xref target="IANA"/>) and Length =
      3. In general, the SYN-OP-SIS TCP option can have different lengths for
      different purposes. However, in a SYN-UD, the SYN-OP-SIS TCP option has
      Length = 3, so that it can carry the 1-octet EOO field, which MUST be
      present in a SYN-UD. The internal structure of the SYN-OP-SIS TCP option
      for a SYN-UD segment is defined in <xref
      target="synopsis_SYN-OP-SIS-naive"/>.</t>

      <figure align="center" anchor="synopsis_SYN-OP-SIS-naive"
              title="SYN-OP-SIS TCP Option for a deterministic SYN-UD">
        <artwork><![CDATA[+---------------+---------------+---------------+
| Kind=SYNOPSYS | Length=3      | EOO           |
+---------------+---------------+---------------+

]]></artwork>
      </figure>

      <t>The Extra Options Offset (EOO) field defines the offset in 4-octet
      words from the start of the payload to the start of the first extra TCP
      option at the end of the payload. If a payload is not required, EOO will
      be zero, but it MUST still be present.</t>

      <t>An upgraded server processes the TCP options in a SYN-UD in the
      following order:<list style="numbers">
          <t>The regular TCP options following the main header but before the
          SYN-OP-SIS TCP option (TCP-Opt#1 in <xref
          target="synopsis_SYN-UD"/>)</t>

          <t>The TCP options at the end of the payload (TCP-Opt#2 in <xref
          target="synopsis_SYN-UD"/>)</t>

          <t>The regular TCP options following the main header but after the
          SYN-OP-SIS TCP option (TCP-Opt#3 in <xref
          target="synopsis_SYN-UD"/>);</t>
        </list></t>
    </section>
  </back>
</rfc>