TCP Maintenance and Minor Extensions (tcpm) B. Briscoe
Internet-Draft BT
Intended status: Experimental July 22, 2014
Expires: January 23, 2015
Extended TCP Option Space in the Payload of an Alternative SYN
draft-briscoe-tcpm-syn-op-sis-01
Abstract
This document describes an experimental method to extend the option
space for connection parameters within the initial TCP SYN segment at
the start of a TCP connection. In this method the TCP client sends
two alternative SYNs: one intended for legacy servers and one
intended for upgraded servers. Once it establishes which type of
server has responded, it continues the connection appropriate to that
server type and aborts the other. The SYN intended for upgraded
servers includes additional options at the end of the payload.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 23, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Briscoe Expires January 23, 2015 [Page 1]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Experiment Goals . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Specification . . . . . . . . . . . . . . . . . . . 3
3. Interaction with TCP . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Alternative Protocol Specifications . . . . . . . . 8
A.1. Deterministic Protocol Specification . . . . . . . . . . 8
A.2. Non-Deterministic Explicit Protocol Specification . . . . 11
A.3. Deterministic Implicit Protocol Specification . . . . . . 11
A.4. Comparison of Alternatives . . . . . . . . . . . . . . . 12
Appendix B. Protocol Design Issues (to be Deleted before
Publication) . . . . . . . . . . . . . . . . . . . . 13
Appendix C. Change Log (to be Deleted before Publication) . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
This document describes an experimental method to extend the option
space available in the initial SYN segment of a TCP connection (i.e.
SYN set and ACK not set) [RFC0793]. This extension is required to
support some combinations of TCP options, notably large ones such as
TCP AO [RFC5925] (16B), Multipath TCP [RFC6824] (12B), and TCP Fast
Open [I-D.ietf-tcpm-fastopen] (6-18B) as well as other options
already typically used in TCP connections, such as SACK-ok (2B),
Timestamp (10B), Window Scale (3B), MSS (4B) .
In this method the TCP client sends two alternative SYNs: one
intended for legacy servers and one intended for upgraded servers.
Once it establishes which type of server has responded, it continues
the connection appropriate to that server type and aborts the other.
The SYN intended for upgraded servers includes additional options at
the end of the payload.
Briscoe Expires January 23, 2015 [Page 2]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
1.1. Scope
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.
1.2. Experiment Goals
TCP is critical to the robust functioning of the Internet, therefore
any proposed modifications to TCP need to be thoroughly tested. The
present specification describes an experimental protocol that
provides extra option space on the initial TCP SYN segment. The
intention is to specify the protocol sufficiently so that more than
one implementation can be built in order to test its function,
robustness and interoperability (with itself, with previous version
of TCP, and with various commonly deployed middleboxes).
Success criteria: The experimental protocol will be considered
successful if it satisfies the following requirements in the
consensus opinion of the IETF tcpm working group. {ToDo: describe
success criteria}
Duration: To be credible, the experiment will need to last at least
12 months from publication of the present specification. If
successful, a report on the experiment will be written up. it
would then be appropriate to work on a standards track
specification, in which the experiment report may be included.
1.3. Terminology
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 [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.
2. Protocol Specification
This method is termed the non-deterministic method to distinguish it
from similar alternative methods specified in Appendix A. In this
method the TCP client sends two alternative SYNs: a regular SYN
intended for legacy servers and a SYN-UN intended for upgraded
servers. The two SYNs will have the same network addresses and the
same destination port, but different source ports. Once it
establishes which type of server has responded, it continues the
connection appropriate to that server type and aborts the other. The
Briscoe Expires January 23, 2015 [Page 3]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
SYN intended for upgraded servers (SYN-UN) includes additional
options at the end of the payload. The options are placed at the end
of the payload to ensure that the SYN-UN is more likely to traverse
middleboxes that inspect application-layer headers, which they expect
to be at the start of the payload.
Table 1 summarises the TCP 3-way handshake exchange for each of the
two SYNs between an upgraded TCP (active opening) client and either
i) a legacy server or ii) an upgraded server.
+---+--------------+--------------+----------------+----------------+
| | Legacy | Legacy | Upgraded | Upgraded |
| | Server | Server | Server | Server |
+---+--------------+--------------+----------------+----------------+
| 1 | SYN | SYN-UN | SYN | SYN-UN |
| 2 | SYN/ACK | SYN/ACK | SYN/ACK | SYN/ACK-U |
| 3 | ACK | RST | Wait for | ACK |
| | | | SYN/ACK-U | |
| 4 | Cont... | | RST | Cont... |
+---+--------------+--------------+----------------+----------------+
Table 1: Overview of 3-Way Handshakes for the Two Alternative SYNs in
Two Server Scenarios: Non-Deterministic Alternative
{ToDo: explain the table long-hand.}
If the client receives a response to the SYN, but not the SYN-UN, it
SHOULD retransmit the SYN-UN. In parallel to any retransmission, or
instead of any retransmission, the client MAY give up on the SYN-UN
connection and complete the 3-way handshake of the other regular
connection. If the client receives no response at all, it SHOULD
solely retransmit the SYN. It MUST NOT retransmit both segments,
because the lack of response could be due to severe congestion.
The SYN-UN is structured as shown in Figure 1. It can be seen that
TCP options are placed at the end of the payload at an offset from
the start of the payload defined using the Extra Options Offset (EOO)
field.
The EOO field is read from a new 'SYN-OP-SYS' TCP option defined in
this specification. The SynOpSis TCP options MUST be the final TCP
option right-aligned at the end of the payload (preceded by padding
options if necessary), so that the server can find it (using the
length of the whole packet found in the network layer header, e.g.
IPv4 or IPv6).
Briscoe Expires January 23, 2015 [Page 4]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
| EOO | EPOO |
,-------->,---------->|
+---------+-----------+---------+-----------+-----------+----------+
| TCP hdr | TCP-Opt#2 | Payload | TCP-Opt#1 | TCP-Opt#3 | SynOpSis |
+---------+-----------+---------+-----------+-----------+----------+
Figure 1: The Structure of a SYN-UN segment (not to scale)
The SynOpSis TCP option has Kind SynOpSis, with a value (TBA) (See
Section 4). In general, the SynOpSis TCP option can have different
lengths for different purposes. However, in a SYN-UN, the SynOpSis
TCP option MUST have Length = 8, so that the server can find where it
starts (8 octets before the end of the segment).
The internal structure of the SynOpSis TCP option for a SYN-UN is
defined in Figure 2. The SynOpSis TCP option for a SYN-UN MUST have
Length = 8. The first 4 octets of the option contain a magic number
(TBA) to reduce the chance that arbitrary data within the payload
will be mistaken for a SynOpSis TCP option.
+---------------+---------------+-------------------------------+
| Kind=SynOpSis | Length=8 | Magic Number |
+---------------+---------------+---------------+---------------+
| Magic Number (cont) | EOO | EPOO |
+---------------+---------------+---------------+---------------+
Figure 2: SynOpSis TCP Option for a SYN-UN
Two single octet offset fields are placed at the end of the SynOpSis
TCP option for a SYN-UN:
The Extra Options Offset (EOO): The EOO field defines the offset in
4-octet words from the start of the payload to the start of the
first extra TCP option at the end of the payload. If a payload is
not required, EOO will be zero.
The Extra Prefix Options Offset: The EPOO field defined an
additional offset from the start of the extra TCP options in order
to identify any extra TCP options that need to be processed before
any regular TCP options in the SYN-U. The EPOO field defines this
offset in 4-octet words.
An upgraded server determines whether there is a SynOpSis TCP option
at the end of the packet by checking all the following conditions:
o The Kind value is the SynOpSis Kind value;
Briscoe Expires January 23, 2015 [Page 5]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
o The length is 8;
o The next 4 octets match the magic number;
o The sum of the value of the EOO field, and all the length fields
found by walking along the TCP options at the end of the payload
exactly reaches the end of the packet.
If any of these conditions fails, the server MUST treat the whole
payload as user-data.
With this non-deterministic approach, there will be a very small
probability (roughly 2^{-48-L}) that payload data on a regular (non-
SynOpSis) SYN will happen to contain a pattern in exactly the right
place that matches the magic number, and that the payload data also
happens to contain a valid sequence of numbers in exactly the right
places to look like a valid string of TCP options (where L is the sum
of all the bits in all the TCP option length fields that seem to be
in the payload). For instance, if it appears that there are 2 TCP
options before the SynOpSis option at the end of the payload, then
L=2*8=16, and the probability of incorrectly using user-data as TCP
options will then be roughly 2^(-64) = 1 in 18 billion billion
(18x10^18).
It is recognised that it is potentially dangerous to use probability
to determine whether TCP options are hidden at the end of the
payload. This 'stealth' approach has been taken in order to maximise
the chances of traversing middleboxes; by ensuring that all the TCP
headers and options of a SYN-UN are completely indistinguishable from
a regular SYN. If this non-deterministic approach is not preferred,
an alternative more conventional deterministic protocol designs is
provided in Appendix A.
An upgraded server processes the TCP options in a SYN-UN in the
following order:
1. The Prefix TCP options (TCP-Opt#1 in Figure 1)
2. The regular TCP options following the main header but before the
payload (TCP-Opt#2 in Figure 1);
3. The Suffix TCP options (TCP-Opt#3 in Figure 1)
SYN/ACK-U carries a simple SynOpSis flag TCP option as defined in
Figure 3. It solely identifies that the SYN/ACK is from a server
that supports SynOpSis TCP options.
Briscoe Expires January 23, 2015 [Page 6]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
+---------------+---------------+
| Kind=SynOpSis | Length=2 |
+---------------+---------------+
Figure 3: A SynOpSis flag TCP option
3. Interaction with TCP
{ToDo: TCP User Interface, TCP States and Transitions, TCP Segment
Processing, Processing and Segment Size Overhead, Connectionless
Resets, ICMP Handling. Interaction with EDO, Interactions with Other
TCP Variants, Forward-Compatibility, Interaction with TCP assumptions
of Middleboxes. }
4. IANA Considerations
This memo will include a request to IANA for a new TCP option kind
SynOpSis.
This specification requires IANA to allocate one value from the TCP
option Kind name-space, against the name "Sister SYN Options
(SynOpSis)"
Early implementation before the IANA allocation MUST follow [RFC6994]
and use experimental option 254 and magic number 0xHHHH (16 bits)
{ToDo TBA and register this with IANA}, then migrate to the new
option after the allocation.
5. Security Considerations
Certain cryptographic functions have different coverage rules for the
TCP payload and TCP options. Placing some TCP options in the payload
could mean that they are treated differently from regular TCP
options. This is a deliberate feature of the protocol, but
application developers will need to be aware that this is the case.
{ToDo: More}
6. Acknowledgements
The idea of this approach grew out of discussions with Joe Touch
while developing draft-touch-tcpm-syn-ext-opt, and with Jana Iyengar
and Olivier Bonaventure. The following people provided useful review
comments: Joe Touch, Yuchung Cheng.
Briscoe Expires January 23, 2015 [Page 7]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
Bob Briscoe was part-funded by the European Community under its
Seventh Framework Programme through the Trilogy 2 project (ICT-
317756). The views expressed here are solely those of the authors.
7. References
7.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC
6994, August 2013.
7.2. Informative References
[I-D.ietf-tcpm-fastopen]
Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", draft-ietf-tcpm-fastopen-09 (work in
progress), July 2014.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013.
Appendix A. Alternative Protocol Specifications
This appendix is informative and will be deleted before publication.
It documents alternative protocol arrangements that may be considered
instead of the non-deterministic protocol in Section 2.
A.1. Deterministic Protocol Specification
This alternative protocol arrangement is termed the Deterministic
SynOpSis protocol. It is termed 'deterministic' because it uses a
more conventional approach for placement of the SynOpSis TCP option
instead of the non-deterministic approach in Section 2. However, it
is likely to be less practical, given it uses TCP options in the
clear, hoping that they will traverse middleboxes, which will not
always be successful.
Briscoe Expires January 23, 2015 [Page 8]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
This method is similar in structure to the non-deterministic method
in Section 2. The TCP client still sends two alternative SYNs: SYN-L
intended for legacy servers and SYN-UD intended for upgraded servers.
The two SYNs will have the same network addresses and the same
destination port, but different source ports. Once the client
establishes which type of server has responded, it continues the
connection appropriate to that server type and aborts the other. The
SYN intended for upgraded servers (SYN-UD) includes additional
options at the end of the payload. The options are placed at the end
of the payload to ensure that the SYN-UD is more likely to traverse
middleboxes that inspect application-layer headers, which they expect
to be at the start of the payload.
Table Table 2 summarises the TCP 3-way handshake exchange for each of
the two SYNs between an upgraded TCP (active opening) client and
either i) a legacy server or ii) an upgraded server.
+---+--------------+--------------+----------------+----------------+
| | Legacy | Legacy | Upgraded | Upgraded |
| | Server | Server | Server | Server |
+---+--------------+--------------+----------------+----------------+
| 1 | SYN-L | SYN-UD | SYN-L | SYN-UD |
| 2 | SYN/ACK | SYN/ACK | RST | SYN/ACK-U |
| 3 | ACK | RST | | ACK |
| 4 | Cont... | | | Cont... |
+---+--------------+--------------+----------------+----------------+
Table 2: Overview of 3-Way Handshakes for the Two Alternative SYNs in
Two Server Scenarios: Deterministic Alternative
{ToDo: Explain the table long-hand.}
If the client receives a RST on one connection and no response on the
other, it SHOULD retransmit the SYN that got no response. In
parallel to any retransmission, or instead of any retransmission, the
client MAY send a SYN without any SynOpSis option, in case this is
the cause of the black-hole. However, the presence of the RST
implies that one of the SYNs with a SynOpSis TCP option probably
reached the server, therefore it is more likely (but not certain)
that the lack of response on the other connection is due to
transmission loss or congestion loss. If the client receives no
response at all, it SHOULD fall-back to sending a regular SYN with no
SynOpSis option. It MUST NOT retransmit both segments, because the
lack of response could be due to severe congestion.
In contrast to the more robust method, the SYN intended for a legacy
server is different from a regular SYN, hence it is called a SYN-L.
The SYN-L is merely a SYN with with an extra SynOpSis flag option as
Briscoe Expires January 23, 2015 [Page 9]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
shown in Figure 3. It solely identifies that the SYN is from a
client that supports SynOpSis TCP options.
The placement of the SynOpSis TCP option in a deterministic SYN-UD
segment is more conventional than in the SYN-U of Section 2, as shown
in Figure 4. Nonetheless, it can be seen that extra TCP options are
stlil placed at the end of the payload at an offset from the start of
the payload defined using the Extra Options Offset (EOO) field.
The EOO field is read from a new 'SYN-OP-SYS' TCP option defined in
this specification. The SynOpSis TCP options is placed in the
regular TCP option space of the SYN-UD.
| EOO |
,-------->|
+---------+-----------+----------+-----------+---------+-----------+
| TCP hdr | TCP-Opt#1 | SynOpSis | TCP-Opt#3 | Payload | TCP-Opt#2 |
+---------+-----------+----------+-----------+---------+-----------+
Figure 4: The Structure of an alternative (deterministic) SYN-UD
segment (not to scale)
The SYN-OP-SYS TCP option for a SYN-UD segment MUST have Kind
SynOpSis, with a value (TBA) (See Section 4) and Length = 3. In
general, the SynOpSis TCP option can have different lengths for
different purposes. However, in a SYN-UD, the SynOpSis TCP option
has Length = 3, so that it can carry the 1-octet EOO field, which
MUST be present in a SYN-UD. The internal structure of the SynOpSis
TCP option for a SYN-UD segment is defined in Figure 5.
+---------------+---------------+---------------+
| Kind=SynOpSis | Length=3 | EOO |
+---------------+---------------+---------------+
Figure 5: SynOpSis TCP Option for a deterministic SYN-UD
The Extra Options Offset (EOO) field defines the offset in 4-octet
words from the start of the payload to the start of the first extra
TCP option at the end of the payload. If space for payload data is
not required, EOO will be zero, but it MUST still be present.
An upgraded server processes the TCP options in a SYN-UD in the
following order:
1. The regular TCP options following the main header but before the
SynOpSis TCP option (TCP-Opt#1 in Figure 4)
Briscoe Expires January 23, 2015 [Page 10]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
2. The TCP options at the end of the payload (TCP-Opt#2 in Figure 4)
3. The regular TCP options following the main header but after the
SynOpSis TCP option (TCP-Opt#3 in Figure 4);
A.2. Non-Deterministic Explicit Protocol Specification
The protocol outlined in Table 3 is a hybrid of the two approaches in
Section 2 and Appendix A.1.
+---+--------------+--------------+----------------+----------------+
| | Legacy | Legacy | Upgraded | Upgraded |
| | Server | Server | Server | Server |
+---+--------------+--------------+----------------+----------------+
| 1 | SYN-L | SYN-UN | SYN-L | SYN-UN |
| 2 | SYN/ACK | SYN/ACK | RST | SYN/ACK-U |
| 3 | ACK | RST | | ACK |
| 4 | Cont... | | | Cont... |
+---+--------------+--------------+----------------+----------------+
Table 3: Overview of 3-Way Handshakes for the Two Alternative SYNs in
Two Server Scenarios: Non-Deterministic Explicit Alternative
The SYN-L might not traverse middleboxes, therefore connections with
legacy servers could suffer from the added latency of a
retransmission. Nonetheless, if it does reach an upgraded server,
the server knows explicitly that the client supports SynOpSis TCP
options and can abort the connection without having had to hold any
state.
The SYN-UN has the advantage that it is all-but indistinguishable
from a regluar SYN, therefore it is likely to traverse most
middleboxes. However, there is a tiny chance that an upgraded server
might mistake some arbitrary payload for a SYN-U, if data happens to
match the magic number.
A.3. Deterministic Implicit Protocol Specification
The protocol outlined in Table 4 is a hybrid of the two approaches in
Section 2 and Appendix A.1.
Briscoe Expires January 23, 2015 [Page 11]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
+---+--------------+--------------+----------------+----------------+
| | Legacy | Legacy | Upgraded | Upgraded |
| | Server | Server | Server | Server |
+---+--------------+--------------+----------------+----------------+
| 1 | SYN | SYN-UD | SYN | SYN-UD |
| 2 | SYN/ACK | SYN/ACK | SYN/ACK | SYN/ACK-U |
| 3 | tACK | RST | Wait for | ACK |
| | | | SYN/ACK-U | |
| 4 | Cont... | | RST | Cont... |
+---+--------------+--------------+----------------+----------------+
Table 4: Overview of 3-Way Handshakes for the Two Alternative SYNs in
Two Server Scenarios: Deterministic Implicit Alternative
The regular SYN will traverse middleboxes so there will be no latency
problems reaching legacy servers. However an upgraded server cannot
know that it comes from a client that supports SynOpSis TCP options,
therefore it has to open connection state for both connections until
the client explicitly aborts the one intended for a legacy server.
The SYN-UD has the advantage that an upgraded server cannot
occasionally mistake payload data for TCP options. However, this
approach could introduce latency reaching an upgraded server, if the
SYN-UD does not traverse a middlebox.
A.4. Comparison of Alternatives
The four solutions in sections 2, A.1, A.2 & A.3, each suffer from
two of the following four failings:
Risk Delay Accessing Legacy Server: due to the SYN intended for a
legacy server being non-normal and therefore at risk of drop by a
middlebox;
Risk Delay Accessing Upgraded Server: due to the SYN intended for an
upgraded server being non-normal and therefore at risk of drop by
a middlebox;
Doubles Upgraded Server State within RTT: because the server has to
hold the second connection's state until the client resets it;
Risk of Upgraded Server Mistaking User-Data for TCP Options: due to
use of the probabilistic magic number technique.
All four schemes double up connection state on the legacy server for
a round trip.
Briscoe Expires January 23, 2015 [Page 12]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
Table 5 places a tick ('/') against the combinations of SYNs that are
better in each respect.
+----------+--------------+------------+---------------+------------+
| | Non- | Determin- | Non-Determin- | Determin- |
| | Determin- | istic | istic | istic |
| | istic | | Explicit | Implicit |
+----------+--------------+------------+---------------+------------+
| | SYN + SYN-UN | SYN-L + | SYN-L + SYN- | SYN + SYN- |
| | | SYN-UD | UN | UD |
| | | | | |
| Min | / | X | X | / |
| Delay to | | | | |
| Legacy | | | | |
| Svr | | | | |
| Min | / | X | / | X |
| Delay to | | | | |
| Upgraded | | | | |
| Svr | | | | |
| Min | X | / | / | X |
| State on | | | | |
| Upgraded | | | | |
| Svr | | | | |
| User- | X | / | X | / |
| Data Unm | | | | |
| istakeab | | | | |
| le | | | | |
+----------+--------------+------------+---------------+------------+
Table 5: Comparison of the Four Alternative Solutions
It should be noted that there is no need for the IETF to choose a
single pair of SYNs. Once the SynOpSis TCP options are defined,
clients can use their own choices of pairs in different cicumstances.
Initially clients might choose the Non-Deterministic scheme to
minimise delays due to middlebox interference. But later, perhaps
once more middleboxes support the scheme, clients might choose the
Non-Deterministic Explicit scheme, to minimise both state and delay
with the upgraded server.
Appendix B. Protocol Design Issues (to be Deleted before Publication)
This appendix is informative, not normative. It records outstanding
issues with the protocol design that will need to be resolved before
publication.
Reliance on segmentation boundary: The definition of the position of
the SynOpSis TCP options depends on where the sender decided to
Briscoe Expires January 23, 2015 [Page 13]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
place a segment boundary. In general, a sender cannot rely on
segment boundaries being preserved, e.g. by segmentation
offloading hardware. In the case of a SYN, no more payload data
is sent in the first round trip, therefore using this segment
boundary might be safe. However, it may constrain future attempts
to send additional data in the first round.
Appendix C. Change Log (to be Deleted before Publication)
A detailed version history can be accesssed at
<http://datatracker.ietf.org/doc/draft-briscoe-tcpm-syn-op-sis/
history/>
From briscoe...-00 to briscoe...-01:
Technical changes:
* Added the definition of a SYN/ACK-U
* Deterministic Protocol Spec: Replaced SYN/ACK-L with RST (Joe
Touch)
* Added Non-Deterministic Explicit and Deterministic Implicit
Protocol Specs in Appendices
* Added Comparison of Alternatives as an Appendix
* Security Considerations: Added note about crypto coverage of
TCP options in the payload being different from that of other
TCP options.
* Added an appendix to record outstanding Protocol Design Issues,
and included segmentation boundary issue (Yuchung Cheng).
Editorial changes:
* Changed TCP option Kind from SYN-OP-SIS to SynOpSis
* Protocol Spec: Explained why the extra TCP options are placed
at the end of the payload
* Throughout: avoided the ambiguity in the word payload, now that
there are TCP options at the end of the payload. Some might
consider these to be within the payload, while others might
consider them to be placed beyond the payload.
* Segment structure figures: Clarified that they are not to
scale.
Briscoe Expires January 23, 2015 [Page 14]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
* Added placeholder section "Interaction with TCP"
* Acknowledged reviewers
Author's Address
Bob Briscoe
BT
B54/77, Adastral Park
Martlesham Heath
Ipswich IP5 3RE
UK
Phone: +44 1473 645196
Email: bob.briscoe@bt.com
URI: http://bobbriscoe.net/
Briscoe Expires January 23, 2015 [Page 15]