< draft-ietf-tcpm-tcp-edo-00.txt   draft-ietf-tcpm-tcp-edo-01.txt >
TCPM WG J. Touch TCPM WG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Updates: 793 Wes Eddy Updates: 793 Wes Eddy
Intended status: Standards Track MTI Systems Intended status: Standards Track MTI Systems
Expires: March 2015 September 29, 2014 Expires: April 2015 October 13, 2014
TCP Extended Data Offset Option TCP Extended Data Offset Option
draft-ietf-tcpm-tcp-edo-00.txt draft-ietf-tcpm-tcp-edo-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 29, 2015. This Internet-Draft will expire on April 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
TCP segments include a Data Offset field to indicate space for TCP 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 options, but the size of the field can limit the space available for
complex options that have evolved. This document updates RFC 793 complex options that have evolved. This document updates RFC 793
with an optional TCP extension to that space to support the use of with an optional TCP extension to that space to support the use of
multiple large options such as SACK with either TCP Multipath or TCP multiple large options such as SACK with either TCP Multipath or TCP
AO. It also explains why the initial SYN of a connection cannot be AO. It also explains why the initial SYN of a connection cannot be
extending as a single segment. extending a single segment.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Conventions used in this document..............................3 2. Conventions used in this document..............................3
3. Requirements for Extending TCP's Data Offset...................3 3. Requirements for Extending TCP's Data Offset...................3
4. The TCP EDO Option.............................................4 4. The TCP EDO Option.............................................4
5. TCP EDO Interaction with TCP...................................6 5. TCP EDO Interaction with TCP...................................6
5.1. TCP User Interface........................................6 5.1. TCP User Interface........................................6
5.2. TCP States and Transitions................................6 5.2. TCP States and Transitions................................7
5.3. TCP Segment Processing....................................7 5.3. TCP Segment Processing....................................7
5.4. Impact on TCP Header Size.................................7 5.4. Impact on TCP Header Size.................................7
5.5. Connectionless Resets.....................................8 5.5. Connectionless Resets.....................................8
5.6. ICMP Handling.............................................8 5.6. ICMP Handling.............................................9
6. Interactions with Middleboxes..................................9 6. Interactions with Middleboxes..................................9
6.1. Middlebox Coexistence with EDO............................9 6.1. Middlebox Coexistence with EDO............................9
6.2. Middlebox Interference with EDO...........................9 6.2. Middlebox Interference with EDO..........................10
7. Comparison to Previous Proposals..............................10 7. Comparison to Previous Proposals..............................11
7.1. EDO Criteria.............................................10 7.1. EDO Criteria.............................................11
7.2. Summary of Approaches....................................11 7.2. Summary of Approaches....................................12
7.3. Extended Segments........................................12 7.3. Extended Segments........................................13
7.4. TCPx2....................................................12 7.4. TCPx2....................................................13
7.5. LO/SLO...................................................12 7.5. LO/SLO...................................................13
7.6. LOIC.....................................................13 7.6. LOIC.....................................................14
7.7. Problems with Extending the Initial SYN..................14 7.7. Problems with Extending the Initial SYN..................14
8. Security Considerations.......................................15 8. Implementation Issues.........................................16
9. IANA Considerations...........................................15 9. Security Considerations.......................................16
10. References...................................................15 10. IANA Considerations..........................................17
10.1. Normative References....................................15 11. References...................................................17
10.2. Informative References..................................15 11.1. Normative References....................................17
11. Acknowledgments..............................................17 11.2. Informative References..................................17
12. Acknowledgments..............................................19
1. Introduction 1. Introduction
TCP's Data Offset is a 4-bit field, which indicates the number of 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 32-bit words of the entire TCP header [RFC793]. This limits the
current total header size to 60 bytes, of which the basic header current total header size to 60 bytes, of which the basic header
occupies 20, leaving 40 bytes for options. These 40 bytes are occupies 20, leaving 40 bytes for options. These 40 bytes are
increasingly becoming a limitation to the development of advanced increasingly becoming a limitation to the development of advanced
capabilities, such as when SACK [RFC2018][RFC6675] is combined with capabilities, such as when SACK [RFC2018][RFC6675] is combined with
either Multipath TCP [RFC6824], TCP-AO [RFC5925], or TCP Fast Open either Multipath TCP [RFC6824], TCP-AO [RFC5925], or TCP Fast Open
[Ch14]. [Ch14].
This document specifies the TCP Extended Data Offset (EDO) option, This document specifies the TCP Extended Data Offset (EDO) option,
and is independent of (and thus compatible with) IPv4 and IPv6. EDO and is independent of (and thus compatible with) IPv4 and IPv6. EDO
extends the space available for TCP options, except for the initial 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 SYN and SYN/ACK. This document also explains why the option space of
connection). This document also explains why the option space of a the initial SYN segments cannot be extended as individual segments
single initial SYN segment cannot be extended without severe impact without severe impact on TCP's initial handshake and the SYN/ACK
on TCP's initial handshake. limitation that results from middlebox misbehavior.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation 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 only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance. interpreted as carrying RFC-2119 significance.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
The primary goal of extending the TCP Data Offset field is to The primary goal of extending the TCP Data Offset field is to
increase the space available for TCP options in all segments except increase the space available for TCP options in all segments except
the initial SYN. the initial SYN.
An important requirement of any such extension is that it not impact An important requirement of any such extension is that it not impact
legacy endpoints. Endpoints seeking to use this new option should legacy endpoints. Endpoints seeking to use this new option should
not incur additional delay or segment exchanges to connect to either not incur additional delay or segment exchanges to connect to either
new endpoints supporting this option or legacy endpoints without new endpoints supporting this option or legacy endpoints without
this option. We call this a "backward downgrade" capability. this option. We call this a "backward downgrade" capability.
An additional consideration of this extension is avoiding user data
corruption in the presence of popular network devices, including
middleboxes. Consideration of middlebox misbehavior can also
interfere with extension in the SYN/ACK.
4. The TCP EDO Option 4. The TCP EDO Option
TCP EDO extends the option space for all segments except the initial TCP EDO extends the option space for all segments except the initial
SYN (i.e., SYN set and ACK not set). The EDO option is organized as SYN (i.e., SYN set and ACK not set) and SYN/ACK response. The EDO
indicated in Figure 1 and Figure 2. For initial SYN segments (i.e., option is organized as indicated in Figure 1 and Figure 2. When
those whose ACK bit is not set), the EDO request option consists of desired, initial SYN segments (i.e., those whose ACK bit is not set)
the required Kind and Length fields only. All other segments use the EDO request option, which consists of the required Kind and
optionally use the EDO length option, which adds a Header_Length Length fields only. Depending on capability and whether EDO is
field (in network-standard byte order), indicating the length of the successfully negotiated, any other segments can use the EDO length
entire TCP header in bytes. The codepoint value of the EDO Kind is option, which adds a Header_Length field (in network-standard byte
EDO-OPT. order), indicating the length of the entire TCP header in 32-bit
words. The codepoint value of the EDO Kind is EDO-OPT.
+--------+--------+ +--------+--------+
| Kind | Length | | Kind | Length |
+--------+--------+ +--------+--------+
Figure 1 TCP EDO request option Figure 1 TCP EDO request option
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind | Length | Header_length | | Kind | Length | Header_length |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 2 TCP EDO length option Figure 2 TCP EDO length option
EDO support is determined in both directions using the same EDO support is determined in both directions using a single
exchange. An endpoint seeking to enable EDO support includes the EDO exchange. An endpoint seeking to enable EDO support includes the EDO
request option in the initial SYN. request option in the initial SYN. If receiver of that SYN agrees to
support EDO, it responds with a null EDO length option in the
SYN/ACK. A null EDO length option contains the same value as the DO
field, i.e., it does not extend the TCP option space.
>> Connections using EDO MUST negotiate its availability during the >> Connections using EDO MUST negotiate its availability during the
initial three-way handshake. initial three-way handshake.
>> An endpoint confirming EDO support MUST respond with an EDO >> An endpoint confirming EDO support MUST respond with a null EDO
length option in its SYN/ACK. length option in its SYN/ACK.
The EDO length option is required in SYN/ACKs when confirming The SYN/ACK uses the null EDO length option because it may not yet
support for EDO. The SYN/ACK thus can take advantage of EDO, using be safe to extend the option space in the reverse direction due to
it to extend its option space. If such extension is not required, middlebox misbehavior (see Section 6.2). Extension of the SYN and
then EDO would be equal to 4 * Data Offset (i.e., EDO would indicate SYN/ACK space is addressed as a separate option (see Section 7.7).
in bytes the same length indicated by Data Offset in words).
>> Once negotiated on a connection, EDO MAY be present as needed on >> The EDO length option MAY be used only if confirmed when the
other segments in either direction. The EDO option SHOULD NOT be connection transitions to the ESTABLISHED state, e.g., a client is
used if the total option space needed can be accommodated by the enabled after receiving the null EDO length option in the SYN/ACK
existing Data Offset field. An endpoint MUST be robust to receiving and the server is enabled after seeing a null or non-null EDO length
the EDO option on segments that do not strictly require it to extend option in the final ACK of the three-way handshake. If either of
the options space. those segments lacks the EDO length option, the connection MUST NOT
use EDO on any other segments.
>> The EDO request option (i.e., whose option length is 2) MAY occur >> Once enabled on a connection, all segments in both directions
in an initial SYN as desired (e.g., as expressed by the MUST include the EDO length option. Segments not needing extension
user/application), but MUST NOT be inserted in other segments. If MUST set the EDO length equal to the DO length.
the EDO request option is received, it MUST be silently ignored.
>> The EDO length option MAY occur in segments other than the Internet paths may vary after connection establishment, introducing
initial SYN if EDO has been negotiated on a connection. If EDO has misbehaving middleboxes (see Section 6.2). Using EDO on all segments
not been negotiated and agreed, the EDO length option MUST be in both directions allows this condition to be detected.
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 >> The EDO request option MAY occur in an initial SYN as desired
space unless needed. Segments that don't need the additional space (e.g., as expressed by the user/application), but MUST NOT be
can use the existing Data Offset field as currently specified inserted in other segments. If the EDO request option is received in
[RFC793]. When processing a segment, EDO needs to be visible within other segments, it MUST be silently ignored.
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 >> If EDO has not been negotiated and agreed, the EDO length option
Data Offset. MUST be silently ignored on subsequent segments. The EDO length
option MUST NOT be sent in an initial SYN segment, and MUST be
silently ignored and not acknowledged if so received.
>> If EDO has been negotiated, any subsequent segments arriving
without the EDO length option MUST be silently ignored. Such events
MAY be logged as warning errors and logging MUST be rate limited.
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 space indicated by
the TCP Data Offset.
>> The EDO length option indicates the total length of the header. >> The EDO length option indicates the total length of the header.
The EDO Header_length field MUST NOT exceed that of the total 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 segment size (i.e., TCP Length).
multiple of 4 to simplify processing.
>> The EDO length option MUST be at least as large as the TCP Data
Offset field of the segment in which they both appear. When the EDO
length equals the DO length, the EDO option is present but it does
not extend the option space. When the EDO length is invalid, the TCP
segment MUST be silently dropped.
>> The EDO request option SHOULD be aligned on a 16-bit boundary and >> 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 the EDO length option SHOULD be aligned on a 32-bit boundary, in
both cases for simpler processing. both cases for simpler processing.
For example, a segment with only EDO would have a Data Offset of 6, 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 where EDO would be the first option processed, at which point the
EDO length option would override the Data Offset and processing EDO length option would override the Data Offset and processing
would continue until the end of the TCP header as indicated by the would continue until the end of the TCP header as indicated by the
EDO Header_length field. EDO Header_length field.
skipping to change at page 6, line 33 skipping to change at page 6, line 50
The following subsections describe how EDO interacts with the TCP The following subsections describe how EDO interacts with the TCP
specification [RFC793]. specification [RFC793].
5.1. TCP User Interface 5.1. TCP User Interface
The TCP EDO option is enabled on a connection using a mechanism The TCP EDO option is enabled on a connection using a mechanism
similar to any other per-connection option. In Unix systems, this is similar to any other per-connection option. In Unix systems, this is
typically performed using the 'setsockopt' system call. typically performed using the 'setsockopt' system call.
>> Implementations can also employ system-wide defaults, however >> Implementations can also employ system-wide defaults, however
systems SHOULD NOT use this extension by default to avoid systems SHOULD NOT activate this extension by default to avoid
interfering with legacy applications. interfering with legacy applications.
>> Due to the potential impacts of legacy middleboxes (discussed in >> Due to the potential impacts of legacy middleboxes (discussed in
Section 6), a TCP implementation supporting EDO SHOULD log any Section 6), a TCP implementation supporting EDO SHOULD log any
events within an EDO connection when options that are malformed or events within an EDO connection when options that are malformed or
show other evidence of tampering arrive. An operating system MAY show other evidence of tampering arrive. An operating system MAY
choose to cache the list of destination endpoints where this has choose to cache the list of destination endpoints where this has
occurred with and block use of EDO on future connections to those occurred with and block use of EDO on future connections to those
endpoints, but this cache needs to be accessible to endpoints, but this cache MUST be accessible to users/applications
users/applications on the host. Note that such endpoint assumptions on the host. Note that such endpoint assumptions can vary in the
may vary in the presence of load balancers where server presence of load balancers where server implementations vary behind
implementations vary behind such balancers. such balancers.
5.2. TCP States and Transitions 5.2. TCP States and Transitions
TCP EDO does not alter the existing TCP state or state transition TCP EDO does not alter the existing TCP state or state transition
mechanisms. mechanisms.
5.3. TCP Segment Processing 5.3. TCP Segment Processing
TCP EDO alters segment processing during the TCP option processing TCP EDO alters segment processing during the TCP option processing
step. Once detected, the TCP EDO length option overrides the TCP step. Once detected, the TCP EDO length option overrides the TCP
Data Offset field for all subsequent option processing. Option Data Offset field for all subsequent option processing. Option
processing continues at the next option after the EDO length option. processing continues at the next option (if present) 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.
5.4. Impact on TCP Header Size 5.4. Impact on TCP Header Size
The TCP EDO request option increases SYN header length by a minimum The TCP EDO request option increases SYN header length by a minimum
of 2 bytes. Currently popular SYN options total 19 bytes, which of 2 bytes. Currently popular SYN options total 19 bytes, which
leaves more than enough room for the EDO request: leaves more than enough room for the EDO request:
o SACK permitted (2 bytes in SYN, optionally 2 + 8N bytes after) o SACK permitted (2 bytes in SYN, optionally 2 + 8N bytes after)
[RFC2018][RFC6675] [RFC2018][RFC6675]
skipping to change at page 8, line 32 skipping to change at page 8, line 42
remaining options. remaining options.
5.5. Connectionless Resets 5.5. Connectionless Resets
A RST may arrive during a currently active connection or may be A RST may arrive during a currently active connection or may be
needed to cleanup old state from an abandoned connection. The latter needed to cleanup old state from an abandoned connection. The latter
occurs when a new SYN is sent to an endpoint with matching existing occurs when a new SYN is sent to an endpoint with matching existing
connection state, at which point that endpoint responds with a RST connection state, at which point that endpoint responds with a RST
and both ends remove stale information. and both ends remove stale information.
The EDO option is not mandatory in any TCP segment, except the SYN The EDO option is mandatory on all TCP segments once negotiated,
and SYN/ACK of the three-way handshake to establish its support. except the SYN and SYN/ACK of the three-way handshake to establish
its support and the RST. A RST may lack the context to know that EDO
is active on a connection.
>> The EDO length option MAY occur in a RST when the endpoint has >> The EDO length option MAY occur in a RST when the endpoint has
connection state that has negotiated EDO. However, unless the RST is connection state that has negotiated EDO. However, unless the RST is
generated by an incoming segment that includes an EDO option, the generated by an incoming segment that includes an EDO option, the
RST MUST NOT include the EDO length option. transmitted RST MUST NOT include the EDO length option.
5.6. ICMP Handling 5.6. ICMP Handling
ICMP responses are intended to include the IP and the port fields of 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]. TCP and UDP headers of typical TCP/IP and UDP/IP packets [RFC792].
This includes the first 8 data bytes of the original datagram, This includes the first 8 data bytes of the original datagram,
intended to include the transport port numbers used for connection intended to include the transport port numbers used for connection
demultiplexing. Later specifications encourage returning as much of demultiplexing. Later specifications encourage returning as much of
the original payload as possible [RFC1812]. In either case, legacy the original payload as possible [RFC1812]. In either case, legacy
options or new options in the EDO extension area might or might not options or new options in the EDO extension area might or might not
skipping to change at page 10, line 6 skipping to change at page 10, line 16
both connections. The use of EDO on one connection is independent of both connections. The use of EDO on one connection is independent of
its use on the other in this case. its use on the other in this case.
6.2. Middlebox Interference with EDO 6.2. Middlebox Interference with EDO
Middleboxes that do not support EDO cannot coexist with its use when Middleboxes that do not support EDO cannot coexist with its use when
they modify segment boundaries or do not forward unknown (e.g., the they modify segment boundaries or do not forward unknown (e.g., the
EDO) options. EDO) options.
So-called "transparent" rewriting proxies, which modify TCP segment So-called "transparent" rewriting proxies, which modify TCP segment
boundaries, would mix option information with user data if they did boundaries, might mix option information with user data if they did
not support EDO. Such devices may also interfere with other TCP not support EDO. Such devices might also interfere with other TCP
options such as TCP-AO. options such as TCP-AO. There are three types of such boxes:
o Those that process received options and transmit sent options
separately, i.e., although they rewrite segments, they behave as
TCP endpoints in both directions.
o Those that split segments, taking a received segment and emitting
two or more segments with revised headers.
o Those that join segments, receiving multiple segments and
emitting a single segment whose data is the concatenation of the
components.
In all three cases, EDO is either treated as independent on
different sides of such boxes or not. If independent, EDO would
either be correctly terminated in either or both directions or
disabled due to lack of SYN/ACK confirmation in either or both
directions. Problems would occur only when TCP segments with EDO are
combined or split while ignoring the EDO option. In the split case,
the key concern is if the split happens within the option extension
space or if EDO is silently copied to both segments without copying
the corresponding extended option space contents. However, the most
comprehensive study of these cases indicates that "although
middleboxes do split and coalesce segments, none did so while
passing unknown options" [Ho11].
Middleboxes that silently remove options they do not implement have
been observed [Ho11]. Such boxes interfere with the use of the EDO
length option in the SYN and SYN/ACK segments because extended
option space would be misinterpreted as user data if the EDO option
were removed, and this cannot be avoided. This is one reason that
SYN and SYN/ACK extension requires alternate mechanisms (see Section
7.7). Further, if such middleboxes become present on a path they
could cause similar misinterpretation on segments exchanged in the
ESTABLISHED and subsequent states. As a result, this document
requires that the EDO length option be avoided on the SYN/ACK and
that this option needs to be used on all segments once successfully
negotiated.
Deep-packet inspection systems that inspect TCP segment payloads or Deep-packet inspection systems that inspect TCP segment payloads or
attempt to reconstitute the data stream would incorrectly include attempt to reconstitute the data stream would incorrectly include
option data in the reconstituted user data stream, which might option data in the reconstituted user data stream, which might
interfere with their operation. interfere with their operation.
>> It may be important to detect misbehavior that could cause EDO >> It can be important to detect misbehavior that could cause EDO
space to be misinterpreted as user data. In such cases, EDO SHOULD space to be misinterpreted as user data. In such cases, EDO SHOULD
be used in conjunction with integrity protection mechanisms, such as be used in conjunction with an integrity protection mechanism, such
IPsec, TCP-AO, etc. It is useful to note that such protection helps as IPsec, TCP-AO, etc. It is useful to note that such protection
find only non-compliant components. helps find only non-compliant components.
This situation is similar to that of ECN and ICMP support in the This situation is similar to that of ECN and ICMP support in the
Internet. In both cases, endpoints have evolved mechanisms for Internet. In both cases, endpoints have evolved mechanisms for
detecting and robustly operating around "black holes". Very similar detecting and robustly operating around "black holes". Very similar
algorithms are expected to be applicable for EDO. algorithms are expected to be applicable for EDO.
7. Comparison to Previous Proposals 7. Comparison to Previous Proposals
EDO is the latest in a long line of attempts to increase TCP option EDO is the latest in a long line of attempts to increase TCP option
space [Al06][Ed08][Ko04][Ra12][Yo11]. The following is a comparison space [Al06][Ed08][Ko04][Ra12][Yo11]. The following is a comparison
skipping to change at page 12, line 50 skipping to change at page 13, line 50
to indicate its use, defeating backward compatibility with all to indicate its use, defeating backward compatibility with all
existing TCP capabilities, including firewalls, NATs/NAPTs, and existing TCP capabilities, including firewalls, NATs/NAPTs, and
legacy endpoints and applications. legacy endpoints and applications.
7.5. LO/SLO 7.5. LO/SLO
The TCP Long Option (LO, [Ed08]) is very similar to EDO, except that The TCP Long Option (LO, [Ed08]) is very similar to EDO, except that
presence of LO results in ignoring the existing DO field and that LO presence of LO results in ignoring the existing DO field and that LO
is required to be the first option. EDO considers the need for other is required to be the first option. EDO considers the need for other
fields to be first and declares that the EDO is the last option as fields to be first and declares that the EDO is the last option as
indicated by the DO field value. Unlike LO, EDO is not required in indicated by the DO field value. Like LO, EDO is required in every
every segment once negotiated, saving 6 bytes if not actively segment once negotiated.
needed.
The TCP Long Option draft also specified the SYN Long Option (SLO) The TCP Long Option draft also specified the SYN Long Option (SLO)
[Ed08]. If SLO is used in the initial SYN and successfully [Ed08]. If SLO is used in the initial SYN and successfully
negotiated, it is used in each subsequent segment until all of the negotiated, it is used in each subsequent segment until all of the
initial SYN options are transmitted. initial SYN options are transmitted.
LO is backward compatible, as is SLO; in both cases, endpoints not LO is backward compatible, as is SLO; in both cases, endpoints not
supporting the option would not respond with the option, and in both supporting the option would not respond with the option, and in both
cases the initial SYN is not itself extended. cases the initial SYN is not itself extended.
skipping to change at page 14, line 10 skipping to change at page 14, line 51
out of order. Finally, by not allowing other options in the out of order. Finally, by not allowing other options in the
negotiation SYN, all connections to legacy endpoints either use no negotiation SYN, all connections to legacy endpoints either use no
options or require a separate connection attempt (either concurrent options or require a separate connection attempt (either concurrent
or subsequent). or subsequent).
7.7. Problems with Extending the Initial SYN 7.7. Problems with Extending the Initial SYN
The key difficulty with most previous proposals is the desire to The key difficulty with most previous proposals is the desire to
extend the option space in all TCP segments, including the initial extend the option space in all TCP segments, including the initial
SYN, i.e., SYN with no ACK, typically the first segment of a SYN, i.e., SYN with no ACK, typically the first segment of a
connection. It has proven difficult to extend space in this initial connection, as well as possibly the SYN/ACK. It has proven difficult
SYN in the absence of prior negotiation while maintaining current to extend space within the segment of the initial SYN in the absence
TCP three-way handshake properties. of prior negotiation while maintaining current TCP three-way
handshake properties, and it may be similarly challenging to extend
the SYN/ACK (depending on asymmetric middlebox assumptions).
A new TCP option cannot extend the Data Offset of a single TCP A new TCP option cannot extend the Data Offset of a single TCP
initial SYN segment. All TCP segments, including the initial SYN, initial SYN segment, and cannot extend a SYN/ACK in a single segment
may include user data in the payload data [RFC793], and this can be when considering misbehaving middleboxes. All TCP segments,
useful for some proposed features such as TCP Fast Open [Ch14]. including the initial SYN and SYN/ACK, may include user data in the
Legacy endpoints that ignore the new option would process the payload data [RFC793], and this can be useful for some proposed
payload contents as user data and send an ACK. Once ACK'd, this data features such as TCP Fast Open [Ch14]. Legacy endpoints that ignore
cannot be removed from the user stream. 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 Reserved TCP header bits cannot be redefined easily, even though The Reserved TCP header bits cannot be redefined easily, even though
three of the six total bits have already been redefined (ECE/CWR three of the six total bits have already been redefined (ECE/CWR
[RFC3168] and NS [RFC3540]). Legacy endpoints have been known to [RFC3168] and NS [RFC3540]). Legacy endpoints have been known to
reflect received values in these fields; this was safely dealt with reflect received values in these fields; this was safely dealt with
for ECN but would be difficult here [RFC3168]. for ECN but would be difficult here [RFC3168].
TCP initial SYN (SYN and not ACK) segments can use every other TCP TCP initial SYN (SYN and not ACK) segments can use every other TCP
header field except the Acknowledgement number, which is not used header field except the Acknowledgement number, which is not used
because the ACK field is not set. In all other segments, all fields because the ACK field is not set. In all other segments, all fields
skipping to change at page 14, line 47 skipping to change at page 15, line 44
combined, so that a new Kind would indicate a specific combination combined, so that a new Kind would indicate a specific combination
of options, whose order is fixed and whose length is indicated by of options, whose order is fixed and whose length is indicated by
one Length field. Most TCP options use fields whose size is much one Length field. Most TCP options use fields whose size is much
larger than the required Kind and Length components, so the larger than the required Kind and Length components, so the
resulting efficiency is typically insufficient for additional resulting efficiency is typically insufficient for additional
options. options.
The option space of an initial SYN segment might be extended by The option space of an initial SYN segment might be extended by
using multiple initial segments (e.g., multiple SYNs or a SYN and using multiple initial segments (e.g., multiple SYNs or a SYN and
non-SYN) or based on the context of previous or parallel non-SYN) or based on the context of previous or parallel
connections. Because of their potential complexity, these approaches connections. This method may also be needed to extend space in the
are addressed in separate documents [Br14][To14]. SYN/ACK in the presence of misbehaving middleboxes. Because of their
potential complexity, these approaches are addressed in separate
documents [Br14][To14].
Option space cannot be extended in outer layer headers, e.g., IPv4 Option space cannot be extended in outer layer headers, e.g., IPv4
or IPv6. These layers typically try to avoid extensions altogether, or IPv6. These layers typically try to avoid extensions altogether,
to simplify forwarding processing at routers. Introducing new shim to simplify forwarding processing at routers. Introducing new shim
layers to accommodate additional option space would interfere with layers to accommodate additional option space would interfere with
deep-packet inspection mechanisms that are in widespread use. deep-packet inspection mechanisms that are in widespread use.
As a result, EDO does not attempt to extend the space available for 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 options in TCP initial SYNs. It does extend that space in all other
segments (including SYN/ACK), which has always been trivially segments (including SYN/ACK), which has always been trivially
possible once an option is defined. possible once an option is defined.
8. Security Considerations 8. Implementation Issues
TCP segment processing can involve accessing nonlinear data
structures, such as chains of buffers. Such chains are often
designed so that the maximum default TCP header (60 bytes) fits in
the first buffer. Extending the TCP header across multiple buffers
may necessitate buffer traversal functions that span boundaries
between buffers. Such traversal can also have a significant
performance impact, which is additional rationale for using TCP
option space - even extended option space - sparingly.
Although EDO can be large enough to consume the entire segment, it
is important to leave space for data so that the TCP connection can
make forward progress. It would be wise to limit EDO to consuming no
more than MSS-4 bytes of the IP segment, preferably even less (e.g.,
MSS-128 bytes).
When using the ExID variant for testing and experimentation, either
TCP option codepoint (253, 254) is valid in sent or received
segments.
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.
9. Security Considerations
It is meaningless to have the Data Offset further exceed the It is meaningless to have the Data Offset further exceed the
position of the EDO data offset option. position of the EDO data offset option.
>> When the EDO length option is present, the EDO length 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, SHOULD be the last non-null option covered by the TCP Data Offset,
because it would be the last option affected by 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 This also makes it more difficult to use the Data Offset field as a
covert channel. covert channel.
9. IANA Considerations 10. IANA Considerations
We request that, upon publication, this option be assigned a TCP We request that, upon publication, this option be assigned a TCP
Option codepoint by IANA, which the RFC Editor will replace EDO-OPT Option codepoint by IANA, which the RFC Editor will replace EDO-OPT
in this document with codepoint value. in this document with codepoint value.
This section is to be removed prior to publication as an RFC. The TCP Experimental ID (ExID) with a 16-bit value of 0x0ED0 (in
network standard byte order) has been assigned for use during
testing and preliminary experiments.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, September 1981.
10.2. Informative References 11.2. Informative References
[Al06] Allman, M., "TCPx2: Don't Fence Me In", draft-allman- [Al06] Allman, M., "TCPx2: Don't Fence Me In", draft-allman-
tcpx2-hack-00 (work in progress), May 2006. tcpx2-hack-00 (work in progress), May 2006.
[Br14] Briscoe, B., "Extended TCP Option Space in the Payload of [Br14] Briscoe, B., "Extended TCP Option Space in the Payload of
an Alternative SYN", draft-briscoe-tcpm-syn-op-sis-02 an Alternative SYN", draft-briscoe-tcpm-syn-op-sis-02
(work in progress), September 2014. (work in progress), September 2014.
[Ch14] Cheng, Y., Chu, J., and A. Jain, "TCP Fast Open", draft- [Ch14] Cheng, Y., Chu, J., and A. Jain, "TCP Fast Open", draft-
ietf-tcpm-fastopen-10, September 2014. ietf-tcpm-fastopen-10, September 2014.
[Ed08] Eddy, W. and A. Langley, "Extending the Space Available [Ed08] Eddy, W. and A. Langley, "Extending the Space Available
for TCP Options", draft-eddy-tcp-loo-04 (work in for TCP Options", draft-eddy-tcp-loo-04 (work in
progress), July 2008. progress), July 2008.
[Ho11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A.,
Handley, M., and H. Tokuda, "Is it still possible to
extend TCP", Proc. ACM Sigcomm Internet Measurement
Conference (IMC), 2011, pp. 181-194.
[Ko04] Kohler, E., "Extended Option Space for TCP", draft-kohler- [Ko04] Kohler, E., "Extended Option Space for TCP", draft-kohler-
tcpm-extopt-00 (work in progress), September 2004. tcpm-extopt-00 (work in progress), September 2004.
[Ni14] Nishida, Y., "A-PAWS: Alternative Approach for PAWS", [Ni14] Nishida, Y., "A-PAWS: Alternative Approach for PAWS",
draft-nishida-tcpm-apaws-01 (work in progress), June 2014. draft-nishida-tcpm-apaws-01 (work in progress), June 2014.
[Ra12] Ramaiah, A., "TCP option space extension", draft-ananth- [Ra12] Ramaiah, A., "TCP option space extension", draft-ananth-
tcpm-tcpoptext-00 (work in progress), March 2012. tcpm-tcpoptext-00 (work in progress), March 2012.
[RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792,
skipping to change at page 17, line 17 skipping to change at page 19, line 9
September 2014. September 2014.
[To14] Touch, J., T. Faber, "TCP SYN Extended Option Space Using [To14] Touch, J., T. Faber, "TCP SYN Extended Option Space Using
an Out-of-Band Segment", draft-touch-tcpm-tcp-syn-ext-opt- an Out-of-Band Segment", draft-touch-tcpm-tcp-syn-ext-opt-
01 (work in progress), September 2014. 01 (work in progress), September 2014.
[Yo11] Yourtchenko, A., "Introducing TCP Long Options by Invalid [Yo11] Yourtchenko, A., "Introducing TCP Long Options by Invalid
Checksum", draft-yourtchenko-tcp-loic-00 (work in Checksum", draft-yourtchenko-tcp-loic-00 (work in
progress), April 2011. progress), April 2011.
11. Acknowledgments 12. Acknowledgments
The authors would like to thank the IETF TCPM WG for their feedback, The authors would like to thank the IETF TCPM WG for their feedback,
in particular: Oliver Bonaventure, Bob Briscoe, Ted Faber, John in particular: Oliver Bonaventure, Bob Briscoe, Ted Faber, John
Leslie, Richard Scheffenegger, and Alexander Zimmerman. Leslie, Pasi Sarolahti, Richard Scheffenegger, and Alexander
Zimmerman.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses Authors' Addresses
Joe Touch Joe Touch
USC/ISI USC/ISI
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292-6695 USA Marina del Rey, CA 90292-6695 USA
 End of changes. 42 change blocks. 
112 lines changed or deleted 207 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/