< draft-ietf-tcpm-tcp-edo-07.txt   draft-ietf-tcpm-tcp-edo-08.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: July 2017 January 3, 2017 Expires: December 2017 June 26, 2017
TCP Extended Data Offset Option TCP Extended Data Offset Option
draft-ietf-tcpm-tcp-edo-07.txt draft-ietf-tcpm-tcp-edo-08.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 July 3, 2017. This Internet-Draft will expire on December 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 3, line 28 skipping to change at page 3, line 28
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 and SYN/ACK. This document also explains why the option space of SYN and SYN/ACK. This document also explains why the option space of
the initial SYN segments cannot be extended as individual segments the initial SYN segments cannot be extended as individual segments
without severe impact on TCP's initial handshake and the SYN/ACK without severe impact on TCP's initial handshake and the SYN/ACK
limitation that results from potential middlebox misbehavior. limitation that results from potential middlebox misbehavior.
Multiple other TCP extensions are being considered in the TCPM Multiple other TCP extensions are being considered in the TCPM
working group in order to address the case of SYN and SYN/ACK working group in order to address the case of SYN and SYN/ACK
segments [Bo14][Br14][To15]. Some of these other extensions can work segments [Bo14][Br14][To17]. Some of these other extensions can work
in conjunction with EDO (e.g., [To15]). in conjunction with EDO (e.g., [To17]).
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 8, line 20 skipping to change at page 8, line 20
>> Options that depend on other options, such as TCP-AO [RFC5925] >> Options that depend on other options, such as TCP-AO [RFC5925]
(which may include or exclude options in MAC calculations) MUST also (which may include or exclude options in MAC calculations) MUST also
be augmented to interpret the EDO Extension option to operate be augmented to interpret the EDO Extension option to operate
correctly. correctly.
5.3. The two EDO Extension variants 5.3. The two EDO Extension variants
There are two variants of the EDO Extension option; one includes a There are two variants of the EDO Extension option; one includes a
copy of the TCP segment length, copied from the TCP pseduoheader copy of the TCP segment length, copied from the TCP pseduoheader
[RFC793]. The Segment_Length field is added to the longer variant to [RFC793]. The Segment_Length field is added to the longer variant to
detect when segments are merged by middleboxes or TCP offload detect when segments are incorrectly and inappropriately merged by
processing but without consideration for the additional option space middleboxes or TCP offload processing but without consideration for
indicated by the EDO Header_Length field. Such effects are described the additional option space indicated by the EDO Header_Length
in further detail in Section 7.2. field. Such effects are described in further detail in Section 7.2.
>> An endpoint MAY use either variant of the EDO Extension option >> An endpoint MAY use either variant of the EDO Extension option
interchangeably. interchangeably.
When the longer, 6-byte variant is used, the Segment_Length field is When the longer, 6-byte variant is used, the Segment_Length field is
used to check whether modification of the segment was performed used to check whether modification of the segment was performed
consistent with knowledge of the EDO option. The Segment_Length consistent with knowledge of the EDO option. The Segment_Length
field will detect any modification of the length of the segment, field will detect any modification of the length of the segment,
such as might occur when segments are split or merged, that occurs such as might occur when segments are split or merged, that occurs
without also updating the Segment Length field as well. The Segment without also updating the Segment Length field as well. The Segment
skipping to change at page 11, line 15 skipping to change at page 11, line 15
segments. segments.
The full combination of the above options (47 bytes for TS, WS, MSS, The full combination of the above options (47 bytes for TS, WS, MSS,
SACK, TCP-AO, and MPTCP) does not fit in the existing SYN option SACK, TCP-AO, and MPTCP) does not fit in the existing SYN option
space and (as noted) that space cannot be extended within a single space and (as noted) that space cannot be extended within a single
SYN segment. There has been a proposal to change TS to a 2 byte "TS SYN segment. There has been a proposal to change TS to a 2 byte "TS
permitted" signal in the initial SYN, provided it can be safely permitted" signal in the initial SYN, provided it can be safely
enabled during the connection later or might be avoided completely enabled during the connection later or might be avoided completely
[Ni15]. Even using "TS-permitted", the total space is still too [Ni15]. Even using "TS-permitted", the total space is still too
large to support in the initial SYN without SYN option space large to support in the initial SYN without SYN option space
extension [Bo14][Br14][To15]. extension [Bo14][Br14][To17].
The EDO Extension option has negligible impact on other headers, The EDO Extension option has negligible impact on other headers,
because it can either come first or just after security information, because it can either come first or just after security information,
and in either case the additional 4 or 6 bytes are easily and in either case the additional 4 or 6 bytes are easily
accommodated within the TCP Data Offset length. Once the EDO option accommodated within the TCP Data Offset length. Once the EDO option
is processed, the entirety of the remainder of the TCP segment is is processed, the entirety of the remainder of the TCP segment is
available for any remaining options. available for any remaining options.
6.5. Connectionless Resets 6.5. Connectionless Resets
skipping to change at page 13, line 11 skipping to change at page 13, line 11
They would support EDO by following the host requirements herein on They would support EDO by following the host requirements herein on
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.
7.2. Middlebox Interference with EDO 7.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 inappropriately and
boundaries, might mix option information with user data if they did incorrectly modify TCP segment boundaries, might mix option
not support EDO. Such devices might also interfere with other TCP information with user data if they did not support EDO. Such devices
options such as TCP-AO. There are three types of such boxes: might also interfere with other TCP options such as TCP-AO. There
are three types of such boxes:
o Those that process received options and transmit sent options o Those that process received options and transmit sent options
separately, i.e., although they rewrite segments, they behave as separately, i.e., although they rewrite segments, they behave as
TCP endpoints in both directions. TCP endpoints in both directions.
o Those that split segments, taking a received segment and emitting o Those that split segments, taking a received segment and emitting
two or more segments with revised headers. two or more segments with revised headers.
o Those that join segments, receiving multiple segments and o Those that join segments, receiving multiple segments and
emitting a single segment whose data is the concatenation of the emitting a single segment whose data is the concatenation of the
skipping to change at page 13, line 45 skipping to change at page 13, line 46
the corresponding extended option space contents. However, the most the corresponding extended option space contents. However, the most
comprehensive study of these cases indicates that "although comprehensive study of these cases indicates that "although
middleboxes do split and coalesce segments, none did so while middleboxes do split and coalesce segments, none did so while
passing unknown options" [Ho11]. passing unknown options" [Ho11].
Note that the second and third types of middlebox behaviors listed Note that the second and third types of middlebox behaviors listed
above may create syndromes similar to TCP transmit and receive above may create syndromes similar to TCP transmit and receive
hardware offload engines that incorrectly modify segments with hardware offload engines that incorrectly modify segments with
unknown options. unknown options.
Middleboxes that silently remove options they do not implement have Middleboxes that silently remove options that they do not implement
been observed [Ho11]. Such boxes interfere with the use of the EDO have been observed [Ho11]. Such boxes interfere with the use of the
Extension option in the SYN and SYN/ACK segments because extended EDO Extension option in the SYN and SYN/ACK segments because
option space would be misinterpreted as user data if the EDO extended option space would be misinterpreted as user data if the
Extension option were removed, and this cannot be avoided. This is EDO Extension option were removed, and this cannot be avoided. This
one reason that SYN and SYN/ACK extension requires alternate is one reason that SYN and SYN/ACK extension requires alternate
mechanisms (see Section 8.7). It is also the reason for the 6-byte mechanisms (see Section 8.7). It is also the reason for the 6-byte
EDO Extension variant (see Section 5.3), which can detect such EDO Extension variant (see Section 5.3), which can detect such
merging or splitting of segments. Further, if such middleboxes merging or splitting of segments. Further, if such middleboxes
become present on a path they could cause similar misinterpretation become present on a path they could cause similar misinterpretation
on segments exchanged in the ESTABLISHED and subsequent states. As a on segments exchanged in the ESTABLISHED and subsequent states. As a
result, this document requires that the EDO Extension option be result, this document requires that the EDO Extension option be
avoided on the SYN/ACK and that this option needs to be used on all avoided on the SYN/ACK and that this option needs to be used on all
segments once successfully negotiated and encourages use of the 6- segments once successfully negotiated and encourages use of the 6-
byte EDO Extension variant. byte EDO Extension variant.
skipping to change at page 19, line 11 skipping to change at page 19, line 11
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. This method may also be needed to extend space in the connections. This method may also be needed to extend space in the
SYN/ACK in the presence of misbehaving middleboxes. Because of their SYN/ACK in the presence of misbehaving middleboxes. Because of their
potential complexity, these approaches are addressed in separate potential complexity, these approaches are addressed in separate
documents [Bo14][Br14][To15]. documents [Bo14][Br14][To17].
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
skipping to change at page 20, line 4 skipping to change at page 20, line 4
TCP option codepoint (253, 254) is valid in sent or received TCP option codepoint (253, 254) is valid in sent or received
segments. segments.
Implementers need to be careful about the potential for offload Implementers need to be careful about the potential for offload
support interfering with this option. The EDO data needs to be support interfering with this option. The EDO data needs to be
passed to the protocol stack as part of the option space, not passed to the protocol stack as part of the option space, not
integrated with the user segment, to allow the offload to integrated with the user segment, to allow the offload to
independently determine user data segment boundaries and combine independently determine user data segment boundaries and combine
them correctly with the extended option data. Some legacy hardware them correctly with the extended option data. Some legacy hardware
receive offload engines may present challenges in this regard, and receive offload engines may present challenges in this regard, and
may be incompatible with EDO where they incorrectly process segments may be incompatible with EDO where they incorrectly attempt to
with unknown options. Such offload engines should be considered part process segments with unknown options. Such offload engines are part
of the protocol stack and updated accordingly. Issues with incorrect of the protocol stack and updated accordingly. Issues with incorrect
resegmentation by an offload engine can be detected in the same way resegmentation by an offload engine can be detected in the same way
as middlebox tampering. as middlebox tampering.
10. Security Considerations 10. 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 Extension option is present, the EDO Extension >> When the EDO Extension option is present, the EDO Extension
skipping to change at page 22, line 21 skipping to change at page 22, line 21
"TCP Extensions for Multipath Operation with Multiple "TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013. Addresses", RFC 6824, January 2013.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger
(Ed.), "TCP Extensions for High Performance", RFC 7323, (Ed.), "TCP Extensions for High Performance", RFC 7323,
September 2014. September 2014.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, December 2014. Fast Open", RFC 7413, December 2014.
[To15] Touch, J., T. Faber, "TCP SYN Extended Option Space Using [To17] 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-
06 (work in progress), January 2017. 07 (work in progress), June 2017.
[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.
13. Acknowledgments 13. 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, Pasi Sarolahti, Richard Scheffenegger, and Alexander Leslie, Pasi Sarolahti, Richard Scheffenegger, and Alexander
Zimmerman. Zimmerman.
This work is partly supported by USC/ISI's Postel Center.
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
Phone: +1 (310) 448-9151 Phone: +1 (310) 448-9151
 End of changes. 13 change blocks. 
25 lines changed or deleted 28 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/