idnits 2.17.1 draft-touch-tcpm-tcp-syn-ext-opt-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 date (July 20, 2014) is 3568 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 (-10) exists of draft-ietf-tcpm-fastopen-09 -- 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 USC/ISI 3 Intended status: Experimental B. Briscoe 4 Expires: January 2015 BT 5 T. Faber 6 USC/ISI 7 July 20, 2014 9 TCP SYN Extended Option Space 10 in the Payload of a Supplementary Segment 11 draft-touch-tcpm-tcp-syn-ext-opt-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on January 20, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. 48 Abstract 50 This document describes an experimental method to extend the option 51 space for connection parameters within the initial TCP SYN segment, 52 at the start of a TCP connection. This method effectively extends 53 the option space of an initial SYN by using an additional coupled 54 segment. It complements the proposed Extended Data Offset (EDO) 55 option that is applicable only after the initial segment. 57 Table of Contents 59 1. Introduction...................................................3 60 2. Conventions used in this document..............................3 61 3. Experiment Goals...............................................3 62 4. Using Multiple Segments to Establish a Connection..............4 63 5. The TCP SYN-EOS Option.........................................5 64 5.1. SYN-EOS OOB...............................................6 65 5.2. SYN-EOS DS................................................7 66 5.3. Interaction with EDO.....................................12 67 6. Issues........................................................12 68 6.1. Common Issues............................................12 69 6.1.1. Option processing order and duplication:............13 70 6.2. OOB Issues...............................................14 71 6.3. DS Issues................................................14 72 6.4. Meddlebox Transit Issues ;-).............................15 73 7. TCP SYN-EOS Interaction with TCP..............................15 74 7.1. TCP User Interface.......................................15 75 7.2. TCP States and Transitions...............................15 76 7.3. TCP Segment Processing...................................16 77 7.4. Impact on TCP Header Size................................16 78 8. Connectionless Resets.........................................16 79 8.1. ICMP Handling............................................16 80 9. Interactions with Middleboxes.................................16 81 10. Security Considerations......................................16 82 11. IANA Considerations..........................................16 83 12. References...................................................16 84 12.1. Normative References....................................16 85 12.2. Informative References..................................17 86 13. Acknowledgments..............................................17 88 1. Introduction 90 This document describes a method to extend the option space 91 available in the initial SYN segment of a TCP connection (e.g., SYN 92 set and ACK not set) [RFC793]. This extension is required to support 93 some combinations of TCP options, notably large ones such as TCP AO 94 [RFC5925], Multipath TCP [RFC6824], and TCP Fast Open [Ch14] with 95 other options already typically used in most TCP connections. This 96 document specifies this TCP SYN Extended Offset Space (SYN-EOS) 97 option, and is independent of (and thus compatible with) IPv4 and 98 IPv6. SYN-EOS complements the proposed TCP Extended Data Offset 99 (EDO) option, which increases the space available for options in all 100 segments except the initial SYN [To14]. 102 2. Conventions used in this document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC-2119 [RFC2119]. 108 In this document, these words will appear with that interpretation 109 only when in ALL CAPS. Lower case uses of these words are not to be 110 interpreted as carrying RFC-2119 significance. 112 In this document, the characters ">>" preceding an indented line(s) 113 indicates a compliance requirement statement using the key words 114 listed above. This convention aids reviewers in quickly identifying 115 or finding the explicit compliance requirements of this RFC. 117 3. Experiment Goals 119 TCP is critical to the robust functioning of the Internet, therefore 120 any proposed modifications to TCP need to be thoroughly tested. The 121 present specification describes an experimental protocol that 122 initiates a connection using two coupled segments instead of the 123 traditional single one. The intention is to specify the protocol 124 sufficiently so that more than one implementation can be built in 125 order to test its function, robustness, and interoperability with 126 itself, with other variants of TCP and with common network 127 equipment, whether standardized or not. 129 The following describe the criteria that define success for this 130 experiment and its expected duration. 132 Success criteria: The experimental protocol will be considered 133 successful if, in the consensus opinion of the IETF, it functions 134 correctly in a sufficiently wide scope to be useful and it does no 135 harm, which implies that it ought to introduce minimal additional 136 delay or load to either updated or existing implementations and it 137 introduces no new security vulnerabilities. It is also required not 138 to be unduly difficult or complex to implement correctly, so that it 139 is not likely to lead to additional bugs or vulnerabilities. 141 Duration: To be credible, the experiment will need to last at least 142 12 months from publication of the present specification. At that 143 time, a report on the experiment will be written up. If successful, 144 it would then be appropriate to work on a standards track 145 specification. 147 4. Using Multiple Segments to Establish a Connection 149 The basis of SYN-EOS is the use of multiple TCP segments to initiate 150 a TCP connection. It is also possible to extend initial SYN option 151 space using context established from prior connections or using 152 separate TCP connections (e.g., using the FTP control channel), this 153 document focuses on mechanisms that apply to any connection 154 (including the first between two hosts) and do not require prior or 155 established concurrent TCP connections. 157 There are four examples of approaches: 159 o Send a primary SYN and an extension SYN (LOIC [Yo11]) 161 o Send a primary SYN and extension non-SYN data (LO/SLO [Ed08]) 163 o Send dual-SYNs: a primary SYN on one port pair and an extension 164 SYN on a separate port pair (Dual-SYN or DS, this document) 166 o Send a primary SYN and an extension out-of-band segment (OOB, 167 this document) 169 All four approaches extend the space available in the initial SYN by 170 sending an additional segment during the first phase of the three- 171 way handshake. The Long Options by Invalid Checksum (LOIC) approach 172 differentiates the two SYNs by using an invalid TCP checksum in the 173 extension SYN [Yo11], which thus cannot traverse NAT/NAPT devices 174 [RFC3234]. 176 The LO/SLO approach extends the three-way handshake into a five-way 177 handshake to include extra options during the third segment, so the 178 traditional SYN/ACK does not complete the active connection [Ed08]. 179 In current implementations, the client TCP state machine transitions 180 to the ESTABLISHED state upon receipt of the SYN/ACK (including 181 transmission of the resulting ACK). In SLO, additional options sent 182 during the third segment are treated as part of the initial SYN and 183 the fourth segment with responses to these options is treated as 184 part of the conventional SYN/ACK. As with conventional TCP, data can 185 be sent during this handshake as part of any segment, but this data 186 needs to wait for the entire handshake to complete before being 187 forwarded to the application to ensure that all options have been 188 negotiated successfully. This adds an additional round trip of 189 latency which is undesirable in many cases. Connection-splitting 190 middleboxes that merge these segments might also cause long options 191 to be interpreted as data. 193 The remainder of this document presents the DS and OOB approaches, 194 both of which are believed overcome these limitations. 196 5. The TCP SYN-EOS Option 198 >>>>>>>> WG NOTE: 200 The SYN-EOS mechanism can rely on either the DS or OOB approaches. 201 As a result, both are presented here until the TCPM WG makes a 202 decision whether one is preferred or both should be part of the 203 experiment for different environments. 205 <<<<<<<< END WG NOTE. 207 The SYN-EOS OOB approach uses a primary conventional SYN and an 208 additional out-of-band data segment, the latter being a non-SYN 209 packet with the ACK flag not set. 211 The SYN-EOS DS approach uses two separate conventional SYNs using 212 the same IP addresses and destination port, in which the particular 213 option indicates which is primary and which is supplemental to 214 provide additional option space. 216 Additional options are placed in payload of the supplementary 217 segment. This offers the following advantages: 219 1. It provide expansion space for options on a SYN, limited only by 220 the default maximum segment size (535 payload bytes for IPv4); 222 2. It reduces the chances that middleboxes will alter the extra 223 options, given there is a higher bar to altering the payload than 224 header fields. 226 3. It allows for future structured ways to hide extra options from 227 middleboxes and/or to protect them from being altered. 229 Behaviors common to both approaches are described after the aspects 230 that are unique to each approach. 232 5.1. SYN-EOS OOB 234 A client initiating a TCP connection (i.e., issuing an active open) 235 uses the SYN-EOS out-of-band (OOB) option flag to indicate the 236 presence of the extended option space (Figure 1). This follows the 237 TCP option format, where Kind is SYN-EOS-OPT and Length is 2. 239 +--------+--------+ 240 | Kind | Length | 241 +--------+--------+ 243 Figure 1 TCP SYN-EOS OOB option 245 An upgraded client supporting this feature uses this option only 246 when the space needed for options in the initial SYN exceeds that of 247 legacy TCP. When needed, the client sends the SYN-EOS OOB option in 248 the initial SYN, together with whatever other options are intended 249 for connections to legacy servers (i.e., passive listeners). A 250 legacy server would respond with a SYN/ACK without the SYN-EOS OOB 251 option, while also confirming other supported options, and the 252 connection would proceed without the SYN-EOS extension. 254 The upgraded client that sends the initial SYN using this option 255 also sends an out-of-band (OOB) data segment with the same option to 256 the same source and destination addresses and ports as the initial 257 SYN. An OOB data segment is herein defined as a TCP segment in which 258 neither SYN nor ACK flag is set. In particular, this looks like a 259 conventional data segment with the ACK field cleared. Current TCP 260 requirements allow the ACK field to be cleared for only the initial 261 SYN, so this segment looks like a data segment that has been 262 transmitted 'out-of-band', before a connection has been established. 263 The entire payload of the segment is used for additional options. 265 Upgraded servers that receive the TCP SYN with the SYN-EOS OOB 266 option wait for the corresponding OOB segment and treat the entire 267 set of options in both segments as if they arrived with the initial 268 SYN. Once both have arrived, the server first processes TCP options 269 placed before each SYN-EOS OOB option, applying them solely to their 270 own individual segment. Then the server marshals together all the 271 TCP options placed after each SYN-EOS OOB option. It applies them to 272 the initial SYN only, as if they had all been concatenated after the 273 SYN-EOS OOB option. 275 >> The server MUST process the options placed after each SYN-EOS OOB 276 option in the following order: 278 1. Those in the option space of the initial SYN 280 2. Those in the option space of the OOB segment 282 3. Those in the payload space of the OOB segment 284 The upgraded server proceeds with the remainder of the connection as 285 if the SYN-EOS OOB option were a also EDO request option [To14] in 286 the SYN. 288 >> The SYN/ACK MUST include the SYN-EOS OOB option to confirm the 289 server's support for both the SUN-EOS and EDO capabilities and to 290 confirm receipt of both the SYN and OOB segment. The server MAY also 291 extend the options space of the SYN/ACK using the EDO option if 292 needed. 294 >> Any host that supports SYN-EOS OOB MUST also thus support EDO. 296 >> The OOB segment MUST use the same sequence number as the initial 297 SYN. 299 >> The client MUST NOT send multiple different OOB segments. If the 300 server receives more than one OOB segment for the same connection it 301 MUST solely use the first. 303 5.2. SYN-EOS DS 305 The SYN-EOS dual-SYN (DS) option operates nearly identically to the 306 OOB option, with two important differences: 308 1. Instead of the client using an OOB data segment, it uses a second 309 SYN for additional option space, sent using the same source and 310 destination IP addresses and destination port but with a 311 different source port. 313 2. Instead of using a simple option flag, an additional 314 Connection_ID field is required to correlate the two SYNs. 316 The two SYNs of the SYN-EOS DS option are defined as: 318 o SYN-D: the initial SYN that initiates the TCP (data) connection 320 o SYN-C: the SYN with (control) options in its payload that that 321 augment the option space in SYN-D 323 The SYN-EOS DS option appears in both the SYN-D and SYN-C segments, 324 and its structure is shown in Figure 2. The length of the 325 Connection_ID (CID) field is shown as 23 bits [NOTE: this has not 326 yet been decided]. It needs to be sufficient to pair corresponding 327 SYNs using this option. Given there are at most 65K possible 328 concurrent connections using the same address pair and destination 329 port (e.g., that vary in only source port), one possible lower bound 330 on the CID is 16 bits, but longer CIDs might be preferred to protect 331 against false positives. 333 +--------+--------+--------+--------+ 334 | Kind | Length |C| Connection ID | 335 +--------+--------+--------+--------+ 336 | con't | 337 +--------+ 339 Figure 2 TCP SYN-EOS DS option 341 >> The client MUST write the same Connection-ID within each of the 342 coupled SYNs (SYN-C and SYN-D). The client sets the control (C) flag 343 on a SYN-C and clears the C flag on a SYN-D to distinguish the two. 345 >> The initiating client MUST NOT include any option in the header 346 of SYN-C that could cause a legacy server to pass the payload to the 347 application (e.g. a TCP Fast-Open cookie to resume a connection). 349 Upgraded servers that receive a SYN-D or SYN-C with the SYN-EOS DS 350 option wait for the corresponding coupled SYN. Once both have 351 arrived, the server first processes TCP options placed before each 352 SYN-EOS DS option, applying them solely to their own individual 353 segment. Then the server marshals together all the TCP options 354 placed after each SYN-EOS DS option. It applies them to the SYN-D 355 only, as if they had all been concatenated after the SYN-EOS DS 356 option. This order is the same as that for the OOB variant, where 357 the SYN-C corresponds to the OOB segment. 359 >> The server MUST process the options placed after each SYN-EOS DS 360 option in the following order: 362 1. Those in the option space of SYN-D 364 2. Those in the option space of SYN-C 366 3. Those in the payload of the SYN-C 368 An upgraded server distinguishes SYN-D from SYN-C by the C flag of 369 the SYN-EOS TCP option. It responds to the SYN-D with a single 370 SYN/ACK that addresses the options in both SYNs, so it does not 371 respond explicitly to the SYN-C. 373 >> An upgraded server MUST NOT create or hold any connection state 374 based on SYN-C, but SHOULD cache SYN-C segments that arrive before 375 their corresponding SYN-D segment unless under memory constraints. 377 An upgraded server proceeds with the remainder of the connection as 378 if the SYN-EOS DS option were also an EDO request option [To14] on 379 SYN-D. 381 >> The server MUST include the SYN-EOS DS option on the SYN/ACK to 382 confirm its support for both the SYN-EOS and the EDO capability and 383 to acknowledge receipt of both SYNs. It MAY also extend the option 384 space of the SYN/ACK using the EDO option if needed. 386 >> A host that supports SYN-EOS DS MUST also support EDO. 388 >> A client MUST NOT send send multiple different SYN-C segments. If 389 the server receives more than one valid SYN-C segment associated 390 with one SYN-D, it MUST solely use the first. 392 A legacy server that does not support SYN-EOS will respond to both 393 SYNs with two independent SYN-ACKs. 395 >> The SYN-EOS client MUST respond to the SYN/ACK corresponding to 396 the C-SYN with a connection reset (RST). It responds to the other 397 SYN/ACK as normal and proceeds with that connection. 399 It might be naively considered that the two SYNs could use the same 400 initial sequence number, which would serve the role of a Connection 401 ID. However, this approach has not been followed because it would 402 not traverse certain middleboxes that do not preserve TCP sequence 403 numbers end-to-end. 405 5.3. Reliable Delivery of Lone Initial Segments 407 In both the OOB and the DS cases, the server acknowledges the 408 initial segment and the additional initial segment together by using 409 a SYN/ACK that carries the appropriate SYN-EOS option. The following 410 subsections describe how the server acknowledges initial segments 411 after a certain time if only one has arrived. 413 5.3.1. Reliable Delivery of a lone SYN-EOS OOB 415 If an upgraded server has received only a SYN with the SYN-EOS OOB 416 option but no corresponding OOB segment, after a certain time it 417 MUST proceed with the connection as if the SYN had been received 418 without the SYN-EOS OOB option. I.e. it processes all other TCP 419 options and responds with a SYN/ACK without the SYN-EOS OOB option. 421 A client will not be able to tell whether this SYN/ACK is from a 422 legacy server or an upgraded server. How the client proceeds on 423 receipt of such a SYN/ACK depends on whether it wishes to retry 424 sending the TCP options in the OOB segment or to proceed without 425 them (e.g. for latency reasons): 427 o >> If the client chooses to proceed without the OOB segment, it 428 MUST proceed as if the SYN-EOS OOB option had never been used, by 429 sending an ACK to complete the three-way handshake. 431 o >> If the client chooses to retry, it MUST retransmit the OOB 432 segment with the same sequence number as the ISN of the SYN, so 433 it is still out-of-band. However, this time it sets the ACK flag 434 and it sets the acknowledgement number to one greater than the 435 sequence number of the SYN/ACK. This effectively acknowledges 436 receipt of the SYN/ACK, but requests a fuller SYN/ACK that also 437 covers the OOB segment. At this stage a client that has chosen to 438 retry the OOB segment MUST NOT send the ACK that would normally 439 complete the three-way handshake. 441 >> If an upgraded server receives such a retransmitted OOB segment, 442 it MUST process the additional TCP options as if they were placed 443 after those in the initial SYN. Then it MUST send a SYN/ACK 444 containing the SYN-EOS OOB option, as if it had not sent the earlier 445 SYN/ACK . 447 On receipt of this SYN/ACK, the client sends an ACK to complete the 448 handshake. 450 >> If an upgraded server receives an ACK to complete the handshake, 451 then later receives an OOB segment, it MUST discard the late OOB 452 segment. 454 >> If a server, whether upgraded or not, receives only an OOB 455 segment and no corresponding SYN, it MUST discard it and it MUST NOT 456 ever respond (see Security Considerations). 458 5.3.2. Reliable Delivery of a Lone SYN-D 460 >> If an upgraded server has received only a SYN-D with the SYN-EOS 461 DS option but no corresponding SYN-C, after a certain time it MUST 462 proceed with the connection as if the SYN-D had been received 463 without the SYN-EOS DS option. I.e. it processes any TCP options 464 after the SYN-EOS DS option and responds to the SYN-D with a SYN/ACK 465 without the SYN-EOS DS option (to the source port of the SYN-D). 467 A client will not be able to tell whether this SYN/ACK is from a 468 legacy server or an upgraded server. How the client proceeds on 469 receipt of such a SYN/ACK depends on whether it wishes to retry 470 sending the TCP options in the SYN-C or to proceed without them 471 (e.g. for latency reasons): 473 o >> If the client chooses to proceed without the DS segment, it 474 MUST proceed as if the SYN-EOS DS option had never been used, by 475 sending an ACK (from the same port as the SYN-D) to complete the 476 three-way handshake. 478 o >> If the client chooses to retry, it MUST retransmit the SYN-C 479 from the same port and with the same flags and the same initial 480 sequence number as it used before . This requests a fuller 481 SYN/ACK that also covers the SYN-C. At this stage a client that 482 has chosen to retry the SYN-C segment MUST NOT send the ACK that 483 would normally complete the three-way handshake. 485 >> If an upgraded server receives such a retransmitted SYN-C, it 486 MUST process the additional TCP options as if they were placed after 487 those in the SYN-D. Then it MUST send a SYN/ACK containing the SYN- 488 EOS DS option, as if it had not sent the earlier SYN/ACK. 490 On receipt of this SYN/ACK, the client sends an ACK to complete the 491 handshake. 493 >> If an upgraded server receives an ACK to complete the handshake, 494 then later receives a SYN-C, it MUST discard the late SYN-C. 496 5.3.3. Reliable Delivery of a Lone SYN-C 498 >> If an upgraded server receives only a SYN-C and no corresponding 499 SYN-D, after a certain time it MUST acknowledge the SYN-C alone to 500 elicit a fast retransmission of the SYN-D, because it cannot proceed 501 without the SYN-D. It MUST NOT process any of the options after the 502 SYN-EOS DS option in the SYN-C. Instead, it MUST send a SYN/ACK with 503 the SYN-EOS DS option (to the source port of the SYN-C). 505 >> On receipt of such a SYN/ACK on the SYN-C port, if the client has 506 not received a SYN/ACK for the SYN-D, it MUST retransmit the SYN-D 507 unchanged. 509 >> If an upgraded server receives such a retransmitted SYN-D, it 510 MUST proceed as if the original SYN-D had arrived, and as if it had 511 not sent the earlier SYN/ACK. 513 5.4. Interaction with EDO 515 Successful negotiation of either SYN-EOS option has the same effect 516 as EDO. Successful SYN-EOS negotiation enables EDO for the remainder 517 of the connection. 519 >> Segments after the initial SYN MAY use the EDO option. 521 Note that a failure to negotiate SYN-EOS has also fails to 522 automatically negotiate EDO for endpoints that support EDO but not 523 SYN-EOS. As a consequence: 525 >> If EDO is desired when SYN-EOS fails, the initial SYN options 526 MUST include a separate EDO request option. 528 If SYN-EOS is sent in the initial SYN and confirmed in the SYN/ACK, 529 EDO is available for the remainder of the connection. Segments that 530 need to extend their option space would then include EDO. 532 >> If SYN-EOS and EDO are sent in the initial SYN and received by 533 SYN-EOS capable server, the server MUST include SYN-EOS in the 534 SYN/ACK, and MAY also include EDO also needed to provide additional 535 option space. 537 >> If the server agrees to EDO but cannot support SYN-EOS, the 538 SYN/ACK MUST include EDO as per [To14] to confirm the capability. 540 6. Issues 542 The following issues are known. 544 6.1. Common Issues 546 Caching is required because it is unlikely that both segments 547 involved in initiating a SYN-EOS connection will arrive at the same 548 time: 550 >> Servers supporting SYN-EOS SHOULD cache received initial SYNs 551 with the SYN-EOS option. Servers MAY decline to cache received 552 initial SYNs if they are under memory constraints. 554 >> Servers supporting SYN-EOS SHOULD cache received SYN-C segments 555 with the SYN-EOS option. Servers MAY cache received OOB segments but 556 MUST NOT examine or process them further in any way until their 557 corresponding SYN segment arrives. 559 Similarly, clients need to be able to retransmit supplements to 560 ensure their delivery: 562 >> Clients MUST retransmit the supplemental segment any time they 563 retransmit the initial SYN segment. 565 Should this be a new option or just a variant of EDO, and if so, how 566 would it change EDO? 568 SYN Cookies: An updated server can achieve the same outcome as SYN 569 cookies by putting all the necessary connection state in TCP options 570 in the SYN/ACK (using EDO if extra space is needed). It would then 571 discard its own copy of this state, which it could recover from the 572 TCP options in the final ACK of the 3WHS sent by the client. New TCP 573 options complementary to SYN-EOS might need to be defined to achieve 574 this for some types of TCP option (TBA). A legacy server will not 575 understand the SYN-EOS option whether it uses SYN cookies or not, so 576 it will provide the same legacy service whether or not it uses SYN 577 cookies. 579 6.1.1. Option processing order 581 TCP options before the EOS-SYN on initial SYN segments are 582 necessarily processed individually when each segment arrives. When 583 both segments of an EOS-SYN connection establishment arrive, the 584 remaining options are processed in the following sequence: 586 1. Initial SYN options 588 2. Supplement options 590 3. Supplement payload 592 *** NOTE TO THE WG: 594 There are two other constraints that might be applied to the 595 supplement options: 597 >> I. Supplement options MUST exactly match initial SYN options. 599 >> II. Supplement options MUST contain only the SYN-EOS option. 601 If either of these is chosen, the supplement options are NOT 602 processed again (i.e., they are discarded). 604 The former constraint helps the supplement segment share the same 605 fate as the initial SYN. The latter recognizes that the supplement 606 option space is not needed given the supplement payload, because the 607 option space is created from the payload space anyway. 609 *** END NOTE 611 6.2. OOB Issues 613 Useful to send SYN, wait shortly, then send OOB 615 OOB traversal concerns 617 6.3. DS Issues 619 Connection IDs, which could lead to spoof control options being 620 applied to a connection. 622 Fate sharing Disjoint paths: To network devices, the two SYNs appear 623 as if they belong to separate connections. Therefore network 624 equipment is more likely to forward them over disjoint paths than 625 packets belonging to the same flow. Traversing different paths might 626 lead to unpredictably different treatments (e.g., different firewall 627 blocking policies, etc.) 629 Legacy load balancers could direct the two SYNs to physically 630 separate servers. Therefore a site deploying SYN-EOS DS would have 631 to either a) upgrade its load balancers to understand the new 632 protocol or b) arrange for its servers to redirect coupled SYNs to a 633 common server. 635 Stack Implementation: Even once both SYNs are directed to the same 636 physical stack, the implementation would have to pass information 637 between connections, which would run counter to the structure of 638 some implementations. 640 Impact on connection rate: A server (whether legacy or upgraded) 641 will receive (1+p) times as many SYNs, where p is the proportion of 642 its clients that have upgraded to use SYN-EOS. 644 o An upgraded server does not create or hold connection state for 645 any C-SYN, so its performance impact is limited to the (1+p) 646 processing and bandwidth capacity needed, with extra memory only 647 required for transient storage during actual processing. 649 o A legacy server will usually receive a reset after 1 RTT for the 650 additional proportion p of connections, for which it will never 651 have entered the established state. Any legacy server 652 experiencing a reduction in its ability to serve new connections 653 with its given hardware can always upgrade its stack software to 654 support SYN-EOS, so at least it will not need to invest in 655 upgrading its memory hardware. 657 6.4. Middlebox Transit Issues 659 NB: this variant will require an additional 1-byte field on the SYN- 660 EOS option for the EOO field. 662 Traversal of middleboxes that ensure the payload matches the 663 destination port number. It would be possible to include the 664 facility for either the SYN-EOS OOB or the SYN-EOS DS TCP option to 665 include an Extra Option Offset (EOO) field. A client setting EOO to 666 a non-zero value would offset the start of the additional TCP 667 options by this number of 4-byte words from the start of the 668 payload. 670 >> An upgraded SYN-EOS server MUST start reading the additional TCP 671 options from a point within the payload that is offset by this 672 number of 4-byte words from the start of the payload. An upgraded 673 SYN-EOS server MUST ignore all data in the payload up to this point. 675 The client would then be free to include fake data at the start of 676 the payload consistent with what a middlebox might expect for the 677 destination port in use. The data to use would be application and 678 implementation dependent, and is not determined in the present 679 specification. 681 7. TCP SYN-EOS Interaction with TCP 683 The following subsections describe how SYN-EOS interacts with the 684 TCP specification [RFC793]. 686 7.1. TCP User Interface 688 TBD. 690 7.2. TCP States and Transitions 692 TBD. 694 7.3. TCP Segment Processing 696 TBD. 698 7.4. Impact on TCP Header Size 700 TBD. 702 8. Connectionless Resets 704 TBD. 706 8.1. ICMP Handling 708 TBD [RFC792]. 710 9. Interactions with Middleboxes 712 TBD. 714 10. Security Considerations 716 >> By default, a SYN-EOS OOB server must not cache an OOB segment 717 and MUST NOT respond to an OOB segment if it arrives before the 718 corresponding SYN segment, because many legacy firewalls will allow 719 OOB segments into private networks. Caching of OOB segments MAY be 720 enabled explicitly on public servers. 722 More TBD. 724 11. IANA Considerations 726 TBD. 728 This section is to be removed prior to publication as an RFC. 730 12. References 732 12.1. Normative References 734 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 735 Requirement Levels", BCP 14, RFC 2119, March 1997. 737 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 738 793, September 1981. 740 [To14] Touch, J., W. Eddy, "TCP Extended Data Offset Option", 741 draft-touch-tcpm-tcp-edo-03 (work in progress), July 2014. 743 12.2. Informative References 745 [Ch14] Cheng, Y., Chu, J., and A. Jain, "TCP Fast Open", draft- 746 ietf-tcpm-fastopen-09, June 2014. 748 [Ed08] Eddy, W. and A. Langley, "Extending the Space Available 749 for TCP Options", draft-eddy-tcp-loo-04 (work in 750 progress), July 2008. 752 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. 754 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 755 Issues", RFC 3234, February 2002. 757 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 758 Authentication Option", RFC 5925, June 2010. 760 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 761 "TCP Extensions for Multipath Operation with Multiple 762 Addresses", RFC 6824, January 2013. 764 [Yo11] Yourtchenko, A., "Introducing TCP Long Options by Invalid 765 Checksum", draft-yourtchenko-tcp-loic-00 (work in 766 progress), April 2011. 768 13. Acknowledgments 770 The authors would like to thank the IETF TCPM WG for their feedback. 772 Bob Briscoe is part-funded by the European Community under its 773 Seventh Framework Programme through the Trilogy 2 project (ICT- 774 317756). The views expressed here are solely those of the authors. 776 This document was prepared using 2-Word-v2.0.template.dot. 778 Authors' Addresses 780 Joe Touch 781 USC/ISI 782 4676 Admiralty Way 783 Marina del Rey, CA 90292-6695 USA 785 Phone: +1 (310) 448-9151 786 Email: touch@isi.edu 787 URI: http://www.isi.edu/touch 789 Bob Briscoe 790 BT 791 B54/77, Adastral Park 792 Martlesham Heath 793 Ipswich IP5 3RE 794 UK 796 Phone: +44 1473 645196 797 EMail: bob.briscoe@bt.com 798 URI: http://bobbriscoe.net/ 800 Ted Faber 801 USC/ISI 802 4676 Admiralty Way 803 Marina del Rey, CA 90292-6695 USA 805 Phone: +1 (310) 448-9190 806 Email: faber@isi.edu