idnits 2.17.1 draft-touch-tcpm-tcp-syn-ext-opt-08.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 (January 19, 2018) is 2281 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TCPM WG J. Touch 2 Internet Draft 3 Intended status: Experimental T. Faber 4 Expires: July 2018 The Aerospace Corporation 5 January 19, 2018 7 TCP SYN Extended Option Space Using an Out-of-Band Segment 8 draft-touch-tcpm-tcp-syn-ext-opt-08.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 July 19, 2018. 33 Copyright Notice 35 Copyright (c) 2018 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 This document describes an experimental method to extend the option 48 space for connection parameters within the initial TCP SYN segment, 49 at the start of a TCP connection. This method effectively extends 50 the option space of an initial SYN by using an additional coupled 51 segment that is sent 'out-of-band'. It complements the proposed 52 Extended Data Offset (EDO) option that is applicable only after the 53 initial segment. 55 Table of Contents 57 1. Introduction...................................................2 58 2. Conventions used in this document..............................3 59 3. Experiment Goals...............................................3 60 4. Using Multiple Segments to Establish a Connection..............4 61 5. The TCP SYN-EOS Option.........................................5 62 5.1. Reliable Delivery of Lone Initial Segments................7 63 5.2. Reliable Delivery of a Lone SYN with SYN-EOS..............7 64 5.3. Interaction with EDO......................................8 65 6. Issues.........................................................9 66 6.1. General Issues............................................9 67 6.2. Option processing order...................................9 68 6.3. Middlebox Transit Issues.................................10 69 6.4. Interaction with Other TCP Options.......................11 70 6.5. TCP Fast Open............................................11 71 6.5.1. TCP Authentication Option and TCP MD5...............11 72 7. TCP SYN-EOS Interaction with TCP..............................11 73 7.1. TCP User Interface.......................................11 74 7.2. TCP States and Transitions...............................11 75 7.3. TCP Segment Processing...................................11 76 7.4. Impact on TCP Header Size................................11 77 8. Error Conditions..............................................12 78 8.1. Connectionless Resets....................................12 79 8.2. ICMP Handling............................................12 80 9. Security Considerations.......................................12 81 10. IANA Considerations..........................................12 82 11. References...................................................12 83 11.1. Normative References....................................12 84 11.2. Informative References..................................12 85 12. Acknowledgments..............................................13 87 1. Introduction 89 This document describes a method to extend the option space 90 available in the initial SYN segment of a TCP connection (e.g., SYN 91 set and ACK not set) [RFC793]. This extension is required to support 92 some combinations of TCP options, notably large ones such as TCP AO 93 [RFC5925], Multipath TCP [RFC6824], and TCP Fast Open [RFC7413] with 94 other options already typically used in most TCP connections. This 95 document specifies this TCP SYN extended option space (SYN-EOS) 96 option, and is independent of (and thus compatible with) IPv4 and 97 IPv6. SYN-EOS complements the proposed TCP Extended Data Offset 98 (EDO) option, which increases the space available for options in all 99 segments except the initial SYN [To18]. 101 2. Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC-2119 [RFC2119]. 107 In this document, these words will appear with that interpretation 108 only when in ALL CAPS. Lower case uses of these words are not to be 109 interpreted as carrying RFC-2119 significance. 111 In this document, the characters ">>" preceding an indented line(s) 112 indicates a compliance requirement statement using the key words 113 listed above. This convention aids reviewers in quickly identifying 114 or finding the explicit compliance requirements of this RFC. 116 3. Experiment Goals 118 TCP is critical to the robust functioning of the Internet, therefore 119 any proposed modifications to TCP need to be thoroughly tested. The 120 present specification describes an experimental protocol that 121 initiates a connection using two coupled segments instead of the 122 traditional single one. The intention is to specify the protocol 123 sufficiently so that more than one implementation can be built in 124 order to test its function, robustness, and interoperability with 125 itself, with other variants of TCP and with common network 126 equipment, whether standardized or not. 128 The following describe the criteria that define success for this 129 experiment and its expected duration. 131 Success criteria: The experimental protocol will be considered 132 successful if, in the consensus opinion of the IETF, it functions 133 correctly in a sufficiently wide scope to be useful and it does no 134 harm, which implies that it ought to introduce minimal additional 135 delay or load to either updated or existing implementations and it 136 introduces no new security vulnerabilities. It is also required not 137 to be unduly difficult or complex to implement correctly, so that it 138 is not likely to lead to additional bugs or vulnerabilities. 140 Duration: To be credible, the experiment will need to last at least 141 12 months from publication of the present specification. At that 142 time, a report on the experiment will be written up. If successful, 143 it would then be appropriate to work on a standards track 144 specification. 146 4. Using Multiple Segments to Establish a Connection 148 The basis of SYN-EOS is the use of multiple TCP segments to initiate 149 a TCP connection. It is also possible to extend initial SYN option 150 space using context established from prior connections or using 151 separate TCP connections (e.g., using the FTP control channel), this 152 document focuses on a mechanisms that applies to any connection 153 (including the first between two hosts) and do not require prior or 154 established concurrent TCP connections. 156 There are four examples of such approaches: 158 o Send a primary SYN and an extension SYN (LOIC [Yo11]) 160 o Send a primary SYN and extension non-SYN data (LO/SLO [Ed08]) 162 o Send two separate SYNs: a legacy SYN and an upgraded SYN on 163 separate port pairs (dual-stack, named "Sister-SYN" [Br14]) 165 o Send a primary SYN and an extension out-of-band segment (OOB, 166 this document) 168 All four approaches extend the space available in the initial SYN by 169 sending an additional segment during the first phase of the three- 170 way handshake. The Long Options by Invalid Checksum (LOIC) approach 171 differentiates the two SYNs by using an invalid TCP checksum in the 172 extension SYN [Yo11], which thus cannot traverse NAT/NAPT devices 173 [RFC3234]. 175 The LO/SLO approach extends the three-way handshake into a five-way 176 handshake to include extra options during the third segment, so the 177 traditional SYN/ACK does not complete the active connection [Ed08]. 178 In current implementations, the client TCP state machine transitions 179 to the ESTABLISHED state upon receipt of the SYN/ACK (including 180 transmission of the resulting ACK). In SLO, additional options sent 181 during the third segment are treated as part of the initial SYN and 182 the fourth segment with responses to these options is treated as 183 part of the conventional SYN/ACK. As with conventional TCP, data can 184 be sent during this handshake as part of any segment, but this data 185 needs to wait for the entire handshake to complete before being 186 forwarded to the application to ensure that all options have been 187 negotiated successfully. This adds an additional round trip of 188 latency which is undesirable in many cases. Connection-splitting 189 middleboxes that merge these segments might also cause long options 190 to be interpreted as data. 192 The Sister-SYN approach is a dual-stack mechanism. Both legacy 193 servers and upgraded servers process both SYNs; clients terminate 194 the appropriate pending connection based on whether the option is 195 acknowledged for each connection. 197 The remainder of this document presents the SYN-EOS approach, which 198 overcomes these limitations using an out-of-band segment to extend 199 the option space of the SYN. 201 5. The TCP SYN-EOS Option 203 The SYN-EOS approach uses a primary conventional SYN and an 204 additional out-of-band data segment, the latter being a non-SYN 205 packet with the ACK flag not set. Additional options are placed in 206 payload of an out-of-band (OOB) segment, i.e., a segment whose ACK 207 bit is cleared but is not a SYN (i.e., both SYN and ACK are zero). 208 This offers the following advantages: 210 1. It provide expansion space for options on a SYN, limited only by 211 the default maximum segment size (535 payload bytes for IPv4); 213 2. It reduces the chances that middleboxes will alter the extra 214 options, given there is a higher bar to altering the payload than 215 header fields. 217 3. It allows for future structured ways to hide extra options from 218 middleboxes and/or to protect them from being altered. 220 A client initiating a TCP connection (i.e., issuing an active open) 221 uses the SYN-EOS option flag to indicate the presence of the 222 extended option space (Figure 1). This follows the TCP option 223 format, where Kind is SYN-EOS-OPT and Length is 2. 225 +--------+--------+ 226 | Kind | Length | 227 +--------+--------+ 229 Figure 1 TCP SYN-EOS OOB option 231 An upgraded client supporting this feature uses this option only 232 when the space needed for options in the initial SYN exceeds that of 233 legacy TCP. When needed, the client sends the SYN-EOS option in the 234 initial SYN, together with whatever other options are intended for 235 connections to legacy servers (i.e., passive listeners). A legacy 236 server would respond with a SYN/ACK without the SYN-EOS option, 237 while also confirming other supported options, and the connection 238 would proceed without the SYN-EOS extension. 240 The upgraded client that sends the initial SYN using this option 241 also sends an out-of-band (OOB) data segment with the same option to 242 the same source and destination addresses and ports as the initial 243 SYN. An OOB data segment is herein defined as a TCP segment in which 244 neither SYN nor ACK flag is set. In particular, this looks like a 245 conventional data segment with the ACK field cleared. Current TCP 246 requirements allow the ACK field to be cleared for only the initial 247 SYN, so this segment looks like a data segment that has been 248 transmitted 'out-of-band', before a connection has been established. 249 The entire payload of the segment is used for additional options. 251 Upgraded servers that receive the TCP SYN with the SYN-EOS option 252 wait for the corresponding OOB segment and treat the entire set of 253 options in both segments as if they arrived with the initial SYN. 254 Once both have arrived, the server first processes TCP options 255 placed before each SYN-EOS option, applying them solely to their own 256 individual segment. Then the server marshals together all the TCP 257 options placed after each SYN-EOS option. It applies them to the 258 initial SYN only, as if they had all been concatenated after the 259 SYN-EOS OOB option. 261 >> The server MUST process the options placed after each SYN-EOS 262 option in the following order: 264 1. Those in the option space of the initial SYN 266 2. Those in the option space of the OOB segment 268 3. Those in the payload space of the OOB segment 270 The upgraded server proceeds with the remainder of the connection as 271 if the SYN-EOS OOB option were a also EDO request option [To18] in 272 the SYN. 274 >> The SYN/ACK MUST include the SYN-EOS option to confirm the 275 server's support for both the SUN-EOS and EDO capabilities and to 276 confirm receipt of both the SYN and OOB segment. The server MAY also 277 extend the options space of the SYN/ACK using the EDO option if 278 needed. 280 >> Any host that supports SYN-EOS MUST also thus support EDO. 282 >> The OOB segment MUST use the same sequence number as the initial 283 SYN. 285 >> The client MUST NOT send multiple different OOB segments. If the 286 server receives more than one OOB segment for the same connection it 287 MUST solely use the first. 289 5.1. Reliable Delivery of Lone Initial Segments 291 The server acknowledges the initial segment and the OOB segment 292 together by using a SYN/ACK that carries the appropriate SYN-EOS 293 option. The following subsections describe how the server 294 acknowledges initial segments after a certain time if only one has 295 arrived. 297 5.2. Reliable Delivery of a Lone SYN with SYN-EOS 299 If an upgraded server has received only a SYN with the SYN-EOS 300 option but no corresponding OOB segment, after a certain time it 301 MUST proceed with the connection as if the SYN had been received 302 without the SYN-EOS option. I.e. it processes all other TCP options 303 and responds with a SYN/ACK without the SYN-EOS option. 305 A client will not be able to tell whether this SYN/ACK is from a 306 legacy server or an upgraded server. How the client proceeds on 307 receipt of such a SYN/ACK depends on whether it wishes to retry 308 sending the TCP options in the OOB segment or to proceed without 309 them (e.g. for latency reasons): 311 >> If the client chooses to proceed without the OOB segment, it MUST 312 proceed as if the SYN-EOS option had never been used, by sending an 313 ACK to complete the three-way handshake. 315 >> If the client chooses to retry, it MUST retransmit the OOB 316 segment with the same sequence number as the ISN of the SYN, so it 317 is still out-of-band. However, this time it sets the ACK flag and it 318 sets the acknowledgement number to one greater than the sequence 319 number of the SYN/ACK. This effectively acknowledges receipt of the 320 SYN/ACK, but requests a fuller SYN/ACK that also covers the OOB 321 segment. At this stage a client that has chosen to retry the OOB 322 segment MUST NOT send the ACK that would normally complete the 323 three-way handshake. 325 >> If an upgraded server receives such a retransmitted OOB segment, 326 it MUST process the additional TCP options as if they were placed 327 after those in the initial SYN. Then it MUST send a SYN/ACK 328 containing the SYN-EOS option, as if it had not sent the earlier 329 SYN/ACK . 331 On receipt of this SYN/ACK, the client sends an ACK to complete the 332 handshake. 334 >> If an upgraded server receives an ACK to complete the handshake, 335 then later receives an OOB segment, it MUST discard the late OOB 336 segment. 338 >> If a server, whether upgraded or not, receives only an OOB 339 segment and no corresponding SYN, it MUST discard it and it MUST NOT 340 ever respond (see Security Considerations). 342 5.3. Interaction with EDO 344 Successful negotiation of either SYN-EOS option has the same effect 345 as EDO. Successful SYN-EOS negotiation enables EDO for the remainder 346 of the connection. 348 >> After successful SYN-EOS negotiation, segments after the initial 349 SYN MAY use the EDO option. 351 Note that a failure to negotiate SYN-EOS has also fails to 352 automatically negotiate EDO for endpoints that support EDO but not 353 SYN-EOS. As a consequence: 355 >> If EDO is desired when SYN-EOS fails, the initial SYN options 356 MUST include a separate EDO Supported option. 358 If SYN-EOS is sent in the initial SYN and confirmed in the SYN/ACK, 359 EDO is available for the remainder of the connection. Segments that 360 need to extend their option space would then include EDO. 362 >> If SYN-EOS and EDO Supported are sent in the initial SYN and 363 received by SYN-EOS capable server, the server MUST include SYN-EOS 364 in the SYN/ACK, and MAY also include EDO Extension if needed to 365 provide additional option space. 367 >> If the server agrees to EDO but cannot support SYN-EOS, the 368 SYN/ACK MUST include EDO Supported as per [To18] to confirm the 369 capability. 371 6. Issues 373 The following issues are known. 375 6.1. General Issues 377 Caching is required because it is unlikely that both segments 378 involved in initiating a SYN-EOS connection will arrive at the same 379 time: 381 >> Servers supporting SYN-EOS SHOULD cache received initial SYNs 382 with the SYN-EOS option. Servers MAY decline to cache received 383 initial SYNs if they are under memory constraints. 385 >> Servers supporting SYN-EOS SHOULD cache received SYN-C segments 386 with the SYN-EOS option. Servers MAY cache received OOB segments but 387 MUST NOT examine or process them further in any way until their 388 corresponding SYN segment arrives. 390 Similarly, clients need to be able to retransmit supplements to 391 ensure their delivery: 393 >> Clients MUST retransmit the supplemental segment any time they 394 retransmit the initial SYN segment. 396 Should this be a new option or just a variant of EDO, and if so, how 397 would it change EDO? 399 SYN Cookies: An updated server can achieve the same outcome as SYN 400 cookies by putting all the necessary connection state in TCP options 401 in the SYN/ACK (using EDO if extra space is needed). It would then 402 discard its own copy of this state, which it could recover from the 403 TCP options in the final ACK of the 3WHS sent by the client. New TCP 404 options complementary to SYN-EOS might need to be defined to achieve 405 this for some types of TCP option (TBA). A legacy server will not 406 understand the SYN-EOS option whether it uses SYN cookies or not, so 407 it will provide the same legacy service whether or not it uses SYN 408 cookies. 410 Useful to send SYN, wait shortly, then send OOB 412 OOB traversal concerns 414 6.2. Option processing order 416 TCP options before the EOS-SYN on initial SYN segments are 417 necessarily processed individually when each segment arrives. When 418 both segments of an EOS-SYN connection establishment arrive, the 419 remaining options are processed in the following sequence: 421 1. Initial SYN options 423 2. Supplement options 425 3. Supplement payload 427 *** NOTE TO THE WG: 429 There are two other constraints that might be applied to the 430 supplement options: 432 >> I. Supplement options MUST exactly match initial SYN options. 434 >> II. Supplement options MUST contain only the SYN-EOS option. 436 If either of these is chosen, the supplement options are NOT 437 processed again (i.e., they are discarded). 439 The former constraint helps the supplement segment share the same 440 fate as the initial SYN. The latter recognizes that the supplement 441 option space is not needed given the supplement payload, because the 442 option space is created from the payload space anyway. 444 *** END NOTE 446 6.3. Middlebox Transit Issues 448 NB: this variant will require an additional 1-byte field on the SYN- 449 EOS option for the EOO field. 451 Traversal of middleboxes that ensure the payload matches the 452 destination port number. It would be possible to include the 453 facility for SYN-EOS to include an Extra Option Offset (EOO) field. 454 A client setting EOO to a non-zero value would offset the start of 455 the additional TCP options by this number of 4-byte words from the 456 start of the payload. 458 >> An upgraded SYN-EOS server MUST start reading the additional TCP 459 options from a point within the payload that is offset by this 460 number of 4-byte words from the start of the payload. An upgraded 461 SYN-EOS server MUST ignore all data in the payload up to this point. 463 The client would then be free to include fake data at the start of 464 the payload consistent with what a middlebox might expect for the 465 destination port in use. The data to use would be application and 466 implementation dependent, and is not determined in the present 467 specification. 469 Interaction with TCP Fast Open 471 6.4. Interaction with Other TCP Options 473 6.5. TCP Fast Open 475 TBD. 477 Notes: SYN-EOS appears to be safe with TFO. Dual-SYN variants appear 478 to have potential problems with both upgraded and legacy servers. 479 With upgraded servers, receipt of a legacy SYN with the SYN 480 extension option flag present might require delayed response. With 481 legacy servers, it may be impossible to safely use TFO with the 482 extended SYN. 484 6.5.1. TCP Authentication Option and TCP MD5 486 TBD. 488 Notes: Likely to be similar to TCP EDO, i.e., requiring 489 authentication processing before extension processing. 491 7. TCP SYN-EOS Interaction with TCP 493 The following subsections describe how SYN-EOS interacts with the 494 TCP specification [RFC793]. 496 7.1. TCP User Interface 498 TBD. 500 7.2. TCP States and Transitions 502 TBD. 504 7.3. TCP Segment Processing 506 TBD. 508 7.4. Impact on TCP Header Size 510 TBD. 512 8. Error Conditions 514 8.1. Connectionless Resets 516 TBD. 518 8.2. ICMP Handling 520 TBD [RFC792]. 522 9. Security Considerations 524 >> By default, a SYN-EOS server must not cache an OOB segment and 525 MUST NOT respond to an OOB segment if it arrives before the 526 corresponding SYN segment, because many legacy firewalls will allow 527 OOB segments into private networks. Caching of OOB segments MAY be 528 enabled explicitly on public servers. 530 More TBD. 532 10. IANA Considerations 534 TBD. 536 This section is to be removed prior to publication as an RFC. 538 11. References 540 11.1. Normative References 542 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 543 793, September 1981. 545 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 546 Requirement Levels", BCP 14, RFC 2119, March 1997. 548 [To18] Touch, J., W. Eddy, "TCP Extended Data Offset Option", 549 draft-ietf-tcpm-tcp-edo (work in progress), Jan. 2018. 551 11.2. Informative References 553 [Br14] Briscoe, B., "Inner Space for TCP Options", 554 draft-briscoe-tcpm-inner-space-01 (work in progress), 555 October 2014. 557 [Ed08] Eddy, W. and A. Langley, "Extending the Space Available 558 for TCP Options", draft-eddy-tcp-loo-04 (work in 559 progress), July 2008. 561 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. 563 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 564 Issues", RFC 3234, February 2002. 566 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 567 Authentication Option", RFC 5925, June 2010. 569 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 570 "TCP Extensions for Multipath Operation with Multiple 571 Addresses", RFC 6824, January 2013. 573 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 574 Fast Open", RFC 7413, December 2014. 576 [Yo11] Yourtchenko, A., "Introducing TCP Long Options by Invalid 577 Checksum", draft-yourtchenko-tcp-loic-00 (work in 578 progress), April 2011. 580 12. Acknowledgments 582 The authors would like to thank the IETF TCPM WG for their feedback. 584 The use of multiple segments to extend the option space of a SYN was 585 initially proposed by Bob Briscoe. His initial proposal used 586 complementary SYNs in an earlier version of this document, which 587 evolved into mutually-exclusive "Sister-SYNs" in [Br14]. 589 This work is partly supported by USC/ISI's Postel Center. 591 This document was prepared using 2-Word-v2.0.template.dot. 593 Authors' Addresses 595 Joe Touch 597 Manhattan Beach, CA 90266 USA 599 Phone: +1 (310) 560-0334 600 Email: touch@strayalpha.com 601 URI: http://www.strayalpha.com/ 602 Ted Faber 603 Engineering Specialist 604 Computer Systems Research Department 605 The Aerospace Corporation 606 2310 E. El Segundo Blvd. 607 El Segundo, CA 90245-4609 USA 609 Phone: +1 (310) 336-7373 610 Email: theodore.v.faber@aero.org