TCPM WG J. Touch Internet Draft USC/ISI Intended status: Experimental B. Briscoe Expires: January 2015 BT T. Faber USC/ISI July 20, 2014 TCP SYN Extended Option Space in the Payload of a Supplementary Segment draft-touch-tcpm-tcp-syn-ext-opt-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 20, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Touch Expires January 20, 2015 [Page 1] Internet-Draft TCP SYN Extended Offset Space Option July 2014 carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes an experimental method to extend the option space for connection parameters within the initial TCP SYN segment, at the start of a TCP connection. This method effectively extends the option space of an initial SYN by using an additional coupled segment. It complements the proposed Extended Data Offset (EDO) option that is applicable only after the initial segment. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................3 3. Experiment Goals...............................................3 4. Using Multiple Segments to Establish a Connection..............4 5. The TCP SYN-EOS Option.........................................5 5.1. SYN-EOS OOB...............................................6 5.2. SYN-EOS DS................................................7 5.3. Interaction with EDO.....................................12 6. Issues........................................................12 6.1. Common Issues............................................12 6.1.1. Option processing order and duplication:............13 6.2. OOB Issues...............................................14 6.3. DS Issues................................................14 6.4. Meddlebox Transit Issues ;-).............................15 7. TCP SYN-EOS Interaction with TCP..............................15 7.1. TCP User Interface.......................................15 7.2. TCP States and Transitions...............................15 7.3. TCP Segment Processing...................................16 7.4. Impact on TCP Header Size................................16 8. Connectionless Resets.........................................16 8.1. ICMP Handling............................................16 9. Interactions with Middleboxes.................................16 10. Security Considerations......................................16 11. IANA Considerations..........................................16 12. References...................................................16 12.1. Normative References....................................16 12.2. Informative References..................................17 13. Acknowledgments..............................................17 Touch Expires January 20, 2015 [Page 2] Internet-Draft TCP SYN Extended Offset Space Option July 2014 1. Introduction This document describes a method to extend the option space available in the initial SYN segment of a TCP connection (e.g., SYN set and ACK not set) [RFC793]. This extension is required to support some combinations of TCP options, notably large ones such as TCP AO [RFC5925], Multipath TCP [RFC6824], and TCP Fast Open [Ch14] with other options already typically used in most TCP connections. This document specifies this TCP SYN Extended Offset Space (SYN-EOS) option, and is independent of (and thus compatible with) IPv4 and IPv6. SYN-EOS complements the proposed TCP Extended Data Offset (EDO) option, which increases the space available for options in all segments except the initial SYN [To14]. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. In this document, the characters ">>" preceding an indented line(s) indicates a compliance requirement statement using the key words listed above. This convention aids reviewers in quickly identifying or finding the explicit compliance requirements of this RFC. 3. Experiment Goals TCP is critical to the robust functioning of the Internet, therefore any proposed modifications to TCP need to be thoroughly tested. The present specification describes an experimental protocol that initiates a connection using two coupled segments instead of the traditional single one. The intention is to specify the protocol sufficiently so that more than one implementation can be built in order to test its function, robustness, and interoperability with itself, with other variants of TCP and with common network equipment, whether standardized or not. The following describe the criteria that define success for this experiment and its expected duration. Success criteria: The experimental protocol will be considered successful if, in the consensus opinion of the IETF, it functions correctly in a sufficiently wide scope to be useful and it does no Touch Expires January 20, 2015 [Page 3] Internet-Draft TCP SYN Extended Offset Space Option July 2014 harm, which implies that it ought to introduce minimal additional delay or load to either updated or existing implementations and it introduces no new security vulnerabilities. It is also required not to be unduly difficult or complex to implement correctly, so that it is not likely to lead to additional bugs or vulnerabilities. Duration: To be credible, the experiment will need to last at least 12 months from publication of the present specification. At that time, a report on the experiment will be written up. If successful, it would then be appropriate to work on a standards track specification. 4. Using Multiple Segments to Establish a Connection The basis of SYN-EOS is the use of multiple TCP segments to initiate a TCP connection. It is also possible to extend initial SYN option space using context established from prior connections or using separate TCP connections (e.g., using the FTP control channel), this document focuses on mechanisms that apply to any connection (including the first between two hosts) and do not require prior or established concurrent TCP connections. There are four examples of approaches: o Send a primary SYN and an extension SYN (LOIC [Yo11]) o Send a primary SYN and extension non-SYN data (LO/SLO [Ed08]) o Send dual-SYNs: a primary SYN on one port pair and an extension SYN on a separate port pair (Dual-SYN or DS, this document) o Send a primary SYN and an extension out-of-band segment (OOB, this document) All four approaches extend the space available in the initial SYN by sending an additional segment during the first phase of the three- way handshake. The Long Options by Invalid Checksum (LOIC) approach differentiates the two SYNs by using an invalid TCP checksum in the extension SYN [Yo11], which thus cannot traverse NAT/NAPT devices [RFC3234]. The LO/SLO approach extends the three-way handshake into a five-way handshake to include extra options during the third segment, so the traditional SYN/ACK does not complete the active connection [Ed08]. In current implementations, the client TCP state machine transitions to the ESTABLISHED state upon receipt of the SYN/ACK (including transmission of the resulting ACK). In SLO, additional options sent Touch Expires January 20, 2015 [Page 4] Internet-Draft TCP SYN Extended Offset Space Option July 2014 during the third segment are treated as part of the initial SYN and the fourth segment with responses to these options is treated as part of the conventional SYN/ACK. As with conventional TCP, data can be sent during this handshake as part of any segment, but this data needs to wait for the entire handshake to complete before being forwarded to the application to ensure that all options have been negotiated successfully. This adds an additional round trip of latency which is undesirable in many cases. Connection-splitting middleboxes that merge these segments might also cause long options to be interpreted as data. The remainder of this document presents the DS and OOB approaches, both of which are believed overcome these limitations. 5. The TCP SYN-EOS Option >>>>>>>> WG NOTE: The SYN-EOS mechanism can rely on either the DS or OOB approaches. As a result, both are presented here until the TCPM WG makes a decision whether one is preferred or both should be part of the experiment for different environments. <<<<<<<< END WG NOTE. The SYN-EOS OOB approach uses a primary conventional SYN and an additional out-of-band data segment, the latter being a non-SYN packet with the ACK flag not set. The SYN-EOS DS approach uses two separate conventional SYNs using the same IP addresses and destination port, in which the particular option indicates which is primary and which is supplemental to provide additional option space. Additional options are placed in payload of the supplementary segment. This offers the following advantages: 1. It provide expansion space for options on a SYN, limited only by the default maximum segment size (535 payload bytes for IPv4); 2. It reduces the chances that middleboxes will alter the extra options, given there is a higher bar to altering the payload than header fields. 3. It allows for future structured ways to hide extra options from middleboxes and/or to protect them from being altered. Touch Expires January 20, 2015 [Page 5] Internet-Draft TCP SYN Extended Offset Space Option July 2014 Behaviors common to both approaches are described after the aspects that are unique to each approach. 5.1. SYN-EOS OOB A client initiating a TCP connection (i.e., issuing an active open) uses the SYN-EOS out-of-band (OOB) option flag to indicate the presence of the extended option space (Figure 1). This follows the TCP option format, where Kind is SYN-EOS-OPT and Length is 2. +--------+--------+ | Kind | Length | +--------+--------+ Figure 1 TCP SYN-EOS OOB option An upgraded client supporting this feature uses this option only when the space needed for options in the initial SYN exceeds that of legacy TCP. When needed, the client sends the SYN-EOS OOB option in the initial SYN, together with whatever other options are intended for connections to legacy servers (i.e., passive listeners). A legacy server would respond with a SYN/ACK without the SYN-EOS OOB option, while also confirming other supported options, and the connection would proceed without the SYN-EOS extension. The upgraded client that sends the initial SYN using this option also sends an out-of-band (OOB) data segment with the same option to the same source and destination addresses and ports as the initial SYN. An OOB data segment is herein defined as a TCP segment in which neither SYN nor ACK flag is set. In particular, this looks like a conventional data segment with the ACK field cleared. Current TCP requirements allow the ACK field to be cleared for only the initial SYN, so this segment looks like a data segment that has been transmitted 'out-of-band', before a connection has been established. The entire payload of the segment is used for additional options. Upgraded servers that receive the TCP SYN with the SYN-EOS OOB option wait for the corresponding OOB segment and treat the entire set of options in both segments as if they arrived with the initial SYN. Once both have arrived, the server first processes TCP options placed before each SYN-EOS OOB option, applying them solely to their own individual segment. Then the server marshals together all the TCP options placed after each SYN-EOS OOB option. It applies them to the initial SYN only, as if they had all been concatenated after the SYN-EOS OOB option. Touch Expires January 20, 2015 [Page 6] Internet-Draft TCP SYN Extended Offset Space Option July 2014 >> The server MUST process the options placed after each SYN-EOS OOB option in the following order: 1. Those in the option space of the initial SYN 2. Those in the option space of the OOB segment 3. Those in the payload space of the OOB segment The upgraded server proceeds with the remainder of the connection as if the SYN-EOS OOB option were a also EDO request option [To14] in the SYN. >> The SYN/ACK MUST include the SYN-EOS OOB option to confirm the server's support for both the SUN-EOS and EDO capabilities and to confirm receipt of both the SYN and OOB segment. The server MAY also extend the options space of the SYN/ACK using the EDO option if needed. >> Any host that supports SYN-EOS OOB MUST also thus support EDO. >> The OOB segment MUST use the same sequence number as the initial SYN. >> The client MUST NOT send multiple different OOB segments. If the server receives more than one OOB segment for the same connection it MUST solely use the first. 5.2. SYN-EOS DS The SYN-EOS dual-SYN (DS) option operates nearly identically to the OOB option, with two important differences: 1. Instead of the client using an OOB data segment, it uses a second SYN for additional option space, sent using the same source and destination IP addresses and destination port but with a different source port. 2. Instead of using a simple option flag, an additional Connection_ID field is required to correlate the two SYNs. The two SYNs of the SYN-EOS DS option are defined as: o SYN-D: the initial SYN that initiates the TCP (data) connection o SYN-C: the SYN with (control) options in its payload that that augment the option space in SYN-D Touch Expires January 20, 2015 [Page 7] Internet-Draft TCP SYN Extended Offset Space Option July 2014 The SYN-EOS DS option appears in both the SYN-D and SYN-C segments, and its structure is shown in Figure 2. The length of the Connection_ID (CID) field is shown as 23 bits [NOTE: this has not yet been decided]. It needs to be sufficient to pair corresponding SYNs using this option. Given there are at most 65K possible concurrent connections using the same address pair and destination port (e.g., that vary in only source port), one possible lower bound on the CID is 16 bits, but longer CIDs might be preferred to protect against false positives. +--------+--------+--------+--------+ | Kind | Length |C| Connection ID | +--------+--------+--------+--------+ | con't | +--------+ Figure 2 TCP SYN-EOS DS option >> The client MUST write the same Connection-ID within each of the coupled SYNs (SYN-C and SYN-D). The client sets the control (C) flag on a SYN-C and clears the C flag on a SYN-D to distinguish the two. >> The initiating client MUST NOT include any option in the header of SYN-C that could cause a legacy server to pass the payload to the application (e.g. a TCP Fast-Open cookie to resume a connection). Upgraded servers that receive a SYN-D or SYN-C with the SYN-EOS DS option wait for the corresponding coupled SYN. Once both have arrived, the server first processes TCP options placed before each SYN-EOS DS option, applying them solely to their own individual segment. Then the server marshals together all the TCP options placed after each SYN-EOS DS option. It applies them to the SYN-D only, as if they had all been concatenated after the SYN-EOS DS option. This order is the same as that for the OOB variant, where the SYN-C corresponds to the OOB segment. >> The server MUST process the options placed after each SYN-EOS DS option in the following order: 1. Those in the option space of SYN-D 2. Those in the option space of SYN-C 3. Those in the payload of the SYN-C An upgraded server distinguishes SYN-D from SYN-C by the C flag of the SYN-EOS TCP option. It responds to the SYN-D with a single Touch Expires January 20, 2015 [Page 8] Internet-Draft TCP SYN Extended Offset Space Option July 2014 SYN/ACK that addresses the options in both SYNs, so it does not respond explicitly to the SYN-C. >> An upgraded server MUST NOT create or hold any connection state based on SYN-C, but SHOULD cache SYN-C segments that arrive before their corresponding SYN-D segment unless under memory constraints. An upgraded server proceeds with the remainder of the connection as if the SYN-EOS DS option were also an EDO request option [To14] on SYN-D. >> The server MUST include the SYN-EOS DS option on the SYN/ACK to confirm its support for both the SYN-EOS and the EDO capability and to acknowledge receipt of both SYNs. It MAY also extend the option space of the SYN/ACK using the EDO option if needed. >> A host that supports SYN-EOS DS MUST also support EDO. >> A client MUST NOT send send multiple different SYN-C segments. If the server receives more than one valid SYN-C segment associated with one SYN-D, it MUST solely use the first. A legacy server that does not support SYN-EOS will respond to both SYNs with two independent SYN-ACKs. >> The SYN-EOS client MUST respond to the SYN/ACK corresponding to the C-SYN with a connection reset (RST). It responds to the other SYN/ACK as normal and proceeds with that connection. It might be naively considered that the two SYNs could use the same initial sequence number, which would serve the role of a Connection ID. However, this approach has not been followed because it would not traverse certain middleboxes that do not preserve TCP sequence numbers end-to-end. 5.3. Reliable Delivery of Lone Initial Segments In both the OOB and the DS cases, the server acknowledges the initial segment and the additional initial segment together by using a SYN/ACK that carries the appropriate SYN-EOS option. The following subsections describe how the server acknowledges initial segments after a certain time if only one has arrived. 5.3.1. Reliable Delivery of a lone SYN-EOS OOB If an upgraded server has received only a SYN with the SYN-EOS OOB option but no corresponding OOB segment, after a certain time it Touch Expires January 20, 2015 [Page 9] Internet-Draft TCP SYN Extended Offset Space Option July 2014 MUST proceed with the connection as if the SYN had been received without the SYN-EOS OOB option. I.e. it processes all other TCP options and responds with a SYN/ACK without the SYN-EOS OOB option. A client will not be able to tell whether this SYN/ACK is from a legacy server or an upgraded server. How the client proceeds on receipt of such a SYN/ACK depends on whether it wishes to retry sending the TCP options in the OOB segment or to proceed without them (e.g. for latency reasons): o >> If the client chooses to proceed without the OOB segment, it MUST proceed as if the SYN-EOS OOB option had never been used, by sending an ACK to complete the three-way handshake. o >> If the client chooses to retry, it MUST retransmit the OOB segment with the same sequence number as the ISN of the SYN, so it is still out-of-band. However, this time it sets the ACK flag and it sets the acknowledgement number to one greater than the sequence number of the SYN/ACK. This effectively acknowledges receipt of the SYN/ACK, but requests a fuller SYN/ACK that also covers the OOB segment. At this stage a client that has chosen to retry the OOB segment MUST NOT send the ACK that would normally complete the three-way handshake. >> If an upgraded server receives such a retransmitted OOB segment, it MUST process the additional TCP options as if they were placed after those in the initial SYN. Then it MUST send a SYN/ACK containing the SYN-EOS OOB option, as if it had not sent the earlier SYN/ACK . On receipt of this SYN/ACK, the client sends an ACK to complete the handshake. >> If an upgraded server receives an ACK to complete the handshake, then later receives an OOB segment, it MUST discard the late OOB segment. >> If a server, whether upgraded or not, receives only an OOB segment and no corresponding SYN, it MUST discard it and it MUST NOT ever respond (see Security Considerations). 5.3.2. Reliable Delivery of a Lone SYN-D >> If an upgraded server has received only a SYN-D with the SYN-EOS DS option but no corresponding SYN-C, after a certain time it MUST proceed with the connection as if the SYN-D had been received without the SYN-EOS DS option. I.e. it processes any TCP options Touch Expires January 20, 2015 [Page 10] Internet-Draft TCP SYN Extended Offset Space Option July 2014 after the SYN-EOS DS option and responds to the SYN-D with a SYN/ACK without the SYN-EOS DS option (to the source port of the SYN-D). A client will not be able to tell whether this SYN/ACK is from a legacy server or an upgraded server. How the client proceeds on receipt of such a SYN/ACK depends on whether it wishes to retry sending the TCP options in the SYN-C or to proceed without them (e.g. for latency reasons): o >> If the client chooses to proceed without the DS segment, it MUST proceed as if the SYN-EOS DS option had never been used, by sending an ACK (from the same port as the SYN-D) to complete the three-way handshake. o >> If the client chooses to retry, it MUST retransmit the SYN-C from the same port and with the same flags and the same initial sequence number as it used before . This requests a fuller SYN/ACK that also covers the SYN-C. At this stage a client that has chosen to retry the SYN-C segment MUST NOT send the ACK that would normally complete the three-way handshake. >> If an upgraded server receives such a retransmitted SYN-C, it MUST process the additional TCP options as if they were placed after those in the SYN-D. Then it MUST send a SYN/ACK containing the SYN- EOS DS option, as if it had not sent the earlier SYN/ACK. On receipt of this SYN/ACK, the client sends an ACK to complete the handshake. >> If an upgraded server receives an ACK to complete the handshake, then later receives a SYN-C, it MUST discard the late SYN-C. 5.3.3. Reliable Delivery of a Lone SYN-C >> If an upgraded server receives only a SYN-C and no corresponding SYN-D, after a certain time it MUST acknowledge the SYN-C alone to elicit a fast retransmission of the SYN-D, because it cannot proceed without the SYN-D. It MUST NOT process any of the options after the SYN-EOS DS option in the SYN-C. Instead, it MUST send a SYN/ACK with the SYN-EOS DS option (to the source port of the SYN-C). >> On receipt of such a SYN/ACK on the SYN-C port, if the client has not received a SYN/ACK for the SYN-D, it MUST retransmit the SYN-D unchanged. Touch Expires January 20, 2015 [Page 11] Internet-Draft TCP SYN Extended Offset Space Option July 2014 >> If an upgraded server receives such a retransmitted SYN-D, it MUST proceed as if the original SYN-D had arrived, and as if it had not sent the earlier SYN/ACK. 5.4. Interaction with EDO Successful negotiation of either SYN-EOS option has the same effect as EDO. Successful SYN-EOS negotiation enables EDO for the remainder of the connection. >> Segments after the initial SYN MAY use the EDO option. Note that a failure to negotiate SYN-EOS has also fails to automatically negotiate EDO for endpoints that support EDO but not SYN-EOS. As a consequence: >> If EDO is desired when SYN-EOS fails, the initial SYN options MUST include a separate EDO request option. If SYN-EOS is sent in the initial SYN and confirmed in the SYN/ACK, EDO is available for the remainder of the connection. Segments that need to extend their option space would then include EDO. >> If SYN-EOS and EDO are sent in the initial SYN and received by SYN-EOS capable server, the server MUST include SYN-EOS in the SYN/ACK, and MAY also include EDO also needed to provide additional option space. >> If the server agrees to EDO but cannot support SYN-EOS, the SYN/ACK MUST include EDO as per [To14] to confirm the capability. 6. Issues The following issues are known. 6.1. Common Issues Caching is required because it is unlikely that both segments involved in initiating a SYN-EOS connection will arrive at the same time: >> Servers supporting SYN-EOS SHOULD cache received initial SYNs with the SYN-EOS option. Servers MAY decline to cache received initial SYNs if they are under memory constraints. >> Servers supporting SYN-EOS SHOULD cache received SYN-C segments with the SYN-EOS option. Servers MAY cache received OOB segments but Touch Expires January 20, 2015 [Page 12] Internet-Draft TCP SYN Extended Offset Space Option July 2014 MUST NOT examine or process them further in any way until their corresponding SYN segment arrives. Similarly, clients need to be able to retransmit supplements to ensure their delivery: >> Clients MUST retransmit the supplemental segment any time they retransmit the initial SYN segment. Should this be a new option or just a variant of EDO, and if so, how would it change EDO? SYN Cookies: An updated server can achieve the same outcome as SYN cookies by putting all the necessary connection state in TCP options in the SYN/ACK (using EDO if extra space is needed). It would then discard its own copy of this state, which it could recover from the TCP options in the final ACK of the 3WHS sent by the client. New TCP options complementary to SYN-EOS might need to be defined to achieve this for some types of TCP option (TBA). A legacy server will not understand the SYN-EOS option whether it uses SYN cookies or not, so it will provide the same legacy service whether or not it uses SYN cookies. 6.1.1. Option processing order TCP options before the EOS-SYN on initial SYN segments are necessarily processed individually when each segment arrives. When both segments of an EOS-SYN connection establishment arrive, the remaining options are processed in the following sequence: 1. Initial SYN options 2. Supplement options 3. Supplement payload *** NOTE TO THE WG: There are two other constraints that might be applied to the supplement options: >> I. Supplement options MUST exactly match initial SYN options. >> II. Supplement options MUST contain only the SYN-EOS option. If either of these is chosen, the supplement options are NOT processed again (i.e., they are discarded). Touch Expires January 20, 2015 [Page 13] Internet-Draft TCP SYN Extended Offset Space Option July 2014 The former constraint helps the supplement segment share the same fate as the initial SYN. The latter recognizes that the supplement option space is not needed given the supplement payload, because the option space is created from the payload space anyway. *** END NOTE 6.2. OOB Issues Useful to send SYN, wait shortly, then send OOB OOB traversal concerns 6.3. DS Issues Connection IDs, which could lead to spoof control options being applied to a connection. Fate sharing Disjoint paths: To network devices, the two SYNs appear as if they belong to separate connections. Therefore network equipment is more likely to forward them over disjoint paths than packets belonging to the same flow. Traversing different paths might lead to unpredictably different treatments (e.g., different firewall blocking policies, etc.) Legacy load balancers could direct the two SYNs to physically separate servers. Therefore a site deploying SYN-EOS DS would have to either a) upgrade its load balancers to understand the new protocol or b) arrange for its servers to redirect coupled SYNs to a common server. Stack Implementation: Even once both SYNs are directed to the same physical stack, the implementation would have to pass information between connections, which would run counter to the structure of some implementations. Impact on connection rate: A server (whether legacy or upgraded) will receive (1+p) times as many SYNs, where p is the proportion of its clients that have upgraded to use SYN-EOS. o An upgraded server does not create or hold connection state for any C-SYN, so its performance impact is limited to the (1+p) processing and bandwidth capacity needed, with extra memory only required for transient storage during actual processing. Touch Expires January 20, 2015 [Page 14] Internet-Draft TCP SYN Extended Offset Space Option July 2014 o A legacy server will usually receive a reset after 1 RTT for the additional proportion p of connections, for which it will never have entered the established state. Any legacy server experiencing a reduction in its ability to serve new connections with its given hardware can always upgrade its stack software to support SYN-EOS, so at least it will not need to invest in upgrading its memory hardware. 6.4. Middlebox Transit Issues NB: this variant will require an additional 1-byte field on the SYN- EOS option for the EOO field. Traversal of middleboxes that ensure the payload matches the destination port number. It would be possible to include the facility for either the SYN-EOS OOB or the SYN-EOS DS TCP option to include an Extra Option Offset (EOO) field. A client setting EOO to a non-zero value would offset the start of the additional TCP options by this number of 4-byte words from the start of the payload. >> An upgraded SYN-EOS server MUST start reading the additional TCP options from a point within the payload that is offset by this number of 4-byte words from the start of the payload. An upgraded SYN-EOS server MUST ignore all data in the payload up to this point. The client would then be free to include fake data at the start of the payload consistent with what a middlebox might expect for the destination port in use. The data to use would be application and implementation dependent, and is not determined in the present specification. 7. TCP SYN-EOS Interaction with TCP The following subsections describe how SYN-EOS interacts with the TCP specification [RFC793]. 7.1. TCP User Interface TBD. 7.2. TCP States and Transitions TBD. Touch Expires January 20, 2015 [Page 15] Internet-Draft TCP SYN Extended Offset Space Option July 2014 7.3. TCP Segment Processing TBD. 7.4. Impact on TCP Header Size TBD. 8. Connectionless Resets TBD. 8.1. ICMP Handling TBD [RFC792]. 9. Interactions with Middleboxes TBD. 10. Security Considerations >> By default, a SYN-EOS OOB server must not cache an OOB segment and MUST NOT respond to an OOB segment if it arrives before the corresponding SYN segment, because many legacy firewalls will allow OOB segments into private networks. Caching of OOB segments MAY be enabled explicitly on public servers. More TBD. 11. IANA Considerations TBD. This section is to be removed prior to publication as an RFC. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. Touch Expires January 20, 2015 [Page 16] Internet-Draft TCP SYN Extended Offset Space Option July 2014 [To14] Touch, J., W. Eddy, "TCP Extended Data Offset Option", draft-touch-tcpm-tcp-edo-03 (work in progress), July 2014. 12.2. Informative References [Ch14] Cheng, Y., Chu, J., and A. Jain, "TCP Fast Open", draft- ietf-tcpm-fastopen-09, June 2014. [Ed08] Eddy, W. and A. Langley, "Extending the Space Available for TCP Options", draft-eddy-tcp-loo-04 (work in progress), July 2008. [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792. [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010. [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013. [Yo11] Yourtchenko, A., "Introducing TCP Long Options by Invalid Checksum", draft-yourtchenko-tcp-loic-00 (work in progress), April 2011. 13. Acknowledgments The authors would like to thank the IETF TCPM WG for their feedback. Bob Briscoe is part-funded by the European Community under its Seventh Framework Programme through the Trilogy 2 project (ICT- 317756). The views expressed here are solely those of the authors. This document was prepared using 2-Word-v2.0.template.dot. Touch Expires January 20, 2015 [Page 17] Internet-Draft TCP SYN Extended Offset Space Option July 2014 Authors' Addresses Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 USA Phone: +1 (310) 448-9151 Email: touch@isi.edu URI: http://www.isi.edu/touch Bob Briscoe BT B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE UK Phone: +44 1473 645196 EMail: bob.briscoe@bt.com URI: http://bobbriscoe.net/ Ted Faber USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 USA Phone: +1 (310) 448-9190 Email: faber@isi.edu Touch Expires January 20, 2015 [Page 18]