idnits 2.17.1 draft-touch-tcpm-tcp-edo-03.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 (July 2, 2014) is 3579 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-09 == Outdated reference: A later version (-02) exists of draft-nishida-tcpm-apaws-01 -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) -- No information found for draft-touch-tcp-syn-edo - is the name correct? Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 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: January 2015 July 2, 2014 7 TCP Extended Data Offset Option 8 draft-touch-tcpm-tcp-edo-03.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 January 2, 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. 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 to support the use of 51 multiple large options such as SACK with either TCP Multipath or TCP 52 AO. It also explains why the initial SYN of a connection cannot be 53 extending as a single segment. 55 Table of Contents 57 1. Introduction...................................................2 58 2. Conventions used in this document..............................3 59 3. Requirements for Extending TCP's Data Offset...................3 60 4. The TCP EDO Option.............................................3 61 5. TCP EDO Interaction with TCP...................................6 62 5.1. TCP User Interface........................................6 63 5.2. TCP States and Transitions................................6 64 5.3. TCP Segment Processing....................................6 65 5.4. Impact on TCP Header Size.................................6 66 5.5. Connectionless Resets.....................................7 67 5.6. ICMP Handling.............................................8 68 6. Interactions with Middleboxes..................................8 69 7. Comparison to Previous Proposals...............................9 70 7.1. EDO Criteria..............................................9 71 7.2. Summary of Approaches....................................10 72 7.3. Extended Segments........................................11 73 7.4. TCPx2....................................................11 74 7.5. LOO/SLO..................................................12 75 7.6. LOIC.....................................................12 76 7.7. Problems with Extending the Initial SYN..................13 77 8. Security Considerations.......................................14 78 9. IANA Considerations...........................................14 79 10. References...................................................14 80 10.1. Normative References....................................14 81 10.2. Informative References..................................15 82 11. Acknowledgments..............................................16 84 1. Introduction 86 TCP's Data Offset is a 4-bit field, which indicates the number of 87 32-bit words of the entire TCP header [RFC793]. This limits the 88 current total header size to 60 bytes, of which the basic header 89 occupies 20, leaving 40 bytes for options. These 40 bytes are 90 increasingly becoming a limitation to the development of advanced 91 capabilities, such as when SACK [RFC2018][RFC6675] is combined with 92 either Multipath TCP [RFC6824] or TCP-AO [RFC5925]. 94 This document specifies the TCP Extended Data Offset (EDO) option, 95 and is independent of (and thus compatible with) IPv4 and IPv6. EDO 96 extends the space available for TCP options, except for the initial 97 SYN segment (i.e., SYN and not ACK, the first segment of a new 98 connection). This document also explains why the option space of a 99 single initial SYN segment cannot be extended without severe impact 100 on TCP's initial handshake. 102 2. Conventions used in this document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC-2119 [RFC2119]. 108 In this document, these words will appear with that interpretation 109 only when in ALL CAPS. Lower case uses of these words are not to be 110 interpreted as carrying RFC-2119 significance. 112 In this document, the characters ">>" preceding an indented line(s) 113 indicates a compliance requirement statement using the key words 114 listed above. This convention aids reviewers in quickly identifying 115 or finding the explicit compliance requirements of this RFC. 117 3. Requirements for Extending TCP's Data Offset 119 The primary goal of extending the TCP Data Offset field is to 120 increase the space available for TCP options in all segments except 121 the initial SYN. 123 An important requirement of any such extension is that it not impact 124 legacy endpoints. Endpoints seeking to use this new option should 125 not incur additional delay or segment exchanges to connect to either 126 new endpoints supporting this option or legacy endpoints without 127 this option. We call this a "backward downgrade" capability. 129 4. The TCP EDO Option 131 TCP EDO extends the option space for all segments except the initial 132 SYN (i.e., SYN set and ACK not set). The EDO option is organized as 133 indicated in Figure 1 and Figure 2. For initial SYN segments (i.e., 134 those whose ACK bit is not set), the EDO request option consists of 135 the required Kind and Length fields only. All other segments 136 optionally use the EDO length option, which adds a Header_Length 137 field (in network-standard byte rder), indicating the length of the 138 entire TCP header in bytes. The codepoint value of the EDO Kind is 139 EDO-OPT. 141 +--------+--------+ 142 | Kind | Length | 143 +--------+--------+ 145 Figure 1 TCP EDO request option 147 +--------+--------+--------+--------+ 148 | Kind | Length | Header_length | 149 +--------+--------+--------+--------+ 151 Figure 2 TCP EDO length option 153 EDO support is determined in both directions using the same 154 exchange. An endpoint seeking to enable EDO support includes the EDO 155 request option in the initial SYN. 157 >> Connections using EDO MUST negotiate its availability during the 158 initial three-way handshake. 160 >> An endpoint confirming EDO support MUST respond with EDO length 161 option in its SYN-ACK. 163 The EDO length option is required in SYN-ACKs when confirming 164 support for EDO. The SYN-ACK thus can take advantage of EDO, using 165 it to extend its option space. If such extension is not required, 166 then EDO would be equal to 4 * Data Offset (i.e., EDO would indicate 167 in bytes the same length indicated by Data Offset in words). 169 >> Once negotiated on a connection, EDO MAY be present as needed on 170 other segments in either direction. The EDO option SHOULD NOT be 171 used if the total option space needed can be accommodated by the 172 existing Data Offset field. 174 >> The EDO request option (i.e., whose option length is 2) MAY occur 175 in an initial SYN as desired (e.g., by the user/application), but 176 MUST NOT be inserted in other segments. If the EDO request option is 177 received, it MUST be silently ignored. 179 >> The EDO length option MAY occur in segments other than the 180 initial SYN if EDO has been negotiated on a connection. If EDO has 181 not been negotiated and agreed, the EDO length option MUST be 182 silently ignored. The EDO length option MUST NOT be sent in an 183 initial SYN segment, and MUST be silently ignored and not 184 acknowledged if so received. 186 EDO extends the space available for options, but does not consume 187 space unless needed. Segments that don't need the additional space 188 can use the existing Data Offset field as currently specified 189 [RFC793]. When processing a segment, EDO needs to be visible within 190 the area indicated by the Data Offset field, so that processing can 191 use the EDO Header_length to override the Data Offset for that 192 segment. 194 >> The EDO length option MUST occur within the length of the TCP 195 Data Offset. 197 >> The EDO length option indicates the total length of the header. 198 The EDO Header_length field MUST NOT exceed that of the total 199 segment size (i.e., TCP Length). The EDO Header_length SHOULD be a 200 multiple of 4 to simplify processing. 202 >> The EDO request option SHOULD be aligned on a 16-bit boundary and 203 the EDO length option SHOULD be aligned on a 32-bit boundary, in 204 both cases for simpler processing. 206 For example, a segment with only EDO would have a Data Offset of 6, 207 where EDO would be the first option processed, at which point the 208 EDO length option would override the Data Offset and processing 209 would continue until the end of the TCP header as indicated by the 210 EDO Header_length field. 212 There are cases where it might be useful to process other options 213 before EDO, notably those that determine whether the TCP header is 214 valid, such as authentication, encryption, or alternate checksums. 215 In those cases, the EDO length option is preferably the first option 216 after a validation option, and the payload after the Data Offset is 217 treated as user data for the purposes of validation. 219 >> The EDO length option SHOULD occur as early as possible, either 220 first or just after any authentication or encryption, and SHOULD be 221 the last option covered by the Data Offset value. 223 Other options are generally handled in the same manner as when the 224 EDO option is not active, unless they interact with other options. 225 One such example is TCP-AO [RFC5925], which optionally ignores the 226 contents of TCP options, so it would need to be aware of EDO to 227 operate correctly when options are excluded from the HMAC 228 calculation. 230 >> Options that depend on other options, such as TCP-AO [RFC5925] 231 (which may include or exclude options in MAC calculations) MUST also 232 be augmented to interpret the EDO length option to operate 233 correctly. 235 5. TCP EDO Interaction with TCP 237 The following subsections describe how EDO interacts with the TCP 238 specification [RFC793]. 240 5.1. TCP User Interface 242 The TCP EDO option is enabled on a connection using a mechanism 243 similar to any other per-connection option. In Unix systems, this is 244 typically performed using the 'setsockopt' function. 246 >> Implementations can also employ system-wide defaults, however 247 systems SHOULD NOT use this extension by default to avoid 248 interfering with legacy applications. 250 5.2. TCP States and Transitions 252 TCP EDO does not alter the existing TCP state or state transition 253 mechanisms. 255 5.3. TCP Segment Processing 257 TCP EDO alters segment processing during the TCP option processing 258 step. Once detected, the TCP EDO length option overrides the TCP 259 Data Offset field for all subsequent option processing. Option 260 processing continues at the next option after the EDO length option. 262 Implementers need to be careful about the potential for offload 263 support interfering with this option. The EDO data needs to be 264 passed to the protocol stack as part of the option space, not 265 integrated with the user segment, to allow the offload to 266 independently determine user data segment boundaries and combine 267 them correctly with the extended option data. 269 5.4. Impact on TCP Header Size 271 The TCP EDO request option increases SYN header length by a minimum 272 of 2 bytes. Currently popular SYN options total 19 bytes, which 273 leaves more than enough room for the EDO request: 275 o SACK permitted (2 bytes in SYN, optionally 2 + 8N bytes after) 276 [RFC2018][RFC6675] 278 o Timestamp (10 bytes) [RFC1323] 279 o Window scale (3 bytes) [RFC1323] 281 o MSS option (4 bytes) [RFC793] 283 Adding the EDO option would result in a total of 21 bytes of SYN 284 option space. Subsequent segments would use 19 bytes of option space 285 without any SACK blocks or allow up to 4 SACK blocks before needing 286 to use EDO; with EDO, the number of SACK blocks or additional 287 options would be substantially increased. 289 TCP EDO can also be negotiated in SYNs with either of the following 290 options: 292 o TCP-AO (authentication) (16 bytes) [RFC5925] 294 o Multipath TCP (12 bytes in SYN and SYN-ACK, 20 after) [RFC6824] 296 Including TCP-AO increases the SYN option space use to 37 bytes; 297 with Multipath TCP the use is 33 bytes. When Multipath TCP is 298 enabled with the typical options, later segments might require 39 299 bytes without SACK, thus effectively disabling the SACK option 300 unless EDO is also supported on at least non-SYN segments. 302 The full combination of the above options (49 bytes including EDO) 303 does not fit in the existing SYN option space and (as noted) that 304 space cannot be extended within a single SYN segment. There has been 305 a proposal to change TS to a 2 byte "TS permitted" signal in the 306 initial SYN, provided it can be safely enabled during the connection 307 later or might be avoided completely [Ni14]. Even using "TS- 308 permitted", the total space is still too large to support in the 309 initial SYN without SYN option space extension [To14]. 311 The EDO option has negligible impact on other headers, because it 312 can either come first or just after security information, and in 313 either case the additional 4 bytes are easily accommodated within 314 the TCP Data Offset length. Once the EDO option is processed, the 315 entirety of the remainder of the TCP segment is available for any 316 remaining options. 318 5.5. Connectionless Resets 320 A RST may arrive during a currently active connection or may be 321 needed to cleanup old state from an abandoned connection. The latter 322 occurs when a new SYN is sent to an endpoint with matching existing 323 connection state, at which point that endpoint responds with a RST 324 and both ends remove stale information. 326 The EDO option is not mandatory in any TCP segment, except the SYN 327 and SYN-ACK of the three-way handshake to establish its support. 329 >> The EDO length option MAY occur in a RST when the endpoint has 330 connection state that has negotiated EDO. However, unless the RST is 331 generated by an incoming segment that includes an EDO option, the 332 RST MUST NOT include the EDO length option. 334 5.6. ICMP Handling 336 ICMP responses are intended to include the IP and the port fields of 337 TCP and UDP headers of typical TCP/IP and UDP/IP packets [RFC792]. 338 This includes the first 8 data bytes of the original datagram, 339 intended to include the transport port numbers used for connection 340 demultiplexing. Later specifications encourage returning as much of 341 the original payload as possible [RFC1812]. In either case, legacy 342 options or new options in the EDO extension area might or might not 343 be included, and so options are generally not assumed to be part of 344 ICMP processing anyway. 346 6. Interactions with Middleboxes 348 Any new TCP option may be impacted by the presence of any on-path 349 device that examines or modifies transport headers [RFC3234]. Boxes 350 that parse or modify TCP options need to follow the same 351 requirements of TCP endpoints in supporting EDO, or they could 352 interfere with connections. The primary concern is so-called 353 "transparent" rewriting proxies, which modify TCP segment boundaries 354 and thus would mix option information with user data if they do not 355 support EDO. Such devices interfere with many other TCP options, and 356 although their use is not common they would interfere with 357 connections that use EDO. 359 More common are NATs, which rewrite IP address and/or transport port 360 fields. NATs are not affected by the EDO option. 362 Deep-packet inspection systems that inspect TCP segment payloads or 363 attempt to reconstitute the data stream would incorrectly include 364 options, which might interfere with their operation. 366 It may be important to detect misbehavior that could cause EDO space 367 to be misinterpreted as user data. In such cases, EDO SHOULD be used 368 in conjunction with integrity protection mechanisms, such as IPsec, 369 TCP-AO, etc. It is useful to note that such protection helps find 370 only non-compliant components. 372 --- 373 ?? should we include a header checksum, as suggested by Oliver 374 Bonaventure, too? Should it be integrated with EDO or independent? 375 If so, we either need one of the following: 377 +--------+--------+--------+--------+ 378 | Kind | Length | Header_length | 379 +--------+--------+--------+--------+ 380 | EDO-checksum | 381 +--------+--------+ 383 Figure 3 TCP EDO length + sum option 385 +--------+--------+--------+--------+ 386 | Kind | Length | Header_checksum | 387 +--------+--------+--------+--------+ 389 Figure 4 TCP header checksum option 391 The former adds a header checksum to EDO - this could be optional or 392 required, and its presence can be determined from the option length. 393 The checksum would be over only the additional EDO space. 395 The latter requires a new option and we'd need to decide what the 396 option covered. It could cover just the option space. 398 Finally, another option would be to try to make rewriting 399 middleboxes fail by some other, more opaque means - such as using 400 DO=0 when EDO is used as suggested by John Leslie (but this would 401 also require considering whether EDO would be required on all 402 packets, or just on DO=0, as well as where EDO would be and whether 403 it could precede security/integrity options such as TCP-AO). 405 7. Comparison to Previous Proposals 407 EDO is the latest in a long line of attempts to increase TCP option 408 space [Al06][Ed08][Ko04][Ra12][Yo11]. The following is a comparison 409 of these approaches to EDO, based partly on a previous summary 410 [Ra12]. This comparison differs from that summary by using a 411 different set of success criteria. 413 7.1. EDO Criteria 415 Our criteria for a successful solution are as follows: 417 o Zero-cost fallback to legacy endpoints. 419 o Minimal impact on middlebox compatibility. 421 o No additional side-effects. 423 Zero-cost fallback requires that upgraded hosts incur no penalty for 424 attempting to use EDO. This disqualifies dual-stack approaches, 425 because the client might have to delay connection establishment to 426 wait for the preferred connection mode to complete. Note that the 427 impact of legacy endpoints that silently reflect unknown options are 428 not considered, as they are already non-compliant with existing TCP 429 requirements [RFC793]. 431 Minimal impact on middlebox compatibility requires that EDO works 432 through simple NAT and NAPT boxes, which modify IP addresses and 433 ports and recompute IPv4 header and TCP segment checksums. 434 Middleboxes that reject unknown options or that process segments in 435 detail without regard for unknown options are not considered; they 436 process segments as if they were an endpoint but do so in ways that 437 are not compliant with existing TCP requirements (e.g., they should 438 have rejected the initial SYN because of its unknown options rather 439 than silently relaying it). 441 EDO also attempts to avoid creating side-effects, such as might 442 happen if options were split across multiple TCP segments (which 443 could arrive out of order or be lost) or across different TCP 444 connections (which could fail to share fate through firewalls or 445 NAT/NAPTs). 447 These requirements are similar to those noted in [Ra12], but EDO 448 groups cases of segment modification beyond address and port - such 449 as rewriting, segment drop, sequence number modification, and option 450 stripping - as already in violation of existing TCP requirements 451 regarding unknown options, and so we do not consider their impact on 452 this new option. 454 7.2. Summary of Approaches 456 There are three basic ways in which TCP option space extension has 457 been attempted: 459 1. Use of a TCP option. 461 2. Redefinition of the existing TCP header fields. 463 3. Use of option space in multiple TCP segments (split across 464 multiple segments). 466 A TCP option is the most direct way to extend the option space and 467 is the basis of EDO. This approach cannot extend the option space of 468 the initial SYN. 470 Redefining existing TCP header fields can be used to either contain 471 additional options or as a pointer indicating alternate ways to 472 interpret the segment payload. All such redefinitions make it 473 difficult to achieve zero-impact backward compatibility, both with 474 legacy endpoints and middleboxes. 476 Splitting option space across separate segments can create 477 unintended side-effects, such as increased delay to deal with path 478 latency or loss differences. 480 The following discusses three of the most notable past attempts to 481 extend the TCP option space: Extended Segments, TCPx2, LOO/SLO, and 482 LOIC. [Ra12] suggests a few other approaches, including use of TCP 483 option cookies, reuse/overload of other TCP fields (e.g., the URG 484 pointer), or compressing TCP options. None of these is compatible 485 with legacy endpoints or middleboxes. 487 7.3. Extended Segments 489 TCP Extended Segments redefined the meaning of currently unused 490 values of the Data Offset (DO) field [Ko04]. TCP defines DO as 491 indicating the length of the TCP header, including options, in 32- 492 bit words. The default TCP header with no options is 5 such words, 493 so the minimum currently valid DO value is 5 (meaning 40 bytes of 494 option space). This document defines interpretations of values 0-4: 495 DO=0 means 48 bytes of option space, DO=1 means 64, DO=2 means 128, 496 DO=3 means 256, and DO=4 means unlimited (e.g., the entire payload 497 is option space). This variant negotiates the use of this capability 498 by using one of these invalid DO values in the initial SYN. 500 Use of this variant is not backward-compatible with legacy TCP 501 implementations, whether at the desired endpoint or on middleboxes. 502 The variant also defines a way to initiate the feature on the 503 passive side, e.g., using an invalid DO during the SYN-ACK when the 504 initial SYN had a valid DO. This capability allows either side to 505 initiate use of the feature but is also not backward compatible. 507 7.4. TCPx2 509 TCPx2 redefines legacy TCP headers by basically doubling all TCP 510 header fields [Al06]. It relies on a new transport protocol number 511 to indicate its use, defeating backward compatibility with all 512 existing TCP capabilities, including firewalls, NATs/NAPTs, and 513 legacy endpoints and applications. 515 7.5. LOO/SLO 517 The TCP Long Option (LO, [Ed08]) is very similar to EDO, except that 518 presence of LO results in ignoring the existing DO field and that LO 519 is required to be the first option. EDO considers the need for other 520 fields to be first and declares that the EDO is the last option as 521 indicated by the DO field value. Unlike LO, EDO is not required in 522 every segment once negotiated, saving 6 bytes if not actively 523 needed. 525 The TCP Long Option draft also specified the SYN Long Option (SLO) 526 [Ed08]. If SLO is used in the initial SYN and successfully 527 negotiated, it is used in each subsequent segment until all of the 528 initial SYN options are transmitted. 530 LO is backward compatible, as is SLO; in both cases, endpoints not 531 supporting the option would not respond with the option, and in both 532 cases the initial SYN is not itself extended. 534 SLO does modify the three-way handshake because the connection isn't 535 considered completely established until the first data byte is 536 ACKed. Legacy TCP can establish a connection even in the absence of 537 data. SLO also changes the semantics of the SYN-ACK; for legacy TCP, 538 this completes the active side connection establishment, where in 539 SLO an additional data ACK is required. A connection whose initial 540 SYN options have been confirmed in the SYN-ACK might still fail upon 541 receipt of additional options sent in later SLO segments. This case 542 - of late negotiation fail - is not addressed in the specification. 544 7.6. LOIC 546 TCP Long Options by Invalid Checksum is a dual-stack approach that 547 uses two initial SYNS to initiate all updated connections [Yo11]. 548 One SYN negotiates the new option and the other SYN payload contains 549 only the entire options. The negotiation SYN is compliant with 550 existing procedures, but the option SYN has a deliberately incorrect 551 TCP checksum (decremented by 2). A legacy endpoint would discard the 552 segment with the incorrect checksum and respond to the negotiation 553 SYN without the LO option. 555 Use of the option SYN and its incorrect checksum both interfere with 556 other legacy components. Segments with incorrect checksums will be 557 silently dropped by most middleboxes, including NATs/NAPTs. Use of 558 two SYNs creates side-effects that can delay connections to upgraded 559 endpoints, notably when the option SYN is lost or the SYNs arrive 560 out of order. Finally, by not allowing other options in the 561 negotiation SYN, all connections to legacy endpoints either use no 562 options or require a separate connection attempt (either concurrent 563 or subsequent). 565 7.7. Problems with Extending the Initial SYN 567 The key difficulty with most previous proposals is the desire to 568 extend the option space in all TCP segments, including the initial 569 SYN, i.e., SYN with no ACK, typically the first segment of a 570 connection. It has proven difficult to extend space in this initial 571 SYN in the absence of prior negotiation while maintaining current 572 TCP three-way handshake properties. 574 A new TCP option cannot extend the Data Offset of a single TCP 575 initial SYN segment. All TCP segments, including the initial SYN, 576 may include user data in the payload data [RFC793], and this can be 577 useful for some proposed features such as TCP Fast Open [Ch14]. 578 Legacy endpoints that ignore the new option would process the 579 payload contents as user data and send an ACK. Once ACK'd, this data 580 cannot be removed from the user stream. 582 The six Reserved TCP header bits cannot be redefined easily, because 583 the original specification did not require their contents to be 584 ignored, even though three of those bits have already been redefined 585 (ECE/CWR [RFC3168] and NS [RFC3540]). Legacy endpoints are required 586 to drop TCP segments where those bits are not zero, making it 587 difficult to assume backward downgrade. 589 TCP initial SYN (SYN and not ACK) segments can use every other TCP 590 header field except the Acknowledgement number, which is not used 591 because the ACK field is not set. In all other segments, all fields 592 except the three remaining Reserved header bits are actively used. 593 The total amount of available header fields, in either case, is 594 insufficient to be useful in extending the option space. 596 The representation of TCP options can be optimized to minimize the 597 space needed. In such cases, multiple Kind and Length fields are 598 combined, so that a new Kind would indicate a specific combination 599 of options, whose order is fixed and whose length is indicated by 600 one Length field. Most TCP options use fields whose size is much 601 larger than the required Kind and Length components, so the 602 resulting efficiency is typically insufficient for additional 603 options. 605 The option space of an initial SYN segment might be extended by 606 using multiple initial segments (e.g., multiple SYNs or a SYN and 607 non-SYN) or based on the context of previous or parallel 608 connections. Because of their potential complexity, these approaches 609 are addressed in a separate document [To14]. 611 Option space cannot be extended in outer layer headers, e.g., IPv4 612 or IPv6. These layers typically try to avoid extensions altogether, 613 to simplify forwarding processing at routers. Introducing new shim 614 layers to accommodate additional option space would interfere with 615 deep-packet inspection mechanisms that are in widespread use. 617 As a result, EDO does not attempt to extend the space available for 618 options in TCP initial SYNs. It does extend that space in all other 619 segments (including SYN-ACK), which has always been trivially 620 possible once an option is defined. 622 8. Security Considerations 624 It is meaningless to have the Data Offset further exceed the 625 position of the EDO data offset option. 627 >> When the EDO length option is present, the EDO length option 628 SHOULD be the last non-null option covered by the TCP Data Offset, 629 because it would be the last option affected by Data Offset. 631 This also makes it more difficult to use the Data Offset field as a 632 covert channel. 634 9. IANA Considerations 636 We request that, upon publication, this option be assigned a TCP 637 Option codepoint by IANA, which the RFC Editor will replace EDO-OPT 638 in this document with codepoint value. 640 This section is to be removed prior to publication as an RFC. 642 10. References 644 10.1. Normative References 646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 647 Requirement Levels", BCP 14, RFC 2119, March 1997. 649 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 650 793, September 1981. 652 10.2. Informative References 654 [Al06] Allman, M., "TCPx2: Don't Fence Me In", draft-allman- 655 tcpx2-hack-00 (work in progress), May 2006. 657 [Ch14] Cheng, Y., Chu, J., and A. Jain, "TCP Fast Open", draft- 658 ietf-tcpm-fastopen-09, June 2014. 660 [Ed08] Eddy, W. and A. Langley, "Extending the Space Available 661 for TCP Options", draft-eddy-tcp-loo-04 (work in 662 progress), July 2008. 664 [Ko04] Kohler, E., "Extended Option Space for TCP", draft-kohler- 665 tcpm-extopt-00 (work in progress), September 2004. 667 [Ni14] Nishida, Y., "A-PAWS: Alternative Approach for PAWS", 668 draft-nishida-tcpm-apaws-01 (work in progress), June 2014. 670 [Ra12] Ramaiah, A., "TCP option space extension", draft-ananth- 671 tcpm-tcpoptext-00 (work in progress), March 2012. 673 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. 675 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 676 for High Performance", RFC 1323, May 1992. 678 [RFC1812] Baker, F. (Ed.), "Requirements for IP Version 4 Routers," 679 RFC 1812, June 1995. 681 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 682 Selective Acknowledgment Options", RFC 2018, October 1996. 684 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 685 of Explicit Congestion Notification (ECN) to IP", RFC 686 3168, September 2001. 688 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 689 Issues", RFC 3234, February 2002. 691 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 692 Congestion Notification (ECN) Signaling with Nonces", RFC 693 3540, June 2003. 695 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 696 Authentication Option", RFC 5925, June 2010. 698 [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., 699 and Y.. Nishida, "A Conservative Loss Recovery Algorithm 700 Based on Selective Acknowledgment (SACK) for TCP", RFC 701 6675, August 2012. 703 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 704 "TCP Extensions for Multipath Operation with Multiple 705 Addresses", RFC 6824, January 2013. 707 [To14] Touch, J., (et al., TBD), "Extending TCP Option Space 708 During Connection Establishment", draft-touch-tcp-syn-edo- 709 00 (work in progress), July 2014. 711 [Yo11] Yourtchenko, A., "Introducing TCP Long Options by Invalid 712 Checksum", draft-yourtchenko-tcp-loic-00 (work in 713 progress), April 2011. 715 11. Acknowledgments 717 The authors would like to thank the IETF TCPM WG for their feedback, 718 in particular: Oliver Bonaventure, Bob Briscoe, Ted Faber, John 719 Leslie, Richard Scheffenegger, and Alexander Zimmerman. 721 This document was prepared using 2-Word-v2.0.template.dot. 723 Authors' Addresses 725 Joe Touch 726 USC/ISI 727 4676 Admiralty Way 728 Marina del Rey, CA 90292-6695 USA 730 Phone: +1 (310) 448-9151 731 Email: touch@isi.edu 733 Wesley M. Eddy 734 MTI Systems 735 US 737 Email: wes@mti-systems.com