An Upgraded TCP Session Type

Introduction defines TCP sessions and segments. In this document, those sessions and segments are called ordinary sessions (SES-O) and ordinary segments (SEG-O). depicts an SEG-O.

Ordinary TCP Segment (SEG-O) Every SEG-O contains a header. Some SEG-O's also contain data. Each field in the header, except for the last, has a fixed length. These initial fixed-length fields occupy 20 octets, collectively. One of these fields is called the Data Offset field. The last field in the header contains options . Its length varies from 0 to 40 octets. The Data Offset field identifies the boundary between the segment header and the segment data. It is measured in 4-octet units. The Data Offset field also determines the length of the Options field. This is because the Options field consumes all of the space between the initial fixed-length fields and the data. The Data Offset field contains 4 bits. So, its nominal value ranges from 0 to 15. However, values 0 to 4 are invalid. This is because data must follow the fixed-length header fields, and those fields occupy 20 octets. Because the value of the Data Offset field cannot exceed 15, the data offset cannot exceed 60 and the length of the Options field cannot exceed 40 (i.e., 60 minus 20). In the future, applications may require more than 40 octets of options. For example, an application may use a 36-byte TCP Authentication Option (TCP-AO) , leaving insufficient space for other required options. Therefore, this document describes an experiment in which upgraded sessions (SES-U) exchange upgraded segments (SEG-U). Each SEG-U can accommodate up to 1,016 octets of Individual Options.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 when, and only when, they appear in all capitals, as shown here.

SEG-O Versus SEG-U SEG-O and SEG-U are semantically identical, except that SEG-O can accommodate only 40 octets of options while SEG-U can accommodate 1,016 octets of Individual Options. SEG-O and SEG-U share the format depicted in . However:

In SEG-O, the Data Offset value ranges from 5 to 15, inclusive. Values 0 to 4 are invalid.
In SEG-U, the Data Offset value MUST be equal to 0. All other values are invalid.

The Data Offset value is the only attribute by which a SEG-O can be distinguished from a SEG-U. In a SEG-U, the Options field MUST be as depicted in .

SEG-U TCP Options

Length: 8-bit unsigned integer. Represents the length of TCP Options, including the Length and Reserved fields. Measured in 4-octet units. Value MUST be 1 or greater. A value of 1 indicates that only the Length and Reserved fields are present, with no Individual Options (i.e., the options region is empty).
Reserved: MUST be set to 0 by the sender and MUST be ignored by the receiver.
Individual Options: Defined in .

In a SEG-U, the receiver MUST use the Length field to determine the boundary between the Options field and segment data. Segment data begins at byte offset 20 + (Length x 4) from the start of the TCP header, where 20 is the length of the fixed-length header fields. This replaces the role of the Data Offset field, which MUST NOT be used as an offset in a SEG-U. Before accessing the Options field or segment data, the receiver MUST verify that the received TCP segment is at least 20 + (Length x 4) octets long. If the received TCP segment is shorter than the length indicated by the Length field, the receiver MUST discard the SEG-U as malformed. The TCP checksum for a SEG-U MUST be calculated and validated as specified in . It covers the IP pseudo-header, the entire TCP header (including the fixed-length fields, the Data Offset field, and the complete Options field), and the segment data. When the MKT TCP option flag excludes TCP options from the MAC, the four-byte Length/Reserved prefix and TCP-AO (with its MAC field zeroed) are still included in the MAC input. The receiver MUST validate the checksum before processing Individual Options or delivering segment data. A SEG-U can include up to 1,016 octets of Individual Options. However, options consume space within the path MTU, leaving less space for segment data and increasing the risk that a segment will exceed the path MTU. Therefore, although larger options fields may be required in the distant future, TCP options are RECOMMENDED not to exceed 256 octets.

SES-O Versus SES-U TCP clients initiate a SES-O by sending a SEG-O with the SYN bit set. The TCP server MAY respond with a SEG-O with the SYN and ACK bits set. However, the TCP server MUST NOT respond with a SEG-U. Within the context of a SES-O, SEG-O's can be sent, received and processed. However, SEG-U's MUST NOT be sent. If they are received, they MUST be silently discarded. Likewise, TCP clients initiate a SES-U by sending a SEG-U with the SYN bit set. The TCP server MAY respond with a SEG-U with the SYN and ACK bits set. However, the TCP server MUST NOT respond with a SEG-O. Within the context of a SES-U, SEG-U's can be sent, received and processed. However, SEG-O's MUST NOT be sent. If they are received, they MUST be silently discarded. In all other respects, a SES-U conforms to the specifications of .

TCP-AO Considerations This document is compliant with TCP-AO . According to , the Master Key Tuple (MKT) has a TCP option flag. This flag indicates whether TCP options other than TCP-AO are included in the MAC calculation. When options are included, the content of all options, in the order present, is included in the MAC, with TCP-AO's MAC field zeroed out. When the options are not included, all options other than TCP-AO are excluded from all MAC calculations (skipped over, not zeroed). In order to remain compliant with , the first 4 octets of the Options field MUST be included in the MAC calculation, regardless of whether the TCP option flag is set.

Backwards Compatibility Legacy TCP implementations support SES-O only. TCP implementations participating in this experiment support both SES-O and SES-U. Therefore:

A legacy TCP client can establish an SES-O with TCP server participating in this experiment.
A TCP client participating in this experiment can establish an SES-O with a legacy server.
A TCP client participating in this experiment can establish an SES-U with a TCP server participating in this experiment.

However, a TCP client participating in this experiment cannot establish an SES-U with a legacy server. The legacy server will silently discard the SEG-U SYN and the three-way handshake will time out.

Middleboxes and Accelerators Legacy middleboxes and hardware accelerators may discard, reject, or mishandle packets with Data Offset equal to 0. So, when a TCP client sends a SEG-U with the SYN bit set and receives no response, it cannot tell whether the packet was discarded or mishandled by a middlebox or accelerator, or discarded by the server. Regardless of where the packet was ignored, the client observes the behavior described in and behaves as if the packet were ignored by a legacy server.

Applicability and Disclaimer Given the limitations mentioned in and , TCP clients participating in this experiment SHOULD initiate a SES-U only under the following conditions:

When the TCP peer is known to be participating in the experiment and capable of supporting SES-U
When the application requires more than 40 octets of options and the TCP session should not be established unless 1,016 octets of Individual Options can be supported.

Furthermore, TCP clients participating in this experiment SHOULD NOT initiate a SES-U in the presence of legacy middleboxes.

Application Layer Considerations In order to acheive backwards compatibility at the application layer, an application may initiate two separate TCP sessions with a peer, with one session being a SES-U and the other being a SES-O. Depending upon which session or sessions initiate successfully, the application uses one session and terminates the other. This approach is similar to that described in Happy Eyeballs . Because this is orchestrated at the application layer, it is beyond the scope of this document.

Security Considerations This document inherits security considerations from . Setting the Data Offset field to 0 intentionally violates Section 3.1, which mandates that the Data Offset field MUST be 5 or greater. This approach is acceptable because:

compliant implementations will reject or discard segments with invalid Data Offset values (less than 5) before processing options. This ensures that legacy TCP implementations cannot be exploited by SEG-U segments, as the segments will be discarded at the validation stage rather than processed.
Upgraded TCP implementations MUST validate that the Data Offset field is either within the range [5, 15] (indicating a SEG-O) or exactly 0 (indicating a SEG-U). Any other value is malformed and MUST be discarded. Implementations MUST NOT attempt to infer meaning from intermediate values.
Legacy middleboxes that strictly validate TCP headers per will discard or ignore SEG-U segments, which is the desired behavior for backward compatibility. Middleboxes that do not validate Data Offset values may forward SEG-U segments unchanged.

IANA Considerations This document makes no IANA requests.

Experimental Results Parties participating in this experiment should publish experimental results within one year of the publication of this document. Experimental results should address the following:

Effort required to deploy
- Was deployment incremental or network-wide?
- Was there a need to synchronize configurations at each node or could nodes be configured independently?
- Did the deployment require hardware upgrade?
Scale of deployment
Interoperability
- Did you deploy two interoperable implementations?
- Did you experience interoperability problems?
Effectiveness and sufficiency of OAM mechanisms
- Did Wireshark work?
- Did TCPDUMP work?

Success Criteria Successful experimental deployment SHOULD demonstrate the following:

Implementation and testing by at least two independent developers or organizations
Interoperability validation between implementations, demonstrating that SEG-U segments are correctly generated and processed
At least one deployment in a testbed or production environment
No critical security vulnerabilities discovered during the experiment
Positive or neutral feedback regarding middlebox compatibility and packet handling

Acknowledgements The authors wish to acknowledge Keshawn Hamlin, Jordan Head, C. M. Heard, Rahul Khali, Amalesh Maity, Erin MacNeil, Bob Briscoe, Jainam Parikh, Joe Touch and Michael Tuexen for their review and helpful comments.