+---------------+---------------+
| Kind=SynOpSis | Length=2      |
+---------------+---------------+

Figure 3: A SynOpSis flag TCP option

2.4. TCP Option Processing

2.4.1. Writing TCP Options

If an upgraded TCP client includes the TCP Fast Open option [I-D.ietf-tcpm-fastopen] in the SYN, it MUST be placed with the extra TCP options after the end of the payload. An upgraded TCP client MUST NOT place any TCP option in the TCP header of a SYN that might cause a TCP server to pass user-data directly to the application before the 3-way handshake completes.

In order to ensure that the first extra TCP option aligns on a 4-octet word boundary, a TCP client SHOULD {ToDo: MUST?} start the extra TCP options with sufficient 1-octet no-op TCP options [RFC0793]. The number of no-op octets required will be 3 - ((S - 1) % 4), where S is the IP payload size in octets and '%' is the modulo operation.

2.4.2. Reading TCP Options

Before processing any TCP options, if the TCP payload is greater than 9 octets, an upgraded server MUST determine whether there is a SynOpSis TCP option at the end of the packet by checking all the following conditions:Figure 1), and treat all octets after the Data Offset as user-data.

• The Kind value is the SynOpSis Kind value;
• The length is 8;
• The next 4 octets match the magic number;
• The sum of the value of the EOO field, and all the length fields found by walking along the TCP options at the end of the payload exactly reaches the end of the packet.

If any of these conditions fails, the server MUST proceed by processing any TCP options in the TCP header (TCPopts#2 in

If an upgraded server finds a valid SynOpSis TCP option at the end of the packet, it MUST process the TCP options in a SYN-UN in the following order:

1. The Prefix TCP options (TCPopts#1 in Figure 1)
2. The regular TCP options following the main header but before the payload (TCPopts#2 in Figure 1);
3. The Suffix TCP options (TCPopts#3 in Figure 1)

This arrangement allows the client to reveal certain TCP options for processing by middleboxes (TCPopts#2), while concealing others after the payload. And the client can still control the order in which the server processes all the TCP options.

2.4.3. Forwarding TCP Options

Middleboxes exist that process some aspects of the TCP header. Although the present specification defines a new location for extra TCP options at the end of a packet, this is intended for the exclusive use of the destination TCP implementation. Legacy middleboxes will not expect to find TCP options beyond the Data Offset anyway. A middlebox MUST continue to treat any data beyond the Data Offset solely as user-data.

A TCP implementation is not necessarily aware whether it is deployed in a middlebox or in a destination, e.g. a split TCP connection might use a regular TCP implementation. Therefore, a general-purpose TCP that implements the present specification will need a configuration switch to disable any search for TCP options at the end of the packet.

3. Discussion of Non-Determinism

All the TCP headers and options before the payload of a SYN-UN (see Section 2.3.1) are completely indistinguishable from a regular SYN. This makes it very likely that a SYN-UN will be able to traverse any legacy middlebox, even one that splits a TCP connection. A SYN-UN can only be distinguished from any legacy SYN by the presence of the SynOpSis bit-pattern at the end of the packet.

This is termed the non-deterministic segment structure, because there will be a very small probability (roughly 2^{-48-L}) that payload data on a regular (non-SynOpSis) SYN could:

• happen to contain a pattern in exactly the right place that matches the kind, length and magic number of a SynOpSis TCP option and
• happen to contain a valid sequence of numbers in exactly the right places to look like a valid sequence of TCP option lengths.

In the above formula, L is the sum of all the bits in all the TCP option length fields that seem to be in the payload. For instance, if it appears that there are 2 TCP options before the SynOpSis option at the end of the payload, then L=2*8=16, and the probability of incorrectly using user-data as TCP options will then be roughly 2^(-64) = 1 in 18 billion billion (18x10^18). This 'stealth' approach has been taken in order to maximise the chances of traversing all the various types of middlebox.

Note that the non-determinism is only in one direction. I.e., there is a small chance that arbitrary user data might be mistaken for the SynOpSis TCP option, but it is not possible that a valid SynOpSis TCP option would ever be mistaken for user data.

{ToDo: It is recognised that it is potentially unsafe to use probability to determine whether TCP options are hidden at the end of the payload. If the WG prefers not to use the non-deterministic structure in Section 2.3.1, it can be replaced with the alternative more conventional deterministic protocol structure in . [synopsis_Structure_SYN-UD], and this discussion of non-determinism could then be deleted.}

4. Migration to Single Handshake

The strategy of sending two SYNs in parallel is not essential to the Alternative SYN approach. It is merely an initial strategy that minimises latency when the client does not know whether the server has been upgraded. Evolution to a single SYN with greater optio space could proceed as follows:

• Clients could maintain a white-list of upgraded servers discovered by experience and send just the upgraded SYN-U in these cases.
• Then, for white-listed servers, the client could send a legacy SYN only in the rare cases when an attempt to use an upgraded connection had previously failed (perhaps a mobile client encountering a new blockage on a new path to a server that it had previously accessed over a good path).
• In the longer term, once it can be assumed that most servers are upgraded and the risk of having to fall back to legacy has dropped to near-zero, clients could send just the upgraded SYN first, without maintaining a white-list, but still be prepared to send a legacy SYN in the rare cases when that might fail.

There is concern that, although dual handshake approaches might well eventually migrate to a single handshake, they do not scale when there are numerous choices to be made simultaneously. For instance, trying IPv4 and IPv6 in parallel [RFC6555]; and trying SCTP and TCP in parallel [I-D.wing-tsvwg-happy-eyeballs-sctp]; and trying ECN and non-ECN in parallel; and so on. Nonetheless, it is not necessary to try every possible combination of N choices, which would otherwise require 2^N handshakes (assuming each choice is between two options). Instead, a selection of the choices could be attempted together. At the extreme, two handshakes could be attempted, one with all the new features, and one without all the new features.

5. Interaction with Pre-Existing TCP

{ToDo: TCP API, TCP States and Transitions, TCP Segment Processing, Processing and Segment Size Overhead, Connectionless Resets, ICMP Handling. Interaction with EDO, Interaction with TFO (see Section 2.4.1), Interactions with Other TCP Variants including SYN Cookies, Forward-Compatibility, Interaction with TCP assumptions of Middleboxes. }

6. Dual Handshake: The Explicit Variant

This explicit dual handshake is similar to that in Section 2.1, except the SYN that the client intends for a legacy server is explicitly distinguishable from the SYN that would be sent by a legacy client. Then, in the case of an upgraded server, the server can reset the legacy connection itself, rather than creating connection state for at least a round trip until the client resets the connection.

{Temporary note: The choice between the explicit handshake in the present section or the handshake in Section 2.1 is a tradeoff between robustness against middlebox interference and minimal server state. During the IETF review process, one might be chosen as the only variant to go forward, at which point the other will be deleted. Alternatively, the IETF could allow both variants and a client could be implemented with either, or both. If both, the application could choose which to use at run-time. Then we will need a section describing the necessary API.}

For an explicit dual handshake, the TCP client still sends two alternative SYNs: a SYN-L intended for legacy servers and a SYN-U intended for upgraded servers. The two SYNs MUST have the same network addresses and the same destination port, but different source ports. Once the client establishes which type of server has responded, it continues the connection appropriate to that server type and aborts the other. The SYN intended for upgraded servers includes additional options at the end of the payload (the SYN-U defined as before in Section 2.3.1).

Table 2 summarises the TCP 3-way handshake exchange for each of the two SYNs between an upgraded TCP client (the active opener) and either:Table 1, which have already been explained in Section 2.1.

1. a legacy server, using the two columns to the left, or
2. an upgraded server, using the two columns to the right

The table uses the same layout and symbols as

|                   DO                       |         |    EOO    |
,------------------------------------------->|         |<----------.
+---------+-----------+----------+-----------+---------+-----------+
| TCP hdr | TCPopts#1 | SynOpSis | TCPopts#3 | Payload | TCPopts#2 |
+---------+-----------+----------+-----------+---------+-----------+

+---------------+---------------+---------------+
| Kind=SynOpSis | Length=3      | EOO           |
+---------------+---------------+---------------+