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]