TCPM WG J. Touch Internet Draft USC/ISI Updates: 793 Wes Eddy Intended status: Standards Track MTI Systems Expires: November 2014 May 5, 2014 TCP Extended Data Offset Option draft-touch-tcpm-tcp-edo-02.txt 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on November 5, 2014. 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. Touch Expires November 5, 2014 [Page 1]
Internet-Draft TCP Extended Data Offset Option May 2014 Abstract TCP segments include a Data Offset field to indicate space for TCP options, but the size of the field can limit the space available for complex options that have evolved. This document updates RFC 793 with an optional TCP extension to that space and explains why such extensions cannot be used in the initial SYN of a connection. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................3 3. Requirements for Extending TCP's Data Offset...................3 4. Initial SYN Data Offset Cannot be Extended.....................3 5. The TCP EDO Option.............................................4 6. TCP EDO Interaction with TCP...................................7 6.1. TCP User Interface........................................7 6.2. TCP States and Transitions................................7 6.3. TCP Segment Processing....................................7 6.4. Impact on TCP Header Size.................................7 6.5. Connectionless Resets.....................................8 6.6. ICMP Handling.............................................8 7. Interactions with Middleboxes..................................9 8. Security Considerations.......................................10 9. IANA Considerations...........................................10 10. References...................................................10 10.1. Normative References....................................10 10.2. Informative References..................................11 11. Acknowledgments..............................................12 1. Introduction TCP's Data Offset is a 4-bit field, which indicates the number of 32-bit words of the entire TCP header [RFC793]. This limits the current total header size to 60 bytes, of which the basic header occupies 20, leaving 40 bytes for options. These 40 bytes are increasingly becoming a limitation to the development of advanced capabilities, such as when SACK [RFC2018][RFC6675], Multipath [RFC6824], and TCP-AO [RFC5925] are combined. This document specifies the TCP Extended Data Offset (EDO) option, and is independent of (and thus compatible with) IPv4 and IPv6. EDO extends the space available for TCP options, except for the initial SYN segment (i.e., SYN and not ACK, the first segment of a new connection). This document also explains why the option space of an Touch Expires November 5, 2014 [Page 2]
Internet-Draft TCP Extended Data Offset Option May 2014 initial SYN cannot be extended without severe impact on TCP's initial handshake. 2. Conventions used in this document 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 RFC-2119 [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 document, the characters ">>" preceding an indented line(s) indicates a compliance requirement statement using the key words listed above. This convention aids reviewers in quickly identifying or finding the explicit compliance requirements of this RFC. 3. Requirements for Extending TCP's Data Offset The primary goal of extending the TCP Data Offset field is to increase the space available for TCP options. An important requirement of any such extension is that it not impact legacy endpoints. I.e., endpoints seeking to use this new option should not incur additional delay or segment exchanges to connect to either new endpoints supporting this option or legacy endpoints without this option. We call this a "backward downgrade" capability. 4. Initial SYN Data Offset Cannot be Extended There have been a number of previous attempts to extend the space available for TCP options [Al06][Ed08][Ko04][Ra12][Yo11]. The key difficulty with most previous proposals is the desire to extend the option space in all TCP segments, including the initial SYN, i.e., SYN with no ACK, typically the first segment of a connection. There are three basic ways in which this has been attempted: 1. Use of a TCP option. 2. Redefinition of the existing TCP header fields. 3. Use of option space in multiple TCP segments (split-space). A new TCP option cannot extend the Data Offset of a TCP initial SYN. All TCP segments, including the initial SYN, may include user data in the payload data [RFC793], and this can be useful for some Touch Expires November 5, 2014 [Page 3]
Internet-Draft TCP Extended Data Offset Option May 2014 proposed features such as TCP Fast Open [Ch14]. Legacy endpoints that ignore the new option would process the payload contents as user data and send an ACK. Once ACK'd, this data cannot be removed from the user stream. The six Reserved TCP header bits cannot be redefined easily, because the original specification did not require their contents to be ignored, even though three of those bits have already been redefined (ECE/CWR [RFC3168] and NS [RFC3540]). Legacy endpoints are required to drop TCP segments where those bits are not zero, making it difficult to assume backward downgrade. TCP initial SYN (SYN and not ACK) segments can use every other TCP header field except the Acknowledgement number, which is not used because the ACK field is not set. In all other segments, all fields except the three remaining Reserved header bits. The total amount of space, in either case, is insufficient to be useful in extending the option space. The representation of TCP options can be optimized to minimize the space needed. In such cases, multiple Kind and Length fields are combined, so that a new Kind would indicate a specific combination of options, whose order is fixed and whose length is indicated by one Length field. Most TCP options use fields whose size is much larger than the required Kind and Length components, so the resulting efficiency is typically insufficient for additional options. Option space cannot be extended across multiple SYN segments. A legacy endpoint would continue the connection with incomplete option information. Option space cannot be extended in outer layer headers, e.g., IPv4 or IPv6. These layers typically try to avoid extensions altogether, to simplify forwarding processing at routers. Introducing new shim layers to accommodate additional option space would interfere with deep-packet inspection mechanisms that are in widespread use. As a result, EDO does not attempt to extend the space available for options in TCP initial SYNs. It does extend that space in all other segments (including SYN-ACK), which has always been trivially possible once an option is defined. 5. The TCP EDO Option The TCP EDO option is organized as indicated in Figure 1 and Figure 2. For initial SYN segments (i.e., those whose ACK bit is not set), Touch Expires November 5, 2014 [Page 4]
Internet-Draft TCP Extended Data Offset Option May 2014 the EDO request option consists of the required Kind and Length fields only. All other segments optionally use the EDO length option, which adds a Header_Length field (in network-standard byte rder), indicating the length of the entire TCP header in bytes. The codepoint value of the EDO Kind is EDO-OPT. +--------+--------+ | Kind | Length | +--------+--------+ Figure 1 TCP EDO request option +--------+--------+--------+--------+ | Kind | Length | Header_length | +--------+--------+--------+--------+ Figure 2 TCP EDO length option EDO support is determined in both directions using the same exchange. An endpoint seeking to enable EDO support includes the EDO request option in the initial SYN. >> Connections using EDO MUST negotiate its availability during the initial three-way handshake. >> An endpoint confirming EDO support MUST respond with EDO length option in its SYN-ACK. The EDO length option is required in SYN-ACKs when confirming support for EDO. The SYN-ACK thus can take advantage of EDO, using it to extend its option space. If such extension is not required, then EDO would be equal to 4 * Data Offset (i.e., EDO would indicate in bytes the same length indicated by Data Offset in words). >> Once negotiated on a connection, EDO MAY be present as needed on other segments in either direction. The EDO option SHOULD NOT be used if the total option space needed can be accommodated by the existing Data Offset field. >> The EDO request option (i.e., whose option length is 2) MAY occur in an initial SYN as desired (e.g., by the user/application), but MUST NOT be inserted in other segments. If the EDO request option is received, it MUST be silently ignored. >> The EDO length option MAY occur in segments other than the initial SYN if EDO has been negotiated on a connection. If EDO has not been negotiated and agreed, the EDO length option MUST be Touch Expires November 5, 2014 [Page 5]
Internet-Draft TCP Extended Data Offset Option May 2014 silently ignored. The EDO length option MUST NOT be sent in an initial SYN segment, and MUST be silently ignored and not acknowledged if so received. EDO extends the space available for options, but does not consume space unless needed. Segments that don't need the additional space can use the existing Data Offset field as currently specified [RFC793]. When processing a segment, EDO needs to be visible within the area indicated by the Data Offset field, so that processing can use the EDO Header_length to override the Data Offset for that segment. >> The EDO length option MUST occur within the length of the TCP Data Offset. >> The EDO length option indicates the total length of the header. The EDO Header_length field MUST NOT exceed that of the total segment size (i.e., TCP Length). The EDO Header_length SHOULD be a multiple of 4 to simplify processing. >> The EDO request option SHOULD be aligned on a 16-bit boundary and the EDO length option SHOULD be aligned on a 32-bit boundary, in both cases for simpler processing. For example, a segment with only EDO would have a Data Offset of 6, where EDO would be the first option processed, at which point the EDO length option would override the Data Offset and processing would continue until the end of the TCP header as indicated by the EDO Header_length field. There are cases where it might be useful to process other options before EDO, notably those that determine whether the TCP header is valid, such as authentication, encryption, or alternate checksums. In those cases, the EDO length option is preferably the first option after a validation option, and the payload after the Data Offset is treated as user data for the purposes of validation. >> The EDO length option SHOULD occur as early as possible, either first or just after any authentication or encryption, and SHOULD be the last option covered by the Data Offset value. Other options are generally handled in the same manner as when the EDO option is not active, unless they interact with other options. One such example is TCP-AO [RFC5925], which optionally ignores the contents of TCP options, so it would need to be aware of EDO to operate correctly when options are excluded from the HMAC calculation. Touch Expires November 5, 2014 [Page 6]
Internet-Draft TCP Extended Data Offset Option May 2014 >> Options that depend on other options, such as TCP-AO [RFC5925] (which may include or exclude options in MAC calculations) MUST also be augmented to interpret the EDO length option to operate correctly. 6. TCP EDO Interaction with TCP The following subsections describe how EDO interacts with the TCP specification [RFC793]. 6.1. TCP User Interface The TCP EDO option is enabled on a connection using a mechanism similar to any other per-connection option. In Unix systems, this is typically performed using the 'setsockopt' function. >> Implementations can also employ system-wide defaults, however systems SHOULD NOT use this extension by default to avoid interfering with legacy applications. 6.2. TCP States and Transitions TCP EDO does not alter the existing TCP state or state transition mechanisms. 6.3. TCP Segment Processing TCP EDO alters segment processing during the TCP option processing step. Once detected, the TCP EDO length option overrides the TCP Data Offset field for all subsequent option processing. Option processing continues at the next option after the EDO length option. Implementers need to be careful about the potential for offload support interfering with this option. The EDO data needs to be passed to the protocol stack as part of the option space, not integrated with the user segment, to allow the offload to independently determine user data segment boundaries and combine them correctly with the extended option data. 6.4. Impact on TCP Header Size The TCP EDO request option increases SYN header length by a minimum of 2 bytes. Currently popular SYN options total 11 bytes, which leaves more than enough room for the EDO request: o SACK permitted (2 bytes) [RFC2018][RFC6675] Touch Expires November 5, 2014 [Page 7]
Internet-Draft TCP Extended Data Offset Option May 2014 o Timestamp (10 bytes) [RFC1323] o Window scale (3 bytes) [RFC1323] o MSS option (4 bytes) [RFC793] TCP EDO can also be negotiated in SYNs with the following options: o TCP-AO (authentication) (16 bytes) [RFC5925] o Multipath TCP (20 bytes) [RFC6824] Some combinations of the above options may not fit in the existing SYN option space, and (as noted) that space cannot be extended. The EDO option has negligible impact on other headers, because it can either come first or just after security information, and in either case the additional 4 bytes are easily accommodated within the TCP Data Offset length. Once the EDO option is processed, the entirety of the remainder of the TCP segment is available for any remaining options. 6.5. Connectionless Resets A RST may arrive during a currently active connection or may be needed to cleanup old state from an abandoned connection. The latter occurs when a new SYN is sent to an endpoint with matching existing connection state, at which point that endpoint responds with a RST and both ends remove stale information. The EDO option is not mandatory in any TCP segment, except the SYN and SYN-ACK of the three-way handshake to establish its support. >> The EDO length option MAY occur in a RST when the endpoint has connection state that has negotiated EDO. However, unless the RST is generated by an incoming segment that includes an EDO option, the RST MUST NOT include the EDO length option. 6.6. ICMP Handling ICMP responses are intended to include the IP and the port fields of TCP and UDP headers of typical TCP/IP and UDP/IP packets [RFC792]. This includes the first 8 data bytes of the original datagram, intended to include the transport port numbers used for connection demultiplexing. Later specifications encourage returning as much of the original payload as possible [RFC1812]. In either case, legacy options or new options in the EDO extension area might or might not Touch Expires November 5, 2014 [Page 8]
Internet-Draft TCP Extended Data Offset Option May 2014 be included, and so options are generally not assumed to be part of ICMP processing anyway. 7. Interactions with Middleboxes Any new TCP option may be impacted by the presence of any on-path device that examines or modifies transport headers [RFC3234]. Boxes that parse or modify TCP options need to follow the same requirements of TCP endpoints in supporting EDO, or they could interfere with connections. The primary concern is so-called "transparent" rewriting proxies, which modify TCP segment boundaries and thus would mix option information with user data if they do not support EDO. Such devices interfere with many other TCP options, and although their use is not common they would interfere with connections that use EDO. More common are NATs, which rewrite IP address and/or transport port fields. NATs are not affected by the EDO option. Deep-packet inspection systems that inspect TCP segment payloads or attempt to reconstitute the data stream would incorrectly include options, which might interfere with their operation. ?? PROPOSED SOLUTION BELOW It may be important to detect misbehavior that could cause EDO space to be misinterpreted as user data. In such cases, EDO SHOULD be used in conjunction with integrity protection mechanisms, such as IPsec, TCP-AO, etc. --- ?? should we include a header checksum, as suggested by Oliver Bonaventure, too? Should it be integrated with EDO or independent? If so, we either need one of the following: +--------+--------+--------+--------+ | Kind | Length | Header_length | +--------+--------+--------+--------+ | EDO-checksum | +--------+--------+ Figure 3 TCP EDO length + sum option Touch Expires November 5, 2014 [Page 9]
Internet-Draft TCP Extended Data Offset Option May 2014 +--------+--------+--------+--------+ | Kind | Length | Header_checksum | +--------+--------+--------+--------+ Figure 4 TCP header checksum option The former adds a header checksum to EDO - this could be optional or required, and its presence can be determined from the option length. The checksum would be over only the additional EDO space. The latter requires a new option and we'd need to decide what the option covered. It could cover just the option space. Finally, another option would be to try to make rewriting middleboxes fail by some other, more opaque means - such as using DO=0 when EDO is used as suggested by John Leslie (but this would also require considering whether EDO would be required on all packets, or just on DO=0, as well as where EDO would be and whether it could precede security/integrity options such as TCP-AO). 8. Security Considerations It is meaningless to have the Data Offset further exceed the position of the EDO data offset option. >> When the EDO length option is present, the EDO length option SHOULD be the last non-null option covered by the TCP Data Offset, because it would be the last option affected by Data Offset. This also makes it more difficult to use the Data Offset field as a covert channel. 9. IANA Considerations We request that, upon publication, this option be assigned a TCP Option codepoint by IANA, which the RFC Editor will replace EDO-OPT in this document with codepoint value. This section is to be removed prior to publication as an RFC. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Touch Expires November 5, 2014 [Page 10]
Internet-Draft TCP Extended Data Offset Option May 2014 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. 10.2. Informative References [Al06] Allman, M., "TCPx2: Don't Fence Me In", draft-allman- tcpx2-hack-00 (work in progress), May 2006. [Ch14] Cheng, Y., Chu, J., and A. Jain, "TCP Fast Open", draft- ietf-tcpm-fastopen-08, March 2014. [Ed08] Eddy, W. and A. Langley, "Extending the Space Available for TCP Options", draft-eddy-tcp-loo-04 (work in progress), July 2008. [Ko04] Kohler, E., "Extended Option Space for TCP", draft-kohler- tcpm-extopt-00 (work in progress), September 2004. [Ra12] Ramaiah, A., "TCP option space extension", draft-ananth- tcpm-tcpoptext-00 (work in progress), March 2012. [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [RFC1812] Baker, F. (Ed.), "Requirements for IP Version 4 Routers," RFC 1812, June 1995. [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003. [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010. Touch Expires November 5, 2014 [Page 11]
Internet-Draft TCP Extended Data Offset Option May 2014 [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., and Y.. Nishida, "A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP", RFC 6675, August 2012. [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013. [Yo11] Yourtchenko, A., "Introducing TCP Long Options by Invalid Checksum", draft-yourtchenko-tcp-loic-00 (work in progress), April 2011. 11. Acknowledgments The authors would like to thank the IETF TCPM WG for their feedback, in particular: Oliver Bonaventure, Ted Faber, John Leslie, Richard Scheffenegger, and Alexander Zimmerman. This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 USA Phone: +1 (310) 448-9151 Email: touch@isi.edu Wesley M. Eddy MTI Systems US Email: wes@mti-systems.com Touch Expires November 5, 2014 [Page 12]