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
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.
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 (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 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.
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.
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.
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).
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.
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.
Legacy Server | Legacy Server | Upgraded Server | Upgraded Server | |
---|---|---|---|---|
1 | SYN | SYN-U | SYN | SYN-U |
2 | SYN/ACK | SYN/ACK | SYN/ACK | SYN/ACK-U |
3 | ACK | RST | Wait for SYN/ACK-U | ACK |
4 | Cont... | RST | Cont... |
{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.
+---------------+---------------+-------------------------------+ | 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:
An upgraded server processes the TCP options in a SYN-U in the following order:
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.
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.
[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. |
[I-D.ietf-tcpm-fastopen] | Cheng, Y., Chu, J., Radhakrishnan, S. and A. Jain, "TCP Fast Open", Internet-Draft draft-ietf-tcpm-fastopen-09, 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. |
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 Server | Legacy Server | Upgraded Server | Upgraded Server | |
---|---|---|---|---|
1 | SYN-L | SYN-UD | SYN-L | SYN-UD |
2 | SYN/ACK | SYN/ACK | SYN/ACK-L; Discard state | SYN/ACK-U |
3 | ACK | RST | Discard SYN/ACK-L | ACK |
4 | Cont... | Cont... |
{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.
+---------------+---------------+ | 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.
An upgraded server processes the TCP options in a SYN-UD in the following order: