One document matched: draft-briscoe-tcpm-inner-space-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 RFC2018 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2018.xml">
<!ENTITY RFC2675 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2675.xml">
<!ENTITY RFC4987 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4987.xml">
<!ENTITY RFC5925 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml">
<!ENTITY RFC6555 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6555.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 RFC7323 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7323.xml">
<!ENTITY I-D.ietf-tcpm-fastopen SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tcpm-fastopen.xml">
<!ENTITY I-D.wing-tsvwg-happy-eyeballs-sctp SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.wing-tsvwg-happy-eyeballs-sctp.xml">
<!ENTITY I-D.bittau-tcpinc SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.bittau-tcpinc.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-inner-space-00"
ipr="trust200902" updates="793">
<!-- 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="Inner Space">Inner Space for TCP Options</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="19" month="October" 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 limited
space for control options in every segment of a TCP connection. It can
use a dual handshake so that, from the very first SYN segment, extra
option space can immediately start to be used optimistically. At the
same time the dual handshake prevents a legacy server from getting
confused and sending the control options to the application as
user-data. The dual handshake is only one strategy - a single handshake
will usually suffice once deployment has got started. The protocol is
designed to traverse most known middleboxes including connection
splitters, because it sits wholly within the TCP Data. It also provides
reliable ordered delivery for control options. Therefore, it should
allow new TCP options to be introduced i) with minimal middlebox
traversal problems; ii) avoiding incremental deployment problems with
pre-existing servers; iii) without an extra round of handshaking delay
iv) without having to provide its own loss recovery and ordering
mechanism and v) without arbitrary limits on available space.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>TCP has become hard to extend, partly because the option space was
limited to 40B when TCP was first defined <xref target="RFC0793"/> and
partly because many middleboxes only forward TCP headers that conform to
the stereotype they expect.</t>
<t>This specification ensures new TCP capabilities can traverse most
middleboxes by tunnelling TCP options within the TCP Data as 'Inner
Options' (<xref target="inspace_Fig_Encap_Approach"/>). Then the TCP
receiver can reconstruct the Inner Options sent by the sender, even if
the middlebox resegments the data stream and even if it strips 'Outer'
options from the TCP header that it does not recognise. The two words
'Inner Space' are appropriate as a name for the scheme; 'Inner' because
it encapsulates options within the TCP Data and 'Space' because the
space within the TCP Data is virtually unlimited—constrained only
by the maximum segment size.</t>
<figure align="center" anchor="inspace_Fig_Encap_Approach"
title="Encapsulation Approach">
<artwork><![CDATA[,-----. TCP Payload ,-----.
| App |<----------------------------------------->| App |
|-----| |-----|
| | Inner Options within TCP Data | |
| |<----------------------------------------->| |
| | | |
| TCP | TCP Header and TCP header and | TCP |
| | Outer Options ,---------. Outer Options | |
| |<-------------->|Middlebox|<-------------->| |
|-----| |---------| |-----|
| IP | | IP | | IP |
: : : : : :
]]></artwork>
</figure>
<t>TCP options fall into three main categories:<list style="letters">
<t>Those that have to remain as Outer Options—typically those
concerned with transmission of each TCP segment, e.g. Timestamps and
Selective ACKnowledgements (SACK);</t>
<t>Those that are best as Inner Options—typically those
concerned with transmission of the data as a stream, e.g. the TCP
Authentication Option <xref target="RFC5925"/> or tcpcrypt <xref
target="I-D.bittau-tcpinc"/>;</t>
<t>Those that can be either Inner or Outer Options—typically
those used at the start of a connection which is also inherently the
start of the first segment so segmentation is not a concern.</t>
</list></t>
<t>Pressure of space is most acute in the initial segments of each
half-connection, i.e. the SYN and SYN/ACK, and particularly the SYN.
Even though Inner Space is not suitable for category (a) options, moving
all of categories (b) and (c) into Inner Space frees up plenty of outer
space in the header for category (a).</t>
<t>The following list of options that might be required on a SYN
illustrates how acute the problem is:<list style="symbols">
<t>4B: Maximum Segment Size (MSS) <xref target="RFC0793"/>;</t>
<t>2B: SACK-ok <xref target="RFC2018"/>;</t>
<t>3B: Window Scale <xref target="RFC7323"/>;</t>
<t>10B: Timestamp <xref target="RFC7323"/>;</t>
<t>12B: Multipath TCP <xref target="RFC6824"/>;</t>
<t>6-18B: TCP Fast Open on a resumed connection <xref
target="I-D.ietf-tcpm-fastopen"/>;</t>
<t>16B: TCP-AO <xref target="RFC5925"/>;</t>
</list>There is probably potential for compressing together multiple
options in order to mitigate the option space problem. However, the
option space problem has to be faced, because complex special placement
is already being contemplated for options that can be larger than 40B on
their own (e.g. the key agreement options of tcpcrypt <xref
target="I-D.bittau-tcpinc"/>).</t>
<t>Given the Inner Space protocol places control options within TCP
Data, it is critical that a legacy TCP receiver is never confused into
passing this mix to an application as if it were pure data.
Naïvely, both ends could handshake to check they understand the
protocol, but this would introduce a round of delay and it would not
solve the shortage of space in a SYN. Instead, the client uses a dual
handshake; one suitable for an upgraded server, and the other for an
ordinary server. Then, if the client discovers that the server does not
understand the new protocol, it can abort the upgraded handshake before
the server passes corrupt data to the application. Otherwise, if the
server does understand the new protocol, the client can abort the
ordinary handshake. Either way, it has added zero extra delay.
Interworking of the dual handshake with TCP Fast Open <xref
target="I-D.ietf-tcpm-fastopen"/> is carefully defined so that the
server can even pass data to the application as soon as the first SYN
arrives.</t>
<t>When control options are placed within the TCP Data they inherently
get delivered reliably and in order. Although this was not originally
recognised as part of the design brief, it offers the significant
benefit of simplifying the design of new TCP options. Reliable ordered
delivery no longer has to be individually crafted into the design of
each new TCP option.</t>
<t>Solving the five problems of i) option-space exhaustion; ii)
middlebox traversal; iii) legacy server confusion; iv) reliable ordered
control message delivery; and v) handshake latency; does not come
without cost:<list style="symbols">
<t>So that the Inner Space protocol is immune to option stripping,
it flags its presence using a magic number within the TCP Data of
the two initial segments, not a conventional TCP option in the
header. This introduces a risk that payload in an ordinary SYN or
SYN/ACK might be mistaken for the Inner Space protocol (an initial
worst-case estimate of the probability is one connection globally
every 40 years). Nonetheless, the risk is zero in the (currently
common) case of an ordinary connection without payload during the
handshake. There is also no risk of a mistake the other way
round—an upgraded connection cannot be mistaken for an
ordinary connection.</t>
<t>Although the dual handshake introduces no extra latency, it
introduces extra connection processing & state, extra traffic
and extra header processing. Initial estimates put the percentage
overhead in the single digits for connection processing and state,
and traffic overhead should be only a few hundredths of a percent.
Nonetheless, once the most popular TCP servers have upgraded, only a
single handshake will be necessary most of the time and overhead
should drop to vanishingly small proportions.</t>
</list></t>
<t>Finally, it should be noted that the ambition of this work is more
than just an incrementally deployable, low latency way to extend TCP
option space. The aim is to move towards a more structured way for
middleboxes to interact transparently with, rather than arbitrarily
interfere with, end-system TCP stacks. This has been achieved for
connection and stream control options, but it will still be hard to
introduce new per-segment control options, which will still have to be
located with the traditional Outer TCP Options.</t>
<section title="Motivation for Adoption Now (to be removed before publication)">
<t>It seems inevitable that ultimately more option space will be
needed, particularly given that many of the TCP options introduced
recently consume large numbers of bits in order to provide sufficient
information entropy, which is not amenable to compression.</t>
<t>Extension of TCP option space requires support from both ends. This
means it will take many years before the facility is functional for
most pairs of end-points. Therefore, given the problem is already
becoming pressing, a solution needs to start being deployed now.</t>
</section>
<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.</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. The
protocol needs to be sufficiently well specified so that more than
one implementation can be built in order to test its function,
robustness, overhead and interoperability (with itself, with
previous version of TCP, and with various commonly deployed
middleboxes). Non-functional issues such as specified
recommendations on message timing also need to be tested. Various
optional extensions to the protocol are proposed in <xref
target="inspace_Alt_Spec"/> so experiments are also needed to
determine whether these extensions ought to remain optional, or
perhaps be removed or become mandatory. The experimental phase
will be considered successful once all these questions are
answered in the consensus opinion of the tcpm working group.</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, it would then be appropriate to
progress to a standards track specification, complemented by a
report on the experiments.</t>
</list></t>
</section>
<section anchor="inspace_Roadmap" title="Document Roadmap">
<t>The body of the document starts with a full specification of the
Inner Space extension to TCP (<xref
target="inspace_Protocol_Spec_N"/>). It is rather terse, answering
'What?' and 'How?' questions, but deferring 'Why?' to <xref
target="inspace_Design_Rationale"/>. The careful design choices made
are not necessarily apparent from a superficial read of the
specification, so the Design Rationale section is fairly extensive.
The body of the document ends with <xref
target="inspace_Interaction_TCP"/> that checks possible interactions
between the new scheme and pre-existing variants of TCP, including
interaction with partial implementations of TCP in known
middleboxes.</t>
<t><xref target="inspace_Alt_Spec"/> specifies optional extensions to
the protocol that will need to be implemented experimentally to
determine whether they are useful. And <xref
target="inspace_Compare"/> discusses the merits of the chosen design
against alternative schemes.</t>
</section>
<section anchor="inspace_Terminology" 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>
<t><list style="hanging">
<t hangText="TCP Header:">As defined in <xref target="RFC0793"/>.
Even though the present specification places TCP options beyond
the Data Offset, the term 'TCP Header' is still used to mean only
those fields at the head of the segment, delimited by the TCP Data
Offset.</t>
<t hangText="Inner TCP Options">(or just Inner Options): TCP
options placed in the space that the present specification makes
available beyond the Data Offset.</t>
<t hangText="Outer TCP Options">(or just Outer Options): The TCP
options in the traditional location directly after the base TCP
Header and within the TCP Data Offset.</t>
<t hangText="Prefix TCP Options:">Inner Options to be processed
before the Outer Options.</t>
<t hangText="Suffix TCP Options:">Inner Options to be processed
after the Outer Options.</t>
<t hangText="TCP options:">Any TCP options, whether inner, outer
or both. This specification makes this term on its own ambiguous
so it should be qualified if it is intended to mean TCP options in
a certain location.</t>
<t hangText="TCP Payload:">Data to be passed to the layer above
TCP. The present specification redefines the TCP Payload so that
it does not include the Inner TCP Options, the Inner Space Option
and any Magic Number, even though they are located beyond the Data
Offset.</t>
<t hangText="TCP Data:">The information in a TCP segment after the
Data Offset, including the TCP Payload, Inner TCP Options, the
Inner Space Option and the Magic Number defined in the present
specification.</t>
<t hangText="client:">The process taking the role of actively
opening a TCP connection.</t>
<t hangText="server:">The process taking the role of TCP
listener.</t>
<t hangText="Upgraded Segment:">A segment that will only be fully
understood by a host complying with the present specification
(even though it might appear valid to a pre-existing TCP
receiver). Similarly, Upgraded SYN, Upgraded SYN/ACK etc.</t>
<t hangText="Ordinary Segment:">A segment complying with
pre-existing TCP specifications but not the present specification.
Similarly, Ordinary SYN, Ordinary SYN/ACK etc.</t>
<t hangText="Upgraded Connection:">A connection starting with an
Upgraded SYN.</t>
<t hangText="Ordinary Connection:">A connection starting with an
Ordinary SYN.</t>
<t hangText="Upgraded Host:">A host complying with the present
document as well as with pre-existing TCP specifications.
Similarly Upgraded TCP Client, Upgraded TCP Server, etc.</t>
<t hangText="Legacy Host:">A host complying with pre-existing TCP
specifications, but not with the present document. Similarly
Legacy TCP Client, Legacy TCP Server, etc.</t>
</list>Note that the term 'Ordinary' is used for segments and
connections, but the term 'Legacy' is used for hosts. This is because,
if the Inner Space protocol were widely used in future, a host that
could not open an Upgraded Connection would be considered deficient
and therefore 'Legacy', whereas an Ordinary Connection would not be
considered deficient in the future; because it will always be
legitimate to open an Ordinary Connection if extra option space is not
needed.</t>
</section>
</section>
<section anchor="inspace_Protocol_Spec_N" title="Protocol Specification">
<section anchor="inspace_Incr_Deploy" title="Protocol Interaction Model">
<t/>
<section anchor="inspace_Dual_Handshake_Implicit"
title="Dual 3-Way Handshake">
<t>During initial deployment, an Upgraded TCP Client sends two
alternative SYNs: an Ordinary SYN in case the server is legacy and a
SYN-U in case the server is upgraded. The two SYNs MUST 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 without completing the 3-way
handshake.</t>
<t>The format of the SYN-U will be described later (<xref
target="inspace_Format_Segment-UNH"/>). At this stage it is only
necessary to know that the client can put either TCP options or
payload (or both) in a SYN-U, in the space traditionally intended
only for payload. So if the server's response shows that it does not
recognise the Upgraded SYN-U, the client is responsible for aborting
the Upgraded Connection. This ensures that a Legacy TCP Server will
never erroneously confuse the application by passing it TCP options
as if they were user-data.</t>
<t><xref target="inspace_Migration_Single_HS"/> explains various
strategies the client can use to send the SYN-U first and defer or
avoid sending the Ordinary SYN. However, such strategies are local
optimizations that do not need to be standardized. The rules below
cover the most aggressive case, in which the client sends the SYN-U
then the Ordinary SYN back-to-back to avoid any extra delay.
Nonetheless, the rules are just as applicable if the client defers
or avoids sending the Ordinary SYN.</t>
<t><xref target="inspace_Tab_3whs_implicit"/> summarises the TCP
3-way handshake exchange for each of the two SYNs in the two
right-hand columns, between an Upgraded TCP Client (the active
opener) and either:<list style="numbers">
<t>a Legacy Server, in the top half of the table (steps 2-4),
or</t>
<t>an Upgraded Server, in the bottom half of the table (steps
2-4)</t>
</list></t>
<t>Because the two SYNs come from different source ports, the server
will treat them as separate connections, probably using separate
threads (assuming a threaded server). A load balancer might forward
each SYN to separate replicas of the same logical server. Each
replica will deal with each incoming SYN independently - it does not
need to co-ordinate with the other replica.</t>
<texttable anchor="inspace_Tab_3whs_implicit"
title="Dual 3-Way Handshake in Two Server Scenarios">
<ttcol/>
<ttcol align="center"/>
<ttcol>Ordinary Connection</ttcol>
<ttcol>Upgraded Connection</ttcol>
<c>1</c>
<c>Upgraded Client</c>
<c>>SYN</c>
<c>>SYN-U</c>
<c/>
<c/>
<c/>
<c/>
<c>/\/\</c>
<c>/\/\/\/\/\/\/\/\</c>
<c>/\/\/\/\/\/\/\/\/\</c>
<c>/\/\/\/\/\/\/\/\/\</c>
<c>2</c>
<c>Legacy Server</c>
<c><SYN/ACK</c>
<c><SYN/ACK</c>
<c/>
<c/>
<c/>
<c/>
<c>3a</c>
<c>Upgraded Client</c>
<c>Waits for response to both SYNs</c>
<c/>
<c/>
<c/>
<c/>
<c/>
<c>3b</c>
<c>"</c>
<c>>ACK</c>
<c>>RST</c>
<c/>
<c/>
<c/>
<c/>
<c>4</c>
<c/>
<c>Cont...</c>
<c/>
<c/>
<c/>
<c/>
<c/>
<c>/\/\</c>
<c>/\/\/\/\/\/\/\/\</c>
<c>/\/\/\/\/\/\/\/\/\</c>
<c>/\/\/\/\/\/\/\/\/\</c>
<c>2</c>
<c>Upgraded Server</c>
<c><SYN/ACK</c>
<c><SYN/ACK-U</c>
<c/>
<c/>
<c/>
<c/>
<c>3a</c>
<c>Upgraded Client</c>
<c>Waits for response to SYN-U</c>
<c/>
<c/>
<c/>
<c/>
<c/>
<c>3b</c>
<c>"</c>
<c>>RST</c>
<c>>ACK</c>
<c/>
<c/>
<c/>
<c/>
<c>4</c>
<c/>
<c/>
<c>Cont...</c>
</texttable>
<t>Each column of the table shows the required 3-way handshake
exchange within each connection, using the following symbols:<list
style="empty">
<t>> means client to server</t>
<t>< means server to client</t>
<t>Cont... means the TCP connection continues as normal</t>
</list></t>
<t>The connection that starts with an Ordinary SYN is called the
'Ordinary Connection' and the one that starts with a SYN-U is called
the 'Upgraded Connection'. An Upgraded Server MUST respond to a
SYN-U with an Upgraded SYN/ACK (termed a SYN/ACK-U and defined in
<xref target="inspace_Format_Segment-UNH"/>). Then the client
recognises that it is talking to an Upgraded Server. The client's
behaviour depends on which response it receives first, as
follows:<list style="symbols">
<t>If the client first receives a SYN/ACK response on the
Ordinary Connection, it MUST wait for the response on the
Upgraded Connection. It then proceeds as follows:<list
style="symbols">
<t>If the response on the Upgraded Connection is an Ordinary
SYN/ACK, the client MUST reset (RST) the Upgraded Connection
and it can continue with the Ordinary Connection.</t>
<t>If the response on the Upgraded Connection is an Upgraded
SYN/ACK-U, the client MUST reset (RST) the Ordinary
Connection and it can continue with the Upgraded
Connection.</t>
</list></t>
<t>If the client first receives an Ordinary SYN/ACK response on
the Upgraded Connection, it MUST reset (RST) the Upgraded
Connection immediately. It can then wait for the response on the
Ordinary Connection and, once it arrives, continue as
normal.</t>
<t>If the client first receives an Upgraded SYN/ACK-U response
on the Upgraded Connection, it MUST reset (RST) the Ordinary
Connection immediately and continue with the Upgraded
Connection.</t>
</list></t>
</section>
<section anchor="inspace_Rexmt"
title="Dual Handshake Retransmission Behaviour">
<t>If the client receives a response to the SYN, but a short while
after that {ToDo: duration TBA} the response to the SYN-U has not
arrived, it SHOULD retransmit the SYN-U. If latency is more
important than the extra TCP option space, in parallel to any
retransmission, or instead of any retransmission, the client MAY
give up on the Upgraded (SYN-U) Connection by sending a reset (RST)
and completing the 3-way handshake of the Ordinary Connection.</t>
<t>If the client receives no response at all to either the SYN or
the SYN-U, it SHOULD solely retransmit one or the other, not both.
If latency is more important than the extra TCP option space, it
will retransmit the SYN. Otherwise it will retransmit the SYN-U. It
MUST NOT retransmit both segments, because the lack of response
could be due to severe congestion.</t>
</section>
<section title="Continuing the Upgraded Connection">
<t>Once an Upgraded Connection has been successfully negotiated in
the SYN, SYN/ACK exchange, either host can allocate any amount of
the TCP Data space in any subsequent segment for extra TCP options.
In fact, the sender has to use the upgraded segment structure in
every subsequent segment of the connection that contains non-zero
TCP Payload. The sender can use the upgraded structure in a segment
carrying no user-data (e.g. a pure ACK), but it does not have
to.</t>
<t>As well as extra option space, the facility offers other
advantages, such as reliable ordered delivery of Inner TCP Options
on empty segments and more robust middlebox traversal. If none of
these features is needed, at any point the facility can be disabled
for the rest of the connection, using the ModeSwitch TCP option in
<xref target="inspace_Modes"/>. Interestingly, the ModeSwitch
options itself can be very simple because it uses the reliable
ordered delivery property of Inner Options, rather than having to
cater for the possibility that a message to switch to disabled mode
might be lost or reordered.</t>
</section>
</section>
<section anchor="inspace_Structure_Format-UNH"
title="Upgraded Segment Structure and Format">
<section anchor="inspace_Structure_Segment-UNH"
title="Structure of an Upgraded Segment">
<t>An Upgraded Segment is structured as shown in <xref
target="inspace_Fig_Structure_Segment-UNH"/>. Up to the TCP Data
Offset, the structure is identical to an Ordinary TCP Segment, with
a base TCP Header (BaseHdr) and the usual facility to set the Data
Offset (DO) to allow space for TCP options. These regular TCP
options are renamed by this specification to Outer TCP Options or
just Outer Options, and labelled as OuterOpts in the figure.</t>
<t>The first segment in each direction (i.e. the SYN or the SYN/ACK)
is identifiable as upgraded by the presence of the 4-octet Magic
Number A (MagicA) at the start of the TCP Data. The probability that
an Upgraded Server will mistake arbitrary data at the beginning of
the payload of an Ordinary Segment for the Magic Number has to be
allowed for, but it is vanishingly small (see <xref
target="inspace_Non-Determinism"/>). Once an Upgraded Connection has
been negotiated during the SYN - SYN/ACK exchange, a magic number is
not needed to identify Upgraded Segments, because both ends know
that the protocol requires the sender to use the upgraded format on
all subsequent segments with non-zero TCP Data. Aside from the magic
number, the structure of the rest of an Upgraded Segment is the same
whether a) SYN=1 or b) SYN=0.</t>
<figure align="center" anchor="inspace_Fig_Structure_Segment-UNH"
title="The Structure of an Upgraded Segment (not to scale)">
<artwork><![CDATA[ | SOO |
a) SYN=1 ,--------->|
| DO | 1 | Len | InOO | SPS |
,------------------>,------>,------->,-------------------->,------->|
+--------+----------+-------+--------+----------+----------+--------+
| BaseHdr| OuterOpts| MagicA| InSpace|PrefixOpts|SuffixOpts| Payload|
+--------+----------+-------+--------+----------+----------+--------+
| '----------.----------' |
| Inner Options |
`-----------------------.-----------------------'
TCP Data
b) SYN=0
| DO | Len | InOO | SPS |
,------------------>,------->,---------------------->,------->|
+--------+----------+--------+-----------------------+--------+
| BaseHdr| OuterOpts| InSpace| Inner Options | Payload|
+--------+----------+--------+-----------------------+--------+
`----------------.------------------------'
TCP Data
]]></artwork>
<postamble>All offsets are specified in 4-octet (32-bit) words,
except SPS, which is in octets.</postamble>
</figure>
<t>Unlike an Ordinary TCP Segment, the Payload of an Upgraded
Segment does not start straight after the TCP Data Offset. Instead,
<xref target="inspace_Fig_Structure_Segment-UNH"/> shows that space
is provided for additional Inner TCP Options before the TCP Payload.
The size of this space is termed the Inner Options Offset (InOO).
The TCP receiver reads the InOO field from the Inner Option Space
(InSpace) option defined in <xref
target="inspace_Format_Segment-UNH"/>.</t>
<t>The InSpace Option is located in a standardized location so that
the receiver can find it:<list style="symbols">
<t>On a segment with SYN=1, an Upgraded TCP Sender MUST locate
the InSpace Option straight after the magic number, specifically
DO + 4 octets from the start of the segment.</t>
<t>On a segment with SYN=0, an Upgraded TCP Sender MUST locate
the InSpace Option at the beginning of the TCP Data,
specifically DO octets from the start of the segment.</t>
</list></t>
<t>Because the InSpace Option is only ever located in a standardized
location it does not need to follow the RFC 793 format of a TCP
option. Therefore, although we call InSpace an 'option', we do not
describe it as a 'TCP option'.</t>
<t>The Sent Payload Size (SPS) is also read from within the InSpace
Option. If the byte-stream has been resegmented, it allows the
receiver to step from one InSpace Option to the next even if the
InSpace Options are no longer at the start of each segment (see
<xref target="inspace_Option_Proc"/>).</t>
<t>On a segment with SYN=1 (i.e. a SYN or SYN/ACK) the Suffix
Options Offset (SOO) is also read from within the InSpace Option. It
delineates the end of the Prefix TCP Options (PrefixOpts in the
figure) and the start of the Suffix TCP Options (SuffixOpts). When
SYN=1, the receiver processes PrefixOpts before OuterOpts, then
SuffixOpts afterwards. When SYN=0, the receiver processes the Outer
Options before the Inner Options. Full details of option processing
are given in <xref target="inspace_Option_Proc"/>.</t>
</section>
<section anchor="inspace_Format_Segment-UNH"
title="Format of the InSpace Option">
<t>The internal structure of the InSpace Option for an Upgraded SYN
or SYN/ACK segment (SYN=1) is defined in <xref
target="inspace_Fig_InSpace_Segment-UNH"/>a) and for a segment with
SYN=0 in <xref target="inspace_Fig_InSpace_Segment-UNH"/>b).</t>
<figure align="center" anchor="inspace_Fig_InSpace_Segment-UNH"
title="InSpace Option Format">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
a) SYN = 1
+-------------------------------+---------------------------+---+
| Sent Payload Size (SPS) |Inner Options Offset (InOO)|Len|
+-------------------------------+---------------------------+---+
| Magic Number B |Suffix Options Offset (SOO)|CU |
+-------------------------------+---------------------------+---+
b) SYN = 0
+-------------------------------+---------------------------+---+
| Sent Payload Size (SPS) |Inner Options Offset (InOO)|Len|
+-------------------------------+---------------------------+---+
]]></artwork>
</figure>
<t>The fields are defined as follows (see <xref
target="inspace_Rationale_Format"/> for the rationale behind these
format choices):<list style="hanging">
<t hangText="Option Length (Len):">The 2-bit Len field specifies
the length of the InSpace Option in 4-octets words (see <xref
target="inspace_Rationale_Format"/> for rationale). For this
experimental specification:<list style="hanging">
<t hangText="When SYN=1:">the sender MUST use Len=2;</t>
<t hangText="When SYN=0:">the sender MUST use Len=1.</t>
</list></t>
<t hangText="Sent Payload Size (SPS):">In this 16-bit field the
sender MUST record the size in octets of the TCP Payload when it
was sent. This specification defines the TCP Payload as solely
the user-data to be passed to the application. This excludes
Inner TCP options, the InSpace Option and any magic number.</t>
<t hangText="Inner Options Offset (InOO):">This 14-bit field
defines the total size of the Inner TCP Options in 4-octet
words.</t>
</list>The following fields are only defined on a segment with
SYN=1 (i.e. a SYN or SYN/ACK):<list style="hanging">
<t hangText="Magic Number B:">The sender MUST fill this 16-bit
field with Magic Number B {ToDo: Value TBA} to further reduce
the chance that a receiver will mistake the end of an arbitrary
Ordinary Payload for the InSpace Option.</t>
<t hangText="Suffix Options Offset (SOO):">The 14-bit SOO field
defines an additional offset in 4-octet words from the start of
the Inner Options that identifies the extent of the Prefix
Options (see <xref target="inspace_Option_Proc_R"/>).</t>
<t hangText="Currently Unused (CU):">The sender MUST fill the CU
field with zeros and they MUST be ignored and forwarded
unchanged by other nodes, even if their value is different.</t>
</list></t>
</section>
</section>
<section anchor="inspace_Option_Proc"
title="Inner TCP Option Processing">
<section anchor="inspace_Option_Proc_W"
title="Writing Inner TCP Options">
<section anchor="inspace_TFO" title="Constraints on TCP Fast Open">
<t>If an Upgraded TCP Client uses a TCP Fast Open (TFO) cookie
<xref target="I-D.ietf-tcpm-fastopen"/> in an Upgraded SYN-U, it
MUST place the TFO option within the Inner TCP Options, beyond the
Data Offset.</t>
<t>This rule is specific to TFO, but it can be generalised to any
capability similar to TFO as follows: An Upgraded TCP Client MUST
NOT place any TCP option in the Outer TCP Options of a SYN if it
might cause a TCP server to pass user-data directly to the
application before its own 3-way handshake completes.</t>
<t>If a client uses TCP Fast Open cookies on both the parallel
connection attempts of a dual handshake, an Upgraded Server will
deliver the TCP Payload to the application twice before the client
aborts the Ordinary Connection. This is not a problem, because
<xref target="I-D.ietf-tcpm-fastopen"/> requires that TFO is only
used for applications that are robust to duplicate requests.</t>
</section>
<section title="Option Alignment">
<t>If the end of the last Prefix TCP Option does not align on a
4-octet boundary, the sender MUST append sufficient no-op TCP
options. The end of the Suffix TCP Options MUST be similarly
aligned.</t>
<t>If a block-mode transformation (e.g. compression or encryption)
is being used, the sender might have to add some padding options
to align the end of the Inner Options with the end of a block. Any
future encryption specification will need to carefully define this
padding in order not to weaken the cipher.</t>
</section>
<section title="Sequence Space Coverage">
<t>TCP's sequence number and acknowledgement number space MUST
include all the TCP Data, i.e. the InSpace Option, any Inner
Options, and any magic number as well as the TCP Payload. This
rule has significant implications, which are discussed in <xref
target="inspace_Control_in_Sequence"/>.</t>
</section>
<section title="Presence or Absence of Payload">
<t>Whenever the sender includes non-zero user-data payload in a
segment, it MUST also include an InSpace Option, whether or not
there are any Inner Options.</t>
<t>If the sender includes no user-data in a segment (e.g. pure
ACKs, RSTs) it MAY include an InSpace Option but it does not have
to. {ToDo: Consider whether there is any reason to preclude Inner
Options on a RST, FIN or FIN-ACK.}</t>
<t>Once a sender has included the InSpace Option and possibly
other Inner Options on a segment with no TCP Payload, while it has
no further user-data to send it SHOULD NOT repeat the same set of
control options on subsequent segments. Thus, in a sequence of
pure ACKs, any particular set of Inner Options will only appear
once, and other pure ACKs will be empty. The only envisaged
exception to this rule would be infrequent repetition (i.e. tens
of minutes to hours) of the same control options, which might be
necessary to provide a heartbeat or keep-alive capability.</t>
</section>
</section>
<section anchor="inspace_Option_Proc_R"
title="Reading Inner TCP Options">
<t>The rules for reading Inner TCP Options are divided between the
following two subsections, depending on whether SYN=1, SYN=0.</t>
<section anchor="inspace_Option_Proc_R-SYN"
title="Reading Inner TCP Options (SYN=1)">
<t>This subsection applies when TCP receives a segment with SYN=1,
i.e. when the server receives a SYN or the client receives a
SYN/ACK.</t>
<t>Before processing any TCP options, unless the size of the TCP
Data is less than 8 octets, an Upgraded Receiver MUST determine
whether the segment is an Upgraded Segment by checking that all
the following conditions apply:<list style="symbols">
<t>The first 4 octets of the segment match Magic Number A</t>
<t>The value of the Length field of the InSpace Option is
2;</t>
<t>The value of Magic Number B in the InSpace Option is
correct</t>
<t>The value of the Sent Payload Size matches the size of the
TCP Payload.</t>
</list></t>
<t>If all these conditions pass, the receiver MAY walk the
sequence of Inner TCP Options, using the length of each to check
that the sum of their lengths equals InOO. The receiver then
concludes that the received segment is an Upgraded Segment.</t>
<t>The receiver then processes the TCP Options in the following
order:<list style="numbers">
<t>Any Prefix TCP options (PrefixOpts in <xref
target="inspace_Fig_Structure_Segment-UNH"/>)</t>
<t>Any Outer TCP options (OuterOpts in <xref
target="inspace_Fig_Structure_Segment-UNH"/>);</t>
<t>Any Suffix TCP options (SuffixOpts in <xref
target="inspace_Fig_Structure_Segment-UNH"/>)</t>
</list></t>
<t>The receiver removes the magic number, the InSpace Option and
each TCP Option from the TCP Data as it processes each, until only
the TCP Payload remains, which it holds ready to pass to the
application. It then returns the appropriate Upgraded
Acknowledgement to progress the dual handshake (see <xref
target="inspace_Dual_Handshake_Implicit"/>).</t>
<t>If any of the above tests to find the InSpace Option
fails:<list style="numbers">
<t>the receiver concludes that the received segment is an
Ordinary Segment. It MUST then proceed by processing any Outer
TCP options in the TCP Header in the normal order (OuterOpts
in <xref target="inspace_Fig_Structure_Segment-UNH"/>).</t>
<t>If one of the Outer TCP Options causes the TCP receiver to
alter the TCP Data (e.g. decompression, decryption), it reruns
the above tests for an Upgraded Segment.</t>
<t>If it finds an InSpace Option, it suspends processing the
Outer TCP Options and instead processes and removes TCP
Options in the following order:<list style="numbers">
<t>Any Prefix Inner Options;</t>
<t>Any remaining Outer TCP Options;</t>
<t>Any Suffix Inner Options.</t>
</list></t>
<t>If it does not find an InSpace Option, it continues
processing the remaining Outer TCP Options as normal.</t>
</list>For the avoidance of doubt the above rules imply that, as
long as an InSpace Option has not been found in the segment, the
receiver might rerun the tests for it multiple times if multiple
Outer TCP Options alter the TCP Data. However, once the receiver
has found an InSpace Option, it MUST NOT rerun the tests for an
Upgraded Segment in the same segment.</t>
<t>If the receiver has not found an InSpace Option after
processing all the Outer Options, it returns the appropriate
Ordinary Acknowledgement to progress the dual handshake (see <xref
target="inspace_Dual_Handshake_Implicit"/>). As normal, it holds
any TCP Payload ready to pass to the application.</t>
</section>
<section anchor="inspace_Option_Proc_R-Data"
title="Reading Inner TCP Options (SYN=0)">
<t>This subsection applies once the TCP connection has
successfully negotiated to use the upgraded InSpace structure.</t>
<t>As each segment with SYN=0 arrives, the receiver immediately
processes any Outer TCP options.</t>
<t>As the receiver buffers TCP Data, it uses TCP's regular
mechanisms to fill any gaps due to reordering or loss so that it
can work its way along the ordered byte-stream. As the receiver
encounters each set of Inner Options, it MUST process them in the
order they were sent, as illustrated in <xref
target="inspace_Fig_Control_In_v_Out_Seq"/>a) in <xref
target="inspace_Control_in_Sequence"/>. The receiver MUST remove
the InSpace Option and TCP Options from the TCP Data as it
processes them, until only the TCP Payload remains, which it
passes to the application. It uses each InSpace Option to
calculate the extent of the associated Inner Options (using InOO),
and the amount of payload data before the next InSpace Option
(using Sent Payload Size).</t>
<t>The receiver MUST NOT locate InSpace Options by assuming there
is one at the start of the TCP Data in every segment, because
resegmentation might invalidate this assumption.</t>
<t>Therefore, the receiver processes the Inner Options in the
order they were sent, which is not necessarily the order in which
they are received. And if an Inner Option applies to the data
stream, the receiver applies it at the point in the data stream
where the sender inserted it. As a consequence, the receiver
always processes the Inner Options after the Outer Options.</t>
<t>The Inner Options are deliberately placed within the
byte-stream so that the sender can transform them along with the
payload data, e.g. to compress or encrypt them. Therefore, a
previous control message might have required the TCP receiver to
alter the byte-stream before passing it to the application, e.g.
decompression or decryption. If so, the TCP receiver applies
transformations progressively, to one sent segment at a time, in
the following order:<list style="numbers">
<t>The receiver MUST apply any transformations to the
byte-stream up to the end of the next set of Inner Options,
i.e. over the extent of the next Sent Payload Size, InSpace
Option and any Inner Options.</t>
<t>The receiver MUST then process and remove the InSpace
Option and any Inner Options (which might change the way it
transforms the next segment, e.g. a rekey option).</t>
<t>Having established the extent of the next sent segment, The
receiver returns to step 1.</t>
</list></t>
</section>
</section>
<section anchor="inspace_Option_Proc_F"
title="Forwarding Inner TCP Options">
<t>Middleboxes exist that process some aspects of the TCP Header.
Although the present specification defines a new location for Inner
TCP Options beyond the Data Offset, this is intended for the
exclusive use of the destination TCP implementation. A middlebox
MUST treat any octets beyond the Data Offset as immutable user-data.
Legacy Middleboxes already do not expect to find options beyond the
Data Offset anyway.</t>
<t>A TCP implementation is not necessarily aware whether it is
deployed in a middlebox or in a destination, e.g. a split TCP
connection might use a regular off-the-shelf TCP implementation.
Therefore, a general-purpose TCP that implements the present
specification will need a configuration switch to disable any search
for options beyond the Data Offset.</t>
</section>
</section>
<section anchor="inspace_Exceptions" title="Exceptions">
<t>{ToDo: Define behaviour of forwarding or receiving nodes if the
structure or format of an Upgraded Segment is not as specified.}</t>
<t>If an Upgraded TCP Receiver receives an InSpace Option with a
Length it does not recognise as valid, it MUST drop the packet and
acknowledge the octets up to the start of the unrecognised option.</t>
<t>Values of Sent Payload Size greater than 2^16 - 25 (=65,511) octets
MUST be treated as the distance to the next InSpace option, but they
MUST NOT be taken as indicative of the size of the TCP Payload when it
was sent. This is because the TCP Payload in even an IPv6
(non-jumbogram) packet cannot be greater than (2^16 -1 - 20 - 4)
octets (given the minimum TCP header is 20 octets and the minimum
InSpace Option is 4 octets). A Sent Payload Size of 0xFFFF octets MAY
be used to minimise the occurrence of empty InSpace options without
permanently disabling the Inner Space protocol for the rest of the
connection.</t>
</section>
<section anchor="inspace_SYN_Cookie" title="Echo TCP Option">
<t>{Temporary note: This section will be taken out into a stand-alone
Draft. It is initially included here for convenience.}</t>
<t>The Inner Space protocol allows a potentially large amount of
control state to be negotiated during the SYN exchange. The SYN Cookie
mechanism <xref target="RFC4987"/> embeds the cookie within part of
the TCP Initial Sequence Number, so a server can only store a limited
amount of state in the cookie. The only reason that space is limited
is that servers cannot assume all clients will support a cookie
mechanism that could hold more information. The simple solution to
this problem is to make a generic cookie-echo mechanism a prerequisite
for all client InSpace implementations.</t>
<figure align="center" anchor="inspace_Fig_Cookie"
title="The Echo TCP Option">
<artwork><![CDATA[ 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 /| ...
+---------------+---------------+-----------------/ | /---------+
| Echo | Length | OpaqueCookie /||/ ... |
+---------------+---------------+----------------/ | /----------+
|/
]]></artwork>
</figure>
<t>The Echo TCP option is defined in <xref
target="inspace_Fig_Cookie"/>. The option Kind is Echo with value
{ToDo: Value TBA}. The Length in octets can be any value greater than
1. The OpaqueCookie field is available for the server to fill with any
amount of any type of data it wishes to store in the cookie, only
constrained in size to an integer number of octets. The server can
locate the option in a SYN/ACK, either as an Outer or an Inner TCP
Option.</t>
<t>If a TCP receiver receives an Echo TCP option, it MUST echo an
identical Echo TCP option in the following ACK.</t>
<t>A client MAY send an empty Echo TCP option on the SYN to indicate
that it supports the Echo facility. A client implementation of the
Inner Space protocol MUST implement the Echo TCP option. Therefore a
SYN-U is sufficient to imply support for the Echo facility without
having to send an empty Echo TCP option on a SYN as well.</t>
<t>The mechanism a server uses to determine whether the echoed
contents of the cookie are the same as the contents it sent are
implementation dependent and do not need to be standardised.</t>
</section>
</section>
<section anchor="inspace_Design_Rationale" title="Design Rationale">
<t>This section is informative, not normative.</t>
<section anchor="inspace_Migration_Single_HS"
title="Dual Handshake and Migration to Single Handshake">
<t>In traditional <xref target="RFC0793"/> TCP, the space for options
is limited to 40B by the maximum possible Data Offset. Before a TCP
sender places options beyond that, it has to be sure that the receiver
will understand the upgraded protocol, otherwise it will confuse and
potentially crash the application by passing it TCP options as if they
were payload data.</t>
<t>The Dual Handshake (<xref
target="inspace_Dual_Handshake_Implicit"/>) ensures that a Legacy TCP
Server will never pass on TCP options as if they were user-data. If a
SYN carries TCP Data, a TCP server typically holds it back from the
application until the 3-way handshake completes. This gives the client
the opportunity to abort the Upgraded Connection if the response from
the server shows it does not recognise an Upgraded SYN.</t>
<t>The strategy of sending two SYNs in parallel is not essential to
the Alternative SYN approach. It is merely an initial strategy that
minimises latency when the client does not know whether the server has
been upgraded. Evolution to a single SYN with greater option space
could proceed as follows:<list style="symbols">
<t>Clients could maintain a white-list of upgraded servers
discovered by experience and send just the Upgraded SYN-U in these
cases.</t>
<t>Then, for white-listed servers, the client could send an
Ordinary SYN only in the rare cases when an attempt to use an
Upgraded Connection had previously failed (perhaps a mobile client
encountering a new blockage on a new path to a server that it had
previously accessed over a good path).</t>
<t>In the longer term, once it can be assumed that most servers
are upgraded and the risk of having to fall back to legacy has
dropped to near-zero, clients could send just the Upgraded SYN
first, without maintaining a white-list, but still be prepared to
send an Ordinary SYN in the rare cases when that might fail.</t>
</list></t>
<t>There is concern that, although dual handshake approaches might
well eventually migrate to a single handshake, they do not scale when
there are numerous choices to be made simultaneously. For
instance:<list style="symbols">
<t>trying IPv6 then IPv4 <xref target="RFC6555"/>;</t>
<t>and trying SCTP and TCP in parallel <xref
target="I-D.wing-tsvwg-happy-eyeballs-sctp"/>;</t>
<t>and trying ECN and non-ECN in parallel;</t>
<t>and so on.</t>
</list>Nonetheless, it is not necessary to try every possible
combination of N choices, which would otherwise require 2^N handshakes
(assuming each choice is between two options). Instead, a selection of
the choices could be attempted together. At the extreme, two
handshakes could be attempted, one with all the new features, and one
without all the new features.</t>
</section>
<section anchor="inspace_Location_Inner_Space"
title="In-Band Inner Option Space">
<section anchor="inspace_Non-Determinism"
title="Non-Deterministic Magic Number Approach">
<t>This section justifies the magic number approach by contrasting
it with a more 'conventional' approach. A conventional approach
would use a regular (Outer) TCP option to point to the dividing line
within the TCP Data between the extra Inner Options and the TCP
Payload.</t>
<t>This 'conventional' approach cannot provide extra option space
over a path on which a middlebox strips TCP options that it does not
recognise. <xref target="Honda11"/> quantifies the prevalence of
such paths. It reports on experiments conducted in 2010-2011 that
found unknown options were stripped from the SYN-SYN/ACK exchange on
14% of paths to port 80 (HTTP), 6% of paths to port 443 (HTTPS) and
4% of paths to port 34343 (unassigned). Further analysis found that
the option-stripping middleboxes fell into two main categories:
<list style="symbols">
<t>about a quarter appeared to actively remove options that they
did not recognise (perhaps assuming they might be indicative of
an attack?);</t>
<t>the rest were some type of higher layer proxy that split the
TCP connection, unwittingly failing to pass unknown options
between the two connections.</t>
</list></t>
<t>In contrast, the magic number approach ensures that not only are
the Inner Options tucked away beyond the Data Offset, but the option
that gives the extent of the Inner Options is also beyond the Data
Offset (see <xref target="inspace_Structure_Segment-UNH"/>). This
ensures that all the TCP Headers and options up to the Data Offset
are completely indistinguishable from an Ordinary Segment. It is
very unusual for a middlebox not to forward TCP Data unchanged, so
it will be highly likely (but not certain—see <xref
target="inspace_No_Data_in_SYN"/>) to forward the extra Inner
Options.</t>
<t>The downside of the magic number approach is that it is slightly
non-deterministic, quantified as follows:<list style="symbols">
<t>The probability that an Upgraded SYN=1 segment will be
mistaken for an Ordinary Segment is precisely zero.</t>
<t>In the currently common case of a SYN with zero payload, the
probability that it will be mistaken for an Upgraded Segment is
also precisely zero.</t>
<t>However, there will be a very small probability (roughly
2^{-66} or 1 in 74 billion billion (74 * 10^18)) that payload
data in an Ordinary SYN=1 segment could be mistaken for an
Upgraded SYN or SYN/ACK, if it happens to contain a pattern in
exactly the right place that matches the correct Sent Payload
Size, Length and Magic Numbers of an InSpace Option. {ToDo:
Estimate how often a collision will occur globally. Rough
estimate: 1 connection collision globally every 40 years.}</t>
<!--B =
2.5*10^18 B / day (2012) http://en.wikipedia.org/wiki/Big_data
2 * 10^18 B / day (2014) http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/VNI_Hyperconnectivity_WP.html
S = mean flow size =~ 1kB / connection
C = prob of collision = 2^{-66}
B = bytes consumed globally = 2.10^18 B/day (2014) (CAGR = 21% according to Cisco zettabyte era above)
E = no. of connections per consumed connection = 4 (?)
days / year = Y = 365
No. of years per collided connection = S/(C*B*E*Y)
= 1000 / (2^{-66} * 2.10^18 * 4 * 365)
= 40
-->
</list>The above probability is based on the assumptions
that:<list style="symbols">
<t>the magic numbers will be chosen randomly (in reality they
will not—for instance, a magic number that looked just
like the start of an HTTP connection would be rejected)</t>
<t>data at the start of Ordinary SYN=1 segments is random (in
reality it is not—the first few bytes of most payloads are
very predictable).</t>
</list>Therefore even though 2^{-66} is a vanishingly small
probability, the actual probability of a collision will be much
lower.</t>
<t>If a collision does occur, it will result in TCP removing a
number of 32-bit words of data from the start of a byte-stream
before passing it to the application.</t>
</section>
<section anchor="inspace_Security_Middlebox_Evasion"
title="Non-Goal: Security Middlebox Evasion">
<t>The purpose of locating control options within the TCP Data is
not to evade security. Security middleboxes can be expected to
evolve to examine control options in the new inner location.
Instead, the purpose is to traverse middleboxes that block new TCP
options unintentionally—as a side effect of their main
purpose—merely because their designers were too careless to
consider that TCP might evolve. This category of middleboxes tends
to forward the TCP Payload unaltered.</t>
<t>By sitting within the TCP Data, the Inner Space protocol should
traverse enough existing middleboxes to reach critical mass and
prove itself useful. In turn, this will open an opportunity to
introduce integrity protection for the TCP Data, whereas today, no
operating system would introduce integrity protection of Outer TCP
options, because it would fail in too many cases. Once the integrity
of Inner Options is protected, it will raise the stakes. Any attempt
to meddle with control options within the TCP Data will not just
close off the theoretical potential benefit of a protocol advance
that no-one knows they want yet; it will fail integrity checks and
therefore completely break any communication. No network operator
will buy a middlebox that does that.</t>
<t>Then middlebox designers will be on the back foot. To completely
block communications they will need a sound justification. If they
block an attack, that will be fine. But if they block everything
abnormal they will have to block the whole communication, or
nothing. So the operator will want to choose middlebox vendors who
take much more care to ensure their policies track the latest
advances—to avoid costly support calls.</t>
</section>
<section anchor="inspace_Avoiding_Segment_Start"
title="Avoiding the Start of the First Two Segments">
<t>Some middleboxes discard a segment sent to a well-known port
(particularly port 80) if the TCP Data does not conform to the
expected app-layer protocol (particularly HTTP). Often such
middleboxes only parse the start of the app-layer header (e.g. Web
filters only continue until they find the URL being accessed, or DPI
boxes only continue until they have identified the application-layer
protocol).</t>
<t>The segment structure defined in <xref
target="inspace_Structure_Segment-UNH"/> would not traverse such
middleboxes. An alternative segment structure that avoids the start
of the first two segments in each direction is defined in <xref
target="inspace_Structure_Segment-UNT"/>. It is not mandatory to
implement in the present specification. However, it is hoped that it
will be included in some experimental implementations so that it can
be decided whether it is worth making mandatory.</t>
</section>
<section anchor="inspace_Control_in_Sequence"
title="Control Options Within Data Sequence Space">
<t>Including Inner Options within TCP's sequence space gives the
sender a simple way to ensure that control options will be delivered
reliably and in order to the remote TCP, even if the control options
are on segments without user-data. By using TCP's existing stream
delivery mechanisms, it adds no extra protocol processing, no extra
packets and no extra bits.</t>
<t>The sender can even choose to place control options on a segment
without user-data, e.g. to reliably re-key TCP-level encryption on a
connection currently sending no data in one direction. The sender
can even add an InSpace Option without further Inner Options. Then
it can ensure that the segment will automatically be delivered
reliably and in order to the remote TCP, even though it carries no
user-data or other TCP control options, e.g. for a test probe, a
tail-loss probe or a keep-alive.</t>
<t><xref target="inspace_Fig_Control_In_v_Out_Seq"/>a) illustrates
control options arriving reliably and in order at the receiving TCP
stack in comparison with the traditional approach shown in <xref
target="inspace_Fig_Control_In_v_Out_Seq"/>b), in which control
options are outside the sequence space. In the traditional approach,
during a period when the remote TCP is sending no user-data, the
local TCP may receive control options E, B and D without ever
knowing that they are out of order, and without ever knowing that C
is missing.</t>
<figure align="center" anchor="inspace_Fig_Control_In_v_Out_Seq"
title="Control options a) inside vs. b) outside TCP sequence space`">
<artwork><![CDATA[a) __ ____ _______ _ __
|__|____|_______|_| |__| control
:E : D : C :B: :A :
________________: : : : :__________________: :
|________________| |__________________| data
b) __
|__| E
|_|__ B __
|____|D |__|A control
\ / \ /
________________\/__________________\/
|________________||__________________| data
!
!drop
____!__
|_______|C
]]></artwork>
</figure>
<t>By including Inner Options within the sequence space, each
control option is automatically bound to the start of a particular
byte in the data stream, which makes it easy to switch behaviour at
a specific point mid-stream (e.g. re-keying or switching to a
different control mode). With traditional TCP options, a bespoke
reliable and ordered binding to the data stream would have to be
developed for each TCP option that needs this capability (e.g.
co-ordinating use of new keys in TCP-AO <xref target="RFC5925"/> or
tcpcrypt <xref target="I-D.bittau-tcpinc"/>).</t>
<t>Including Inner Options in sequence also allows the receiver to
tell the sender the exact point at which it encountered an
unrecognised TCP option using only TCP's pre-existing
byte-granularity acknowledgement scheme.</t>
<t>Middleboxes exist that rewrite TCP sequence and acknowledgement
numbers, and they also rewrite options that refer to sequence
numbers (at least those known when the middlebox was produced, such
as SACK, but not any introduced afterwards). If Inner Options were
not included in sequence, the number of bytes beyond the TCP Data
Offset in each segment would not match the sequence number increment
between segments. Then, such middleboxes could unintentionally
corrupt the user-data and options by 'normalising' sequence or
acknowledgement numbering. Fortunately, including Inner Options in
sequence improves robustness against such middleboxes.</t>
</section>
<section anchor="inspace_SentPayloadSize"
title="Rationale for the Sent Payload Size Field">
<t>A middlebox that splits a TCP connection can coalesce and/or
divide the original segments. Segmentation offload hardware
introduces similar resegmentation. Inclusion of the Sent Payload
Size field in the InSpace Option makes the scheme robust against
such resegmentation.</t>
<t>The Sent Payload Size is not strictly necessary on a SYN (SYN=1,
ACK=0) because a SYN is never resegmented. However, for simplicity,
the layout for a SYN is made the same as for a SYN/ACK. This
future-proofs the protocol against the possibility that SYNs might
be resegmented in future. And it makes it easy to introduce the
alternative segment structure of <xref
target="inspace_Structure_Segment-UNT"/> if it is needed.</t>
</section>
</section>
<section anchor="inspace_Rationale_Format"
title="Rationale for the InSpace Option Format">
<t>The format of the InSpace Option (<xref
target="inspace_Fig_InSpace_Segment-UNH"/>) does not necessarily have
to comply with the RFC 793 format for TCP options, because it is not
intended to ever appear in a sequence of TCP options. In particular,
it does not need an Option Kind, because the option is always in a
known location. In effect the magic number serves as a multi-octet
Option Kind for the first InSpace Option, and the location of each
subsequent options is always known as an offset from the previous one,
using InOO and Sent Payload Size fields.</t>
<t>Other aspects of the layout are justified as follows:<list
style="hanging">
<t hangText="Length:">Whatever the size of the InSpace Option, the
right-hand edge of the Length field is always located 4 octets
from the start of the option, so that the receiver can find it to
determine the layout of the rest of the option. The option is
always a multiple of 4 octets long, so that any subsequent Inner
TCP Options comply with TCP's option alignment requirements.</t>
<t hangText="Sent Payload Size:">This field is 16 bits wide, which
is reasonable given segment size cannot exceed the limits set by
the Total Length field in the IPv4 header and the Payload Length
field in the IPv6 header, both of which are 16 bits wide.<vspace
blankLines="1"/>If the sender were to use a jumbogram <xref
target="RFC2675"/>, it could use the Jumbo InSpace Option defined
in <xref target="inspace_Structure_Data-UNJ"/>, which offers a
32-bit Sent Payload Size field. The Jumbo InSpace Option is not
mandatory to implement for the present experimental specification.
Even if it is implemented, it is only defined when SYN=0, given
use of a jumbogram for a SYN or SYN/ACK would significantly exceed
other limits that TCP sets for these segments.</t>
<t hangText="InSpace Options Offset">The 14-bit field is in units
of 4-octet words, in order to restrict Inner Options to no less
than the size of a maximum sized segment (given 4 * 2^14 = 2^16
octets).</t>
</list>When SYN=1 the layout of the InSpace Option is extended to
include:<list style="hanging">
<t hangText="Suffix Options Offset:">The SOO field is the same
14-bit width as the InOO field, and for the same reason. Both the
SOO and InOO fields are aligned 2 bits to the left of a word
boundary so that they can be used directly in units of octets by
masking out the 2-bit field to the right.</t>
<t hangText="Magic Number B:">The 32-bit size of Magic Number A is
not enough to reduce the probability of mistaking the start of an
Ordinary SYN Payload for the start of the Inner Space protocol. A
64-bit magic number could have been provided by using the next
4-octet word, but this would be unnecessarily large. Therefore,
when SYN=1, 16 more bits of magic number are provided within the
InSpace Option. Otherwise, these 16-bits would only have to be
used for padding to align with the next 4-octet word boundary
anyway.</t>
</list></t>
</section>
<section anchor="inspace_Overhead" title="Protocol Overhead">
<t>The overhead of the Inner Space protocol is quantified as
follows:<list style="hanging">
<t hangText="Dual Handshake:"><list style="hanging">
<t hangText="Latency:">The latency overhead is zero whether
accessing an Upgraded Server or a Legacy Server.</t>
<t hangText="Connection Rate:">The typical connection rate
will inflate by P*D, where: <list style="hanging">
<t hangText="P">[0-100%] is the proportion of connections
that use extra option space;</t>
<t hangText="D">[0-100%] is the proportion of these that
use a dual handshake (the remainder use a single
handshake, e.g. by caching knowledge of upgraded
servers).</t>
</list>For example, if P=80% and D=10%, the connection rate
will inflate by 8%. P is difficult to predict. D is likely to
be small, and in the longer term it should reduce to the
proportion of connections to remaining legacy servers, which
are likely to be the less frequently accessed ones. In the
worst case if both P & D are 100%, the maximum that the
connection rate can inflate by is 100% (i.e. to twice present
levels).</t>
<t hangText="Connection State:">Connection state on servers
and middleboxes will inflate by P*D/R, where<list
style="hanging">
<t hangText="R">is the average hold time of connection
state measured in round trip times</t>
</list>This is because a server or middlebox only holds dual
connection state for one round trip, until the RST on one of
the two connections. For example, keeping P & D as they
were in the above example, if R = 3 round trips {ToDo: TBA},
connection state would inflate by 2.7%. In the longer term,
any extra connection state would be focused on legacy servers,
with none on upgraded servers. Therefore, if memory for dual
handshake flow state was a problem, upgrading the server to
support the Inner Space protocol would solve the problem.</t>
<t hangText="Network Traffic:">The network traffic overhead is
2*H*P*D/J counting in bytes or 2*P*D/K counting in packets,
where<list style="hanging">
<t hangText="H">is 88B for IPv4 or 108B for IPv6 (assuming
the Ordinary SYN and SYN/ACK have a TCP header packed to
the maximum of 60B with TCP options, they have no TCP
payload, their IP headers have no extensions and the
InSpace Option in the SYN-U and SYN/ACK-U is 8B);</t>
<t hangText="J">is the average number of bytes per TCP
connection (in both directions)</t>
<t hangText="K">is the average number of packets per TCP
connection (in both directions);</t>
</list>For example, keeping and P & D as they were in
the above example, if J = 50KiB for IPv4 and K = 70 packets
(ToDo: TBA), traffic overhead would be 0.03% counting in bytes
or 0.2% counting in packets.</t>
<t hangText="Processing:">{ToDo: Implementation tests}</t>
</list></t>
<t
hangText="InSpace Option on every non-empty SYN=0 segment:"><list
style="hanging">
<t hangText="Network Traffic:">The traffic overhead is
P*Q*4/F, where<list style="hanging">
<t hangText="Q">is the proportion of Inner Space
connections that leave the protocol enabled after the
initial handshake;</t>
<t hangText="F">is the average frame size in bytes
(assuming one segment per frame).</t>
</list>This is because the InSpace option adds 4B per
segment. For example, keeping P as it was in the above example
and taking Q=10% and F=750B, the traffic overhead is 0.04%. It
is as difficult to predict Q as it is to predict P.</t>
<t hangText="Processing:">{ToDo: Implementation tests}</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="inspace_Interaction_TCP"
title="Interaction with Pre-Existing TCP">
<t>A TCP option MUST by default only be used as an Outer Option, unless
it is explicitly specified that it can (or must) be used as an Inner
Option. The following list of pre-existing TCP options can be located as
Inner Options:<list style="symbols">
<t>Maximum Segment Size (MSS) <xref target="RFC0793"/>;</t>
<t>SACK-ok <xref target="RFC2018"/>;</t>
<t>Window Scale <xref target="RFC7323"/>;</t>
<t>Multipath TCP <xref target="RFC6824"/>;</t>
<t>TCP Fast Open <xref target="I-D.ietf-tcpm-fastopen"/>;</t>
<t>TCP-AO <xref target="RFC5925"/>;</t>
<t>tcpcrypt <xref target="I-D.bittau-tcpinc"/>.</t>
</list>The following MUST NOT be located as Inner Options:<list
style="symbols">
<t>Timestamp <xref target="RFC7323"/>;</t>
<t>SACK <xref target="RFC2018"/>;</t>
</list>{ToDo: The above list is not authoritative. Many of the above
schemes involve multiple different types of TCP option, and all the
types need to be separately assessed.}</t>
<t>The Inner Space protocol supports TCP Fast Open, by constraining the
client to obey the rules in <xref target="inspace_TFO"/>).</t>
<t>An Upgraded Server can support SYN Cookies <xref target="RFC4987"/>
for Ordinary Connections. For Upgraded Connections <xref
target="inspace_SYN_Cookie"/> defines a new SYNCookie TCP option that is
a prerequisite for InSpace implementations, and provides sufficient
space for the more extensive connection state requirements of an InSpace
server.</t>
<t>The interaction with the assumptions about TCP made by middleboxes is
covered extensively in <xref target="inspace_Option_Proc_F"/>, <xref
target="inspace_Non-Determinism"/>, <xref
target="inspace_Security_Middlebox_Evasion"/>, <xref
target="inspace_Control_in_Sequence"/> and <xref
target="inspace_SentPayloadSize"/>).</t>
<t>{ToDo: TCP API, TCP States and Transitions, Connectionless Resets,
ICMP Handling, Interactions with Other TCP Variants,
Forward-Compatibility.}</t>
</section>
<section anchor="inspace_IANA" title="IANA Considerations">
<t>This specification requires IANA to allocate four values from the TCP
option Kind name-space against the names:<list style="symbols">
<t>"Echo"</t>
<t>"Inner Option Space Upgraded (InSpaceU)"</t>
<t>"Inner Option Space Ordinary (InSpaceO)"</t>
<t>"ModeSwitch"</t>
</list></t>
<t>Early implementation before the IANA allocation MUST follow <xref
target="RFC6994"/> and use experimental option 254 and respective
Experiment IDs:<list style="symbols">
<t>0xEEEE (16 bits);</t>
<t>0xUUUU (16 bits);</t>
<t>0xOOOO (16 bits);</t>
<t>0xMMMM (16 bits);</t>
</list> {ToDo: Values TBA and register them with IANA} then migrate to
the assigned option after allocation.</t>
</section>
<section anchor="inspace_Security_Considerations"
title="Security Considerations">
<t>Certain cryptographic functions have different coverage rules for the
TCP Header and TCP Payload. Placing some TCP options beyond the Data
Offset 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>A malicious host can send bogus SYN segments with a spoofed source IP
address (a SYN flood attack). The Inner Space protocol does not alter
the feasibility of this attack. However, the extra space for TCP options
on a SYN allows the attacker to include more TCP options on a SYN than
before, so it can make a server do more option processing before
replying with a SYN/ACK. A server under stress could deprioritise SYNs
with longer option fields to focus its resources on SYNs that require
less processing.</t>
<t>{ToDo: More?}</t>
<!--Consider whether there are new SYN flood vulnerabilities.-->
</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 idea that it is architecturally preferable to
place a protocol extension within a higher layer, and code its location
into upgraded implementations of the lower layer, was originally
articulated by Rob Hancock. {ToDo: Ref?} The following people provided
useful review comments: Joe Touch, Yuchung Cheng, John Leslie, Mirja
Kuehlewind, Andrew Yourtchenko.</t>
<t>Bob Briscoe's contribution is part-funded by the European Community
under its Seventh Framework Programme through the Trilogy 2 project
(ICT-317756) and the Reducing Internet Transport Latency (RITE) project
(ICT-317700). The views expressed here are solely those of the
author.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC0793;
&RFC2119;
&RFC6994;
&I-D.ietf-tcpm-fastopen;
</references>
<references title="Informative References">
&RFC2018;
&RFC2675;
&RFC5925;
&RFC4987;
&RFC6555;
&RFC6824;
&RFC7323;
&I-D.wing-tsvwg-happy-eyeballs-sctp;
&I-D.bittau-tcpinc;
<reference anchor="Honda11">
<front>
<title>Is it Still Possible to Extend TCP?</title>
<author fullname="Michio Honda" initials="M" surname="Honda">
<organization>Keio University</organization>
</author>
<author fullname="Yoshifumi Nishida" initials="Y" surname="Nishida">
<organization>Keio University</organization>
</author>
<author fullname="Costin Raiciu" initials="C" surname="Raiciu">
<organization>UP Bucharest</organization>
</author>
<author fullname="Adam Greenhalgh" initials="A" surname="Greenhalgh">
<organization>UCL</organization>
</author>
<author fullname="Mark Handley" initials="M" surname="Handley">
<organization>UCL</organization>
</author>
<author fullname="Hideyuki Tokuda" initials="H" surname="Tokuda">
<organization>Keio University</organization>
</author>
<date month="November" year="2011"/>
</front>
<seriesInfo name="Proc. ACM Internet Measurement Conference (IMC'11)"
value="181--192"/>
<format target="http://dl.acm.org/citation.cfm?id=2068834" type="PDF"/>
</reference>
</references>
<section anchor="inspace_Alt_Spec"
title="Protocol Extension Specifications">
<t>This appendix specifies protocol extensions that are OPTIONAL while
the specification is experimental. If an implementation includes an
extension, this section gives normative specification requirements.
However, if the extension is not implemented, the normative requirements
can be ignored.</t>
<t>{Temporary note: The IETF may wish to consider making some of these
extensions mandatory to implement if early testing shows they are useful
or even necessary. Or it may wish to make at least the receiving side
mandatory to implement to ensure that two-ended experiments are more
feasible.}</t>
<section anchor="inspace_Modes"
title="Disabling InSpace and Generic Connection Mode Switching">
<t hangText="InSpace Flags:">This appendix is normative. It is
separated from the body of the specification because it is OPTIONAL to
implement while the Inner Space protocol is experimental. It defines
the new ModeSwitch TCP option illustrated in <xref
target="inspace_Fig_ModeSwitch"/>. This option provides a facility to
disable the Inner Space protocol for the remainder of a connection. It
also provides a general-purpose facility for a TCP connection to
co-ordinate between the endpoints before switching into a
yet-to-be-defined mode.</t>
<figure align="center" anchor="inspace_Fig_ModeSwitch"
title="The ModeSwitch TCP Option">
<artwork><![CDATA[ 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+---------------+---------------+-----------+-+-+
| ModeSwitch | Length=3 |Flags (CU) |I|R|
+---------------+---------------+-----------+-+-+
]]></artwork>
</figure>
<t>The option Kind is ModeSwitch, the value of which is to be
allocated by IANA {ToDo: Value TBA}. ModeSwitch MUST be used only as
an Inner Option, because it uses the reliable ordered delivery
property of Inner Options. Therefore implementation of the Inner Space
protocol is REQUIRED for an implementation of ModeSwitch. Nonetheless,
ModeSwitch is a generic facility for switching a connection between
yet-to-be-defined modes that do not have to relate to extra option
space.</t>
<t>The sender MUST set the option Length to 3 (octets). The Length
field MUST be forwarded unchanged by other nodes, even if its value is
different.</t>
<t hangText="InSpace Flags:">The Flags field is available for defining
modes of the connection. Only two connection modes are currently
defined. The first 6 bits of the Flags field are Currently Unused (CU)
and the sender MUST set them to zero. The CU flags MUST be ignored and
forwarded unchanged by other nodes, even if their value is
non-zero.</t>
<t hangText="InSpace Flags:">The two 1-bit connection mode flags that
are currently defined have the following meanings:<list
style="symbols">
<t>R: Request flag if 1. Request mode is a special mode that
allows the hosts to co-ordinate a change to any other mode(s);</t>
<t>I: Inner Space mode: Enabled if 1, Disabled if 0.</t>
</list>The default Inner Space mode at the start of a connection is
I=1, meaning Inner Space is in enabled mode.</t>
<t>The procedure for changing a mode or modes is as follows:<list
style="symbols">
<t>The host that wants to change modes (the requester) sends a
ModeSwitch message as an Inner Option with R=1 and with the other
flag(s) set to the mode(s) it wants to change to. The requester
does not change modes yet.</t>
<t>The responder echoes the mode flag(s) it is willing to change
to, with the request flag R=0.</t>
<t>The half-connection from the responder changes to the mode(s)
it confirms directly after the end of the segment that echoes its
confirmation, i.e. after the last octet of the TCP Payload
following the ModeSwitch option that echoes its confirmation.
Therefore it sends the segment carrying the confirmation in the
prior mode(s) of the connection.</t>
<t>Once the requester receives the responder's confirmation
message, it re-echoes its confirmation of the responder's
confirmation, with the mode(s) set to those that both hosts agree
on and R=0.</t>
<t>The half-connection from the requester changes to the mode(s)
it confirms directly after the end of the segment that re-echoes
its confirmation. Therefore it sends the segment carrying the
confirmation in the prior mode(s) of the connection.</t>
<t>The responder can refuse a request to change into a mode in any
one of three ways:<list style="symbols">
<t>either implicitly by never confirming it;</t>
<t>or explicitly by sending a message with R=0 and the
opposite mode;</t>
<t>or explicitly be sending a counter-request to switch to the
opposite mode (that the connection is already in) with
R=1.</t>
</list></t>
</list>The regular TCP sequence numbers and acknowledgement numbers
of requests or confirmations can be used to disambiguate overlapping
requests or responses.</t>
<t>Once a host switches to Disabled mode, it MUST NOT send any further
InSpace Options. Therefore it can send no further Inner Options and it
cannot switch back to Enabled mode for the rest of the connection.</t>
<t>To temporarily reduce InSpace overhead without permanently
disabling the protocol, the sender can use a value of 0xFFFF in the
Sent Payload Size (see <xref target="inspace_Exceptions"/>).</t>
</section>
<section anchor="inspace_Dual_Handshake_Explicit"
title="Dual Handshake: The Explicit Variant">
<t>This appendix is normative. It is separated from the body of the
specification because it is OPTIONAL to implement while the Inner
Space protocol is experimental. It is not mandatory to implement
because it will be more useful once the Inner Space protocol has
become accepted widely enough that fewer middleboxes will discard SYN
segments carrying this option (see <xref target="inspace_Compare"/>
for when best to deploy it). It only works if both ends support it,
but it can be deployed one end at a time, so there is no need for
support in early experimental implementations.</t>
<t>{Temporary note: The choice between the explicit handshake in the
present section or the handshake in <xref
target="inspace_Dual_Handshake_Implicit"/> is a tradeoff between
robustness against middlebox interference and minimal server state.
During the IETF review process, one might be chosen as the only
variant to go forward, at which point the other will be deleted.
Alternatively, the IETF could require a server to understand both
variants and a client could be implemented with either, or both. If
both, the application could choose which to use at run-time. Then we
will need a section describing the necessary API.}</t>
<t>This explicit dual handshake is similar to that in <xref
target="inspace_Dual_Handshake_Implicit"/>, except the SYN that the
Upgraded Client sends on the Ordinary Connection is explicitly
distinguishable from the SYN that would be sent by a Legacy Client
(using a simple Outer TCP Option. Then, if the server actually is an
Upgraded Server, it can reset the Ordinary Connection itself, rather
than creating connection state for at least a round trip until the
client resets the connection.</t>
<t>For an explicit dual handshake, the TCP client still sends two
alternative SYNs: a SYN-O intended for Legacy Servers and a SYN-U
intended for Upgraded Servers. The two SYNs MUST 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 includes additional
options within the TCP Data (the SYN-U defined as before in <xref
target="inspace_Structure_Segment-UNH"/>).</t>
<t><xref target="inspace_Tab_3whs_explicit"/> summarises the TCP 3-way
handshake exchange for each of the two SYNs in the two right-hand
columns, between an Upgraded TCP Client (the active opener) and
either:<list style="numbers">
<t>a Legacy Server, in the top half of the table (steps 2-4),
or</t>
<t>an Upgraded Server, in the bottom half of the table (steps
2-4)</t>
</list>The table uses the same layout and symbols as <xref
target="inspace_Tab_3whs_implicit"/> that have already been explained
in <xref target="inspace_Dual_Handshake_Implicit"/>.</t>
<texttable anchor="inspace_Tab_3whs_explicit"
title="Explicit Variant of Dual 3-Way Handshake in Two Server Scenarios">
<ttcol/>
<ttcol align="center"/>
<ttcol>Ordinary Connection</ttcol>
<ttcol>Upgraded Connection</ttcol>
<c>1</c>
<c>Upgraded Client</c>
<c>>SYN-O</c>
<c>>SYN-U</c>
<c/>
<c/>
<c/>
<c/>
<c>/\/\</c>
<c>/\/\/\/\/\/\/\/\</c>
<c>/\/\/\/\/\/\/\/\/\</c>
<c>/\/\/\/\/\/\/\/\/\</c>
<c>2</c>
<c>Legacy Server</c>
<c><SYN/ACK</c>
<c><SYN/ACK</c>
<c/>
<c/>
<c/>
<c/>
<c>3a</c>
<c>Upgraded Client</c>
<c>Waits for response to both SYNs</c>
<c/>
<c/>
<c/>
<c/>
<c/>
<c>3b</c>
<c>"</c>
<c>>ACK</c>
<c>>RST</c>
<c/>
<c/>
<c/>
<c/>
<c>4</c>
<c/>
<c>Cont...</c>
<c/>
<c/>
<c/>
<c/>
<c/>
<c>/\/\</c>
<c>/\/\/\/\/\/\/\/\</c>
<c>/\/\/\/\/\/\/\/\/\</c>
<c>/\/\/\/\/\/\/\/\/\</c>
<c>2</c>
<c>Upgraded Server</c>
<c><RST</c>
<c><SYN/ACK-U</c>
<c/>
<c/>
<c/>
<c/>
<c>3</c>
<c>Upgraded Client</c>
<c/>
<c>>ACK</c>
<c/>
<c/>
<c/>
<c/>
<c>4</c>
<c/>
<c/>
<c>Cont...</c>
</texttable>
<t>As before, an Upgraded Server MUST respond to a SYN-U with a
SYN/ACK-U. Then, the client recognises that it is talking to an
Upgraded Server.</t>
<t>Unlike before, an Upgraded Server MUST respond to a SYN-O with a
RST. However, the client cannot rely on this behaviour, because a
middlebox might strip the Outer TCP Option from the SYN-O, turning it
into a regular SYN before it reaches the server. Then the handshake
would effectively revert to the implicit variant. Therefore the
client's behaviour still depends on which SYN-ACK arrives first, so
its response to SYN-ACKs has to follow the rules specified for the
implicit handshake variant in <xref
target="inspace_Dual_Handshake_Implicit"/>.</t>
<t>The rules for processing TCP options are also unchanged from those
in <xref target="inspace_Option_Proc"/>.</t>
<section anchor="inspace_Structure_SYN-O" title="SYN-O Structure">
<t>The SYN-O is merely a SYN with an extra InSpaceO Outer TCP Option
as shown in <xref target="inspace_Fig_SYN-O_Flag"/>. It merely
identifies that the SYN is opening an Ordinary Connection, but
explicitly identifies that the client supports the Inner Space
protocol.</t>
<figure align="center" anchor="inspace_Fig_SYN-O_Flag"
title="An InSpaceO TCP Option Flag">
<artwork><![CDATA[ 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
| Kind=InSpaceO | Length=2 |
+---------------+---------------+
]]></artwork>
</figure>
<t>An InSpaceO TCP Option has option Kind InSpaceO with value {ToDo:
Value TBA} and MUST have Length = 2 octets.</t>
<t>To use this option, the client MUST place it with the Outer TCP
Options. A Legacy Server will just ignore this TCP option, which is
the normal behaviour for an option that TCP does not recognise <xref
target="RFC0793"/>.</t>
</section>
<section anchor="inspace_Rexmt_explicit"
title="Retransmission Behaviour - Explicit Variant">
<t>If the client receives a RST on one connection, but a short while
after that {ToDo: duration TBA} the response to the SYN-U has not
arrived, it SHOULD retransmit the SYN-U. If latency is more
important than the extra TCP option space, in parallel to any
retransmission, or instead of any retransmission, the client MAY
send a SYN without any InSpace TCP Option, in case this is the cause
of the black-hole. However, the presence of the RST implies that the
SYN with the InSpaceO TCP Option (the SYN-O) 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.</t>
<t>If the client receives no response at all to either the SYN-O or
the SYN-U, it SHOULD solely retransmit one or the other, not both.
If latency is more important than the extra TCP option space, it
SHOULD send a SYN without an InSpaceO TCP Option. Otherwise it
SHOULD retransmit the SYN-U. It MUST NOT retransmit both segments,
because the lack of response could be due to severe congestion.</t>
</section>
<section anchor="inspace_Corner" title="Corner Cases">
<t>There is a small but finite possibility that the Explicit Dual
Handshake might encounter the cases below. The Implicit Handshake
(<xref target="inspace_Dual_Handshake_Implicit"/>) is robust to
these possibilities, but the Explicit Handshake is not, unless the
following additional rules are followed:<list style="hanging">
<t hangText="Both successful:">This could occur if one
load-sharing replica of a server is upgraded, while another is
not. This could happen in either order but, in both cases, the
client aborts the last connection to respond:<list
style="symbols">
<t>The client completes the Ordinary Handshake (because it
receives a SYN/ACK), but then, before it has aborted the
Upgraded Connection, it receives a SYN/ACK-U on it. In this
case, the client MUST abort the Upgraded Connection even
though it would work. Otherwise the client will have opened
both connections, one with Inner TCP Options and one
without. This could confuse the application.</t>
<t>The client completes the Upgraded Connection after
receiving a SYN/ACK-U, but then it receives a SYN/ACK in
response to the SYN-O. In this case, the client MUST abort
the connection it initiated with the SYN-O.</t>
</list></t>
<t hangText="Both aborted:">The client might receive a RST in
response to its SYN-O, then an Ordinary SYN/ACK on its Upgraded
Connection in response to its SYN-U. This could occur i) if a
split connection middlebox actively forwards unknown options but
holds back or discards data in a SYN; or ii) if one load-sharing
replica of a server is upgraded, while another is not. <vspace
blankLines="1"/>Whatever the likely cause, the client MUST still
respond with a RST on its Upgraded Connection. Otherwise, its
Inner TCP Options will be passed as user-data to the application
by a Legacy Server.<vspace blankLines="1"/>If confronted with
this scenario where both connections are aborted, the client
will not be able to include extra options on a SYN, but it might
still be able to set up a connection with extra option space on
all the other segments in both directions using the approach in
<xref target="inspace_No_Data_in_SYN"/>. If that doesn't work
either, the client's only recourse is to retry a new dual
handshake on different source ports, or ultimately to fall-back
to sending an Ordinary SYN.</t>
</list></t>
</section>
<section anchor="inspace_No_Data_in_SYN"
title="Workround if Data in SYN is Blocked">
<t>If a path either holds back or discards data in a SYN-U, but
there is evidence that the server is upgraded from a RST response to
the SYN-O, the strategy below might at least allow a connection to
use extra option space on all the segments except the SYN.</t>
<t>It is assumed that the symptoms described in the 'both aborted'
case (<xref target="inspace_Corner"/>) have occurred, i.e. the
server has responded to the SYN-O with a RST, but it has responded
to the SYN-U with an Ordinary SYN/ACK not a SYN/ACK-U, so the client
has had to RST the Upgraded Connection as well. In this case, the
client SHOULD attempt the following (alternatively it MAY give up
and fall back to opening an Ordinary TCP connection).</t>
<t>The client sends an 'Alternative SYN-U' by including an InSpaceU
Outer TCP Option (<xref target="inspace_Fig_SYN-U_Flag"/>). This
Alternative SYN-U merely flags that the client is attempting to open
an Upgraded Connection. The client MUST NOT include any Inner
Options or InSpace Option or Magic Number. If the previous aborted
SYN/ACK-U acknowledged the data that the client sent within the
original SYN-U, the client SHOULD resend the TCP Payload data in the
Alternative SYN-U, otherwise it might as well defer it to the first
data segment.</t>
<figure align="center" anchor="inspace_Fig_SYN-U_Flag"
title="An InSpaceU Flag TCP option">
<artwork><![CDATA[ 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
| Kind=InSpaceU | Length=2 |
+---------------+---------------+
]]></artwork>
</figure>
<t>An InSpaceU Flag TCP Option has option Kind InSpaceU with value
{ToDo: Value TBA} and MUST have Length = 2 octets.</t>
<t>To use this option, the client MUST place it with the Outer TCP
Options. A Legacy Server will just ignore this TCP option, which is
the normal behaviour for an option that TCP does not recognise <xref
target="RFC0793"/>. Because the client has received a RST from the
server in response to the SYN-O it can assume that the server is
upgraded. So the client probably only needs to send a single
Alternative SYN-U in this repeat attempt. Nonetheless, the RST might
have been spurious. Therefore the client MAY also send an Ordinary
SYN in parallel, i.e. using the Implicit Dual Handshake (<xref
target="inspace_Dual_Handshake_Implicit"/>).</t>
<t>If an Upgraded Server receives a SYN carrying the InSpaceU
option, it MUST continue the rest of the connection as if it had
received a full SYN-U (<xref
target="inspace_Structure_Format-UNH"/>), i.e. by processing any
Outer Options in the SYN-U and responding with a SYN/ACK-U.</t>
</section>
</section>
<section anchor="inspace_Structure_Data-UNJ"
title="Jumbo InSpace TCP Option (only if SYN=0)">
<t>This appendix is normative. It is separated from the body of the
specification because it is OPTIONAL to implement while the Inner
Space protocol is experimental. In experimental implementations, it
will be sufficient to implement the required behaviour for when the
Length of a received InSpace Option is not recognised (<xref
target="inspace_Exceptions"/>).</t>
<t>If the IPv6 Jumbo extension header is used, the SentPayloadSize
field will need to be 4 octets wide, not 2 octets. This section
defines the format of the InSpace Option necessary to support
jumbograms.</t>
<t>If sending a jumbogram, a sender MUST use the InSpace Option format
defined in <xref target="inspace_Fig_InSpace_Data-UNJH"/>. All the
fields have the same meanings as defined in <xref
target="inspace_Format_Segment-UNH"/>, except InOO and SentPayloadSize
use more bits.</t>
<t>When reading a segment, the Jumbo InSpace Option could be present
in a packet that is not a jumbogram (e.g. due to resegmentation).
Therefore a receiver MUST use the Jumbo InSpace Option to work along
the stream irrespective of whether arriving packets are jumbo sized or
not.</t>
<figure align="center" anchor="inspace_Fig_InSpace_Data-UNJH"
title="InSpace Option for a Jumbo Data-UNJH">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-----------------------------------------------------------+---+
| Inner Options Offset (InOO) |Len|
+-----------------------------------------------------------+---+
| Sent Payload Size (SPS) |
+---------------------------------------------------------------+
]]></artwork>
</figure>
</section>
<section anchor="inspace_Structure_Segment-UNT"
title="Upgraded Segment Structure to Traverse DPI boxes">
<t>This appendix is normative. It is separated from the body of the
specification because it is OPTIONAL to implement while the Inner
Space protocol is experimental. An Upgraded Receiver implementation
that has implemented this extension will not be able to use the base
Inner Space protocol if it is sent a segment with this structure.
However, it will at least fall-back naturally to regular TCP
behaviour.</t>
<t>In experiments conducted between 2010 and 2011, <xref
target="Honda11"/> reported that 7 of 142 paths (about 5%) blocked
access to port 80 if the payload was not parsable as valid HTTP. This
variant of the specification has been defined in case experiments
prove that it significantly improves traversal of such deep packet
inspection (DPI) boxes.</t>
<t>This variant starts the TCP Data with the expected app-layer
headers on the first two segments in each direction:<list
style="hanging">
<t hangText="SYN=1:">The structure in <xref
target="inspace_Fig_Structure_Segment-UNT"/>a) is used on a SYN or
SYN/ACK. The sender locates the 4-octet Magic Number A at the end
of the segment. An receiver implementation will check whether
Magic Number A is present at the end of the segment if it does not
first find it at the start of the segment. The sender right-aligns
the 8-octet InSpace Option just before Magic Number A. Then it
right-aligns the Inner Options against the InSpace Option, all
after the end of the TCP Payload. The start of the Inner Options
is therefore 4 * (InOO +3) octets before the end of the segment,
where InOO is read from within the InSpace Option. Although the
InnerOptions are located at the end of the TCP Payload, they are
considered to be applied before the first octet of the TCP
Payload.</t>
<t hangText="SYN=0:">The structure of the first non-SYN segment
that contains any TCP Data is shown in <xref
target="inspace_Fig_Structure_Segment-UNT"/>b). The receiver finds
the second InSpace Option (InSpace#2) offset SPS#1 octets from the
start of the segment, where SPS#1 is the value of Sent Payload
Size that was read from the InSpace Option in the previous (SYN=1)
segment that started the half-connection. Although the Inner
Options are shifted, as for the first segment, they are still
considered to be applied at the start of the TCP Data in this
second segment.</t>
</list></t>
<t>From the second InSpace Option onwards, the structure of the stream
reverts to that already defined in <xref
target="inspace_Structure_Segment-UNH"/>. So the value of Sent Payload
Size (SPS#2) in the second InSpace Option (InSpace #2) defines the
length of any remaining TCP Payload before the end of the first data
segment, as shown.</t>
<figure align="center" anchor="inspace_Fig_Structure_Segment-UNT"
title="Segment Structures to Traverse DPI boxes (not to scale)">
<artwork><![CDATA[ TCP Data
.------------------------'----------------------.
| Inner Options |
a) SYN=1 | .----------'----------. |
+--------+----------+--------+----------+----------+---------+------+
| BaseHdr| OuterOpts| Payload|PrefixOpts|SuffixOpts|InSpace#1|MagicA|
+--------+----------+--------+----------+----------+---------+------+
| DO | | SOO | | | 1 |
`------------------>| `--------->| | Len |<-----'
| | | InOO |<--------' |
|<--------------------' |
b) First SYN=0 segment in either direction
+--------+----------+----------+---------+---------------+----------+
| BaseHdr| OuterOpts| Payload |InSpace#2| Inner Options | Payload |
+--------+----------+----------+---------+---------------+----------+
| DO | SPS#1 | Len | InOO | SPS#2 |
`------------------>`--------->`-------->`-------------->`--------->|
]]></artwork>
<postamble>All offsets are specified in 4-octet (32-bit) words,
except SPS, which is in octets.</postamble>
</figure>
<t>It is recognised that having to work from the end of the first
segment makes processing more involved. Experimental implementation of
this approach will determine whether the extra complexity improves DPI
box traversal sufficiently to make it worthwhile.</t>
</section>
</section>
<section anchor="inspace_Compare" title="Comparison of Alternatives">
<section title="Implicit vs Explicit Dual Handshake">
<t>In the body of this specification, two variants of the dual
handshake are defined:<list style="numbers">
<t>The implicit dual handshake (<xref
target="inspace_Dual_Handshake_Implicit"/>) starting with just an
Ordinary SYN (no InSpaceO flag option) on the Ordinary
Connection;</t>
<t>The explicit dual handshake (<xref
target="inspace_Dual_Handshake_Explicit"/>) starting with a SYN-O
(InSpaceO flag option) on the Ordinary Connection.</t>
</list></t>
<t>Both schemes double up connection state (for a round trip) on the
Legacy Server. But only the implicit scheme doubles up connection
state (for a round trip) on the Upgraded Server as well. On the other
hand, the explicit scheme risks delay accessing a Legacy Server if a
middlebox discards the SYN-O (it is possible that some firewalls will
discard packets with unrecognised TCP options {ToDo: ref?}). <xref
target="inspace_Tab_Imp_v_Exp_HS"/> summarises these points.</t>
<texttable anchor="inspace_Tab_Imp_v_Exp_HS"
title="Comparison of Implicit vs. Explicit Dual Handshake on the Ordinary Connection">
<ttcol/>
<ttcol align="center">SYN (Implicit)</ttcol>
<ttcol align="center">SYN-L (Explicit)</ttcol>
<c>Minimum state on Upgraded Server</c>
<c>-</c>
<c>+</c>
<c/>
<c/>
<c/>
<c>Minimum risk of delay to Legacy Server</c>
<c>+</c>
<c>-</c>
</texttable>
<t>There is no need for the IETF to choose between these. If the
specification allows either or both, the tradeoff can be left to
implementers at build-time, or to the application at run-time.</t>
<t>Initially clients might choose the Implicit Dual Handshake to
minimise delays due to middlebox interference. But later, perhaps once
more middleboxes support the scheme, clients might choose the Explicit
scheme, to minimise state on Upgraded Servers.</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.<list style="hanging">
<t hangText="Option alignment following re-segmentation:">If the
byte-stream is resegmented (e.g. by a connection splitter), the TCP
options within the stream will not necessarily align on 4-octet word
boundaries within the new segments.</t>
</list></t>
<!--A binary flag may need to be associated with the InOO 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 accessed at
<http://datatracker.ietf.org/doc/draft-briscoe-tcpm-inner-space/history/></t>
<t><list style="hanging">
<t
hangText="From draft-briscoe-tcpm-syn-op-sis-02 to draft-briscoe-tcpm-inner-space-00:">The
Inner Space protocol is a development of a proposal called the
SynOpSis (Sister SYN options) protocol. Most of the elements of
Inner Space were in SynOpSis, such as the implicit and explicit dual
handshakes; the use of a magic number to flag the existence of the
option; the various header offsets; and the option processing
rules.<vspace blankLines="1"/>The main technical differences are:
Inner Space extends option space on any segment, not just the SYN;
this advance requires the introduction of the Sent Payload Size
field and a general rearrangement and simplification of the protocol
format; the option processing rules have been extended to assure
compatibility with TFO and one degree of recursion has been
introduced to cater for encryption or compression of Inner Options;
The Echo option has been added to provide a SYN-cookie-like
capability. Also, the default protocol has been pared down to the
bare bones and optional extensions relegated to appendices.<vspace
blankLines="1"/>The main editorial differences are: The emphasis of
the Abstract and Introduction has expanded from a focus on just
extra space using the dual handshake to include much more
comprehensive middlebox traversal. A comprehensive Design Rationale
section has been added.</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:09:18 |