One document matched: draft-briscoe-tcpm-syn-op-sis-00.txt
TCP Maintenance and Minor Extensions (tcpm) B. Briscoe
Internet-Draft BT
Intended status: Experimental July 21, 2014
Expires: January 22, 2015
Extended TCP Option Space in the Payload of an Alternative SYN
draft-briscoe-tcpm-syn-op-sis-00
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 22, 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 22, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Experiment Goals . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Specification . . . . . . . . . . . . . . . . . . . 3
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Alternative (Deterministic) Protocol Specification . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
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.
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.
Briscoe Expires January 22, 2015 [Page 2]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
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
In this method the TCP client sends two alternative SYNs: a regular
SYN intended for legacy servers and SYN-U intended for upgraded
servers. Once it establishes which type of server has responded, it
continues the connection appropriate to that server type and aborts
the other. The SYN intended for upgraded servers (SYN-U) includes
additional options at the end of the payload.
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.
Briscoe Expires January 22, 2015 [Page 3]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
+---+--------------+--------------+----------------+----------------+
| | Legacy | Legacy | Upgraded | Upgraded |
| | Server | Server | Server | Server |
+---+--------------+--------------+----------------+----------------+
| 1 | SYN | SYN-U | SYN | SYN-U |
| 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
{ToDo: explain the table long-hand.}
The SYN-U 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 SYN-OP-SIS TCP options MUST be the final TCP
option right-aligned at the end of the payload (preceded by padding
if necessary), so that the server can find it (using the length of
the whole segment found in the main TCP header).
| EOO | EOO1 |
--------->----------->|
+---------+-----------+---------+-----------+-----------+------------+
| TCP hdr | TCP-Opt#2 | Payload | TCP-Opt#1 | TCP-Opt#3 | SYN-OP-SIS |
+---------+-----------+---------+-----------+-----------+------------+
Figure 1: The Structure of a SYN-U segment
In general, the SYN-OP-SIS TCP option can have different lengths for
different purposes. However, in a SYN-U, the SYN-OP-SIS TCP option
MUST have Length = 8, so that the server can find where it starts (8
octets before the end of the segment). The internal structure of the
SYN-OP-SIS TCP option is defined in Figure 2.
Briscoe Expires January 22, 2015 [Page 4]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
+---------------+---------------+-------------------------------+
| Kind=SYNOPSYS | Length=8 | Magic Number |
+---------------+---------------+---------------+---------------+
| Magic Number (cont) | EOO | EPOO |
+---------------+---------------+---------------+---------------+
Figure 2: SYN-OP-SIS TCP Option for a SYN-U
The SYN-OP-SYS TCP option has Kind SYN-OP-SIS, with a value (TBA)
(See Section 4) and Length = 8. The first 4 octets of the option
contain a magic number (TBA) to reduce the chance that arbitrary data
within the payload will be mistaken for a SYN-OP-SYS TCP option.
It is recognised that it is potentially dangerous to use probability
to determine whether TCP options are hidden within the payload. This
approach has been taken to ensure that the SYN-U is largely
indistinguishable from a regular SYN, in order to maximise the
chances of traversing middleboxes. If this 'stealth' approach is not
preferred, an alternative mode conventional protocol design is
provided in Appendix A.
Two single octet offset fields are placed at the end of the TCP
option:
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 processes the TCP options in a SYN-U 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)
Briscoe Expires January 22, 2015 [Page 5]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
3. Acknowledgements
The idea of this approach grew out of discussions with Joe Touch
while developing draft-touch-tcpm-syn-ext-opt, and with Janar Iyengar
and Olivier Bonaventure.
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.
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 (SYN-OP-
SIS)"
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
6. References
6.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.
6.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.
Briscoe Expires January 22, 2015 [Page 6]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
[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 (Deterministic) Protocol Specification
This appendix is informative and will be deleted before publication.
It documents an alternative protocol arrangement that may be
considered instead of that in Section 2. It is termed
'deterministic' because it uses a more conventional approach for
placement of the SYN-OP-SIS TCP option instead of the probabilistic
approach in 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.
This method is similar in structure to the more robust 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.
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.
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 Server | Upgraded |
| | Server | Server | | Server |
+---+-------------+-------------+-------------------+---------------+
| 1 | SYN-L | SYN-UD | SYN-L | SYN-UD |
| 2 | SYN/ACK | SYN/ACK | SYN/ACK-L; | SYN/ACK-U |
| | | | Discard state | |
| 3 | ACK | RST | Discard SYN/ACK-L | ACK |
| 4 | Cont... | | | Cont... |
+---+-------------+-------------+-------------------+---------------+
Table 2: Overview of 3-Way Handshakes for the Two Alternative SYNs in
Two Server Scenarios
{ToDo: explain the table long-hand.}
In contrast to the more robust method, the SYN intended for a legacy
server is different from a regular SYN, hence it is called a SYN-L.
The SYN-L is merely a SYN with with an extra SYN-OP-SIS flag option
as shown in Figure 3. It merely identifies that the SYN is from a
client that supports SYN-OP-SIS TCP options.
Briscoe Expires January 22, 2015 [Page 7]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
+---------------+---------------+
| Kind=SYNOPSYS | Length=2 |
+---------------+---------------+
Figure 3: A SYN-OP-SIS flag TCP option
The structure of a deterministic SYN-UD segment is more conventional
than the the SYN-U in Section 2, as shown in Figure 4. 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 SYN-OP-SIS TCP options is placed in the
regular TCP option space of the SYN-UD.
| EOO |
--------->|
+---------+-----------+------------+-----------+---------+-----------+
| TCP hdr | TCP-Opt#1 | SYN-OP-SIS | TCP-Opt#3 | Payload | TCP-Opt#2 |
+---------+-----------+------------+-----------+---------+-----------+
Figure 4: The Structure of an alternative (deterministic) SYN-UD
segment
The SYN-OP-SYS TCP option for a SYN-UD segment MUST have Kind SYN-OP-
SIS, with a value (TBA) (See Section 4) and Length = 3. In general,
the SYN-OP-SIS TCP option can have different lengths for different
purposes. However, in a SYN-UD, the SYN-OP-SIS TCP option has Length
= 3, so that it can carry the 1-octet EOO field, which MUST be
present in a SYN-UD. The internal structure of the SYN-OP-SIS TCP
option for a SYN-UD segment is defined in Figure 5.
+---------------+---------------+---------------+
| Kind=SYNOPSYS | Length=3 | EOO |
+---------------+---------------+---------------+
Figure 5: SYN-OP-SIS 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 a payload is not required,
EOO will be zero, but it MUST still be present.
Briscoe Expires January 22, 2015 [Page 8]
Internet-Draft Ext TCP Options in an Alt SYN Payload July 2014
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
SYN-OP-SIS TCP option (TCP-Opt#1 in Figure 4)
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
SYN-OP-SIS TCP option (TCP-Opt#3 in Figure 4);
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 22, 2015 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-22 07:42:24 |