idnits 2.17.1 draft-eddy-tcp-loo-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 445. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 458. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (May 6, 2005) is 6923 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) == Unused Reference: '3' is defined on line 394, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (ref. '1') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1323 (ref. '4') (Obsoleted by RFC 7323) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Eddy 3 Internet-Draft NASA GRC/Verizon FNS 4 Expires: November 7, 2005 May 6, 2005 6 Extending the Space Available for TCP Options 7 draft-eddy-tcp-loo-03 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 7, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document describes a method for increasing the space available 41 for TCP options. Two new TCP options (LO and SLO) are detailed which 42 reduce the limitations imposed by the TCP header's Data Offset field. 43 The LO option provides this extension after connection establishment, 44 and the SLO option aids in transmission of lengthy connection 45 initialization and configuration options. 47 Table of Contents 49 1. Requirements Notation . . . . . . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. The Long Options (LO) Option . . . . . . . . . . . . . . . . 6 52 4. The SYN Long Options (SLO) Option . . . . . . . . . . . . . 8 53 5. Middlebox Interactions . . . . . . . . . . . . . . . . . . . 10 54 6. Comparison to Extended Segments . . . . . . . . . . . . . . 11 55 7. Security Considerations . . . . . . . . . . . . . . . . . . 13 56 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 57 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 58 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 59 10.1 Normative References . . . . . . . . . . . . . . . . . . 16 60 10.2 Informative References . . . . . . . . . . . . . . . . . 16 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . 17 62 Intellectual Property and Copyright Statements . . . . . . . 18 64 1. Requirements Notation 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119. 70 2. Introduction 72 Every TCP segment's header contains a 4-bit Data Offset (DO) field 73 that implies the length of that segment's TCP header. The DO field 74 has been specified as: "The number of 32-bit words in the TCP Header. 75 This indicates where the data begins. The TCP header (even one 76 including options) is an integral number of 32 bits long" [1]. For a 77 TCP implementation, this means that the boundary separating TCP 78 control data and application data is always exactly DO * 4 bytes from 79 the beginning of the TCP header. 81 As a 4-bit unsigned integer, DO's value is bounded between 0 and 15. 82 This allows for a maximum TCP header length of 60 bytes (15 * 4 83 bytes). The required fields in a TCP header occupy a fixed 20 bytes, 84 leaving 40 bytes as the maximum amount of space for use by TCP 85 options. 87 While 40 bytes is a reasonable amount of space, sufficient for the 88 concurrent use of several presently defined TCP options, there are 89 cases where more space might be useful. For example, the Selective 90 Acknowledgement (SACK) option [5] uses a fixed 2 bytes for its kind 91 and length fields, and requires an additional 8 bytes per SACK block. 92 Thus, the maximum number of SACK blocks a TCP acknowledgement may 93 carry is limited to 4 (with 6 bytes left over). Since SACK is 94 commonly used with the Timestamp option [4], which uses 10 bytes, 95 this further limits the number of SACK blocks that may be carried to 96 3. For specific scenarios involving large windows and combinations 97 of data and acknowledgement loss, additional capacity for SACK blocks 98 is known to be useful [6]. 100 Creation of new TCP options is also hindered by the lack of space 101 left over after currently-used options are accounted for. For long 102 options that must be present at connection-startup time, this is a 103 particular problem, as all negotiable options need to share 40 bytes 104 of space in a SYN segment. One method that has been used to get 105 around this limitation is overloading the Timestamp bytes in the SYN 106 segments [7]. There are other header fields that might be similarly 107 overloaded (e.g. the urgent pointer), but this approach is of 108 obviously limited utility, as it does not address the fundamental 109 limitation imposed by the DO field, and there are a finite number of 110 overloadable header bits. 112 This document specifies two new TCP options, LO and SLO. The Long 113 Options (LO) option allows two hosts to negotiate for the ability to 114 use TCP headers longer than 60 bytes (and thus options space of 115 greater than 40 bytes) on subsequent segments. This is accomplished 116 by ignoring the DO field's value and adding a 16-bit field at a fixed 117 location in the header's options to replace it. The format and usage 118 of the LO option is detailed in Section 3. 120 Attempting to process initial SYN segements with greater than 60 121 bytes of TCP headers might cause errors if received by hosts that 122 consider anything past the DO-specified boundary to be application 123 data. For backwards compatibility reasons, the maximum length of 124 options on a connection-initiating SYN segment remains 40. The SYN 125 Long Options (SLO) option is used in the case where these 40 bytes 126 are not enough space to carry the desired startup configuration 127 options, and negotiates for later reliable delivery of the left-off 128 options. Section 4 describes the format and usage of the SLO option. 130 3. The Long Options (LO) Option 132 A host might implement some set of TCP options allowing it to predict 133 that greater than 40 bytes of TCP options space may be useful (for 134 example SACK, Timestamps, alternate checksums, etc). In this case, a 135 host MAY implement the LO option. When initiating connections 136 through an active open, hosts implementing the LO option SHOULD place 137 a LO option of the form shown in Figure 1 somewhere in the SYN 138 segment's options. The 16-bit field labelled "Header Length" should 139 be filled in with the same value as the DO field in the required 140 portion of the TCP header, left-padded with zeros. 142 1 2 3 143 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 144 +---------------+---------------+-------------------------------+ 145 | Kind = 27 | Length = 4 | Header Length | 146 +---------------+---------------+-------------------------------+ 148 TCP Long Options (LO) Option 150 Figure 1 152 Receipt of an acknowledgement covering the SYN and also containing a 153 LO option means the LO option MUST be used as the first option on all 154 subsequent segments, and the DO field on all subsequent segments 155 SHOULD be set to 6. The value 6 represents the length of the 156 required portions of the TCP header plus the LO option. The Header 157 Length field of a LO option overrides the DO field in the fixed 158 header, and has an identical meaning, but with 16 bits of unsigned 159 precision rather than 4. Semantically, this still represents the 160 offset from the beginning of the TCP header bounding the start of 161 application data bytes. Since the LO option is found in a fixed 162 place on all susbequent segments, it essentially becomes part of the 163 required header, and looking up the Header Length field is of similar 164 computational complexity to that required when the DO field is used. 166 Since a LO option's Header Length field is of the same range as the 167 IP header's Total Length field [2], this allows TCP options to 168 consume an entire maximum-sized IP datagram's length (minus the IP 169 header and required TCP header fields). No matter what size the 170 options section of a TCP header is, it must still be appended with 171 zero-padding to make the total header a multiple of 32 bits, per RFC 172 793 [1]. 174 Listening hosts that implement the LO option, after reception of a 175 SYN segment with the LO option present, SHOULD reply with a LO option 176 in their SYN-ACK. The LO option is then used on all subsequent 177 segments to override the DO field. It can be seen that in both the 178 normal case where one host passively opens and another actively 179 opens, and the more rare case where two hosts simultaneously initiate 180 active opens, the LO option's use can be successfully negotiated. 182 Mandating the use of the LO option on all subsequent segments after 183 negotiation may seem to be a bit arbitrary. For instance, it would 184 be technically feasible to only include LO options on particular 185 segments for which the DO field is determined to not be long enough. 186 This would save 4 bytes of header overhead when the extra options 187 space is not needed. However, the behavior that this document 188 describes proved to be easier to implement in the authors' 189 experiences with two different TCP implementations. Mandating the LO 190 option on all segments makes odd buggy behaviors less likely and 191 simplifies the algorithms for parsing TCP headers and options in the 192 implementations we worked with. If the additional header overhead 193 seems problematic, it can be effectively mitigated using header 194 compression techniques, since the stream of 4 byte LO options 195 typically has very little entropy. 197 4. The SYN Long Options (SLO) Option 199 If the LO option has been successfully negotiated, an active-opening 200 host that has more bytes of initialization options than would fit in 201 the SYN, can use the SYN Long Options (SLO) option. If a host 202 supports the LO option, then it MUST support the SLO option. 204 Any option bytes transmitted using the SLO option will be treated as 205 if they were carried on the SYN segment. Since there is no guarantee 206 that the LO option will be successfully negotiated, the additional 36 207 bytes left over aside from the 4 byte LO option on a SYN segment 208 should be filled with the most important remaining options that will 209 fit, as determined by the particular implementation. A host issuing 210 a passive open, MUST NOT use the SLO option, as it can use the LO 211 option on SYN-ACK segments if it needs to send long initilization 212 options. The SLO option only serves the needs of an active-opening 213 host that, for backwards compatibility reasons, could not send more 214 than 40 bytes of options on the SYN segment. 216 After successful LO negotiation, if a host has any options that did 217 not fit on the SYN, then additional data or acknowledgement segments 218 MUST carry a SLO option until the first data byte has been 219 acknowledged. The SLO option's format is shown in figure Figure 2. 220 The trailing 2 bytes hold a 16-bit unsigned count of the additional 221 bytes that would have been in the SYN segment's options, if they had 222 been possible to include. This represents an offset from the end of 223 the SLO option, to the last byte that should be considered a SYN 224 option. The next "Additional Byte Count"-number of bytes trailing 225 the SLO option MUST be the ones that did not fit in the SYN segment. 226 The SLO option should always immediately follow the LO option, 227 followed by the additional SYN options, and then by normal options, 228 and finally application data. 230 1 2 3 231 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 232 +---------------+---------------+-------------------------------+ 233 | Kind = 28 | Length = 4 | Additional Byte Count | 234 +---------------+---------------+-------------------------------+ 236 TCP SYN Long Options (SLO) Option 238 Figure 2 240 Since TCP connection establishment is often concluded by a pure 241 acknowledgement (carrying no data), only placing the SLO option and 242 additional SYN options in such a single, unreliable segment would be 243 risky. This is why a host MUST continue transmitting SLO options on 244 all segments until its first byte of sent data is acknowledged. 246 Acknowledgement of the first data-byte implicitly covers the SLO and 247 trailing options, as these must have been received end-to-end with 248 the first data byte. 250 If a host does not send any data bytes, but if by some means (perhaps 251 through the received options) it is possible to derive either an 252 explicit or implicit acknowledgement of even a single option 253 transmitted in a SLO-carrying segment (for example via a Timestamp 254 echo), then a host MAY choose to stop transmitting the SLO data. 255 This special case overrides the previously specified MUST condition. 257 A host SHOULD NOT continue sending SLO options after it has received 258 acknowledgement of the first data byte, nor should a host process 259 incoming SLO options other than on the first valid segment it 260 receives that carries them. 262 5. Middlebox Interactions 264 The large number of middleboxes (firewalls, proxies, protocol 265 scrubbers, etc) currently present in the Internet pose some 266 difficulty for deploying new TCP options. Some firewalls may block 267 segments that carry unknown options. For instance, if the LO option 268 is not understood by a firewall, incoming SYNs advertising LO support 269 may be dropped, preventing connection establishment. This is similar 270 to the ECN blackhole problem, where certain faulty hosts and routers 271 throw away packets with ECN bits set [8]. Some recent results 272 indicate that for new TCP options, this may not be a significant 273 threat, with only 0.2% of web requests failing when carrying an 274 unknown option [9]. 276 More problematic, are the implications of TCP connection-splitting 277 middleboxes and protocol scrubbers that do not understand the LO 278 option. Since such middleboxes may operate on a packet's contents 279 (aggregating application data between multiple segments, rewriting 280 sequence numbers, etc), if the LO option is not understood, then 281 there may be a mangling of the data passed to the application, as 282 control data could end up inter-mingled with the application data. 283 Such errors could be difficult to detect at the transport layer, and 284 many applications might not perform their own integrity checks. An 285 encouraging fact is that some of these devices reset connection 286 attempts when they see TCP options that they do not understand. 287 Hosts that implement the TCP options described in this document MAY 288 retry connection attempts without LO options on the SYNs, if their 289 first attempt with LO options fails. 291 6. Comparison to Extended Segments 293 Another proposal that solves the same problem as the LO and SLO 294 options is that of TCP "extended egments" [10]. The extended 295 segments technique was proposed following the initial introduction 296 and discussion of the LO and SLO options within the IETF's TCP 297 Maintenance and Minor Extensions working group. The two methods 298 solve the same problem in rather different ways, and have several 299 minor comparative advantages and disadvantages. 301 The LO and SLO options are designed using the philosophy of using the 302 TCP options space to compensate for insufficiency of the standard 303 header. This is in keeping with the way that several currently-used 304 options work. For example, the Window Scale option deals with the 305 limited space in the advertised receive window field, and the 306 Selective Acknowledgement option solves the lack of information in 307 the cumulative acknowledgement field. Extended segments approach 308 overloads the meaning of the standard Data Offset field, keeping its 309 original meaning for values of 5 and greater, but redefining it for 310 values less than 5. This is seen as acceptable since values less 311 than 5 are currently impossible, illegal, and unusable. Extended 312 segments avoid the need for new options by changing the way that the 313 existing standard header is parsed. 315 A key advantage of the extended segments approach is that it does not 316 increase the TCP header size, whereas the LO option adds 4 bytes of 317 space to TCP headers. The severity or triviality of this bloat in 318 header overhead depends entirely upon the network properties and 319 application traffic for particular use cases. 321 It is also not altogether clear that extended segments will always 322 save space in comparison to LO options. The granularity of option 323 lengths that extended segments can support is limited to the number 324 of unusable Data Offset values (5, 0 through 4). Currently, the 325 extended segments proposal defines 4 fixed lengths, and one 326 "infinite" length that means the entire segment is options, with no 327 application data. The fixed option lengths are 48, 64, 128, and 256 328 bytes. If the required per-data-segment options space for some 329 extension or combination of extensions does not map to exactly these 330 values, then padding bytes are required. If 129 bytes of options are 331 required on a data segment, then a length of 256 must be used, and 332 127 bytes of useless padding are added. The LO option has a single- 333 byte granularity and avoids the need for all wasteful padding, aside 334 from that mandated to make the header a perfect multiple of 4-bytes. 335 It is possible that the overhead on a single extended segment could 336 be more than that of several segments using the LO option. 338 Some networkers have found the SLO mechanism that is required for 339 processing of long initialization options to be somewhat "ugly". 340 Extended segments avoid this by sending long intialization options on 341 the initial SYN and SYN-ACK segments. If the other side does not 342 support extended segments, this adds needless confusion and delay in 343 connection setup. The protocol dance to negotiate use of extended 344 segments is arguably much worse than using SLO. If an extended SYN 345 is not understood, a non-reliably transmitted RST segment signals the 346 initiating host to retry without extended segments. Such a retry 347 mechanism is not commonly found in existing TCP implementations. If 348 the LO option is not understood, a SYN-ACK is still immediately 349 generated and the connection goes on uninterrupted, without any 350 additional retry mechanisms. Furthermore, extended SYN-ACKs may be 351 sent in response to non-extended SYNs. This complicates the recovery 352 proceedure even more, if not understood, and goes against the way 353 that all current negotiable TCP extensions operate (only used on SYN- 354 ACK if advertised on SYN). 356 Over-zealous middleboxes are immensely troublesome for the deployment 357 of most transport layer extensions. It is unclear whether LO and 358 extended segments have any real difference in robustness in the 359 presence of different types of middleboxes. Both types of segments 360 may appear as invalid to some middleboxes, and both may be mangled if 361 rewritten by a middlebox. 363 7. Security Considerations 365 The TCP options presented in this document open no additional 366 vulnerabilities that we are aware of. 368 8. IANA Considerations 370 This document does not create any new registries or modify the rules 371 for any existing registries managed by IANA. 373 This document requires IANA to update values in its registry of TCP 374 options numbers to reflect the use of values 27 and 28 for the LO and 375 SLO options detailed in this document. 377 9. Acknowledgements 379 This document benefitted specifically from discussions with Josh 380 Blanton and Shawn Ostermann. Some comments from Eddie Kohler 381 motivated the discussion of middlebox interactions. Valuable 382 feedback was obtained from Mark Allman and other participants in the 383 TCP Maintenance and Minor Extensions (TCPM) Working Group. 385 10. References 387 10.1 Normative References 389 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 390 September 1981. 392 [2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 394 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 395 Levels", BCP 14, RFC 2119, March 1997. 397 10.2 Informative References 399 [4] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for 400 High Performance", RFC 1323, May 1992. 402 [5] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 403 Selective Acknowledgment Options", RFC 2018, October 1996. 405 [6] Srijith, K., Jacob, L., and A. Ananda, "Worst-case Performance 406 Limitation of TCP SACK and a Feasible Solution", Proceedings of 407 8th IEEE International Conference on Communications Systems 408 (ICCS), November 2002. 410 [7] Snoeren, A. and H. Balakrishnan, "An End-to-End Approach to 411 Host Mobility", Proc. of the Sixth Annual ACM/IEEE 412 International Conference on Mobile Computing and Networking, 413 August 2000. 415 [8] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of 416 Explicit Congestion Notification (ECN) to IP", RFC 3168, 417 September 2001. 419 [9] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions 420 Between Transport Protocols and Middleboxes", ACM SIGCOMM/ 421 USENIX Internet Measurement Conference, October 2004. 423 [10] Kohler, E., "Extended Option Space for TCP", Internet Draft 424 (work in progress), September 2004. 426 Author's Address 428 Wesley M. Eddy 429 NASA GRC/Verizon FNS 430 21000 Brookpark Rd, MS 54-5 431 Cleveland, OH 44135 433 Phone: 216-433-6682 434 Email: weddy@grc.nasa.gov 436 Intellectual Property Statement 438 The IETF takes no position regarding the validity or scope of any 439 Intellectual Property Rights or other rights that might be claimed to 440 pertain to the implementation or use of the technology described in 441 this document or the extent to which any license under such rights 442 might or might not be available; nor does it represent that it has 443 made any independent effort to identify any such rights. Information 444 on the procedures with respect to rights in RFC documents can be 445 found in BCP 78 and BCP 79. 447 Copies of IPR disclosures made to the IETF Secretariat and any 448 assurances of licenses to be made available, or the result of an 449 attempt made to obtain a general license or permission for the use of 450 such proprietary rights by implementers or users of this 451 specification can be obtained from the IETF on-line IPR repository at 452 http://www.ietf.org/ipr. 454 The IETF invites any interested party to bring to its attention any 455 copyrights, patents or patent applications, or other proprietary 456 rights that may cover technology that may be required to implement 457 this standard. Please address the information to the IETF at 458 ietf-ipr@ietf.org. 460 Disclaimer of Validity 462 This document and the information contained herein are provided on an 463 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 464 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 465 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 466 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 467 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 468 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 470 Copyright Statement 472 Copyright (C) The Internet Society (2005). This document is subject 473 to the rights, licenses and restrictions contained in BCP 78, and 474 except as set forth therein, the authors retain all their rights. 476 Acknowledgment 478 Funding for the RFC Editor function is currently provided by the 479 Internet Society.