idnits 2.17.1 draft-touch-tcpm-tcp-edo-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC793, updated by this document, for RFC5378 checks: 1981-09-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 25, 2014) is 3654 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-10) exists of draft-ietf-tcpm-fastopen-08 -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TCPM WG J. Touch 2 Internet Draft USC/ISI 3 Updates: 793 Wes Eddy 4 Intended status: Standards Track MTI Systems 5 Expires: October 2014 April 25, 2014 7 TCP Extended Data Offset Option 8 draft-touch-tcpm-tcp-edo-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on October 25, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. 45 Abstract 47 TCP segments include a Data Offset field to indicate space for TCP 48 options, but the size of the field can limit the space available for 49 complex options that have evolved. This document updates RFC 793 50 with an optional TCP extension to that space and explains why such 51 extensions cannot be used in the initial SYN of a connection. 53 Table of Contents 55 1. Introduction...................................................2 56 2. Conventions used in this document..............................3 57 3. Requirements for Extending TCP's Data Offset...................3 58 4. Initial SYN Data Offset Cannot be Extended.....................3 59 5. The TCP EDO Option.............................................4 60 6. TCP EDO Interaction with TCP...................................7 61 6.1. TCP User Interface........................................7 62 6.2. TCP States and Transitions................................7 63 6.3. TCP Segment Processing....................................7 64 6.4. Impact on TCP Header Size.................................7 65 6.5. Connectionless Resets.....................................8 66 6.6. ICMP Handling.............................................8 67 7. Interactions with Middleboxes..................................8 68 8. Security Considerations........................................9 69 9. IANA Considerations............................................9 70 10. References....................................................9 71 10.1. Normative References.....................................9 72 10.2. Informative References..................................10 73 11. Acknowledgments..............................................11 75 1. Introduction 77 TCP's Data Offset is a 4-bit field, which indicates the number of 78 32-bit words of the entire TCP header [RFC793]. This limits the 79 current total header size to 60 bytes, of which the basic header 80 occupies 20, leaving 40 bytes for options. These 40 bytes are 81 increasingly becoming a limitation to the development of advanced 82 capabilities, such as when SACK [RFC2018][RFC6675], Multipath 83 [RFC6824], and TCP-AO [RFC5925] are combined. 85 This document specifies the TCP Extended Data Offset (EDO) option, 86 and is independent of (and thus compatible with) IPv4 and IPv6. EDO 87 extends the space available for TCP options, except for the initial 88 SYN segment (i.e., SYN and not ACK, the first segment of a new 89 connection). This document also explains why the option space of an 90 initial SYN cannot be extended without severe impact on TCP's 91 initial handshake. 93 2. Conventions used in this document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC-2119 [RFC2119]. 99 In this document, these words will appear with that interpretation 100 only when in ALL CAPS. Lower case uses of these words are not to be 101 interpreted as carrying RFC-2119 significance. 103 In this document, the characters ">>" preceding an indented line(s) 104 indicates a compliance requirement statement using the key words 105 listed above. This convention aids reviewers in quickly identifying 106 or finding the explicit compliance requirements of this RFC. 108 3. Requirements for Extending TCP's Data Offset 110 The primary goal of extending the TCP Data Offset field is to 111 increase the space available for TCP options. 113 An important requirement of any such extension is that it not impact 114 legacy endpoints. I.e., endpoints seeking to use this new option 115 should not incur additional delay or segment exchanges to connect to 116 either new endpoints supporting this option or legacy endpoints 117 without this option. We call this a "backward downgrade" capability. 119 4. Initial SYN Data Offset Cannot be Extended 121 There have been a number of previous attempts to extend the space 122 available for TCP options [Al06][Ed08][Ko04][Ra12][Yo11]. The key 123 difficulty with most previous proposals is the desire to extend the 124 option space in all TCP segments, including the initial SYN, i.e., 125 SYN with no ACK, typically the first segment of a connection. There 126 are three basic ways in which this has been attempted: 128 1. Use of a TCP option. 130 2. Redefinition of the existing TCP header fields. 132 3. Use of option space in multiple TCP segments (split-space). 134 A new TCP option cannot extend the Data Offset of a TCP initial SYN. 135 All TCP segments, including the initial SYN, may include user data 136 in the payload data [RFC793], and this can be useful for some 137 proposed features such as TCP Fast Open [Ch14]. Legacy endpoints 138 that ignore the new option would process the payload contents as 139 user data and send an ACK. Once ACK'd, this data cannot be removed 140 from the user stream. 142 The six Reserved TCP header bits cannot be redefined easily, because 143 the original specification did not require their contents to be 144 ignored, even though three of those bits have already been redefined 145 (ECE/CWR [RFC3168] and NS [RFC3540]). Legacy endpoints are required 146 to drop TCP segments where those bits are not zero, making it 147 difficult to assume backward downgrade. 149 TCP initial SYN (SYN and not ACK) segments can use every other TCP 150 header field except the Acknowledgement number, which is not used 151 because the ACK field is not set. In all other segments, all fields 152 except the three remaining Reserved header bits. The total amount of 153 space, in either case, is insufficient to be useful in extending the 154 option space. 156 The representation of TCP options can be optimized to minimize the 157 space needed. In such cases, multiple Kind and Length fields are 158 combined, so that a new Kind would indicate a specific combination 159 of options, whose order is fixed and whose length is indicated by 160 one Length field. Most TCP options use fields whose size is much 161 larger than the required Kind and Length components, so the 162 resulting efficiency is typically insufficient for additional 163 options. 165 Option space cannot be extended across multiple SYN segments. A 166 legacy endpoint would continue the connection with incomplete option 167 information. 169 Option space cannot be extended in outer layer headers, e.g., IPv4 170 or IPv6. These layers typically try to avoid extensions altogether, 171 to simplify forwarding processing at routers. Introducing new shim 172 layers to accommodate additional option space would interfere with 173 deep-packet inspection mechanisms that are in widespread use. 175 As a result, EDO does not attempt to extend the space available for 176 options in TCP initial SYNs. It does extend that space in all other 177 segments (including SYN-ACK), which has always been trivially 178 possible once an option is defined. 180 5. The TCP EDO Option 182 The TCP EDO option is organized as indicated in Figure 1 and Figure 183 2. For initial SYN segments (i.e., those whose ACK bit is not set), 184 the EDO request option consists of the required Kind and Length 185 fields only. All other segments optionally use the EDO length 186 option, which adds a Header_Length field (in network-standard byte 187 rder), indicating the length of the entire TCP header in bytes. The 188 codepoint value of the EDO Kind is EDO-OPT. 190 +--------+--------+ 191 | Kind | Length | 192 +--------+--------+ 194 Figure 1 TCP EDO request option 196 +--------+--------+--------+--------+ 197 | Kind | Length | Header_length | 198 +--------+--------+--------+--------+ 200 Figure 2 TCP EDO length option 202 EDO support is determined in both directions using the same 203 exchange. An endpoint seeking to enable EDO support includes the EDO 204 request option in the initial SYN. 206 >> Connections using EDO MUST negotiate its availability during the 207 initial three-way handshake. 209 >> An endpoint confirming EDO support MUST respond with EDO length 210 option in its SYN-ACK. 212 The EDO length option is required in SYN-ACKs when confirming 213 support for EDO. The SYN-ACK thus can take advantage of EDO, using 214 it to extend its option space. If such extension is not required, 215 then EDO would be equal to 4 * Data Offset (i.e., EDO would indicate 216 in bytes the same length indicated by Data Offset in words). 218 >> Once negotiated on a connection, EDO MAY be present as needed on 219 other segments in either direction. The EDO option SHOULD NOT be 220 used if the total option space needed can be accommodated by the 221 existing Data Offset field. 223 >> The EDO request option (i.e., whose option length is 2) MAY occur 224 in an initial SYN as desired (e.g., by the user/application), but 225 MUST NOT be inserted in other segments. If the EDO request option is 226 received, it MUST be silently ignored. 228 >> The EDO length option MAY occur in segments other than the 229 initial SYN if EDO has been negotiated on a connection. If EDO has 230 not been negotiated and agreed, the EDO length option MUST be 231 silently ignored. The EDO length option MUST NOT be sent in an 232 initial SYN segment, and MUST be silently ignored and not 233 acknowledged if so received. 235 EDO extends the space available for options, but does not consume 236 space unless needed. Segments that don't need the additional space 237 can use the existing Data Offset field as currently specified 238 [RFC793]. When processing a segment, EDO needs to be visible within 239 the area indicated by the Data Offset field, so that processing can 240 use the EDO Header_length to override the Data Offset for that 241 segment. 243 >> The EDO length option MUST occur within the length of the TCP 244 Data Offset. 246 >> The EDO length option indicates the total length of the header. 247 The EDO Header_length field MUST NOT exceed that of the total 248 segment size (i.e., TCP Length). The EDO Header_length SHOULD be a 249 multiple of 4 to simplify processing. 251 >> The EDO request option SHOULD be aligned on a 16-bit boundary and 252 the EDO length option SHOULD be aligned on a 32-bit boundary, in 253 both cases for simpler processing. 255 For example, a segment with only EDO would have a Data Offset of 6, 256 where EDO would be the first option processed, at which point the 257 EDO length option would override the Data Offset and processing 258 would continue until the end of the TCP header as indicated by the 259 EDO Header_length field. 261 There are cases where it might be useful to process other options 262 before EDO, notably those that determine whether the TCP header is 263 valid, such as authentication, encryption, or alternate checksums. 264 In those cases, the EDO length option is preferably the first option 265 after a validation option, and the payload after the Data Offset is 266 treated as user data for the purposes of validation. 268 >> The EDO length option SHOULD occur as early as possible, either 269 first or just after any authentication or encryption, and SHOULD be 270 the last option covered by the Data Offset value. 272 Other options are generally handled in the same manner as when the 273 EDO option is not active, unless they interact with other options. 274 One such example is TCP-AO [RFC5925], which optionally ignores the 275 contents of TCP options, so it would need to be aware of EDO to 276 operate correctly when options are excluded from the HMAC 277 calculation. 279 >> Options that depend on other options, such as TCP-AO [RFC5925] 280 (which may include or exclude options in MAC calculations) MUST also 281 be augmented to interpret the EDO length option to operate 282 correctly. 284 6. TCP EDO Interaction with TCP 286 The following subsections describe how EDO interacts with the TCP 287 specification [RFC793]. 289 6.1. TCP User Interface 291 The TCP EDO option is enabled on a connection using a mechanism 292 similar to any other per-connection option. In Unix systems, this is 293 typically performed using the 'setsockopt' function. 295 >> Implementations can also employ system-wide defaults, however the 296 default SHOULD be to not use this extension so as to avoid 297 interfering with legacy applications. 299 6.2. TCP States and Transitions 301 TCP EDO does not alter the existing TCP state or state transition 302 mechanisms. 304 6.3. TCP Segment Processing 306 TCP EDO alters segment processing during the TCP option processing 307 step. Once detected, the TCP EDO length option overrides the TCP 308 Data Offset field for all subsequent option processing. Option 309 processing continues at the next option after the EDO length option. 311 6.4. Impact on TCP Header Size 313 The TCP EDO request option increases SYN header length by a minimum 314 of 2 bytes. Currently popular SYN options total 11 bytes, which 315 leaves more than enough room for the EDO request: 317 o SACK permitted (2 bytes) [RFC2018][RFC6675] 319 o Timestamp (10 bytes) [RFC1323] 321 o Window scale (3 bytes) [RFC1323] 323 o MSS option (4 bytes) [RFC793] 325 TCP EDO can also be negotiated in SYNs with the following options: 327 o TCP-AO (authentication) (16 bytes) [RFC5925] 329 o Multipath TCP (20 bytes) [RFC6824] 331 Some combinations of the above options may not fit in the existing 332 SYN option space, and (as noted) that space cannot be extended. 334 The EDO option has negligible impact on other headers, because it 335 can either come first or just after security information, and in 336 either case the additional 4 bytes are easily accommodated within 337 the TCP Data Offset length. Once the EDO option is processed, the 338 entirety of the remainder of the TCP segment is available for any 339 remaining options. 341 6.5. Connectionless Resets 343 A RST may arrive during a currently active connection or may be 344 needed to cleanup old state from an abandoned connection. The latter 345 occurs when a new SYN is sent to an endpoint with matching existing 346 connection state, at which point that endpoint responds with a RST 347 and both ends remove stale information. 349 The EDO option is not mandatory in any TCP segment, except the SYN 350 and SYN-ACK of the three-way handshake to establish its support. 352 >> The EDO length option MAY occur in a RST when the endpoint has 353 connection state that has negotiated EDO. However, unless the RST is 354 generated by an incoming segment that includes an EDO option, the 355 RST MUST NOT include the EDO length option. 357 6.6. ICMP Handling 359 ICMP responses are intended to include the IP and the port fields of 360 TCP and UDP headers of typical TCP/IP and UDP/IP packets [RFC792]. 361 This includes the first 8 data bytes of the original datagram, 362 intended to include the transport port numbers used for connection 363 demultiplexing. Later specifications encourage returning as much of 364 the original payload as possible [RFC1812]. In either case, legacy 365 options or new options in the EDO extension area might or might not 366 be included, and so options are generally not assumed to be part of 367 ICMP processing anyway. 369 7. Interactions with Middleboxes 371 Any new TCP option may be impacted by the presence of any on-path 372 device that examines or modifies transport headers [RFC3234]. Boxes 373 that parse or modify TCP options need to follow the same 374 requirements of TCP endpoints in supporting EDO, or they could 375 interfere with connections. The primary concern is so-called 376 "transparent" rewriting proxies, which modify TCP segment boundaries 377 and thus would mix option information with user data if they do not 378 support EDO. Such devices interfere with many other TCP options, and 379 although their use is not common they would interfere with 380 connections that use EDO. 382 More common are NATs, which rewrite IP address and/or transport port 383 fields. NATs are not affected by the EDO option. 385 Deep-packet inspection systems that inspect TCP segment payloads or 386 attempt to reconstitute the data stream would incorrectly include 387 options, which might interfere with their operation. 389 8. Security Considerations 391 It is meaningless to have the Data Offset further exceed the 392 position of the EDO data offset option. 394 >> When the EDO length option is present, the EDO length option 395 SHOULD be the last non-null option covered by the TCP Data Offset, 396 because it would be the last option affected by Data Offset. 398 This also helps prevent the Data Offset from being used as a covert 399 channel. 401 9. IANA Considerations 403 We request that, upon publication, this option be assigned a TCP 404 Option codepoint by IANA, which the RFC Editor will replace EDO-OPT 405 in this document with codepoint value. 407 This section is to be removed prior to publication as an RFC. 409 10. References 411 10.1. Normative References 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, March 1997. 416 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 417 793, September 1981. 419 10.2. Informative References 421 [Al06] Allman, M., "TCPx2: Don't Fence Me In", draft-allman- 422 tcpx2-hack-00 (work in progress), May 2006. 424 [Ch14] Cheng, Y., Chu, J., and A. Jain, "TCP Fast Open", draft- 425 ietf-tcpm-fastopen-08, March 2014. 427 [Ed08] Eddy, W. and A. Langley, "Extending the Space Available 428 for TCP Options", draft-eddy-tcp-loo-04 (work in 429 progress), July 2008. 431 [Ko04] Kohler, E., "Extended Option Space for TCP", draft-kohler- 432 tcpm-extopt-00 (work in progress), September 2004. 434 [Ra12] Ramaiah, A., "TCP option space extension", draft-ananth- 435 tcpm-tcpoptext-00 (work in progress), March 2012. 437 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. 439 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 440 for High Performance", RFC 1323, May 1992. 442 [RFC1812] Baker, F. (Ed.), "Requirements for IP Version 4 443 Routers," RFC 1812, June 1995. 445 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 446 Selective Acknowledgment Options", RFC 2018, October 1996. 448 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 449 of Explicit Congestion Notification (ECN) to IP", RFC 450 3168, September 2001. 452 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 453 Issues", RFC 3234, February 2002. 455 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 456 Congestion Notification (ECN) Signaling with Nonces", RFC 457 3540, June 2003. 459 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 460 Authentication Option", RFC 5925, June 2010. 462 [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., 463 and Y.. Nishida, "A Conservative Loss Recovery Algorithm 464 Based on Selective Acknowledgment (SACK) for TCP", RFC 465 6675, August 2012. 467 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 468 "TCP Extensions for Multipath Operation with Multiple 469 Addresses", RFC 6824, January 2013. 471 [Yo11] Yourtchenko, A., "Introducing TCP Long Options by Invalid 472 Checksum", draft-yourtchenko-tcp-loic-00 (work in 473 progress), April 2011. 475 11. Acknowledgments 477 The authors would like to thank the IETF TCPM WG for their feedback, 478 in particular: Oliver Bonaventure, Richard Scheffenegger, and 479 Alexander Zimmerman. 481 This document was prepared using 2-Word-v2.0.template.dot. 483 Authors' Addresses 485 Joe Touch 486 USC/ISI 487 4676 Admiralty Way 488 Marina del Rey, CA 90292-6695 USA 490 Phone: +1 (310) 448-9151 491 Email: touch@isi.edu 493 Wesley M. Eddy 494 MTI Systems 495 US 497 Email: wes@mti-systems.com