idnits 2.17.00 (12 Aug 2021) /tmp/idnits2562/draft-ietf-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 -- The document date (October 13, 2014) is 2776 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) == Outdated reference: A later version (-03) exists of draft-briscoe-tcpm-syn-op-sis-02 == Outdated reference: draft-ietf-tcpm-fastopen has been published as RFC 7413 == Outdated reference: A later version (-02) exists of draft-nishida-tcpm-apaws-01 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) == Outdated reference: A later version (-11) exists of draft-touch-tcpm-tcp-syn-ext-opt-01 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 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: April 2015 October 13, 2014 7 TCP Extended Data Offset Option 8 draft-ietf-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 April 13, 2015. 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. Code Components extracted from this 44 document must include Simplified BSD License text as described in 45 Section 4.e of the Trust Legal Provisions and are provided without 46 warranty as described in the Simplified BSD License. 48 Abstract 50 TCP segments include a Data Offset field to indicate space for TCP 51 options, but the size of the field can limit the space available for 52 complex options that have evolved. This document updates RFC 793 53 with an optional TCP extension to that space to support the use of 54 multiple large options such as SACK with either TCP Multipath or TCP 55 AO. It also explains why the initial SYN of a connection cannot be 56 extending a single segment. 58 Table of Contents 60 1. Introduction...................................................3 61 2. Conventions used in this document..............................3 62 3. Requirements for Extending TCP's Data Offset...................3 63 4. The TCP EDO Option.............................................4 64 5. TCP EDO Interaction with TCP...................................6 65 5.1. TCP User Interface........................................6 66 5.2. TCP States and Transitions................................7 67 5.3. TCP Segment Processing....................................7 68 5.4. Impact on TCP Header Size.................................7 69 5.5. Connectionless Resets.....................................8 70 5.6. ICMP Handling.............................................9 71 6. Interactions with Middleboxes..................................9 72 6.1. Middlebox Coexistence with EDO............................9 73 6.2. Middlebox Interference with EDO..........................10 74 7. Comparison to Previous Proposals..............................11 75 7.1. EDO Criteria.............................................11 76 7.2. Summary of Approaches....................................12 77 7.3. Extended Segments........................................13 78 7.4. TCPx2....................................................13 79 7.5. LO/SLO...................................................13 80 7.6. LOIC.....................................................14 81 7.7. Problems with Extending the Initial SYN..................14 82 8. Implementation Issues.........................................16 83 9. Security Considerations.......................................16 84 10. IANA Considerations..........................................17 85 11. References...................................................17 86 11.1. Normative References....................................17 87 11.2. Informative References..................................17 88 12. Acknowledgments..............................................19 90 1. Introduction 92 TCP's Data Offset is a 4-bit field, which indicates the number of 93 32-bit words of the entire TCP header [RFC793]. This limits the 94 current total header size to 60 bytes, of which the basic header 95 occupies 20, leaving 40 bytes for options. These 40 bytes are 96 increasingly becoming a limitation to the development of advanced 97 capabilities, such as when SACK [RFC2018][RFC6675] is combined with 98 either Multipath TCP [RFC6824], TCP-AO [RFC5925], or TCP Fast Open 99 [Ch14]. 101 This document specifies the TCP Extended Data Offset (EDO) option, 102 and is independent of (and thus compatible with) IPv4 and IPv6. EDO 103 extends the space available for TCP options, except for the initial 104 SYN and SYN/ACK. This document also explains why the option space of 105 the initial SYN segments cannot be extended as individual segments 106 without severe impact on TCP's initial handshake and the SYN/ACK 107 limitation that results from middlebox misbehavior. 109 2. Conventions used in this document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC-2119 [RFC2119]. 115 In this document, these words will appear with that interpretation 116 only when in ALL CAPS. Lower case uses of these words are not to be 117 interpreted as carrying RFC-2119 significance. 119 In this document, the characters ">>" preceding an indented line(s) 120 indicates a compliance requirement statement using the key words 121 listed above. This convention aids reviewers in quickly identifying 122 or finding the explicit compliance requirements of this RFC. 124 3. Requirements for Extending TCP's Data Offset 126 The primary goal of extending the TCP Data Offset field is to 127 increase the space available for TCP options in all segments except 128 the initial SYN. 130 An important requirement of any such extension is that it not impact 131 legacy endpoints. Endpoints seeking to use this new option should 132 not incur additional delay or segment exchanges to connect to either 133 new endpoints supporting this option or legacy endpoints without 134 this option. We call this a "backward downgrade" capability. 136 An additional consideration of this extension is avoiding user data 137 corruption in the presence of popular network devices, including 138 middleboxes. Consideration of middlebox misbehavior can also 139 interfere with extension in the SYN/ACK. 141 4. The TCP EDO Option 143 TCP EDO extends the option space for all segments except the initial 144 SYN (i.e., SYN set and ACK not set) and SYN/ACK response. The EDO 145 option is organized as indicated in Figure 1 and Figure 2. When 146 desired, initial SYN segments (i.e., those whose ACK bit is not set) 147 use the EDO request option, which consists of the required Kind and 148 Length fields only. Depending on capability and whether EDO is 149 successfully negotiated, any other segments can use the EDO length 150 option, which adds a Header_Length field (in network-standard byte 151 order), indicating the length of the entire TCP header in 32-bit 152 words. The codepoint value of the EDO Kind is EDO-OPT. 154 +--------+--------+ 155 | Kind | Length | 156 +--------+--------+ 158 Figure 1 TCP EDO request option 160 +--------+--------+--------+--------+ 161 | Kind | Length | Header_length | 162 +--------+--------+--------+--------+ 164 Figure 2 TCP EDO length option 166 EDO support is determined in both directions using a single 167 exchange. An endpoint seeking to enable EDO support includes the EDO 168 request option in the initial SYN. If receiver of that SYN agrees to 169 support EDO, it responds with a null EDO length option in the 170 SYN/ACK. A null EDO length option contains the same value as the DO 171 field, i.e., it does not extend the TCP option space. 173 >> Connections using EDO MUST negotiate its availability during the 174 initial three-way handshake. 176 >> An endpoint confirming EDO support MUST respond with a null EDO 177 length option in its SYN/ACK. 179 The SYN/ACK uses the null EDO length option because it may not yet 180 be safe to extend the option space in the reverse direction due to 181 middlebox misbehavior (see Section 6.2). Extension of the SYN and 182 SYN/ACK space is addressed as a separate option (see Section 7.7). 184 >> The EDO length option MAY be used only if confirmed when the 185 connection transitions to the ESTABLISHED state, e.g., a client is 186 enabled after receiving the null EDO length option in the SYN/ACK 187 and the server is enabled after seeing a null or non-null EDO length 188 option in the final ACK of the three-way handshake. If either of 189 those segments lacks the EDO length option, the connection MUST NOT 190 use EDO on any other segments. 192 >> Once enabled on a connection, all segments in both directions 193 MUST include the EDO length option. Segments not needing extension 194 MUST set the EDO length equal to the DO length. 196 Internet paths may vary after connection establishment, introducing 197 misbehaving middleboxes (see Section 6.2). Using EDO on all segments 198 in both directions allows this condition to be detected. 200 >> The EDO request option MAY occur in an initial SYN as desired 201 (e.g., as expressed by the user/application), but MUST NOT be 202 inserted in other segments. If the EDO request option is received in 203 other segments, it MUST be silently ignored. 205 >> If EDO has not been negotiated and agreed, the EDO length option 206 MUST be silently ignored on subsequent segments. The EDO length 207 option MUST NOT be sent in an initial SYN segment, and MUST be 208 silently ignored and not acknowledged if so received. 210 >> If EDO has been negotiated, any subsequent segments arriving 211 without the EDO length option MUST be silently ignored. Such events 212 MAY be logged as warning errors and logging MUST be rate limited. 214 When processing a segment, EDO needs to be visible within the area 215 indicated by the Data Offset field, so that processing can use the 216 EDO Header_length to override the Data Offset for that segment. 218 >> The EDO length option MUST occur within the space indicated by 219 the TCP Data Offset. 221 >> The EDO length option indicates the total length of the header. 222 The EDO Header_length field MUST NOT exceed that of the total 223 segment size (i.e., TCP Length). 225 >> The EDO length option MUST be at least as large as the TCP Data 226 Offset field of the segment in which they both appear. When the EDO 227 length equals the DO length, the EDO option is present but it does 228 not extend the option space. When the EDO length is invalid, the TCP 229 segment MUST be silently dropped. 231 >> The EDO request option SHOULD be aligned on a 16-bit boundary and 232 the EDO length option SHOULD be aligned on a 32-bit boundary, in 233 both cases for simpler processing. 235 For example, a segment with only EDO would have a Data Offset of 6, 236 where EDO would be the first option processed, at which point the 237 EDO length option would override the Data Offset and processing 238 would continue until the end of the TCP header as indicated by the 239 EDO Header_length field. 241 There are cases where it might be useful to process other options 242 before EDO, notably those that determine whether the TCP header is 243 valid, such as authentication, encryption, or alternate checksums. 244 In those cases, the EDO length option is preferably the first option 245 after a validation option, and the payload after the Data Offset is 246 treated as user data for the purposes of validation. 248 >> The EDO length option SHOULD occur as early as possible, either 249 first or just after any authentication or encryption, and SHOULD be 250 the last option covered by the Data Offset value. 252 Other options are generally handled in the same manner as when the 253 EDO option is not active, unless they interact with other options. 254 One such example is TCP-AO [RFC5925], which optionally ignores the 255 contents of TCP options, so it would need to be aware of EDO to 256 operate correctly when options are excluded from the HMAC 257 calculation. 259 >> Options that depend on other options, such as TCP-AO [RFC5925] 260 (which may include or exclude options in MAC calculations) MUST also 261 be augmented to interpret the EDO length option to operate 262 correctly. 264 5. TCP EDO Interaction with TCP 266 The following subsections describe how EDO interacts with the TCP 267 specification [RFC793]. 269 5.1. TCP User Interface 271 The TCP EDO option is enabled on a connection using a mechanism 272 similar to any other per-connection option. In Unix systems, this is 273 typically performed using the 'setsockopt' system call. 275 >> Implementations can also employ system-wide defaults, however 276 systems SHOULD NOT activate this extension by default to avoid 277 interfering with legacy applications. 279 >> Due to the potential impacts of legacy middleboxes (discussed in 280 Section 6), a TCP implementation supporting EDO SHOULD log any 281 events within an EDO connection when options that are malformed or 282 show other evidence of tampering arrive. An operating system MAY 283 choose to cache the list of destination endpoints where this has 284 occurred with and block use of EDO on future connections to those 285 endpoints, but this cache MUST be accessible to users/applications 286 on the host. Note that such endpoint assumptions can vary in the 287 presence of load balancers where server implementations vary behind 288 such balancers. 290 5.2. TCP States and Transitions 292 TCP EDO does not alter the existing TCP state or state transition 293 mechanisms. 295 5.3. TCP Segment Processing 297 TCP EDO alters segment processing during the TCP option processing 298 step. Once detected, the TCP EDO length option overrides the TCP 299 Data Offset field for all subsequent option processing. Option 300 processing continues at the next option (if present) after the EDO 301 length option. 303 5.4. Impact on TCP Header Size 305 The TCP EDO request option increases SYN header length by a minimum 306 of 2 bytes. Currently popular SYN options total 19 bytes, which 307 leaves more than enough room for the EDO request: 309 o SACK permitted (2 bytes in SYN, optionally 2 + 8N bytes after) 310 [RFC2018][RFC6675] 312 o Timestamp (10 bytes) [RFC7323] 314 o Window scale (3 bytes) [RFC7323] 316 o MSS option (4 bytes) [RFC793] 318 Adding the EDO option would result in a total of 21 bytes of SYN 319 option space. Subsequent segments would use 19 bytes of option space 320 without any SACK blocks or allow up to 3 SACK blocks before needing 321 to use EDO; with EDO, the number of SACK blocks or additional 322 options would be substantially increased. There are also other 323 options that are emerging in the SYN, including TCP Fast Open, which 324 uses another 6-18 (typically 10) bytes in the SYN/ACK of the first 325 connection and in the SYN of subsequent connections [Ch14]. 327 TCP EDO can also be negotiated in SYNs with either of the following 328 large options: 330 o TCP-AO (authentication) (16 bytes) [RFC5925] 332 o Multipath TCP (12 bytes in SYN and SYN/ACK, 20 after) [RFC6824] 334 Including TCP-AO increases the SYN option space use to 37 bytes; 335 with Multipath TCP the use is 33 bytes. When Multipath TCP is 336 enabled with the typical options, later segments might require 39 337 bytes without SACK, thus effectively disabling the SACK option 338 unless EDO is also supported on at least non-SYN segments. 340 The full combination of the above options (49 bytes including EDO) 341 does not fit in the existing SYN option space and (as noted) that 342 space cannot be extended within a single SYN segment. There has been 343 a proposal to change TS to a 2 byte "TS permitted" signal in the 344 initial SYN, provided it can be safely enabled during the connection 345 later or might be avoided completely [Ni14]. Even using "TS- 346 permitted", the total space is still too large to support in the 347 initial SYN without SYN option space extension [Br14][To14]. 349 The EDO option has negligible impact on other headers, because it 350 can either come first or just after security information, and in 351 either case the additional 4 bytes are easily accommodated within 352 the TCP Data Offset length. Once the EDO option is processed, the 353 entirety of the remainder of the TCP segment is available for any 354 remaining options. 356 5.5. Connectionless Resets 358 A RST may arrive during a currently active connection or may be 359 needed to cleanup old state from an abandoned connection. The latter 360 occurs when a new SYN is sent to an endpoint with matching existing 361 connection state, at which point that endpoint responds with a RST 362 and both ends remove stale information. 364 The EDO option is mandatory on all TCP segments once negotiated, 365 except the SYN and SYN/ACK of the three-way handshake to establish 366 its support and the RST. A RST may lack the context to know that EDO 367 is active on a connection. 369 >> The EDO length option MAY occur in a RST when the endpoint has 370 connection state that has negotiated EDO. However, unless the RST is 371 generated by an incoming segment that includes an EDO option, the 372 transmitted RST MUST NOT include the EDO length option. 374 5.6. ICMP Handling 376 ICMP responses are intended to include the IP and the port fields of 377 TCP and UDP headers of typical TCP/IP and UDP/IP packets [RFC792]. 378 This includes the first 8 data bytes of the original datagram, 379 intended to include the transport port numbers used for connection 380 demultiplexing. Later specifications encourage returning as much of 381 the original payload as possible [RFC1812]. In either case, legacy 382 options or new options in the EDO extension area might or might not 383 be included, and so options are generally not assumed to be part of 384 ICMP processing anyway. 386 6. Interactions with Middleboxes 388 Middleboxes are on-path devices that typically examine or modify 389 packets in ways that Internet routers do not [RFC3234]. This 390 includes parsing transport headers and/or rewriting transport 391 segments in ways that may affect EDO. 393 There are several cases to consider: 395 - Typical NAT/NAPT devices, which modify only IP address and/or TCP 396 port number fields (with associated TCP checksum updates) 398 - Middleboxes that try to reconstitute TCP data streams, such as 399 for deep-packet inspection for virus scanning 401 - Middleboxes that modify known TCP header fields 403 - Middleboxes that rewrite TCP segments 405 6.1. Middlebox Coexistence with EDO 407 Middleboxes can coexist with EDO when they either support EDO or 408 when they ignore its impact on segment structure. 410 NATs and NAPTs, which rewrite IP address and/or transport port 411 fields, are the most common form of middlebox and are not affected 412 by the EDO option. 414 Middleboxes that support EDO would be those that correctly parse the 415 EDO option. Such boxes can reconstitute the TCP data stream 416 correctly or can modify header fields and/or rewrite segments 417 without impact to EDO. 419 Conventional TCP proxies terminate the TCP connection in both 420 directions and thus operate as TCP endpoints, such as when a client- 421 middlebox and middlebox-server each have separate TCP connections. 422 They would support EDO by following the host requirements herein on 423 both connections. The use of EDO on one connection is independent of 424 its use on the other in this case. 426 6.2. Middlebox Interference with EDO 428 Middleboxes that do not support EDO cannot coexist with its use when 429 they modify segment boundaries or do not forward unknown (e.g., the 430 EDO) options. 432 So-called "transparent" rewriting proxies, which modify TCP segment 433 boundaries, might mix option information with user data if they did 434 not support EDO. Such devices might also interfere with other TCP 435 options such as TCP-AO. There are three types of such boxes: 437 o Those that process received options and transmit sent options 438 separately, i.e., although they rewrite segments, they behave as 439 TCP endpoints in both directions. 441 o Those that split segments, taking a received segment and emitting 442 two or more segments with revised headers. 444 o Those that join segments, receiving multiple segments and 445 emitting a single segment whose data is the concatenation of the 446 components. 448 In all three cases, EDO is either treated as independent on 449 different sides of such boxes or not. If independent, EDO would 450 either be correctly terminated in either or both directions or 451 disabled due to lack of SYN/ACK confirmation in either or both 452 directions. Problems would occur only when TCP segments with EDO are 453 combined or split while ignoring the EDO option. In the split case, 454 the key concern is if the split happens within the option extension 455 space or if EDO is silently copied to both segments without copying 456 the corresponding extended option space contents. However, the most 457 comprehensive study of these cases indicates that "although 458 middleboxes do split and coalesce segments, none did so while 459 passing unknown options" [Ho11]. 461 Middleboxes that silently remove options they do not implement have 462 been observed [Ho11]. Such boxes interfere with the use of the EDO 463 length option in the SYN and SYN/ACK segments because extended 464 option space would be misinterpreted as user data if the EDO option 465 were removed, and this cannot be avoided. This is one reason that 466 SYN and SYN/ACK extension requires alternate mechanisms (see Section 467 7.7). Further, if such middleboxes become present on a path they 468 could cause similar misinterpretation on segments exchanged in the 469 ESTABLISHED and subsequent states. As a result, this document 470 requires that the EDO length option be avoided on the SYN/ACK and 471 that this option needs to be used on all segments once successfully 472 negotiated. 474 Deep-packet inspection systems that inspect TCP segment payloads or 475 attempt to reconstitute the data stream would incorrectly include 476 option data in the reconstituted user data stream, which might 477 interfere with their operation. 479 >> It can be important to detect misbehavior that could cause EDO 480 space to be misinterpreted as user data. In such cases, EDO SHOULD 481 be used in conjunction with an integrity protection mechanism, such 482 as IPsec, TCP-AO, etc. It is useful to note that such protection 483 helps find only non-compliant components. 485 This situation is similar to that of ECN and ICMP support in the 486 Internet. In both cases, endpoints have evolved mechanisms for 487 detecting and robustly operating around "black holes". Very similar 488 algorithms are expected to be applicable for EDO. 490 7. Comparison to Previous Proposals 492 EDO is the latest in a long line of attempts to increase TCP option 493 space [Al06][Ed08][Ko04][Ra12][Yo11]. The following is a comparison 494 of these approaches to EDO, based partly on a previous summary 495 [Ra12]. This comparison differs from that summary by using a 496 different set of success criteria. 498 7.1. EDO Criteria 500 Our criteria for a successful solution are as follows: 502 o Zero-cost fallback to legacy endpoints. 504 o Minimal impact on middlebox compatibility. 506 o No additional side-effects. 508 Zero-cost fallback requires that upgraded hosts incur no penalty for 509 attempting to use EDO. This disqualifies dual-stack approaches, 510 because the client might have to delay connection establishment to 511 wait for the preferred connection mode to complete. Note that the 512 impact of legacy endpoints that silently reflect unknown options are 513 not considered, as they are already non-compliant with existing TCP 514 requirements [RFC793]. 516 Minimal impact on middlebox compatibility requires that EDO works 517 through simple NAT and NAPT boxes, which modify IP addresses and 518 ports and recompute IPv4 header and TCP segment checksums. 519 Middleboxes that reject unknown options or that process segments in 520 detail without regard for unknown options are not considered; they 521 process segments as if they were an endpoint but do so in ways that 522 are not compliant with existing TCP requirements (e.g., they should 523 have rejected the initial SYN because of its unknown options rather 524 than silently relaying it). 526 EDO also attempts to avoid creating side-effects, such as might 527 happen if options were split across multiple TCP segments (which 528 could arrive out of order or be lost) or across different TCP 529 connections (which could fail to share fate through firewalls or 530 NAT/NAPTs). 532 These requirements are similar to those noted in [Ra12], but EDO 533 groups cases of segment modification beyond address and port - such 534 as rewriting, segment drop, sequence number modification, and option 535 stripping - as already in violation of existing TCP requirements 536 regarding unknown options, and so we do not consider their impact on 537 this new option. 539 7.2. Summary of Approaches 541 There are three basic ways in which TCP option space extension has 542 been attempted: 544 1. Use of a TCP option. 546 2. Redefinition of the existing TCP header fields. 548 3. Use of option space in multiple TCP segments (split across 549 multiple segments). 551 A TCP option is the most direct way to extend the option space and 552 is the basis of EDO. This approach cannot extend the option space of 553 the initial SYN. 555 Redefining existing TCP header fields can be used to either contain 556 additional options or as a pointer indicating alternate ways to 557 interpret the segment payload. All such redefinitions make it 558 difficult to achieve zero-impact backward compatibility, both with 559 legacy endpoints and middleboxes. 561 Splitting option space across separate segments can create 562 unintended side-effects, such as increased delay to deal with path 563 latency or loss differences. 565 The following discusses three of the most notable past attempts to 566 extend the TCP option space: Extended Segments, TCPx2, LO/SLO, and 567 LOIC. [Ra12] suggests a few other approaches, including use of TCP 568 option cookies, reuse/overload of other TCP fields (e.g., the URG 569 pointer), or compressing TCP options. None of these is compatible 570 with legacy endpoints or middleboxes. 572 7.3. Extended Segments 574 TCP Extended Segments redefined the meaning of currently unused 575 values of the Data Offset (DO) field [Ko04]. TCP defines DO as 576 indicating the length of the TCP header, including options, in 32- 577 bit words. The default TCP header with no options is 5 such words, 578 so the minimum currently valid DO value is 5 (meaning 40 bytes of 579 option space). This document defines interpretations of values 0-4: 580 DO=0 means 48 bytes of option space, DO=1 means 64, DO=2 means 128, 581 DO=3 means 256, and DO=4 means unlimited (e.g., the entire payload 582 is option space). This variant negotiates the use of this capability 583 by using one of these invalid DO values in the initial SYN. 585 Use of this variant is not backward-compatible with legacy TCP 586 implementations, whether at the desired endpoint or on middleboxes. 587 The variant also defines a way to initiate the feature on the 588 passive side, e.g., using an invalid DO during the SYN/ACK when the 589 initial SYN had a valid DO. This capability allows either side to 590 initiate use of the feature but is also not backward compatible. 592 7.4. TCPx2 594 TCPx2 redefines legacy TCP headers by basically doubling all TCP 595 header fields [Al06]. It relies on a new transport protocol number 596 to indicate its use, defeating backward compatibility with all 597 existing TCP capabilities, including firewalls, NATs/NAPTs, and 598 legacy endpoints and applications. 600 7.5. LO/SLO 602 The TCP Long Option (LO, [Ed08]) is very similar to EDO, except that 603 presence of LO results in ignoring the existing DO field and that LO 604 is required to be the first option. EDO considers the need for other 605 fields to be first and declares that the EDO is the last option as 606 indicated by the DO field value. Like LO, EDO is required in every 607 segment once negotiated. 609 The TCP Long Option draft also specified the SYN Long Option (SLO) 610 [Ed08]. If SLO is used in the initial SYN and successfully 611 negotiated, it is used in each subsequent segment until all of the 612 initial SYN options are transmitted. 614 LO is backward compatible, as is SLO; in both cases, endpoints not 615 supporting the option would not respond with the option, and in both 616 cases the initial SYN is not itself extended. 618 SLO does modify the three-way handshake because the connection isn't 619 considered completely established until the first data byte is 620 acknowledged. Legacy TCP can establish a connection even in the 621 absence of data. SLO also changes the semantics of the SYN/ACK; for 622 legacy TCP, this completes the active side connection establishment, 623 where in SLO an additional data ACK is required. A connection whose 624 initial SYN options have been confirmed in the SYN/ACK might still 625 fail upon receipt of additional options sent in later SLO segments. 626 This case - of late negotiation fail - is not addressed in the 627 specification. 629 7.6. LOIC 631 TCP Long Options by Invalid Checksum is a dual-stack approach that 632 uses two initial SYNS to initiate all updated connections [Yo11]. 633 One SYN negotiates the new option and the other SYN payload contains 634 only the entire options. The negotiation SYN is compliant with 635 existing procedures, but the option SYN has a deliberately incorrect 636 TCP checksum (decremented by 2). A legacy endpoint would discard the 637 segment with the incorrect checksum and respond to the negotiation 638 SYN without the LO option. 640 Use of the option SYN and its incorrect checksum both interfere with 641 other legacy components. Segments with incorrect checksums will be 642 silently dropped by most middleboxes, including NATs/NAPTs. Use of 643 two SYNs creates side-effects that can delay connections to upgraded 644 endpoints, notably when the option SYN is lost or the SYNs arrive 645 out of order. Finally, by not allowing other options in the 646 negotiation SYN, all connections to legacy endpoints either use no 647 options or require a separate connection attempt (either concurrent 648 or subsequent). 650 7.7. Problems with Extending the Initial SYN 652 The key difficulty with most previous proposals is the desire to 653 extend the option space in all TCP segments, including the initial 654 SYN, i.e., SYN with no ACK, typically the first segment of a 655 connection, as well as possibly the SYN/ACK. It has proven difficult 656 to extend space within the segment of the initial SYN in the absence 657 of prior negotiation while maintaining current TCP three-way 658 handshake properties, and it may be similarly challenging to extend 659 the SYN/ACK (depending on asymmetric middlebox assumptions). 661 A new TCP option cannot extend the Data Offset of a single TCP 662 initial SYN segment, and cannot extend a SYN/ACK in a single segment 663 when considering misbehaving middleboxes. All TCP segments, 664 including the initial SYN and SYN/ACK, may include user data in the 665 payload data [RFC793], and this can be useful for some proposed 666 features such as TCP Fast Open [Ch14]. Legacy endpoints that ignore 667 the new option would process the payload contents as user data and 668 send an ACK. Once ACK'd, this data cannot be removed from the user 669 stream. 671 The Reserved TCP header bits cannot be redefined easily, even though 672 three of the six total bits have already been redefined (ECE/CWR 673 [RFC3168] and NS [RFC3540]). Legacy endpoints have been known to 674 reflect received values in these fields; this was safely dealt with 675 for ECN but would be difficult here [RFC3168]. 677 TCP initial SYN (SYN and not ACK) segments can use every other TCP 678 header field except the Acknowledgement number, which is not used 679 because the ACK field is not set. In all other segments, all fields 680 except the three remaining Reserved header bits are actively used. 681 The total amount of available header fields, in either case, is 682 insufficient to be useful in extending the option space. 684 The representation of TCP options can be optimized to minimize the 685 space needed. In such cases, multiple Kind and Length fields are 686 combined, so that a new Kind would indicate a specific combination 687 of options, whose order is fixed and whose length is indicated by 688 one Length field. Most TCP options use fields whose size is much 689 larger than the required Kind and Length components, so the 690 resulting efficiency is typically insufficient for additional 691 options. 693 The option space of an initial SYN segment might be extended by 694 using multiple initial segments (e.g., multiple SYNs or a SYN and 695 non-SYN) or based on the context of previous or parallel 696 connections. This method may also be needed to extend space in the 697 SYN/ACK in the presence of misbehaving middleboxes. Because of their 698 potential complexity, these approaches are addressed in separate 699 documents [Br14][To14]. 701 Option space cannot be extended in outer layer headers, e.g., IPv4 702 or IPv6. These layers typically try to avoid extensions altogether, 703 to simplify forwarding processing at routers. Introducing new shim 704 layers to accommodate additional option space would interfere with 705 deep-packet inspection mechanisms that are in widespread use. 707 As a result, EDO does not attempt to extend the space available for 708 options in TCP initial SYNs. It does extend that space in all other 709 segments (including SYN/ACK), which has always been trivially 710 possible once an option is defined. 712 8. Implementation Issues 714 TCP segment processing can involve accessing nonlinear data 715 structures, such as chains of buffers. Such chains are often 716 designed so that the maximum default TCP header (60 bytes) fits in 717 the first buffer. Extending the TCP header across multiple buffers 718 may necessitate buffer traversal functions that span boundaries 719 between buffers. Such traversal can also have a significant 720 performance impact, which is additional rationale for using TCP 721 option space - even extended option space - sparingly. 723 Although EDO can be large enough to consume the entire segment, it 724 is important to leave space for data so that the TCP connection can 725 make forward progress. It would be wise to limit EDO to consuming no 726 more than MSS-4 bytes of the IP segment, preferably even less (e.g., 727 MSS-128 bytes). 729 When using the ExID variant for testing and experimentation, either 730 TCP option codepoint (253, 254) is valid in sent or received 731 segments. 733 Implementers need to be careful about the potential for offload 734 support interfering with this option. The EDO data needs to be 735 passed to the protocol stack as part of the option space, not 736 integrated with the user segment, to allow the offload to 737 independently determine user data segment boundaries and combine 738 them correctly with the extended option data. 740 9. Security Considerations 742 It is meaningless to have the Data Offset further exceed the 743 position of the EDO data offset option. 745 >> When the EDO length option is present, the EDO length option 746 SHOULD be the last non-null option covered by the TCP Data Offset, 747 because it would be the last option affected by Data Offset. 749 This also makes it more difficult to use the Data Offset field as a 750 covert channel. 752 10. IANA Considerations 754 We request that, upon publication, this option be assigned a TCP 755 Option codepoint by IANA, which the RFC Editor will replace EDO-OPT 756 in this document with codepoint value. 758 The TCP Experimental ID (ExID) with a 16-bit value of 0x0ED0 (in 759 network standard byte order) has been assigned for use during 760 testing and preliminary experiments. 762 11. References 764 11.1. Normative References 766 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 767 Requirement Levels", BCP 14, RFC 2119, March 1997. 769 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 770 793, September 1981. 772 11.2. Informative References 774 [Al06] Allman, M., "TCPx2: Don't Fence Me In", draft-allman- 775 tcpx2-hack-00 (work in progress), May 2006. 777 [Br14] Briscoe, B., "Extended TCP Option Space in the Payload of 778 an Alternative SYN", draft-briscoe-tcpm-syn-op-sis-02 779 (work in progress), September 2014. 781 [Ch14] Cheng, Y., Chu, J., and A. Jain, "TCP Fast Open", draft- 782 ietf-tcpm-fastopen-10, September 2014. 784 [Ed08] Eddy, W. and A. Langley, "Extending the Space Available 785 for TCP Options", draft-eddy-tcp-loo-04 (work in 786 progress), July 2008. 788 [Ho11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., 789 Handley, M., and H. Tokuda, "Is it still possible to 790 extend TCP", Proc. ACM Sigcomm Internet Measurement 791 Conference (IMC), 2011, pp. 181-194. 793 [Ko04] Kohler, E., "Extended Option Space for TCP", draft-kohler- 794 tcpm-extopt-00 (work in progress), September 2004. 796 [Ni14] Nishida, Y., "A-PAWS: Alternative Approach for PAWS", 797 draft-nishida-tcpm-apaws-01 (work in progress), June 2014. 799 [Ra12] Ramaiah, A., "TCP option space extension", draft-ananth- 800 tcpm-tcpoptext-00 (work in progress), March 2012. 802 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 803 September 1981. 805 [RFC1812] Baker, F. (Ed.), "Requirements for IP Version 4 Routers," 806 RFC 1812, June 1995. 808 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 809 Selective Acknowledgment Options", RFC 2018, October 1996. 811 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 812 of Explicit Congestion Notification (ECN) to IP", RFC 813 3168, September 2001. 815 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 816 Issues", RFC 3234, February 2002. 818 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 819 Congestion Notification (ECN) Signaling with Nonces", RFC 820 3540, June 2003. 822 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 823 Authentication Option", RFC 5925, June 2010. 825 [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., 826 and Y. Nishida, "A Conservative Loss Recovery Algorithm 827 Based on Selective Acknowledgment (SACK) for TCP", RFC 828 6675, August 2012. 830 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 831 "TCP Extensions for Multipath Operation with Multiple 832 Addresses", RFC 6824, January 2013. 834 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger 835 (Ed.), "TCP Extensions for High Performance", RFC 7323, 836 September 2014. 838 [To14] Touch, J., T. Faber, "TCP SYN Extended Option Space Using 839 an Out-of-Band Segment", draft-touch-tcpm-tcp-syn-ext-opt- 840 01 (work in progress), September 2014. 842 [Yo11] Yourtchenko, A., "Introducing TCP Long Options by Invalid 843 Checksum", draft-yourtchenko-tcp-loic-00 (work in 844 progress), April 2011. 846 12. Acknowledgments 848 The authors would like to thank the IETF TCPM WG for their feedback, 849 in particular: Oliver Bonaventure, Bob Briscoe, Ted Faber, John 850 Leslie, Pasi Sarolahti, Richard Scheffenegger, and Alexander 851 Zimmerman. 853 This document was prepared using 2-Word-v2.0.template.dot. 855 Authors' Addresses 857 Joe Touch 858 USC/ISI 859 4676 Admiralty Way 860 Marina del Rey, CA 90292-6695 USA 862 Phone: +1 (310) 448-9151 863 Email: touch@isi.edu 865 Wesley M. Eddy 866 MTI Systems 867 US 869 Email: wes@mti-systems.com