idnits 2.17.1 draft-touch-tcpm-tcp-syn-ext-opt-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 18, 2016) is 2901 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcp-edo-04 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TCPM WG J. Touch 2 Internet Draft T. Faber 3 Intended status: Experimental USC/ISI 4 Expires: October 2016 April 18, 2016 6 TCP SYN Extended Option Space Using an Out-of-Band Segment 7 draft-touch-tcpm-tcp-syn-ext-opt-04.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on April 18, 2015. 32 Copyright Notice 34 Copyright (c) 2016 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. 44 Abstract 46 This document describes an experimental method to extend the option 47 space for connection parameters within the initial TCP SYN segment, 48 at the start of a TCP connection. This method effectively extends 49 the option space of an initial SYN by using an additional coupled 50 segment that is sent 'out-of-band'. It complements the proposed 51 Extended Data Offset (EDO) option that is applicable only after the 52 initial segment. 54 Table of Contents 56 1. Introduction...................................................2 57 2. Conventions used in this document..............................3 58 3. Experiment Goals...............................................3 59 4. Using Multiple Segments to Establish a Connection..............4 60 5. The TCP SYN-EOS Option.........................................5 61 5.1. Reliable Delivery of Lone Initial Segments................7 62 5.2. Reliable Delivery of a Lone SYN with SYN-EOS..............7 63 5.3. Interaction with EDO......................................8 64 6. Issues.........................................................9 65 6.1. General Issues............................................9 66 6.2. Option processing order...................................9 67 6.3. Middlebox Transit Issues.................................10 68 6.4. Interaction with Other TCP Options.......................11 69 6.5. TCP Fast Open............................................11 70 6.5.1. TCP Authentication Option and TCP MD5...............11 71 7. TCP SYN-EOS Interaction with TCP..............................11 72 7.1. TCP User Interface.......................................11 73 7.2. TCP States and Transitions...............................11 74 7.3. TCP Segment Processing...................................11 75 7.4. Impact on TCP Header Size................................11 76 8. Error Conditions..............................................12 77 8.1. Connectionless Resets....................................12 78 8.2. ICMP Handling............................................12 79 9. Security Considerations.......................................12 80 10. IANA Considerations..........................................12 81 11. References...................................................12 82 11.1. Normative References....................................12 83 11.2. Informative References..................................12 84 12. Acknowledgments..............................................13 86 1. Introduction 88 This document describes a method to extend the option space 89 available in the initial SYN segment of a TCP connection (e.g., SYN 90 set and ACK not set) [RFC793]. This extension is required to support 91 some combinations of TCP options, notably large ones such as TCP AO 92 [RFC5925], Multipath TCP [RFC6824], and TCP Fast Open [RFC7413] with 93 other options already typically used in most TCP connections. This 94 document specifies this TCP SYN extended option space (SYN-EOS) 95 option, and is independent of (and thus compatible with) IPv4 and 96 IPv6. SYN-EOS complements the proposed TCP Extended Data Offset 97 (EDO) option, which increases the space available for options in all 98 segments except the initial SYN [To15]. 100 2. Conventions used in this document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC-2119 [RFC2119]. 106 In this document, these words will appear with that interpretation 107 only when in ALL CAPS. Lower case uses of these words are not to be 108 interpreted as carrying RFC-2119 significance. 110 In this document, the characters ">>" preceding an indented line(s) 111 indicates a compliance requirement statement using the key words 112 listed above. This convention aids reviewers in quickly identifying 113 or finding the explicit compliance requirements of this RFC. 115 3. Experiment Goals 117 TCP is critical to the robust functioning of the Internet, therefore 118 any proposed modifications to TCP need to be thoroughly tested. The 119 present specification describes an experimental protocol that 120 initiates a connection using two coupled segments instead of the 121 traditional single one. The intention is to specify the protocol 122 sufficiently so that more than one implementation can be built in 123 order to test its function, robustness, and interoperability with 124 itself, with other variants of TCP and with common network 125 equipment, whether standardized or not. 127 The following describe the criteria that define success for this 128 experiment and its expected duration. 130 Success criteria: The experimental protocol will be considered 131 successful if, in the consensus opinion of the IETF, it functions 132 correctly in a sufficiently wide scope to be useful and it does no 133 harm, which implies that it ought to introduce minimal additional 134 delay or load to either updated or existing implementations and it 135 introduces no new security vulnerabilities. It is also required not 136 to be unduly difficult or complex to implement correctly, so that it 137 is not likely to lead to additional bugs or vulnerabilities. 139 Duration: To be credible, the experiment will need to last at least 140 12 months from publication of the present specification. At that 141 time, a report on the experiment will be written up. If successful, 142 it would then be appropriate to work on a standards track 143 specification. 145 4. Using Multiple Segments to Establish a Connection 147 The basis of SYN-EOS is the use of multiple TCP segments to initiate 148 a TCP connection. It is also possible to extend initial SYN option 149 space using context established from prior connections or using 150 separate TCP connections (e.g., using the FTP control channel), this 151 document focuses on a mechanisms that applies to any connection 152 (including the first between two hosts) and do not require prior or 153 established concurrent TCP connections. 155 There are four examples of such approaches: 157 o Send a primary SYN and an extension SYN (LOIC [Yo11]) 159 o Send a primary SYN and extension non-SYN data (LO/SLO [Ed08]) 161 o Send two separate SYNs: a legacy SYN and an upgraded SYN on 162 separate port pairs (dual-stack, named "Sister-SYN" [Br14]) 164 o Send a primary SYN and an extension out-of-band segment (OOB, 165 this document) 167 All four approaches extend the space available in the initial SYN by 168 sending an additional segment during the first phase of the three- 169 way handshake. The Long Options by Invalid Checksum (LOIC) approach 170 differentiates the two SYNs by using an invalid TCP checksum in the 171 extension SYN [Yo11], which thus cannot traverse NAT/NAPT devices 172 [RFC3234]. 174 The LO/SLO approach extends the three-way handshake into a five-way 175 handshake to include extra options during the third segment, so the 176 traditional SYN/ACK does not complete the active connection [Ed08]. 177 In current implementations, the client TCP state machine transitions 178 to the ESTABLISHED state upon receipt of the SYN/ACK (including 179 transmission of the resulting ACK). In SLO, additional options sent 180 during the third segment are treated as part of the initial SYN and 181 the fourth segment with responses to these options is treated as 182 part of the conventional SYN/ACK. As with conventional TCP, data can 183 be sent during this handshake as part of any segment, but this data 184 needs to wait for the entire handshake to complete before being 185 forwarded to the application to ensure that all options have been 186 negotiated successfully. This adds an additional round trip of 187 latency which is undesirable in many cases. Connection-splitting 188 middleboxes that merge these segments might also cause long options 189 to be interpreted as data. 191 The Sister-SYN approach is a dual-stack mechanism. Both legacy 192 servers and upgraded servers process both SYNs; clients terminate 193 the appropriate pending connection based on whether the option is 194 acknowledged for each connection. 196 The remainder of this document presents the SYN-EOS approach, which 197 overcomes these limitations using an out-of-band segment to extend 198 the option space of the SYN. 200 5. The TCP SYN-EOS Option 202 The SYN-EOS approach uses a primary conventional SYN and an 203 additional out-of-band data segment, the latter being a non-SYN 204 packet with the ACK flag not set. Additional options are placed in 205 payload of an out-of-band (OOB) segment, i.e., a segment whose ACK 206 bit is cleared but is not a SYN (i.e., both SYN and ACK are zero). 207 This offers the following advantages: 209 1. It provide expansion space for options on a SYN, limited only by 210 the default maximum segment size (535 payload bytes for IPv4); 212 2. It reduces the chances that middleboxes will alter the extra 213 options, given there is a higher bar to altering the payload than 214 header fields. 216 3. It allows for future structured ways to hide extra options from 217 middleboxes and/or to protect them from being altered. 219 A client initiating a TCP connection (i.e., issuing an active open) 220 uses the SYN-EOS option flag to indicate the presence of the 221 extended option space (Figure 1). This follows the TCP option 222 format, where Kind is SYN-EOS-OPT and Length is 2. 224 +--------+--------+ 225 | Kind | Length | 226 +--------+--------+ 228 Figure 1 TCP SYN-EOS OOB option 230 An upgraded client supporting this feature uses this option only 231 when the space needed for options in the initial SYN exceeds that of 232 legacy TCP. When needed, the client sends the SYN-EOS option in the 233 initial SYN, together with whatever other options are intended for 234 connections to legacy servers (i.e., passive listeners). A legacy 235 server would respond with a SYN/ACK without the SYN-EOS option, 236 while also confirming other supported options, and the connection 237 would proceed without the SYN-EOS extension. 239 The upgraded client that sends the initial SYN using this option 240 also sends an out-of-band (OOB) data segment with the same option to 241 the same source and destination addresses and ports as the initial 242 SYN. An OOB data segment is herein defined as a TCP segment in which 243 neither SYN nor ACK flag is set. In particular, this looks like a 244 conventional data segment with the ACK field cleared. Current TCP 245 requirements allow the ACK field to be cleared for only the initial 246 SYN, so this segment looks like a data segment that has been 247 transmitted 'out-of-band', before a connection has been established. 248 The entire payload of the segment is used for additional options. 250 Upgraded servers that receive the TCP SYN with the SYN-EOS option 251 wait for the corresponding OOB segment and treat the entire set of 252 options in both segments as if they arrived with the initial SYN. 253 Once both have arrived, the server first processes TCP options 254 placed before each SYN-EOS option, applying them solely to their own 255 individual segment. Then the server marshals together all the TCP 256 options placed after each SYN-EOS option. It applies them to the 257 initial SYN only, as if they had all been concatenated after the 258 SYN-EOS OOB option. 260 >> The server MUST process the options placed after each SYN-EOS 261 option in the following order: 263 1. Those in the option space of the initial SYN 265 2. Those in the option space of the OOB segment 267 3. Those in the payload space of the OOB segment 269 The upgraded server proceeds with the remainder of the connection as 270 if the SYN-EOS OOB option were a also EDO request option [To15] in 271 the SYN. 273 >> The SYN/ACK MUST include the SYN-EOS option to confirm the 274 server's support for both the SUN-EOS and EDO capabilities and to 275 confirm receipt of both the SYN and OOB segment. The server MAY also 276 extend the options space of the SYN/ACK using the EDO option if 277 needed. 279 >> Any host that supports SYN-EOS MUST also thus support EDO. 281 >> The OOB segment MUST use the same sequence number as the initial 282 SYN. 284 >> The client MUST NOT send multiple different OOB segments. If the 285 server receives more than one OOB segment for the same connection it 286 MUST solely use the first. 288 5.1. Reliable Delivery of Lone Initial Segments 290 The server acknowledges the initial segment and the OOB segment 291 together by using a SYN/ACK that carries the appropriate SYN-EOS 292 option. The following subsections describe how the server 293 acknowledges initial segments after a certain time if only one has 294 arrived. 296 5.2. Reliable Delivery of a Lone SYN with SYN-EOS 298 If an upgraded server has received only a SYN with the SYN-EOS 299 option but no corresponding OOB segment, after a certain time it 300 MUST proceed with the connection as if the SYN had been received 301 without the SYN-EOS option. I.e. it processes all other TCP options 302 and responds with a SYN/ACK without the SYN-EOS option. 304 A client will not be able to tell whether this SYN/ACK is from a 305 legacy server or an upgraded server. How the client proceeds on 306 receipt of such a SYN/ACK depends on whether it wishes to retry 307 sending the TCP options in the OOB segment or to proceed without 308 them (e.g. for latency reasons): 310 >> If the client chooses to proceed without the OOB segment, it MUST 311 proceed as if the SYN-EOS option had never been used, by sending an 312 ACK to complete the three-way handshake. 314 >> If the client chooses to retry, it MUST retransmit the OOB 315 segment with the same sequence number as the ISN of the SYN, so it 316 is still out-of-band. However, this time it sets the ACK flag and it 317 sets the acknowledgement number to one greater than the sequence 318 number of the SYN/ACK. This effectively acknowledges receipt of the 319 SYN/ACK, but requests a fuller SYN/ACK that also covers the OOB 320 segment. At this stage a client that has chosen to retry the OOB 321 segment MUST NOT send the ACK that would normally complete the 322 three-way handshake. 324 >> If an upgraded server receives such a retransmitted OOB segment, 325 it MUST process the additional TCP options as if they were placed 326 after those in the initial SYN. Then it MUST send a SYN/ACK 327 containing the SYN-EOS option, as if it had not sent the earlier 328 SYN/ACK . 330 On receipt of this SYN/ACK, the client sends an ACK to complete the 331 handshake. 333 >> If an upgraded server receives an ACK to complete the handshake, 334 then later receives an OOB segment, it MUST discard the late OOB 335 segment. 337 >> If a server, whether upgraded or not, receives only an OOB 338 segment and no corresponding SYN, it MUST discard it and it MUST NOT 339 ever respond (see Security Considerations). 341 5.3. Interaction with EDO 343 Successful negotiation of either SYN-EOS option has the same effect 344 as EDO. Successful SYN-EOS negotiation enables EDO for the remainder 345 of the connection. 347 >> After successful SYN-EOS negotiation, segments after the initial 348 SYN MAY use the EDO option. 350 Note that a failure to negotiate SYN-EOS has also fails to 351 automatically negotiate EDO for endpoints that support EDO but not 352 SYN-EOS. As a consequence: 354 >> If EDO is desired when SYN-EOS fails, the initial SYN options 355 MUST include a separate EDO Supported option. 357 If SYN-EOS is sent in the initial SYN and confirmed in the SYN/ACK, 358 EDO is available for the remainder of the connection. Segments that 359 need to extend their option space would then include EDO. 361 >> If SYN-EOS and EDO Supported are sent in the initial SYN and 362 received by SYN-EOS capable server, the server MUST include SYN-EOS 363 in the SYN/ACK, and MAY also include EDO Extension if needed to 364 provide additional option space. 366 >> If the server agrees to EDO but cannot support SYN-EOS, the 367 SYN/ACK MUST include EDO Supported as per [To15] to confirm the 368 capability. 370 6. Issues 372 The following issues are known. 374 6.1. General Issues 376 Caching is required because it is unlikely that both segments 377 involved in initiating a SYN-EOS connection will arrive at the same 378 time: 380 >> Servers supporting SYN-EOS SHOULD cache received initial SYNs 381 with the SYN-EOS option. Servers MAY decline to cache received 382 initial SYNs if they are under memory constraints. 384 >> Servers supporting SYN-EOS SHOULD cache received SYN-C segments 385 with the SYN-EOS option. Servers MAY cache received OOB segments but 386 MUST NOT examine or process them further in any way until their 387 corresponding SYN segment arrives. 389 Similarly, clients need to be able to retransmit supplements to 390 ensure their delivery: 392 >> Clients MUST retransmit the supplemental segment any time they 393 retransmit the initial SYN segment. 395 Should this be a new option or just a variant of EDO, and if so, how 396 would it change EDO? 398 SYN Cookies: An updated server can achieve the same outcome as SYN 399 cookies by putting all the necessary connection state in TCP options 400 in the SYN/ACK (using EDO if extra space is needed). It would then 401 discard its own copy of this state, which it could recover from the 402 TCP options in the final ACK of the 3WHS sent by the client. New TCP 403 options complementary to SYN-EOS might need to be defined to achieve 404 this for some types of TCP option (TBA). A legacy server will not 405 understand the SYN-EOS option whether it uses SYN cookies or not, so 406 it will provide the same legacy service whether or not it uses SYN 407 cookies. 409 Useful to send SYN, wait shortly, then send OOB 411 OOB traversal concerns 413 6.2. Option processing order 415 TCP options before the EOS-SYN on initial SYN segments are 416 necessarily processed individually when each segment arrives. When 417 both segments of an EOS-SYN connection establishment arrive, the 418 remaining options are processed in the following sequence: 420 1. Initial SYN options 422 2. Supplement options 424 3. Supplement payload 426 *** NOTE TO THE WG: 428 There are two other constraints that might be applied to the 429 supplement options: 431 >> I. Supplement options MUST exactly match initial SYN options. 433 >> II. Supplement options MUST contain only the SYN-EOS option. 435 If either of these is chosen, the supplement options are NOT 436 processed again (i.e., they are discarded). 438 The former constraint helps the supplement segment share the same 439 fate as the initial SYN. The latter recognizes that the supplement 440 option space is not needed given the supplement payload, because the 441 option space is created from the payload space anyway. 443 *** END NOTE 445 6.3. Middlebox Transit Issues 447 NB: this variant will require an additional 1-byte field on the SYN- 448 EOS option for the EOO field. 450 Traversal of middleboxes that ensure the payload matches the 451 destination port number. It would be possible to include the 452 facility for SYN-EOS to include an Extra Option Offset (EOO) field. 453 A client setting EOO to a non-zero value would offset the start of 454 the additional TCP options by this number of 4-byte words from the 455 start of the payload. 457 >> An upgraded SYN-EOS server MUST start reading the additional TCP 458 options from a point within the payload that is offset by this 459 number of 4-byte words from the start of the payload. An upgraded 460 SYN-EOS server MUST ignore all data in the payload up to this point. 462 The client would then be free to include fake data at the start of 463 the payload consistent with what a middlebox might expect for the 464 destination port in use. The data to use would be application and 465 implementation dependent, and is not determined in the present 466 specification. 468 Interaction with TCP Fast Open 470 6.4. Interaction with Other TCP Options 472 6.5. TCP Fast Open 474 TBD. 476 Notes: SYN-EOS appears to be safe with TFO. Dual-SYN variants appear 477 to have potential problems with both upgraded and legacy servers. 478 With upgraded servers, receipt of a legacy SYN with the SYN 479 extension option flag present might require delayed response. With 480 legacy servers, it may be impossible to safely use TFO with the 481 extended SYN. 483 6.5.1. TCP Authentication Option and TCP MD5 485 TBD. 487 Notes: Likely to be similar to TCP EDO, i.e., requiring 488 authentication processing before extension processing. 490 7. TCP SYN-EOS Interaction with TCP 492 The following subsections describe how SYN-EOS interacts with the 493 TCP specification [RFC793]. 495 7.1. TCP User Interface 497 TBD. 499 7.2. TCP States and Transitions 501 TBD. 503 7.3. TCP Segment Processing 505 TBD. 507 7.4. Impact on TCP Header Size 509 TBD. 511 8. Error Conditions 513 8.1. Connectionless Resets 515 TBD. 517 8.2. ICMP Handling 519 TBD [RFC792]. 521 9. Security Considerations 523 >> By default, a SYN-EOS server must not cache an OOB segment and 524 MUST NOT respond to an OOB segment if it arrives before the 525 corresponding SYN segment, because many legacy firewalls will allow 526 OOB segments into private networks. Caching of OOB segments MAY be 527 enabled explicitly on public servers. 529 More TBD. 531 10. IANA Considerations 533 TBD. 535 This section is to be removed prior to publication as an RFC. 537 11. References 539 11.1. Normative References 541 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 542 793, September 1981. 544 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 545 Requirement Levels", BCP 14, RFC 2119, March 1997. 547 [To15] Touch, J., W. Eddy, "TCP Extended Data Offset Option", 548 draft-ietf-tcpm-tcp-edo-04 (work in progress), Nov. 2015. 550 11.2. Informative References 552 [Br14] Briscoe, B., "Inner Space for TCP Options", draft-briscoe- 553 tcpm-inner-space-01 (work in progress), October 2014. 555 [Ed08] Eddy, W. and A. Langley, "Extending the Space Available 556 for TCP Options", draft-eddy-tcp-loo-04 (work in 557 progress), July 2008. 559 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. 561 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 562 Issues", RFC 3234, February 2002. 564 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 565 Authentication Option", RFC 5925, June 2010. 567 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 568 "TCP Extensions for Multipath Operation with Multiple 569 Addresses", RFC 6824, January 2013. 571 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 572 Fast Open", RFC 7413, December 2014. 574 [Yo11] Yourtchenko, A., "Introducing TCP Long Options by Invalid 575 Checksum", draft-yourtchenko-tcp-loic-00 (work in 576 progress), April 2011. 578 12. Acknowledgments 580 The authors would like to thank the IETF TCPM WG for their feedback. 582 The use of multiple segments to extend the option space of a SYN was 583 initially proposed by Bob Briscoe. His initial proposal used 584 complementary SYNs in an earlier version of this document, which 585 evolved into mutually-exclusive "Sister-SYNs" in [Br14]. 587 This document was prepared using 2-Word-v2.0.template.dot. 589 Authors' Addresses 591 Joe Touch 592 USC/ISI 593 4676 Admiralty Way 594 Marina del Rey, CA 90292-6695 USA 596 Phone: +1 (310) 448-9151 597 Email: touch@isi.edu 598 URI: http://www.isi.edu/touch 599 Ted Faber 600 USC/ISI 601 4676 Admiralty Way 602 Marina del Rey, CA 90292-6695 USA 604 Phone: +1 (310) 448-9190 605 Email: faber@isi.edu