idnits 2.17.1 draft-ietf-tcpm-tcp-edo-00.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 (September 29, 2014) is 3497 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 (-03) exists of draft-briscoe-tcpm-syn-op-sis-02 == 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 (-12) exists of draft-touch-tcpm-tcp-syn-ext-opt-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 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: March 2015 September 29, 2014 7 TCP Extended Data Offset Option 8 draft-ietf-tcpm-tcp-edo-00.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 March 29, 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 as 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................................6 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.............................................8 71 6. Interactions with Middleboxes..................................9 72 6.1. Middlebox Coexistence with EDO............................9 73 6.2. Middlebox Interference with EDO...........................9 74 7. Comparison to Previous Proposals..............................10 75 7.1. EDO Criteria.............................................10 76 7.2. Summary of Approaches....................................11 77 7.3. Extended Segments........................................12 78 7.4. TCPx2....................................................12 79 7.5. LO/SLO...................................................12 80 7.6. LOIC.....................................................13 81 7.7. Problems with Extending the Initial SYN..................14 82 8. Security Considerations.......................................15 83 9. IANA Considerations...........................................15 84 10. References...................................................15 85 10.1. Normative References....................................15 86 10.2. Informative References..................................15 87 11. Acknowledgments..............................................17 89 1. Introduction 91 TCP's Data Offset is a 4-bit field, which indicates the number of 92 32-bit words of the entire TCP header [RFC793]. This limits the 93 current total header size to 60 bytes, of which the basic header 94 occupies 20, leaving 40 bytes for options. These 40 bytes are 95 increasingly becoming a limitation to the development of advanced 96 capabilities, such as when SACK [RFC2018][RFC6675] is combined with 97 either Multipath TCP [RFC6824], TCP-AO [RFC5925], or TCP Fast Open 98 [Ch14]. 100 This document specifies the TCP Extended Data Offset (EDO) option, 101 and is independent of (and thus compatible with) IPv4 and IPv6. EDO 102 extends the space available for TCP options, except for the initial 103 SYN segment (i.e., SYN and not ACK, the first segment of a new 104 connection). This document also explains why the option space of a 105 single initial SYN segment cannot be extended without severe impact 106 on TCP's initial handshake. 108 2. Conventions used in this document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC-2119 [RFC2119]. 114 In this document, these words will appear with that interpretation 115 only when in ALL CAPS. Lower case uses of these words are not to be 116 interpreted as carrying RFC-2119 significance. 118 In this document, the characters ">>" preceding an indented line(s) 119 indicates a compliance requirement statement using the key words 120 listed above. This convention aids reviewers in quickly identifying 121 or finding the explicit compliance requirements of this RFC. 123 3. Requirements for Extending TCP's Data Offset 125 The primary goal of extending the TCP Data Offset field is to 126 increase the space available for TCP options in all segments except 127 the initial SYN. 129 An important requirement of any such extension is that it not impact 130 legacy endpoints. Endpoints seeking to use this new option should 131 not incur additional delay or segment exchanges to connect to either 132 new endpoints supporting this option or legacy endpoints without 133 this option. We call this a "backward downgrade" capability. 135 4. The TCP EDO Option 137 TCP EDO extends the option space for all segments except the initial 138 SYN (i.e., SYN set and ACK not set). The EDO option is organized as 139 indicated in Figure 1 and Figure 2. For initial SYN segments (i.e., 140 those whose ACK bit is not set), the EDO request option consists of 141 the required Kind and Length fields only. All other segments 142 optionally use the EDO length option, which adds a Header_Length 143 field (in network-standard byte order), indicating the length of the 144 entire TCP header in bytes. The codepoint value of the EDO Kind is 145 EDO-OPT. 147 +--------+--------+ 148 | Kind | Length | 149 +--------+--------+ 151 Figure 1 TCP EDO request option 153 +--------+--------+--------+--------+ 154 | Kind | Length | Header_length | 155 +--------+--------+--------+--------+ 157 Figure 2 TCP EDO length option 159 EDO support is determined in both directions using the same 160 exchange. An endpoint seeking to enable EDO support includes the EDO 161 request option in the initial SYN. 163 >> Connections using EDO MUST negotiate its availability during the 164 initial three-way handshake. 166 >> An endpoint confirming EDO support MUST respond with an EDO 167 length option in its SYN/ACK. 169 The EDO length option is required in SYN/ACKs when confirming 170 support for EDO. The SYN/ACK thus can take advantage of EDO, using 171 it to extend its option space. If such extension is not required, 172 then EDO would be equal to 4 * Data Offset (i.e., EDO would indicate 173 in bytes the same length indicated by Data Offset in words). 175 >> Once negotiated on a connection, EDO MAY be present as needed on 176 other segments in either direction. The EDO option SHOULD NOT be 177 used if the total option space needed can be accommodated by the 178 existing Data Offset field. An endpoint MUST be robust to receiving 179 the EDO option on segments that do not strictly require it to extend 180 the options space. 182 >> The EDO request option (i.e., whose option length is 2) MAY occur 183 in an initial SYN as desired (e.g., as expressed by the 184 user/application), but MUST NOT be inserted in other segments. If 185 the EDO request option is received, it MUST be silently ignored. 187 >> The EDO length option MAY occur in segments other than the 188 initial SYN if EDO has been negotiated on a connection. If EDO has 189 not been negotiated and agreed, the EDO length option MUST be 190 silently ignored. The EDO length option MUST NOT be sent in an 191 initial SYN segment, and MUST be silently ignored and not 192 acknowledged if so received. 194 EDO extends the space available for options, but does not consume 195 space unless needed. Segments that don't need the additional space 196 can use the existing Data Offset field as currently specified 197 [RFC793]. When processing a segment, EDO needs to be visible within 198 the area indicated by the Data Offset field, so that processing can 199 use the EDO Header_length to override the Data Offset for that 200 segment. 202 >> The EDO length option MUST occur within the length of the TCP 203 Data Offset. 205 >> The EDO length option indicates the total length of the header. 206 The EDO Header_length field MUST NOT exceed that of the total 207 segment size (i.e., TCP Length). The EDO Header_length SHOULD be a 208 multiple of 4 to simplify processing. 210 >> The EDO request option SHOULD be aligned on a 16-bit boundary and 211 the EDO length option SHOULD be aligned on a 32-bit boundary, in 212 both cases for simpler processing. 214 For example, a segment with only EDO would have a Data Offset of 6, 215 where EDO would be the first option processed, at which point the 216 EDO length option would override the Data Offset and processing 217 would continue until the end of the TCP header as indicated by the 218 EDO Header_length field. 220 There are cases where it might be useful to process other options 221 before EDO, notably those that determine whether the TCP header is 222 valid, such as authentication, encryption, or alternate checksums. 223 In those cases, the EDO length option is preferably the first option 224 after a validation option, and the payload after the Data Offset is 225 treated as user data for the purposes of validation. 227 >> The EDO length option SHOULD occur as early as possible, either 228 first or just after any authentication or encryption, and SHOULD be 229 the last option covered by the Data Offset value. 231 Other options are generally handled in the same manner as when the 232 EDO option is not active, unless they interact with other options. 233 One such example is TCP-AO [RFC5925], which optionally ignores the 234 contents of TCP options, so it would need to be aware of EDO to 235 operate correctly when options are excluded from the HMAC 236 calculation. 238 >> Options that depend on other options, such as TCP-AO [RFC5925] 239 (which may include or exclude options in MAC calculations) MUST also 240 be augmented to interpret the EDO length option to operate 241 correctly. 243 5. TCP EDO Interaction with TCP 245 The following subsections describe how EDO interacts with the TCP 246 specification [RFC793]. 248 5.1. TCP User Interface 250 The TCP EDO option is enabled on a connection using a mechanism 251 similar to any other per-connection option. In Unix systems, this is 252 typically performed using the 'setsockopt' system call. 254 >> Implementations can also employ system-wide defaults, however 255 systems SHOULD NOT use this extension by default to avoid 256 interfering with legacy applications. 258 >> Due to the potential impacts of legacy middleboxes (discussed in 259 Section 6), a TCP implementation supporting EDO SHOULD log any 260 events within an EDO connection when options that are malformed or 261 show other evidence of tampering arrive. An operating system MAY 262 choose to cache the list of destination endpoints where this has 263 occurred with and block use of EDO on future connections to those 264 endpoints, but this cache needs to be accessible to 265 users/applications on the host. Note that such endpoint assumptions 266 may vary in the presence of load balancers where server 267 implementations vary behind such balancers. 269 5.2. TCP States and Transitions 271 TCP EDO does not alter the existing TCP state or state transition 272 mechanisms. 274 5.3. TCP Segment Processing 276 TCP EDO alters segment processing during the TCP option processing 277 step. Once detected, the TCP EDO length option overrides the TCP 278 Data Offset field for all subsequent option processing. Option 279 processing continues at the next option after the EDO length option. 281 Implementers need to be careful about the potential for offload 282 support interfering with this option. The EDO data needs to be 283 passed to the protocol stack as part of the option space, not 284 integrated with the user segment, to allow the offload to 285 independently determine user data segment boundaries and combine 286 them correctly with the extended option data. 288 5.4. Impact on TCP Header Size 290 The TCP EDO request option increases SYN header length by a minimum 291 of 2 bytes. Currently popular SYN options total 19 bytes, which 292 leaves more than enough room for the EDO request: 294 o SACK permitted (2 bytes in SYN, optionally 2 + 8N bytes after) 295 [RFC2018][RFC6675] 297 o Timestamp (10 bytes) [RFC7323] 299 o Window scale (3 bytes) [RFC7323] 301 o MSS option (4 bytes) [RFC793] 303 Adding the EDO option would result in a total of 21 bytes of SYN 304 option space. Subsequent segments would use 19 bytes of option space 305 without any SACK blocks or allow up to 3 SACK blocks before needing 306 to use EDO; with EDO, the number of SACK blocks or additional 307 options would be substantially increased. There are also other 308 options that are emerging in the SYN, including TCP Fast Open, which 309 uses another 6-18 (typically 10) bytes in the SYN/ACK of the first 310 connection and in the SYN of subsequent connections [Ch14]. 312 TCP EDO can also be negotiated in SYNs with either of the following 313 large options: 315 o TCP-AO (authentication) (16 bytes) [RFC5925] 317 o Multipath TCP (12 bytes in SYN and SYN/ACK, 20 after) [RFC6824] 319 Including TCP-AO increases the SYN option space use to 37 bytes; 320 with Multipath TCP the use is 33 bytes. When Multipath TCP is 321 enabled with the typical options, later segments might require 39 322 bytes without SACK, thus effectively disabling the SACK option 323 unless EDO is also supported on at least non-SYN segments. 325 The full combination of the above options (49 bytes including EDO) 326 does not fit in the existing SYN option space and (as noted) that 327 space cannot be extended within a single SYN segment. There has been 328 a proposal to change TS to a 2 byte "TS permitted" signal in the 329 initial SYN, provided it can be safely enabled during the connection 330 later or might be avoided completely [Ni14]. Even using "TS- 331 permitted", the total space is still too large to support in the 332 initial SYN without SYN option space extension [Br14][To14]. 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 5.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 5.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 6. Interactions with Middleboxes 371 Middleboxes are on-path devices that typically examine or modify 372 packets in ways that Internet routers do not [RFC3234]. This 373 includes parsing transport headers and/or rewriting transport 374 segments in ways that may affect EDO. 376 There are several cases to consider: 378 - Typical NAT/NAPT devices, which modify only IP address and/or TCP 379 port number fields (with associated TCP checksum updates) 381 - Middleboxes that try to reconstitute TCP data streams, such as 382 for deep-packet inspection for virus scanning 384 - Middleboxes that modify known TCP header fields 386 - Middleboxes that rewrite TCP segments 388 6.1. Middlebox Coexistence with EDO 390 Middleboxes can coexist with EDO when they either support EDO or 391 when they ignore its impact on segment structure. 393 NATs and NAPTs, which rewrite IP address and/or transport port 394 fields, are the most common form of middlebox and are not affected 395 by the EDO option. 397 Middleboxes that support EDO would be those that correctly parse the 398 EDO option. Such boxes can reconstitute the TCP data stream 399 correctly or can modify header fields and/or rewrite segments 400 without impact to EDO. 402 Conventional TCP proxies terminate the TCP connection in both 403 directions and thus operate as TCP endpoints, such as when a client- 404 middlebox and middlebox-server each have separate TCP connections. 405 They would support EDO by following the host requirements herein on 406 both connections. The use of EDO on one connection is independent of 407 its use on the other in this case. 409 6.2. Middlebox Interference with EDO 411 Middleboxes that do not support EDO cannot coexist with its use when 412 they modify segment boundaries or do not forward unknown (e.g., the 413 EDO) options. 415 So-called "transparent" rewriting proxies, which modify TCP segment 416 boundaries, would mix option information with user data if they did 417 not support EDO. Such devices may also interfere with other TCP 418 options such as TCP-AO. 420 Deep-packet inspection systems that inspect TCP segment payloads or 421 attempt to reconstitute the data stream would incorrectly include 422 option data in the reconstituted user data stream, which might 423 interfere with their operation. 425 >> It may be important to detect misbehavior that could cause EDO 426 space to be misinterpreted as user data. In such cases, EDO SHOULD 427 be used in conjunction with integrity protection mechanisms, such as 428 IPsec, TCP-AO, etc. It is useful to note that such protection helps 429 find only non-compliant components. 431 This situation is similar to that of ECN and ICMP support in the 432 Internet. In both cases, endpoints have evolved mechanisms for 433 detecting and robustly operating around "black holes". Very similar 434 algorithms are expected to be applicable for EDO. 436 7. Comparison to Previous Proposals 438 EDO is the latest in a long line of attempts to increase TCP option 439 space [Al06][Ed08][Ko04][Ra12][Yo11]. The following is a comparison 440 of these approaches to EDO, based partly on a previous summary 441 [Ra12]. This comparison differs from that summary by using a 442 different set of success criteria. 444 7.1. EDO Criteria 446 Our criteria for a successful solution are as follows: 448 o Zero-cost fallback to legacy endpoints. 450 o Minimal impact on middlebox compatibility. 452 o No additional side-effects. 454 Zero-cost fallback requires that upgraded hosts incur no penalty for 455 attempting to use EDO. This disqualifies dual-stack approaches, 456 because the client might have to delay connection establishment to 457 wait for the preferred connection mode to complete. Note that the 458 impact of legacy endpoints that silently reflect unknown options are 459 not considered, as they are already non-compliant with existing TCP 460 requirements [RFC793]. 462 Minimal impact on middlebox compatibility requires that EDO works 463 through simple NAT and NAPT boxes, which modify IP addresses and 464 ports and recompute IPv4 header and TCP segment checksums. 465 Middleboxes that reject unknown options or that process segments in 466 detail without regard for unknown options are not considered; they 467 process segments as if they were an endpoint but do so in ways that 468 are not compliant with existing TCP requirements (e.g., they should 469 have rejected the initial SYN because of its unknown options rather 470 than silently relaying it). 472 EDO also attempts to avoid creating side-effects, such as might 473 happen if options were split across multiple TCP segments (which 474 could arrive out of order or be lost) or across different TCP 475 connections (which could fail to share fate through firewalls or 476 NAT/NAPTs). 478 These requirements are similar to those noted in [Ra12], but EDO 479 groups cases of segment modification beyond address and port - such 480 as rewriting, segment drop, sequence number modification, and option 481 stripping - as already in violation of existing TCP requirements 482 regarding unknown options, and so we do not consider their impact on 483 this new option. 485 7.2. Summary of Approaches 487 There are three basic ways in which TCP option space extension has 488 been attempted: 490 1. Use of a TCP option. 492 2. Redefinition of the existing TCP header fields. 494 3. Use of option space in multiple TCP segments (split across 495 multiple segments). 497 A TCP option is the most direct way to extend the option space and 498 is the basis of EDO. This approach cannot extend the option space of 499 the initial SYN. 501 Redefining existing TCP header fields can be used to either contain 502 additional options or as a pointer indicating alternate ways to 503 interpret the segment payload. All such redefinitions make it 504 difficult to achieve zero-impact backward compatibility, both with 505 legacy endpoints and middleboxes. 507 Splitting option space across separate segments can create 508 unintended side-effects, such as increased delay to deal with path 509 latency or loss differences. 511 The following discusses three of the most notable past attempts to 512 extend the TCP option space: Extended Segments, TCPx2, LO/SLO, and 513 LOIC. [Ra12] suggests a few other approaches, including use of TCP 514 option cookies, reuse/overload of other TCP fields (e.g., the URG 515 pointer), or compressing TCP options. None of these is compatible 516 with legacy endpoints or middleboxes. 518 7.3. Extended Segments 520 TCP Extended Segments redefined the meaning of currently unused 521 values of the Data Offset (DO) field [Ko04]. TCP defines DO as 522 indicating the length of the TCP header, including options, in 32- 523 bit words. The default TCP header with no options is 5 such words, 524 so the minimum currently valid DO value is 5 (meaning 40 bytes of 525 option space). This document defines interpretations of values 0-4: 526 DO=0 means 48 bytes of option space, DO=1 means 64, DO=2 means 128, 527 DO=3 means 256, and DO=4 means unlimited (e.g., the entire payload 528 is option space). This variant negotiates the use of this capability 529 by using one of these invalid DO values in the initial SYN. 531 Use of this variant is not backward-compatible with legacy TCP 532 implementations, whether at the desired endpoint or on middleboxes. 533 The variant also defines a way to initiate the feature on the 534 passive side, e.g., using an invalid DO during the SYN/ACK when the 535 initial SYN had a valid DO. This capability allows either side to 536 initiate use of the feature but is also not backward compatible. 538 7.4. TCPx2 540 TCPx2 redefines legacy TCP headers by basically doubling all TCP 541 header fields [Al06]. It relies on a new transport protocol number 542 to indicate its use, defeating backward compatibility with all 543 existing TCP capabilities, including firewalls, NATs/NAPTs, and 544 legacy endpoints and applications. 546 7.5. LO/SLO 548 The TCP Long Option (LO, [Ed08]) is very similar to EDO, except that 549 presence of LO results in ignoring the existing DO field and that LO 550 is required to be the first option. EDO considers the need for other 551 fields to be first and declares that the EDO is the last option as 552 indicated by the DO field value. Unlike LO, EDO is not required in 553 every segment once negotiated, saving 6 bytes if not actively 554 needed. 556 The TCP Long Option draft also specified the SYN Long Option (SLO) 557 [Ed08]. If SLO is used in the initial SYN and successfully 558 negotiated, it is used in each subsequent segment until all of the 559 initial SYN options are transmitted. 561 LO is backward compatible, as is SLO; in both cases, endpoints not 562 supporting the option would not respond with the option, and in both 563 cases the initial SYN is not itself extended. 565 SLO does modify the three-way handshake because the connection isn't 566 considered completely established until the first data byte is 567 acknowledged. Legacy TCP can establish a connection even in the 568 absence of data. SLO also changes the semantics of the SYN/ACK; for 569 legacy TCP, this completes the active side connection establishment, 570 where in SLO an additional data ACK is required. A connection whose 571 initial SYN options have been confirmed in the SYN/ACK might still 572 fail upon receipt of additional options sent in later SLO segments. 573 This case - of late negotiation fail - is not addressed in the 574 specification. 576 7.6. LOIC 578 TCP Long Options by Invalid Checksum is a dual-stack approach that 579 uses two initial SYNS to initiate all updated connections [Yo11]. 580 One SYN negotiates the new option and the other SYN payload contains 581 only the entire options. The negotiation SYN is compliant with 582 existing procedures, but the option SYN has a deliberately incorrect 583 TCP checksum (decremented by 2). A legacy endpoint would discard the 584 segment with the incorrect checksum and respond to the negotiation 585 SYN without the LO option. 587 Use of the option SYN and its incorrect checksum both interfere with 588 other legacy components. Segments with incorrect checksums will be 589 silently dropped by most middleboxes, including NATs/NAPTs. Use of 590 two SYNs creates side-effects that can delay connections to upgraded 591 endpoints, notably when the option SYN is lost or the SYNs arrive 592 out of order. Finally, by not allowing other options in the 593 negotiation SYN, all connections to legacy endpoints either use no 594 options or require a separate connection attempt (either concurrent 595 or subsequent). 597 7.7. Problems with Extending the Initial SYN 599 The key difficulty with most previous proposals is the desire to 600 extend the option space in all TCP segments, including the initial 601 SYN, i.e., SYN with no ACK, typically the first segment of a 602 connection. It has proven difficult to extend space in this initial 603 SYN in the absence of prior negotiation while maintaining current 604 TCP three-way handshake properties. 606 A new TCP option cannot extend the Data Offset of a single TCP 607 initial SYN segment. All TCP segments, including the initial SYN, 608 may include user data in the payload data [RFC793], and this can be 609 useful for some proposed features such as TCP Fast Open [Ch14]. 610 Legacy endpoints that ignore the new option would process the 611 payload contents as user data and send an ACK. Once ACK'd, this data 612 cannot be removed from the user stream. 614 The Reserved TCP header bits cannot be redefined easily, even though 615 three of the six total bits have already been redefined (ECE/CWR 616 [RFC3168] and NS [RFC3540]). Legacy endpoints have been known to 617 reflect received values in these fields; this was safely dealt with 618 for ECN but would be difficult here [RFC3168]. 620 TCP initial SYN (SYN and not ACK) segments can use every other TCP 621 header field except the Acknowledgement number, which is not used 622 because the ACK field is not set. In all other segments, all fields 623 except the three remaining Reserved header bits are actively used. 624 The total amount of available header fields, in either case, is 625 insufficient to be useful in extending the option space. 627 The representation of TCP options can be optimized to minimize the 628 space needed. In such cases, multiple Kind and Length fields are 629 combined, so that a new Kind would indicate a specific combination 630 of options, whose order is fixed and whose length is indicated by 631 one Length field. Most TCP options use fields whose size is much 632 larger than the required Kind and Length components, so the 633 resulting efficiency is typically insufficient for additional 634 options. 636 The option space of an initial SYN segment might be extended by 637 using multiple initial segments (e.g., multiple SYNs or a SYN and 638 non-SYN) or based on the context of previous or parallel 639 connections. Because of their potential complexity, these approaches 640 are addressed in separate documents [Br14][To14]. 642 Option space cannot be extended in outer layer headers, e.g., IPv4 643 or IPv6. These layers typically try to avoid extensions altogether, 644 to simplify forwarding processing at routers. Introducing new shim 645 layers to accommodate additional option space would interfere with 646 deep-packet inspection mechanisms that are in widespread use. 648 As a result, EDO does not attempt to extend the space available for 649 options in TCP initial SYNs. It does extend that space in all other 650 segments (including SYN/ACK), which has always been trivially 651 possible once an option is defined. 653 8. Security Considerations 655 It is meaningless to have the Data Offset further exceed the 656 position of the EDO data offset option. 658 >> When the EDO length option is present, the EDO length option 659 SHOULD be the last non-null option covered by the TCP Data Offset, 660 because it would be the last option affected by Data Offset. 662 This also makes it more difficult to use the Data Offset field as a 663 covert channel. 665 9. IANA Considerations 667 We request that, upon publication, this option be assigned a TCP 668 Option codepoint by IANA, which the RFC Editor will replace EDO-OPT 669 in this document with codepoint value. 671 This section is to be removed prior to publication as an RFC. 673 10. References 675 10.1. Normative References 677 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 678 Requirement Levels", BCP 14, RFC 2119, March 1997. 680 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 681 793, September 1981. 683 10.2. Informative References 685 [Al06] Allman, M., "TCPx2: Don't Fence Me In", draft-allman- 686 tcpx2-hack-00 (work in progress), May 2006. 688 [Br14] Briscoe, B., "Extended TCP Option Space in the Payload of 689 an Alternative SYN", draft-briscoe-tcpm-syn-op-sis-02 690 (work in progress), September 2014. 692 [Ch14] Cheng, Y., Chu, J., and A. Jain, "TCP Fast Open", draft- 693 ietf-tcpm-fastopen-10, September 2014. 695 [Ed08] Eddy, W. and A. Langley, "Extending the Space Available 696 for TCP Options", draft-eddy-tcp-loo-04 (work in 697 progress), July 2008. 699 [Ko04] Kohler, E., "Extended Option Space for TCP", draft-kohler- 700 tcpm-extopt-00 (work in progress), September 2004. 702 [Ni14] Nishida, Y., "A-PAWS: Alternative Approach for PAWS", 703 draft-nishida-tcpm-apaws-01 (work in progress), June 2014. 705 [Ra12] Ramaiah, A., "TCP option space extension", draft-ananth- 706 tcpm-tcpoptext-00 (work in progress), March 2012. 708 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 709 September 1981. 711 [RFC1812] Baker, F. (Ed.), "Requirements for IP Version 4 Routers," 712 RFC 1812, June 1995. 714 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 715 Selective Acknowledgment Options", RFC 2018, October 1996. 717 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 718 of Explicit Congestion Notification (ECN) to IP", RFC 719 3168, September 2001. 721 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 722 Issues", RFC 3234, February 2002. 724 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 725 Congestion Notification (ECN) Signaling with Nonces", RFC 726 3540, June 2003. 728 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 729 Authentication Option", RFC 5925, June 2010. 731 [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., 732 and Y. Nishida, "A Conservative Loss Recovery Algorithm 733 Based on Selective Acknowledgment (SACK) for TCP", RFC 734 6675, August 2012. 736 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 737 "TCP Extensions for Multipath Operation with Multiple 738 Addresses", RFC 6824, January 2013. 740 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger 741 (Ed.), "TCP Extensions for High Performance", RFC 7323, 742 September 2014. 744 [To14] Touch, J., T. Faber, "TCP SYN Extended Option Space Using 745 an Out-of-Band Segment", draft-touch-tcpm-tcp-syn-ext-opt- 746 01 (work in progress), September 2014. 748 [Yo11] Yourtchenko, A., "Introducing TCP Long Options by Invalid 749 Checksum", draft-yourtchenko-tcp-loic-00 (work in 750 progress), April 2011. 752 11. Acknowledgments 754 The authors would like to thank the IETF TCPM WG for their feedback, 755 in particular: Oliver Bonaventure, Bob Briscoe, Ted Faber, John 756 Leslie, Richard Scheffenegger, and Alexander Zimmerman. 758 This document was prepared using 2-Word-v2.0.template.dot. 760 Authors' Addresses 762 Joe Touch 763 USC/ISI 764 4676 Admiralty Way 765 Marina del Rey, CA 90292-6695 USA 767 Phone: +1 (310) 448-9151 768 Email: touch@isi.edu 770 Wesley M. Eddy 771 MTI Systems 772 US 774 Email: wes@mti-systems.com