One document matched: draft-briscoe-tcpm-syn-op-sis-01.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-01"
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="22" 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_N" title="Protocol Specification">
<t>This method is termed the non-deterministic method to distinguish it
from similar alternative methods specified in <xref
target="synopsis_Alt_Spec"/>. In this method the TCP client sends two
alternative SYNs: a regular SYN intended for legacy servers and a SYN-UN
intended for upgraded servers. The two SYNs will have the same network
addresses and the same destination port, but different source ports.
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-UN) includes additional options at
the end of the payload. The options are placed at the end of the payload
to ensure that the SYN-UN is more likely to traverse middleboxes that
inspect application-layer headers, which they expect to be at the start
of the payload. </t>
<t><xref target="synopsis_tab_3whs-overview-N"/> 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-N"
title="Overview of 3-Way Handshakes for the Two Alternative SYNs in Two Server Scenarios: Non-Deterministic Alternative">
<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-UN</c>
<c>SYN</c>
<c>SYN-UN</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>If the client receives a response to the SYN, but not the SYN-UN, it
SHOULD retransmit the SYN-UN. In parallel to any retransmission, or
instead of any retransmission, the client MAY give up on the SYN-UN
connection and complete the 3-way handshake of the other regular
connection. If the client receives no response at all, it SHOULD solely
retransmit the SYN. It MUST NOT retransmit both segments, because the
lack of response could be due to severe congestion.</t>
<t>The SYN-UN is structured as shown in <xref
target="synopsis_SYN-UN"/>. 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 SynOpSis TCP options MUST be the final TCP
option right-aligned at the end of the payload (preceded by padding
options if necessary), so that the server can find it (using the length
of the whole packet found in the network layer header, e.g. IPv4 or
IPv6). </t>
<figure align="center" anchor="synopsis_SYN-UN"
title="The Structure of a SYN-UN segment (not to scale)">
<artwork><![CDATA[ | EOO | EPOO |
,-------->,---------->|
+---------+-----------+---------+-----------+-----------+----------+
| TCP hdr | TCP-Opt#2 | Payload | TCP-Opt#1 | TCP-Opt#3 | SynOpSis |
+---------+-----------+---------+-----------+-----------+----------+
]]></artwork>
</figure>
<t>The SynOpSis TCP option has Kind SynOpSis, with a value (TBA) (See
<xref target="synopsis_IANA"/>). In general, the SynOpSis TCP option can
have different lengths for different purposes. However, in a SYN-UN, the
SynOpSis TCP option MUST have Length = 8, so that the server can find
where it starts (8 octets before the end of the segment). </t>
<t>The internal structure of the SynOpSis TCP option for a SYN-UN is
defined in <xref target="synopsis_SynOpSis-UN"/>. The SynOpSis TCP
option for a SYN-UN MUST have 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 SynOpSis TCP option. </t>
<figure align="center" anchor="synopsis_SynOpSis-UN"
title="SynOpSis TCP Option for a SYN-UN">
<artwork><![CDATA[+---------------+---------------+-------------------------------+
| Kind=SynOpSis | Length=8 | Magic Number |
+---------------+---------------+---------------+---------------+
| Magic Number (cont) | EOO | EPOO |
+---------------+---------------+---------------+---------------+
]]></artwork>
</figure>
<t>Two single octet offset fields are placed at the end of the SynOpSis
TCP option for a SYN-UN:<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 determines whether there is a SynOpSis TCP option
at the end of the packet by checking all the following conditions:<list
style="symbols">
<t>The Kind value is the SynOpSis Kind value;</t>
<t>The length is 8;</t>
<t>The next 4 octets match the magic number;</t>
<t>The sum of the value of the EOO field, and all the length fields
found by walking along the TCP options at the end of the payload
exactly reaches the end of the packet.</t>
</list>If any of these conditions fails, the server MUST treat the
whole payload as user-data.</t>
<t>With this non-deterministic approach, there will be a very small
probability (roughly 2^{-48-L}) that payload data on a regular
(non-SynOpSis) SYN will happen to contain a pattern in exactly the right
place that matches the magic number, and that the payload data also
happens to contain a valid sequence of numbers in exactly the right
places to look like a valid string of TCP options (where L is the sum of
all the bits in all the TCP option length fields that seem to be in the
payload). For instance, if it appears that there are 2 TCP options
before the SynOpSis option at the end of the payload, then L=2*8=16, and
the probability of incorrectly using user-data as TCP options will then
be roughly 2^(-64) = 1 in 18 billion billion (18x10^18).</t>
<t>It is recognised that it is potentially dangerous to use probability
to determine whether TCP options are hidden at the end of the payload.
This 'stealth' approach has been taken in order to maximise the chances
of traversing middleboxes; by ensuring that all the TCP headers and
options of a SYN-UN are completely indistinguishable from a regular SYN.
If this non-deterministic approach is not preferred, an alternative more
conventional deterministic protocol designs is provided in <xref
target="synopsis_Alt_Spec"/>.</t>
<t>An upgraded server processes the TCP options in a SYN-UN in the
following order:<list style="numbers">
<t>The Prefix TCP options (TCP-Opt#1 in <xref
target="synopsis_SYN-UN"/>)</t>
<t>The regular TCP options following the main header but before the
payload (TCP-Opt#2 in <xref target="synopsis_SYN-UN"/>);</t>
<t> The Suffix TCP options (TCP-Opt#3 in <xref
target="synopsis_SYN-UN"/>)</t>
</list></t>
<t>SYN/ACK-U carries a simple SynOpSis flag TCP option as defined in
<xref target="synopsis_SYN_Flag"/>. It solely identifies that the
SYN/ACK is from a server that supports SynOpSis TCP options.</t>
<figure align="center" anchor="synopsis_SYN_Flag"
title="A SynOpSis flag TCP option">
<artwork><![CDATA[+---------------+---------------+
| Kind=SynOpSis | Length=2 |
+---------------+---------------+
]]></artwork>
</figure>
</section>
<section title="Interaction with TCP">
<t>{ToDo: TCP User Interface, TCP States and Transitions, TCP Segment
Processing, Processing and Segment Size Overhead, Connectionless Resets,
ICMP Handling. Interaction with EDO, Interactions with Other TCP
Variants, Forward-Compatibility, Interaction with TCP assumptions of
Middleboxes. }</t>
</section>
<section anchor="synopsis_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
(SynOpSis)"</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>
</section>
<section anchor="synopsis_Security_Considerations"
title="Security Considerations">
<t>Certain cryptographic functions have different coverage rules for the
TCP payload and TCP options. Placing some TCP options in the payload
could mean that they are treated differently from regular TCP options.
This is a deliberate feature of the protocol, but application developers
will need to be aware that this is the case.</t>
<t>{ToDo: More}</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 Jana Iyengar and
Olivier Bonaventure. The following people provided useful review
comments: Joe Touch, Yuchung Cheng.</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>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC0793;
&RFC2119;
&RFC6994;
</references>
<references title="Informative References">
&RFC5925;
&RFC6824;
&I-D.ietf-tcpm-fastopen;
</references>
<section anchor="synopsis_Alt_Spec"
title="Alternative Protocol Specifications">
<t>This appendix is informative and will be deleted before publication.
It documents alternative protocol arrangements that may be considered
instead of the non-deterministic protocol in <xref
target="synopsis_Protocol_Spec_N"/>. </t>
<section anchor="synopsis_Protocol_Spec_D"
title="Deterministic Protocol Specification">
<t>This alternative protocol arrangement is termed the Deterministic
SynOpSis protocol. It is termed 'deterministic' because it uses a more
conventional approach for placement of the SynOpSis TCP option instead
of the non-deterministic approach in <xref
target="synopsis_Protocol_Spec_N"/>. 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 non-deterministic method
in <xref target="synopsis_Protocol_Spec_N"/>. The TCP client still
sends two alternative SYNs: SYN-L intended for legacy servers and
SYN-UD intended for upgraded servers. The two SYNs will have the same
network addresses and the same destination port, but different source
ports. 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. The options are placed
at the end of the payload to ensure that the SYN-UD is more likely to
traverse middleboxes that inspect application-layer headers, which
they expect to be at the start of the payload.</t>
<t>Table <xref target="synopsis_tab_3whs-overview-D"/> 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-D"
title="Overview of 3-Way Handshakes for the Two Alternative SYNs in Two Server Scenarios: Deterministic Alternative">
<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>RST</c>
<c>SYN/ACK-U</c>
<c>3</c>
<c>ACK</c>
<c>RST</c>
<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>If the client receives a RST on one connection and no response on
the other, it SHOULD retransmit the SYN that got no response. In
parallel to any retransmission, or instead of any retransmission, the
client MAY send a SYN without any SynOpSis option, in case this is the
cause of the black-hole. However, the presence of the RST implies that
one of the SYNs with a SynOpSis TCP option probably reached the
server, therefore it is more likely (but not certain) that the lack of
response on the other connection is due to transmission loss or
congestion loss. If the client receives no response at all, it SHOULD
fall-back to sending a regular SYN with no SynOpSis option. It MUST
NOT retransmit both segments, because the lack of response could be
due to severe congestion.</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 SynOpSis flag
option as shown in <xref target="synopsis_SYN_Flag"/>. It solely
identifies that the SYN is from a client that supports SynOpSis TCP
options.</t>
<t>The placement of the SynOpSis TCP option in a deterministic SYN-UD
segment is more conventional than in the SYN-U of <xref
target="synopsis_Protocol_Spec_N"/>, as shown in <xref
target="synopsis_SYN-UD"/>. Nonetheless, it can be seen that extra TCP
options are stlil 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 SynOpSis 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 (not to scale)">
<artwork><![CDATA[ | EOO |
,-------->|
+---------+-----------+----------+-----------+---------+-----------+
| TCP hdr | TCP-Opt#1 | SynOpSis | TCP-Opt#3 | Payload | TCP-Opt#2 |
+---------+-----------+----------+-----------+---------+-----------+
]]></artwork>
</figure>
<t>The SYN-OP-SYS TCP option for a SYN-UD segment MUST have Kind
SynOpSis, with a value (TBA) (See <xref target="synopsis_IANA"/>) and
Length = 3. In general, the SynOpSis TCP option can have different
lengths for different purposes. However, in a SYN-UD, the SynOpSis 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
SynOpSis TCP option for a SYN-UD segment is defined in <xref
target="synopsis_SynOpSis_UD"/>.</t>
<figure align="center" anchor="synopsis_SynOpSis_UD"
title="SynOpSis TCP Option for a deterministic SYN-UD">
<artwork><![CDATA[+---------------+---------------+---------------+
| Kind=SynOpSis | 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 space for payload data 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 SynOpSis 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
SynOpSis TCP option (TCP-Opt#3 in <xref
target="synopsis_SYN-UD"/>);</t>
</list></t>
</section>
<section anchor="synopsis_Protocol_Spec_N-Explicit"
title="Non-Deterministic Explicit Protocol Specification">
<t>The protocol outlined in <xref
target="synopsis_tab_3whs-overview-N-explicit"/> is a hybrid of the
two approaches in <xref target="synopsis_Protocol_Spec_N"/> and <xref
target="synopsis_Protocol_Spec_D"/>.</t>
<texttable anchor="synopsis_tab_3whs-overview-N-explicit"
title="Overview of 3-Way Handshakes for the Two Alternative SYNs in Two Server Scenarios: Non-Deterministic Explicit Alternative">
<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-UN</c>
<c>SYN-L</c>
<c>SYN-UN</c>
<c>2</c>
<c>SYN/ACK</c>
<c>SYN/ACK</c>
<c>RST</c>
<c>SYN/ACK-U</c>
<c>3</c>
<c>ACK</c>
<c>RST</c>
<c/>
<c>ACK</c>
<c>4</c>
<c>Cont...</c>
<c/>
<c/>
<c>Cont...</c>
</texttable>
<t>The SYN-L might not traverse middleboxes, therefore connections
with legacy servers could suffer from the added latency of a
retransmission. Nonetheless, if it does reach an upgraded server, the
server knows explicitly that the client supports SynOpSis TCP options
and can abort the connection without having had to hold any state.
</t>
<t>The SYN-UN has the advantage that it is all-but indistinguishable
from a regluar SYN, therefore it is likely to traverse most
middleboxes. However, there is a tiny chance that an upgraded server
might mistake some arbitrary payload for a SYN-U, if data happens to
match the magic number.</t>
</section>
<section anchor="synopsis_Protocol_Spec_D-Implicit"
title="Deterministic Implicit Protocol Specification">
<t>The protocol outlined in <xref
target="synopsis_tab_3whs-overview-D-implicit"/> is a hybrid of the
two approaches in <xref target="synopsis_Protocol_Spec_N"/> and <xref
target="synopsis_Protocol_Spec_D"/>.</t>
<texttable anchor="synopsis_tab_3whs-overview-D-implicit"
title="Overview of 3-Way Handshakes for the Two Alternative SYNs in Two Server Scenarios: Deterministic Implicit Alternative">
<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-UD</c>
<c>SYN</c>
<c>SYN-UD</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>tACK</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>The regular SYN will traverse middleboxes so there will be no
latency problems reaching legacy servers. However an upgraded server
cannot know that it comes from a client that supports SynOpSis TCP
options, therefore it has to open connection state for both
connections until the client explicitly aborts the one intended for a
legacy server.</t>
<t>The SYN-UD has the advantage that an upgraded server cannot
occasionally mistake payload data for TCP options. However, this
approach could introduce latency reaching an upgraded server, if the
SYN-UD does not traverse a middlebox.</t>
</section>
<section title="Comparison of Alternatives">
<t>The four solutions in sections <xref format="counter"
target="synopsis_Protocol_Spec_N"/>, <xref format="counter"
target="synopsis_Protocol_Spec_D"/>, <xref format="counter"
target="synopsis_Protocol_Spec_N-Explicit"/> & <xref
format="counter" target="synopsis_Protocol_Spec_D-Implicit"/>, each
suffer from two of the following four failings:<list style="hanging">
<t hangText="Risk Delay Accessing Legacy Server:">due to the SYN
intended for a legacy server being non-normal and therefore at
risk of drop by a middlebox;</t>
<t hangText="Risk Delay Accessing Upgraded Server:">due to the SYN
intended for an upgraded server being non-normal and therefore at
risk of drop by a middlebox;</t>
<t hangText="Doubles Upgraded Server State within RTT:">because
the server has to hold the second connection's state until the
client resets it;</t>
<t
hangText="Risk of Upgraded Server Mistaking User-Data for TCP Options:">due
to use of the probabilistic magic number technique.</t>
</list>All four schemes double up connection state on the legacy
server for a round trip. </t>
<t><xref target="synopsis_tab_Compare"/> places a tick ('/') against
the combinations of SYNs that are better in each respect.</t>
<texttable anchor="synopsis_tab_Compare"
title="Comparison of the Four Alternative Solutions">
<ttcol/>
<ttcol>Non-Determin-istic </ttcol>
<ttcol>Determin-istic</ttcol>
<ttcol>Non-Determin-istic Explicit</ttcol>
<ttcol>Determin-istic Implicit</ttcol>
<c/>
<c>SYN + SYN-UN</c>
<c>SYN-L + SYN-UD</c>
<c>SYN-L + SYN-UN</c>
<c>SYN + SYN-UD</c>
<c/>
<c/>
<c/>
<c/>
<c/>
<c>Min Delay to Legacy Svr</c>
<c>/</c>
<c>X</c>
<c>X</c>
<c>/</c>
<c>Min Delay to Upgraded Svr</c>
<c>/</c>
<c>X</c>
<c>/</c>
<c>X</c>
<c>Min State on Upgraded Svr</c>
<c>X</c>
<c>/</c>
<c>/</c>
<c>X</c>
<c>User-Data Unmistakeable</c>
<c>X</c>
<c>/</c>
<c>X</c>
<c>/</c>
</texttable>
<t>It should be noted that there is no need for the IETF to choose a
single pair of SYNs. Once the SynOpSis TCP options are defined,
clients can use their own choices of pairs in different cicumstances.
Initially clients might choose the Non-Deterministic scheme to
minimise delays due to middlebox interference. But later, perhaps once
more middleboxes support the scheme, clients might choose the
Non-Deterministic Explicit scheme, to minimise both state and delay
with the upgraded server.</t>
</section>
</section>
<section title="Protocol Design Issues (to be Deleted before Publication)">
<t>This appendix is informative, not normative. It records outstanding
issues with the protocol design that will need to be resolved before
publication. </t>
<t><list style="hanging">
<t hangText="Reliance on segmentation boundary:">The definition of
the position of the SynOpSis TCP options depends on where the sender
decided to place a segment boundary. In general, a sender cannot
rely on segment boundaries being preserved, e.g. by segmentation
offloading hardware. In the case of a SYN, no more payload data is
sent in the first round trip, therefore using this segment boundary
might be safe. However, it may constrain future attempts to send
additional data in the first round.</t>
</list></t>
<!--A binary flag may need to be associated with the EOO field to tell an upgraded server whether to use or discard the data in the payload
of a SYN-U or a SYN-UD, i.e. if the flag is set, the data between the start of the payload and the extra options offset is passed to the application,
otherwise it is discarded.-->
</section>
<section title="Change Log (to be Deleted before Publication)">
<t>A detailed version history can be accesssed at
<http://datatracker.ietf.org/doc/draft-briscoe-tcpm-syn-op-sis/history/></t>
<t><list style="hanging">
<t hangText="From briscoe...-00 to briscoe...-01:"><vspace
blankLines="1"/>Technical changes:<list style="symbols">
<t>Added the definition of a SYN/ACK-U</t>
<t>Deterministic Protocol Spec: Replaced SYN/ACK-L with RST (Joe
Touch)</t>
<t>Added Non-Deterministic Explicit and Deterministic Implicit
Protocol Specs in Appendices</t>
<t>Added Comparison of Alternatives as an Appendix</t>
<t>Security Considerations: Added note about crypto coverage of
TCP options in the payload being different from that of other
TCP options.</t>
<t>Added an appendix to record outstanding Protocol Design
Issues, and included segmentation boundary issue (Yuchung
Cheng).</t>
</list>Editorial changes:<list style="symbols">
<t>Changed TCP option Kind from SYN-OP-SIS to SynOpSis</t>
<t>Protocol Spec: Explained why the extra TCP options are placed
at the end of the payload</t>
<t>Throughout: avoided the ambiguity in the word payload, now
that there are TCP options at the end of the payload. Some might
consider these to be within the payload, while others might
consider them to be placed beyond the payload.</t>
<t>Segment structure figures: Clarified that they are not to
scale.</t>
<t>Added placeholder section "Interaction with TCP"</t>
<t>Acknowledged reviewers</t>
</list></t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 16:13:08 |