TCPM Working Group Y. Nishida Internet-Draft AWS Intended status: Informational 23 October 2022 Expires: 26 April 2023 Aggregated Option for SYN Option Space Extension draft-nishida-tcpm-agg-syn-ext-01 Abstract TCP option space is scarce resource as its max length is limited to 40 bytes. This limitation becomes more significant in SYN segments as all options used in a connection should be exchanged during SYN negotiations. This document proposes a new SYN option negotiation scheme that can aggregate multiple TCP options in SYN segments into a single option so that more options can be negotiate during 3 way handshake. With its simple design, the approach does not require fundamental changes in TCP. 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 https://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 26 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Nishida Expires 26 April 2023 [Page 1] Internet-Draft Aggregated_SynOpt October 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Aggregated Option Design . . . . . . . . . . . . . . . . . . 4 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Option Bits Registration . . . . . . . . . . . . . . . . 6 3.3. Utilizing 3rd and 4th Segments for Further Negotiations . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5.1. Aggregated Option . . . . . . . . . . . . . . . . . . . . 6 5.2. Option Bits Registry for Aggregated Option . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction TCP option space is scarce resource as its max length is limited to 40 bytes. This limitation is a nominal issue especially for SYN segment. This is because although a TCP endpoint can send only one SYN segment to the peer, SYN segments need to contain all options expected to be used for the connection. As a result, the current SYN option space tends to be congested. Many TCP connections use MSS [RFC9293], Timestamp and Window Scale [RFC7323], SACK Permitted options [RFC2018] which already consume 19 bytes (10 + 4 + 3 + 2). In addition to them, if a connection wants to use Multipath TCP [RFC8684], it requires additional 4-12 bytes for MP_CAPABLE or 12-16 bytes for MP_JOIN option. Similarly, TCP Fast Open [RFC7413] and TCP AO [RFC5925] require additional 6-18 bytes and 16 bytes respectively. Moreover, Experimental Option Format defined in [RFC6994] requires 16 bits or 32 bits EXID, which means the length of any experimental options will have at least 4 bytes. Nishida Expires 26 April 2023 [Page 2] Internet-Draft Aggregated_SynOpt October 2022 If an endpoint is willing to add some of extra options in addition to commonly used options, 40 bytes space may not be sufficient. If a SYN segment cannot accommodate all options that an endpoint wants to use, the endpoint needs to give up using some of them. This problem affects the extensibility of TCP. There have been various proposals in order to extend option space in SYN Segments such as [I-D.eddy-tcp-loo] [I-D.yourtchenko-tcp-loic] [I-D.touch-tcpm-tcp-syn-ext-opt] [I-D.briscoe-tcpm-inner-space] [I-D.allman-tcpx2-hack]. These proposals have adopted one or both of the following two types of approach. o Extending TCP header in SYN segment: This approach tries to accommodate more options in a SYN segment by using payload. (E.g override Data Offset field in TCP header) o Using Multiple SYN or SYN-like segment: This approach tries to use multiple SYN segment or additional segment that can be treated as a SYN segment. (E.g sending another SYN with wrong checksum or from different source port) However, these approach require a certain complexity as it needs to update fundamental design of TCP and have potential risks for middlebox interventions because of it. Instead, we propose a very simple approach that can aggregate multiple TCP options into a single options. As this approach does not require drastic changes in TCP SYN negotiation scheme, the risk for middlebox interventions will be minimized. One limitations of this approach is that it cannot aggregate all kinds of options. However, we believe it still will be useful especially for newly defined experimental options. One example use case is [I-D.gomez-tcpm-ack-rate-request]. In order to use the feature proposed in the draft, endpoints need to exchange a 4 bytes TCP option during 3 way handshake so that it can confirm the peer is capable of the feature. However, whether an endpoint supports the feature or not is just 1 bit information. Using 4 bytes field to carry 1 bit information looks redundant. On the other hand, Aggregated Option can accommodate up to 24 TCP options like this example into a single TCP option. Also, even if more than 1 bit information needs to be carried in a TCP option for a certain feature, it is still possible to utilize aggregated options in some cases. In this case, at first, an endpoint confirms that the peer supports the feature it wants to use by using aggregated option. After that, it can negotiate required parameters through 3rd segment and 4th segment. This type of approach is used in MPTCP [RFC8684]. Nishida Expires 26 April 2023 [Page 3] Internet-Draft Aggregated_SynOpt October 2022 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Aggregated Option Design 3.1. Option Format This aggregated option can be used to indicate that an endpoint wants to enable the specified features during SYN segment exchanges. This option uses one bit in the option field for one TCP option. The receiver of the option also use this option to indicate that it agrees to use the requested features or not. The format of aggregated option format is shown in Figure 1. The option contains 1 bytes field named called "Aggregated Block". Aggregated Option can accommodate 1-3 Aggregated Blocks. 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 +--------------+---------------+---------------+- - - - - - - - | Kind = TBD | Length = 3-5 | Block #1 | Block #2 | +--------------+---------------+---------------+- - - - - - - - | Block #3 | - - - - - - - - Figure 1: Aggregated Option format Figure 2 shows the format of Aggregated block. Aggregated block has 1 byte length which consists of 2 bits "Group ID" (GID) field and 6 bits "Option Bits" field. The options supported by Aggregated Option is split into 4 groups, Group ID field is used to identify the group identifier of the option bits in the Aggregated Option and each single bit in Option Bits field represent a option in the group. If all options that an endpoint wants to aggregate belong to the same Group ID, the aggregated option needs to contain only one Aggregated Block. Otherwise, it needs to contain multiple blocks. 0 1 2 3 4 5 6 7 +----------------------+ | GID | Option Bits | +----------------------+ Figure 2: Aggregated Block format Nishida Expires 26 April 2023 [Page 4] Internet-Draft Aggregated_SynOpt October 2022 GID field in Aggregated Block indicate the group ID that option bits in the block belongs to. Aggregated Blocks are appeared in SYN and SYN ACK segments, however, different mappings between GID value in the option and Group ID are used for these two segments. This is because some implementations may copy back unknown options in SYN/ACK segments. These mappings is used not to be confused by such cases. Figure 3 shows the mapping between GID value in the option and Group ID. For example, GID value 1 in SYN represents group 2, while GID value 1 in ACK segment for SYN ACK represents group 1. +------------------+----------------------+----------------------+ | GID value in SYN | GID value in SYN ACK | Group ID Description | +------------------+----------------------+----------------------+ | 0 | 1 | group 1 | | | | | | 1 | 2 | group 2 | | | | | | 2 | 3 | group 3 | | | | | | 3 | 0 | group 4 | +------------------+----------------------+----------------------+ Figure 3: Mapping between GID value and Group ID The allocation of the bit in Option Bits field in each group will be managed by the registry provided by IANA. Since an aggregated block has 6 bits field to indicate options, one group can have 6 options at most. As a result, the maximum number of options that can be used with Aggregated Option will be limited to 24. We believe this is sufficient number for the time being based on the current usage of option code points. Aggregated Option MUST be only used in SYN segments. When an endpoint received SYN segments with Aggregated Option, it checks Aggregated Blocks in the option. Otherwise, he segment MUST be silently discarded. If it contains Aggregated Blocks, the options specified in the blocks MUST be processed as well as options in original formats. When a responder sends back SYN ACK to the initiator, it SHOULD send back its response with Aggregated Option. But, it MAY uses original formats of the options for the response as long as there is enough option space. Nishida Expires 26 April 2023 [Page 5] Internet-Draft Aggregated_SynOpt October 2022 3.2. Option Bits Registration As described in Section 3, Aggregated Option has 24 Option bits space and each bit represents a single option ID. The allocation of the Option Bits in Aggregated Option is maintained by IANA. If a new option can be aggregatable, one can request Option Bit in addition to the current procedure, requesting TCP Option Kind Number in [TCPParameters] . If a option already has assigned TCP Option Kind Number, one can request Option bit only which will represent the assigned option kind. 3.3. Utilizing 3rd and 4th Segments for Further Negotiations Aggregated Option is designed to exchange 1 bit information for each TCP extension that indicate the willingness to use the feature. Hence, if a TCP extension wants to carry more information in the TCP option for the extension, Aggregated Option is basically not applicable for it. However, it is still possible for these TCP extensions to utilize Aggregated Option in some situations. It is based on the fact that not all TCP extensions will be used right after SYN exchanges. For example, SACK options are only used when there are packet losses. If a TCP extension is not used right after SYN exchange, it is possible to exchange additional parameters by using utilizing 3rd segments and 4th segments. This approach is already used in MPTCP [RFC8684]. As we have a solid precedence, we believe it will not be difficult to implement similar negotiation schemes for other features. However, discussing negotiation schemes with 3rd and 4th segments is out of scope of the document. 4. Security Considerations We believe Aggregated Option maintains the same level of security as other TCP options does. 5. IANA Considerations This document requests new TCP option codepoint. In addition, this document requires new registry for the option. They are described in the following subsections. 5.1. Aggregated Option This document requests to add new option: Aggregated Option to the TCP option space registry which points to this document as follows: Nishida Expires 26 April 2023 [Page 6] Internet-Draft Aggregated_SynOpt October 2022 +------+--------+--------------------+----------------+ | Kind | Length | Meaning | Reference | +------+--------+--------------------+----------------+ | TBD | N | Aggregated Option | This Document | +------+--------+--------------------+----------------+ Figure 4: Aggregated Option Format 5.2. Option Bits Registry for Aggregated Option This document also requests to create a "Aggregated Option Identifiers" registry in IANA registries. The registry maintains 24 records which are mapped to the TCP Option Kind Number Records in [TCPParameters] The 24 records are divided into 4 groups so that each group contains 6 records. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, DOI 10.17487/RFC6994, August 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, . 6.2. Informative References [I-D.allman-tcpx2-hack] Allman, M., "TCPx2: Don't Fence Me In", Work in Progress, Internet-Draft, draft-allman-tcpx2-hack-00, 8 May 2006, . [I-D.briscoe-tcpm-inner-space] Briscoe, B., "Inner Space for TCP Options", Work in Progress, Internet-Draft, draft-briscoe-tcpm-inner-space- Nishida Expires 26 April 2023 [Page 7] Internet-Draft Aggregated_SynOpt October 2022 01, 27 October 2014, . [I-D.eddy-tcp-loo] Eddy, W. and A. Langley, "Extending the Space Available for TCP Options", Work in Progress, Internet-Draft, draft- eddy-tcp-loo-04, 1 July 2008, . [I-D.gomez-tcpm-ack-rate-request] Gomez, C. and J. Crowcroft, "TCP ACK Rate Request Option", Work in Progress, Internet-Draft, draft-gomez-tcpm-ack- rate-request-06, 12 October 2022, . [I-D.touch-tcpm-tcp-syn-ext-opt] Touch, J. D. and T. Faber, "TCP SYN Extended Option Space Using an Out-of-Band Segment", Work in Progress, Internet- Draft, draft-touch-tcpm-tcp-syn-ext-opt-12, 22 October 2022, . [I-D.yourtchenko-tcp-loic] Yourtchenko, A., "Introducing TCP Long Options by Invalid Checksum", Work in Progress, Internet-Draft, draft- yourtchenko-tcp-loic-00, 11 April 2011, . [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, . Nishida Expires 26 April 2023 [Page 8] Internet-Draft Aggregated_SynOpt October 2022 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, . [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2020, . [TCPParameters] "Transmission Control Protocol (TCP) Parameters", n.d., . Author's Address Yoshifumi Nishida Amazon Web Services 440 Terry Ave N Seattle, WA 98109 United States of America Email: nsd.ietf@gmail.com Nishida Expires 26 April 2023 [Page 9]