TCP Extended Data Offset Option
draft-touch-tcpm-tcp-edo-00

TCPM WG                                                        J. Touch
Internet Draft                                                  USC/ISI
Intended status: Standards Track                               Wes Eddy
Expires: October 2014                                       MTI Systems
                                                         April 18, 2014

                      TCP Extended Data Offset Option
                      draft-touch-tcpm-tcp-edo-00.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 October 18, 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 October 18, 2014                [Page 1]
Internet-Draft     TCP Extended Data Offset Option           April 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 specifies an
   optional extension to that space and explains why such extensions
   (including this) cannot be used in the initial SYN.

Table of Contents

   1. Introduction...................................................2
   2. Conventions used in this document..............................3
   3. Requirements for Extending TCP's Data Offset...................3
   4. SYN Data Offset Cannot be Extended.............................3
   5. The TCP EDO Option.............................................4
   6. TCP EDO Interaction with TCP...................................5
      6.1. TCP User Interface........................................5
      6.2. TCP States and Transitions................................5
      6.3. TCP Segment Processing....................................6
      6.4. Impact on TCP Header Size.................................6
      6.5. Connectionless Resets.....................................6
      6.6. ICMP Handling.............................................7
   7. Interactions with Middleboxes..................................7
   8. Security Considerations........................................7
   9. IANA Considerations............................................8
   10. References....................................................8
      10.1. Normative References.....................................8
      10.2. Informative References...................................8
   11. Acknowledgments...............................................9

1. Introduction

   TCP's Data Offset is a 4-bit field, which indicates the number of
   32-bit words of the entire TCP header. 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.

   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. This document also explains why the option space of
   that SYN cannot be extended without severe impact on TCP's initial
   handshake.

Touch                  Expires October 18, 2014                [Page 2]
Internet-Draft     TCP Extended Data Offset Option           April 2014

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. 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. 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 SYN. A SYN
   may include user data in the payload data. 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.

Touch                  Expires October 18, 2014                [Page 3]
Internet-Draft     TCP Extended Data Offset Option           April 2014

   The six reserved TCP header bits cannot be redefined easily, because
   the original specification did not require their contents to be
   ignored. Legacy endpoints are required to drop TCP segments where
   those bits are not zero, defeating the goal of backward downgrade.
   The same is true for redefinition of other TCP fields, which are all
   in active, current use.

   Option space cannot be extended across multiple SYN segments. A
   legacy endpoint would continue the connection with incomplete option
   information.

   As a result, EDO does not attempt to extend the space available for
   options in TCP SYNs. It does extend that space in all other
   segments, 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. The EDO length option consists of the required Kind and option
   Length fields followed by the length of the entire TCP header in
   bytes. For initial SYN segments (i.e., those whose ACK bit is not
   set), the EDO request option omits the Header_length field and is
   thus two bytes shorter. The codepoint value of the EDO Kind is EDO-
   OPT in both cases. The Header_length is in network-standard byte
   order.

                            +--------+--------+
                            |  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.

Touch                  Expires October 18, 2014                [Page 4]
Internet-Draft     TCP Extended Data Offset Option           April 2014

   >> An endpoint confirming EDO support MAY respond with EDO length
   option in its SYN-ACK.

   >> 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.

   >> Because it overrides an existing TCP header field when present,
   the EDO length option MUST occur within the length of the TCP Data
   Offset. The EDO length option SHOULD occur as early as possible,
   either first or just after any authentication or encryption.

   >> 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.

   Other options are generally handled in the same manner as when the
   EDO option is not active.

   >> Options that depend on other options, such as TCP-AO (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.

6.2. TCP States and Transitions

   TCP EDO does not alter the existing TCP state or state transition
   mechanisms.

Touch                  Expires October 18, 2014                [Page 5]
Internet-Draft     TCP Extended Data Offset Option           April 2014

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.

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 15 bytes, which
   leaves more than enough room for the EDO request:

   o  SACK permitted (2 bytes) [RFC2018][RFC6675]

   o  Timestamp (10 bytes) [RFC1323]

   o  Window scale (3 bytes) [RFC1323]

   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.

Touch                  Expires October 18, 2014                [Page 6]
Internet-Draft     TCP Extended Data Offset Option           April 2014

   >> 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
   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
   their use is not common.

   More common are NATs, which rewrite IP address and/or transport port
   fields. NATs are not affected by the EDO option.

8. Security Considerations

   It is meaningless to have the Data Offset further exceed that
   position. As a result:

   >> 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.

   This also helps prevent the Data Offset from being used as a covert
   channel.

Touch                  Expires October 18, 2014                [Page 7]
Internet-Draft     TCP Extended Data Offset Option           April 2014

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.

   [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.

   [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.

   [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
             Issues", RFC 3234, February 2002.

Touch                  Expires October 18, 2014                [Page 8]
Internet-Draft     TCP Extended Data Offset Option           April 2014

   [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
             Authentication Option", RFC 5925, June 2010.

   [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

   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 October 18, 2014                [Page 9]