One document matched: draft-yourtchenko-tcp-loic-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.tuexen-sctp-udp-encaps SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tuexen-sctp-udp-encaps.xml">
<!ENTITY rfc4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY rfc1671 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1671.xml">
<!ENTITY rfc2766 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2766.xml">
<!ENTITY rfc3484 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml">
<!ENTITY rfc4966 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4966.xml">
<!ENTITY rfc4074 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4074.xml">
<!ENTITY rfc5245 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY I-D.natarajan-http-over-sctp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.natarajan-http-over-sctp.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc rfcprocack="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="info" docName="draft-yourtchenko-tcp-loic-00" ipr="trust200902">
  <front>
    <title abbrev="TCP LOIC">Introducing TCP Long Options by Invalid Checksum</title>

    <author fullname="Andrew Yourtchenko" initials="A." surname="Yourtchenko">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>De Kleetlaan, 7</street>

          <city>Diegem</city>

          <code>B-1831</code>

          <country>Belgium</country>
        </postal>

        <email>ayourtch@cisco.com</email>
      </address>
    </author>

    <date year="2011" />

    <workgroup>tcpm</workgroup>

    <abstract>
<t>This document discusses a possible approach to TCP option space expansion, which allows placing the long TCP options into the TCP SYN segments.
</t>

    </abstract>
  </front>

<middle>
    <section title="Introduction">
      <t>What this document IS NOT: the definitive guide, the review of the existing solutions, the full description of the option space upgrade, the review of the existing solutions.
      </t>
      <t>What this document IS: a write-up of an idea for a building block to be used as part of a bigger protocol - intended for information purposes and further development only - verifying the feasibility of this approach will need extensive experiments.
      </t>
      <t>
      </t>
    </section>

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

    <section anchor="problem_statement" title="Problem Statement">
<t>
The TCP options are the mechanism which is used to evolve the TCP protocol - thanks to their existence, 
such additions as Selective Acknowledgements and Timestamps [refs tbd] (to name just a couple) were introduced.
However, the space in the TCP segment where the options may be transmitted 
is very scarce and is currently at the borderline of being exhausted. 
This practically blocks any further development in the TCP protocol space.
</t>
<t>
In order for the TCP development to continue, we need a way to dedicate a larger storage space for TCP options within the segment - 
further referred as TCP Long Options.
</t>
<t>
A mechanism for doing that must fulfil at least two prerequisites: transmission of the Long Options within the TCP SYN, and a graceful fallback to the 'legacy' mechanism in case the Long Options can not be used (thus abandoning all of the Long Options).
</t>
<t>
The above two are to certain extent at odds with each other - the SYN is the very first segment within the TCP session, so any drastic change that is misunderstood by the remote party or the middleboxes will cause the segment to be dropped, thus interrupting the communication.
</t>
    </section>
    <section anchor="solution" title="Proposed High-level Approach">
<t>
The proposal is to transmit two SYN segments instead of one, created with different goals in mind: the first one, aimed at backwards compatibility,
would merely signal the sender's desire to use Long Options. The second SYN segment, aimed at the parties that understand the new mechanism, would 
contain the Long Options themselves. The Long Options would be in place where there normally is data (there's simply no other space) - so this
segment, together with the first one, would form a contradiction from the perspective of the TCP protocol, if interpreted by the unaware node.
</t>
<t>
To mitigate the above issue, we can explicitly mark the second SYN as "TCP-invalid". The simplest way to do this is to increment the valid TCP checksum by 2. With such a modification, the second packet will be either dropped by a middlebox that does not support the new method, or by the destination node itself - if the destionation does not support this method.
</t>
<t>On the other hand, if the stack supports the new method for the Long Options, it can treat the first segment as a partial duplicate of the second -
thus allowing to upgrade the protocol behaviour. (NB: the overall upgrade protocol is a much larger problem and is out of scope for this document).
</t>
    </section>
    <section anchor="solution-details" title="Implementation Details">
<t>
Allocate two new TCP options: a 4 bytes long "LOIC-FLAG" and a 4 bytes long "LOIC-LEN" (Long Options with Invalidated Checksum).
</t>
<t>
The first one is aimed into inclusion into the 'compatible segments' to signal that the system understands the long options mechanism,
as well as later possibly be used as a signaling mechanism about the end-to-end connectivity for the Long Options segments.
The goal here is to minimize the potential of the disruption for the existing applications. 
</t>
<t>
The two bytes of usable payload of the second option will hold the length of the TCP Long Options area (zero being an allowed
value and meaning there is no Long Options at all). The TCP Long Options area will be placed between the end of the 'classic' 
TCP header and the beginning of the TCP segment data. The presence of this option will mean that before verifying the TCP checksum, one 
MUST decrement the received value by 2 - and only then verify the checksum. To allow more efficiency in the implementations,
this option MUST be the first TCP option within the segment - this way the analysis of the TCP checksum would not be impacted too much.
</t>


    </section>


    <section anchor="security_considerations" title="Security Considerations">
      <t>[[Placeholder.]]</t>
    </section>

    <section title="Acknowledgements">
<t>
The concept of using the invalid checksum came up during one of the discussions with Dan Wing about an unrelated matter. 
Thanks to following individuals for the initial discussions about this idea: Wesley Eddy, Alan Ford, Anantha Ramaiah, 
Fernando Gont [[ Please remind me who I forgot, I forgot a few folks for sure ]]
</t>
    </section>

    <section title="IANA Considerations">
      <t>This document, being informational, has no IANA actions. However, its derivatives that adopt the described approach,
      would have an action to update the registry of the TCP options to include the LOIC-FLAG and LOIC-LEN definitions.</t>
    </section>


  </middle>

  <back>
    <references title="Normative References">
      &rfc2119;

    </references>

    <references title="Informational References">

      &rfc1671;

    </references>
  </back>
</rfc>