idnits 2.17.1 draft-ananth-tcpm-tcpoptext-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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 25, 2012) is 4386 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2616' is defined on line 575, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-12) exists of draft-ietf-mptcp-multiaddressed-07 -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6093 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCPM WG A. Ramaiah 3 Internet-Draft Cisco 4 Intended status: Informational March 25, 2012 5 Expires: September 26, 2012 7 TCP option space extension 8 draft-ananth-tcpm-tcpoptext-00.txt 10 Abstract 12 The document goals are as follows: Firstly, this document summarizes 13 the motivations for extending TCP option space. Secondly, It tries 14 to summarize the various known issues that needs to be taken into 15 account while extending the TCP option space. Thirdly, it briefly 16 provides a short summary of the various TCP option space proposals 17 that has been proposed so far. Some additional proposals which 18 includes variations to the existing proposals are also presented. 19 The goal of this document is to rejuvenate the discussions on this 20 topic and eventually to converge on a scheme for extending TCP option 21 space. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 26, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Common issues with TCP option extension . . . . . . . . . . . 5 61 4. TCP option space extension proposals . . . . . . . . . . . . . 7 62 4.1. TCP LO and SLO . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2. TCP DO field overload (Extended segments) . . . . . . . . 8 64 4.3. Increase (Double) TCP header size - TCPx2 . . . . . . . . 9 65 4.4. TCP LOIC . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 4.5. Multiple segments with continuation . . . . . . . . . . . 11 67 4.6. TCP option cookies . . . . . . . . . . . . . . . . . . . . 12 68 4.7. Reuse/overload of other TCP fields . . . . . . . . . . . . 12 69 4.8. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 12 70 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 1. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119] 85 Middlebox : the middlebox could be a proxy like PEP (performance 86 enhancing proxies), NAT device or a Firewall. Note : The term packet 87 and segment is used interchangeably in this document. 89 2. Introduction 91 TCP [RFC0793] as part of its header includes TCP options which 92 provides some special functionality that can be negotiated by both 93 ends of the TCP connection. As the name implies, these aren't 94 mandatory but must be supported by both ends in order to be active on 95 a given TCP connection. Some examples of deployed TCP options 96 include TCP MSS, Window Scale, Selective ACK, Timestamps ([RFC1323] 97 ). Many other TCP options have been proposed and have been in use in 98 different environments eg:- TCP-MD5 [RFC2385] is used to secure a BGP 99 session. The TCP option space limitation is imposed by the 4 bit 100 Data Offset (DO) field which restricts the total length of the TCP 101 header (including options) to 60 bytes ([RFC0793]). Since the 102 required fields of the TCP header consumes 20 bytes, this leaves 40 103 bytes as the maximum amount of space for use by TCP options. 105 2.1. Motivation 107 The TCP option space of 40 bytes which was considered reasonable for 108 the concurrent usage of some popular TCP options, is no longer able 109 to cater to needs of recent growing demands. Over the past few years 110 several new TCP options like TCP-UTO ([RFC5482]), TCP-AO ([RFC5925]), 111 experimental TCP options for acknowledgment congestion control 112 ([RFC5690]), have been proposed. MultiPath TCP 113 ([I-D.ietf-mptcp-multiaddressed]) is another feature which calls for 114 more TCP option space. Lastly middleboxes doing WAN optimization 115 functionality can also benefit with the increased TCP option space, 116 although it is not the intention of this memo to address such 117 requirements. It is mentioned here simply for the sake of 118 completeness. 120 Since it is not easy to extend TCP option space, TCP option space 121 hungry applications could move to a different protocol like SCTP 122 ([RFC4960]), which for instance provides 255 chunks (each SCTP chunk 123 is analogous to a TCP option) Needless to mention, this is not always 124 possible and moving to a new protocol, at the least not only has all 125 the issues that is exhibited by a new TCP option but even more (like 126 general protocol upgrade and support, etc.,) 128 It is therefore expedient to extend the TCP option space to meet the 129 near term requirements coming from the various TCP applications for 130 active internet deployment and research. 132 3. Common issues with TCP option extension 134 Typically any proposal trying to extend the TCP option space needs to 135 use some form of explicit signaling during the 3 way handshake of TCP 136 to negotiate the usage of TCP extended options. This is typically 137 accomplished by means of having a new TCP option or by using one of 138 the reserved bits of the TCP header. In the reminder of the text we 139 refer both of these methods simply as "TCP extended option(s)". The 140 following notes apply to either of these methods. 142 Any TCP option extension proposals needs to be aware of the following 143 design issues :- 145 End host backward compatibility - Any of the TCP option space 146 extension proposals needs to satisfy the following end-host 147 compatibility requirements :- 149 H1) Needs to have the capability to interoperate with stacks that 150 do not have ability to negotiate the TCP extended option space. 152 H2) If the TCP extended options could not be negotiated, then it 153 needs to fall back to normal mode of operation. 155 H3) It also needs to be noted that in some rare cases end-hosts 156 not understanding a TCP option simply echoes back the TCP 157 option in response. This is due to buggy implementation and 158 hence this is not a requirement at all. Just mentioned for the 159 sake of completeness. 161 Middle box interoperability - This is the toughest of the problems 162 in getting towards a cleaner solution for extending TCP option 163 space. It needs to be noted that middlebox interactions disrupt 164 the end-to-end flow characteristics and any solution is 165 susceptible to it's presence. TCP option space extension 166 proposals need to be aware of the following issues :- 168 M1) Some middleboxes terminate TCP connections (Performance 169 Enhancing Proxies) [RFC3135] 171 M2) Some middleboxes examine TCP payloads (Virus scanner, 172 firewall), some modify the TCP payloads (NAT ALG) 174 M3) In general middleboxes keep state which includes TCP sequence 175 numbers, some of them (proxies which do not terminate the TCP 176 connection) would adjust the sequence and acknowledgement 177 numbers on a per packet basis. 179 M4) Some middleboxes strip unknown TCP options. 181 M5) Some middleboxes resegment TCP data. 183 M6) Some middleboxes drop packets containing unknown TCP options. 185 Among the above M4, M5 and M6 are not common, M1, M2 & M3 exhibits 186 varying degrees of commonality. Cases M2 and to some extent M3 187 proves to be the toughest candidate to work with for seamless TCP 188 option extension. 190 Another point worthy of mention would be that, the outgoing path or 191 the return path may change between connections or even during a 192 connection, which can lead to traversal of different middleboxes. 193 This simply means that the same middlebox behavior cannot be 194 guaranteed for all the packets of a given TCP connection. 196 4. TCP option space extension proposals 198 The following section summarizes some of the existing TCP option 199 space proposals (section 4.1 to 4.4), touches upon some new ideas and 200 variations of the existing proposals (section 4.5 to 4.7), and 201 analyses each one of the proposal's strengths and weaknesses. It 202 needs to be emphasized that the new ideas (section 4.5 to 4.7) are by 203 no means a complete solution, but some general ideas which can be 204 used as building blocks or food for thought when trying to devise 205 solution for the TCP option space exhaustion issue. 207 4.1. TCP LO and SLO 209 This ID ([I-D.eddy-tcp-loo]) talks about the defining a new TCP 210 option that overrides the standard TCP DO field definition. This is 211 accomplished by means of a TCP Long Option (LO) which gets negotiated 212 during SYN. If both ends understand the LO option, then whenever the 213 LO option is present, the DO field of the standard TCP header would 214 be ignored for computing the TCP data offset. Instead the "Header 215 Length" specified in the LO option would be used to derive the Data 216 Offset. The LO option MUST be the first option present in the TCP 217 segment. The draft actually mandates the LO option to be present in 218 all segments, to circumvent odd bugs arising due to TCP segments with 219 different interpretations of DO with and without the presence of the 220 LO option. 222 The draft also defines a SYN Long Option (SLO). The purpose of this 223 option is to retain backward compatibility with hosts that do not 224 support the LO option. This is needed because a host which does not 225 understand the LO option would mistakenly treat anything past the DO- 226 specified boundary to be application data. The SLO option is used in 227 the case where 40 bytes (max option space in standard TCP) is not 228 enough to carry the desired TCP options to be sent on the SYN. It is 229 only used by devices issuing an active open, since the passive open 230 side can always use the LO option to send the long list of TCP 231 options. The left-off options are reliably delivered in the 232 subsequent data (and acknowledgment ) segments. 234 Discussion : 236 This proposal addresses the host backward compatibility well (H1 & 237 H2), since if the LO is not understood or stripped by a middlebox in 238 between it would simply proceed with standard TCP semantics. However 239 there is no provision for handling H3. This can be circumvented if 240 needed, but it not probably worth the effort since such hosts are 241 very uncommon in author's viewpoint. In the reminder of the 242 proposals H3's compatibility is not going to be discussed. 244 Coming to the middlebox case, if the middlebox strips the TCP option 245 (M4), it is fine, since this option would not be negotiated. If the 246 SYN gets dropped by a middlebox (M6), then retransmission request may 247 be tried without the long option. For the case of PEP's (M1) if the 248 connection gets terminated, then the middlebox which doesn't 249 understand the LO option would reply with SYN+ACK without LO and it 250 is fine since fallback to normal mode would happen. But this 251 proposal (like any other proposal) may have implications with 252 resegmenting (M5) feature of some middleboxes (which do not 253 understand the LO option) since the TCP options gets blindly copied 254 in all segmented segments by the middlebox. This would cause the 255 end-host understanding the LO option to get confused, since it would 256 interpret the duplicated segments as containing the TCP options. 258 The issue of option data getting confused as payload due the 259 middlebox segmenting the TCP data can be circumvented by either 260 having the total length of the TCP segment OR the TCP sequence number 261 which points to the beginning of the data (instead of the proposed 262 header length field which points to the Data Offset). It also needs 263 to be noted that it is strongly advisable for any TCP options that 264 could not fit into the standard TCP option space (40 bytes) begin 265 after the 40 bytes boundary since any middlebox that cannot 266 understand the LO option and does some TCP header fields sanity can 267 get confused and drop the segment, if the new option is not fully 268 contained in the TCP option space. 270 This proposal would have an issue with middleboxes that do not 271 understand the extension and tries operate on the TCP payload (M2). 272 For M3, it really depends on the middlebox, if the middlebox sees the 273 next sequence number as lesser than the one it expects, it would 274 simply treat that as a duplicate (good thing), however for some 275 middleboxes if it tries to cache segments and perform retransmissions 276 etc., it may be a problematic. 278 4.2. TCP DO field overload (Extended segments) 280 This proposal ([I-D.kohler-tcpm-extopt]) tries to solve the TCP 281 option space issue by redefining the TCP DO field. Extended segments 282 approach overloads the meaning of the standard TCP Data Offset field, 283 keeping its original meaning for values of 5 and greater, but 284 redefining it for values less than 5. This is seen as acceptable 285 since values less than 5 are currently impossible, illegal, and 286 unusable. Extended segments avoid the need for new options by 287 changing the way that the existing standard header is parsed. 289 The granularity of option lengths that extended segments can support 290 is limited to the number of unusable Data Offset values (5, 0 through 291 4). Currently, the extended segments proposal defines 4 fixed 292 lengths, and one "infinite" length that means the entire segment is 293 options, with no application data. The fixed option lengths are 48, 294 64, 128, and 256 bytes. 296 Discussion : 298 If the required per-data-segment TCP options space for some extension 299 or combination of extensions does not map to exactly one of the 300 extended DO values, then padding bytes are required. If 129 bytes of 301 options are required on a data segment, then a length of 256 must be 302 used, and 127 bytes of useless padding are added. 304 As far as the end host compatibilty goes, if the end host doesn't 305 understand the extended SYN (i.e. a SYN with DO < 5), the SYN would 306 get dropped which is the typical behavior. Instead if some 307 implementations who chose to send RST due to malformed segment (TCP 308 header validation failure) is problematic since the end host would 309 get confused whether the RST is due to its original intention (i.e. 310 listener not present on the server or some other known thing like 311 policy restrictions). The draft also mentions that extended SYN-ACKs 312 may be sent in response to non-extended SYNs. This complicates the 313 recovery procedure even more, if not understood, and goes against the 314 way that all current negotiable TCP extensions operate (only used on 315 SYN-ACK if advertised on SYN). Hence we can see that the fallback 316 (cases H1 and H2) is not smooth when compared to the LO proposal. 318 As the middlebox goes, it suffers the same set of issues as the LO 319 proposal. But there is no provision that can be made for the case of 320 re-segmentation by middleboxes (M5). So, extended segments approach 321 seems to be inferior compared to LO proposal in terms of robustness. 323 4.3. Increase (Double) TCP header size - TCPx2 325 This proposal([I-D.allman-tcpx2-hack]) was aimed to not just address 326 the TCP option space exhaustion but to address other myriad of issues 327 surrounding the TCP header fields. (like window size, reserved bits 328 etc.,) TCPx2 requires a new IP protocol number. It defines a new TCP 329 header which has all the original field sizes doubled. Hence the TCP 330 DO field becomes 8 bits instead of the original 4 bits. 332 Discussion : 334 Ideally this proposal seems to be the best long term solution for TCP 335 issues caused due the limits imposed by the various fields of TCP 336 header, which includes the TCP option space issue. However, for 337 short, medium or immediate term deployment it is not practical. 338 TCPx2 would face the same resistance (even worse since it is a new 339 entrant) from middleboxes as experienced by some "newer" protocols 340 like SCTP etc., which hampered their successful adoption and 341 deployment. End hosts TCP/IP stacks need to change to support the 342 new IP protocol number, demux logic and new TCP header. The standard 343 algorithms like TCP checksum, TCP MAC computation etc., needs to 344 change, especially makes it difficult in cases where this 345 functionality is assisted by hardware. The sockets API or TCP API's 346 would have to change to accommodate the TCP header changes (src and 347 dest ports) and also to offer backward compatibility to existing TCP. 348 All the diagnostic tools surrounding etc., needs to change, the list 349 only continues. 351 4.4. TCP LOIC 353 The crux of this proposal ([I-D.yourtchenko-tcp-loic]) is to quickly 354 negotiate the LO (referred as LOIC in the document) option by sending 355 it in SYN segment and also fallback to normal mode if the remote end 356 or the middlebox drops the SYN. This is accomplished by sending 2 357 SYN's, one with the intent of negotiating the LO option and other one 358 which contains the all the options that needs to be negotiated 359 (includes the ones that cannot fit in the standard option space). To 360 prevent the TCP option space mistakenly read as data, the proposal 361 deliberately increments the checksum by 2 in the second SYN segment 362 (which contains the TCP options). If the end host (or middlebox) 363 doesn't understand the signalling (checksum + 2), it would drop the 364 segment and the first SYN would get replied with SYN+ACK without LO. 365 OTOH, if the stack understands the method, it would be able to 366 process the both the SYNs (all the TCP options) and reply back with 367 LO. 369 Discussion 371 This proposal cleverly avoids doing the option exchange dance after 372 the SYN segment gets ACKnowledged like seen in LO proposal (section 373 4.1) by sending duplicate SYN's. This proposal addresses the host 374 backward compatibility well (H1 & H2). However it has some issues. 375 The overloading of checksum can have other implications esp., with 376 some middeboxes that modify the checksum (NAT) which can rollover the 377 16 bit field and the checksum decrement would fail to work. 378 Overloading checksum would not bode well with diagnostic tools 379 (sniffers etc.,) and also in cases where checksum gets offloaded to 380 some hardware which needs to understand this method. 382 M1, M4, M6 are taken care of well by this proposal. It suffers the 383 same fate as other proposals as far as M5 is concerned. It exhibits 384 the same behavior as far as M2 and M3 goes, since the proposal sends 385 TCP options as part of the standard TCP header. 387 One other note worthy of mentioning would be, this proposal is in 388 some sense similar to the concept of "extended segments". Extended 389 segments approach tries to overload (use the illegal unused values) 390 the DO field. One could argue that instead of mucking around with 391 the checksum you could actually send the second SYN with "incorrect" 392 ( DO < 5) value. However if we throw in the middlebox into the 393 equation, the likelihood of a packet getting dropped by the middlebox 394 (firewall which does some TCP header validation) with DO field 395 incorrectly specified is more when compared to packet with incorrect 396 checksum. (This is because typically firewalls don't try to do 397 compute intensive operations like TCP checksum validation) 399 4.5. Multiple segments with continuation 401 Both, extended segments and LOIC (section 4.2 and section 4.4) 402 already mentions about sending multiple SYNs. This idea also uses 403 the same approach with a key difference, i.e. send multiple SYNs with 404 a "TCP continuation option". The TCP continuation option's purpose 405 (which is a simple option-kind option) is to convey to the other end 406 that "not all TCP options could be fit into to the current TCP 407 segment's standard option space (40 bytes) and subsequent segments 408 would convey the reminder of the option". For example lets us say we 409 have 100 bytes of TCP option, this would require 3 segments to 410 convey, the first 2 of which would have the TCP continuation option 411 set. The rationale for this kind of thinking is twofold. Firstly, 412 keeping in mind short term goals, TCP option space requirement isn't 413 very large, hence a few segments should do the task at hand. 414 Secondly, middleboxes (and end hosts) gets confused if you send 415 something in the data portion, hence don't take chance of putting 416 anything in the data portion of TCP. 418 The obvious drawback of this scheme is that if there a way too many 419 TCP options to be conveyed, then it would take more segments to 420 convey all of them. For SYN segments, send multiple SYNs, for Data 421 segments (during the middle of connection) try to send multiple data 422 segments (behave as though nagle is turned off) and piggyback TCP 423 options with TCP continuation. Well, this may sound outrageous but 424 it should at least get rid of the middlebox issue at the cost of 425 adding more processing and delay. Pick the devil. 427 Sending duplicate segments is generally ok and should not have 428 adverse middlebox effects. Sending old segments (ones that are 429 already ACKed is another school of thought. This is how keepalives 430 work where the sequence number is set to TCB.SNDUNA - 1, which 431 solicits a corrective ACK from the other end. Sending old data 432 segment, simply gets dropped and one could use that to convey TCP 433 options, but that may get clumsier since you really need TCP options 434 to be inline with the current data. Just mentioned here for the sake 435 of completeness. 437 4.6. TCP option cookies 439 This is yet another interesting thought (at least in author's 440 opinion). The idea is to pack TCP options in a similar way TCP SYN 441 cookies did. i.e., instead of doing the "Option-Kind" OR "option- 442 kind-value", we could just have bit masks OR some encoding scheme 443 defined under a TCP option template. We can call it as a "TCP 444 template or TCP Master option". At least during the initial 445 negotiation this would be helpful to scavenge TCP option space. The 446 details of this need to be thought of and extensibility also needs to 447 be addressed. Compressing TCP options is another school of thought 448 along the similar lines, but the compression overhead needs space as 449 well, hence needs to be carefully thought about. 451 4.7. Reuse/overload of other TCP fields 453 Some of the schemes already tried to overload some TCP fields like 454 TCP DO (section 4.2) and TCP checksum overload (section 4.4). 455 Another tempting field to overload is the TCP urgent pointer. It 456 needs to be noted that the TCP urgent pointer is valid only when the 457 URG bit is set. Also the TCP urgent pointer is used only by some 458 legacy applications like Telnet and rlogin, both of which don't use 459 any advanced TCP options nor require such a functionality. Also 460 ([RFC6093]), suggests deprecating its usage for newer applications. 461 It mentions that due to inconsistent interpretation of the urgent 462 pointer by end hosts and some middleboxes which clear the urgent flag 463 and urgent pointer, the urgent mechanism should be deprecated. But, 464 in authors opinion, the middleboxes that clear the urgent pointer 465 only for some given ports like telnet and FTP. Given all these 466 facts, it is not unreasonable to try to put this field to some good 467 use. The urgent pointer could be used to redefine the TCP DO field 468 in the same way the TCP DO redefinition scheme did but with a 16 bits 469 of precision as opposed to just 3 (values < 5). The hope is that 470 middleboxes (firewalls) would simply ignore the urgent pointer value 471 since the URG bit is not set. We could also use the Urgent pointer 472 for a fallback mechanism like the TCP checksum (LOIC) proposal did. 474 4.8. Miscellaneous 476 The previous sections have been trying to do a best possible effort 477 in identifying some candidates for scavenging TCP option space, some 478 ways of getting around the middleboxes etc., One school of thought 479 would be, it is sometimes ok to convey TCP options across multiple 480 segments (the TCP continuation option touched upon this aspect). for 481 example let's say there are 5 SACK blocks, they can't be conveyed 482 using a single TCP segment, this takes multiple TCP segments which is 483 ok (the way it is working today). It may be possible to do this for 484 other TCP options as well, which need not be conveyed on every packet 485 like the TCP security option. For e.g., TCP timestamps need to be 486 conveyed on every segment, but care needs to be taken not to break 487 PAWS etc., 489 5. Conclusion 491 If we get this far in the document, the obvious question would be "is 492 there a winner?" clearly not since any method has some issue or the 493 other and most of them are vulnerable to the middlebox processing of 494 packets (in particular cases M2 and M3 are tough to circumvent with). 495 But, there are different types of middleboxes and it really needs to 496 be seen what percentage of them exists in different environments. 497 There was a recent interesting study [IMC2011], which focused on the 498 issues of extending TCP which includes the analysis of various 499 middlebox behaviors. This could be used as a reference point for any 500 new proposals on extending TCP which includes the TCP option space 501 extension proposals. 503 This document listed a plethora of solutions (some of which may be 504 half-baked) to address some common middlebox problems and graceful 505 fallback to regular TCP methods. Now, no solution is a perfect 506 solution and it is impossible to work around all the use cases 507 imposed by middleboxes. Moving to a new protocol also is not a 508 solution, hence we are left with no choice but to extend TCP that 509 works for most of the use cases. Lastly, but not the least, the hope 510 of this document is that it serves as a foundational document that 511 touches upon the various aspects of extending TCP option space and 512 acts as a motivational document to converge to a possible solution 513 for the TCP option space exhaustion issue. 515 6. IANA Considerations 517 None. 519 7. Security Considerations 521 None at this time. 523 8. Acknowledgements 525 Thanks to Dan Wing and Andrew Yourtchenko for the initial review of 526 the draft. 528 9. References 530 9.1. Normative References 532 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 533 RFC 793, September 1981. 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, March 1997. 538 9.2. Informative References 540 [I-D.allman-tcpx2-hack] 541 Allman, M., "TCPx2: Don't Fence Me In", 542 draft-allman-tcpx2-hack-00 (work in progress), May 2006. 544 [I-D.eddy-tcp-loo] 545 Eddy, W. and A. Langley, "Extending the Space Available 546 for TCP Options", draft-eddy-tcp-loo-04 (work in 547 progress), July 2008. 549 [I-D.ietf-mptcp-multiaddressed] 550 Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 551 "TCP Extensions for Multipath Operation with Multiple 552 Addresses", draft-ietf-mptcp-multiaddressed-07 (work in 553 progress), March 2012. 555 [I-D.kohler-tcpm-extopt] 556 Kohler, E., "Extended Option Space for TCP", 557 draft-kohler-tcpm-extopt-00 (work in progress), 558 September 2004. 560 [I-D.yourtchenko-tcp-loic] 561 Yourtchenko, A., "Introducing TCP Long Options by Invalid 562 Checksum", draft-yourtchenko-tcp-loic-00 (work in 563 progress), April 2011. 565 [IMC2011] Honda et. al, M., "Internet Measurement conference 2011. 566 http://conferences.sigcomm.org/imc/2011/docs/p181.pdf", 567 November 2011. 569 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 570 for High Performance", RFC 1323, May 1992. 572 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 573 Signature Option", RFC 2385, August 1998. 575 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 576 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 577 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 579 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 580 Shelby, "Performance Enhancing Proxies Intended to 581 Mitigate Link-Related Degradations", RFC 3135, June 2001. 583 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 584 RFC 4960, September 2007. 586 [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", 587 RFC 5482, March 2009. 589 [RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding 590 Acknowledgement Congestion Control to TCP", RFC 5690, 591 February 2010. 593 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 594 Authentication Option", RFC 5925, June 2010. 596 [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the 597 TCP Urgent Mechanism", RFC 6093, January 2011. 599 Author's Address 601 Anantha Ramaiah 602 Cisco 603 170 Tasman Drive 604 San Jose, CA 95134 605 USA 607 Phone: +1 (408) 525-6486 608 Email: ananth@cisco.com