]> HPE

Herndon Virginia USA ronald.bonica@hpe.com

HPE

Sunnyvale California USA tony.li@tony.li

Transport TCPM Working Group TCP A TCP header accommodates only 40 octets of TCP options. In the future, applications may require more than 40 octets of TCP options. For example, an application may require a TCP Authentication Option (TCP-AO) with a 384-bit MAC. This option requires 52 octets of option space. This document defines a TCP extension that accommodates up to 1,016 octets of TCP options while maintaining backward compatibility with legacy implementations.

Introduction depicts a TCP segment.

TCP Segment

Every TCP segment contains a header. Some TCP segments also contain data. Each field in the TCP header, except for the last, has a fixed length. The fixed length fields in the TCP header occupy 20 octets. One of these fields is called the Data Offset field. The final field in the TCP header contains TCP options . Its length varies from 0 to 40 octets. The Data Offset field represents the TCP data offset, 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 space between the fixed length fields in the TCP header and the TCP data. The Data Offset field contains 4 bits. So, its nominal value ranges from 0 to 15. However, the value of the Data Offset field must be 5 or greater. This is because TCP 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 TCP 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 TCP options. For example, an application may require a TCP Authentication Option (TCP-AO) with a 384-bit MAC . This option requires 52 octets of option space. This document defines a TCP extension that accommodates up to 1,016 octets of TCP options while maintaining backward compatibility with legacy implementations.

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.

Terminology This document uses the following terms:

• TCP Client - The TCP endpoint that initiates a session.
• TCP Server - The TCP endpoint that communicates with the TCP Client.
• Ordinary Segment (SEG-O) - A TCP segment, as defined in . In a SEG-O, the Data Offset field has a value from 5 to 15.
• Updated Segment (SEG-U) - A TCP segment, as defined in . However, in a SEG-U, the Data Offset field must be equal to 0. That value identifies the segment as a SEG-U. See .
• Ordinary SYN (SYN-O) - A SEG-O whose SYN bit is set and ACK bit is not set.
• Updated SYN (SYN-U) - A SEG-U whose SYN bit is set and ACK bit is not set.
• Ordinary SYN/ACK (SYN/ACK-O) - A SEG-O whose SYN and ACK bits are set.
• Updated SYN/ACK (SYN/ACK-U) - A SEG-U whose SYN and ACK bits are set.
• Ordinary TCP Connection (TCP-O) - A TCP connection, as defined in . A TCP-O exchanges only SEG-O's.
• Updated TCP Connection (TCP-U) - A TCP connection, as defined in . However, a TCP-U can exchange both SEG-O's and SEG-U's. See .
• Legacy TCP - A TCP implementation that supports TCP-O only.
• Upgraded TCP - A TCP implementation that supports both TCP-O and TCP-U.

The Updated TCP Connection (TCP-U) A TCP-U sends SEG-U's:

• During the three-way handshake, even if those segments do not contain options
• When the segment contains more than 40 octets of options.

When neither of the above conditions is true, a TCP-U MAY send either SEG-O's or SEG-U's.

Updated TCP Segment (SEG-U) According to :

• The Data Offset field must have a value of 5 or greater
• TCP Options can be present only when the Data Offset field has a value greater than 5.

In a SEG-U, the Data Offset MUST have a value of 0. This value identifies the segment as a SEG-U and indicates that the format of the TCP 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 TCP data. TCP data begins at byte offset 20 + (Length x 4) from the start of the TCP header, where 20 is the length of the fixed TCP header fields. This replaces the role of the Data Offset field, which MUST be ignored as an offset in a SEG-U. As per , checksums are calculated over the entire Options field. A SEG-U can include 1,016 octets of options. While this may be required in the distant future, it is RECOMMENDED that TCP options not exceed 256 octets.

Backwards Compatibility Considerations When a legacy TCP client initiates a session with an updated TCP server, it sends a SYN-O. Depending upon local policy and application requirements, the server can refuse the connection request or continue with a TCP-O. When an updated TCP client initiates a session with a legacy TCP server, it sends a SYN-U. The server can ignore the SYN-U and allow the session to time out, as per or respond with a SYN/ACK-O, in violation of . In the latter case, depending upon local policy and application requirements, the updated TCP client can either terminate the connection or continue with a TCP-O. The behavior described above is acceptable in environments where extended TCP options are essential. However, it is not acceptable in environments where extended TCP options are desirable, but not essential. In these environments, implementations SHOULD implement the Dual Three-Way Handshake described in . In the Dual Three-Way Handshake, the client simultaneously initiates both a TCP-U and a TCP-O connection, and proceeds with whichever is accepted, preferring TCP-U when it is accepted.

Middleboxes and Accelerators Legacy middleboxes and hardware accelerators ignore packets with Data Offset equal to 0. So, when a TCP client sends a SYN-U and receives no response, it cannot tell whether the packet was ignored by a middlebox, an accelerator, or 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.

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?
  • Did you implement the Dual Three-Way Handshake?
• Effectiveness and sufficiency of OAM mechanisms
  • Did Wireshark work?
  • Did TCPDUMP work?

Success Criteria Successful experimental deployment SHOULD demonstrate the following:

1. Implementation and testing by at least two independent developers or organizations
2. Interoperability validation between implementations, demonstrating that SEG-U segments are correctly generated and processed
3. At least one deployment in a testbed or production environment
4. No critical security vulnerabilities discovered during the experiment
5. 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, Prashant Kumar, Amalesh Maity, Erin MacNeil, Jainam Parikh, Joe Touch and Michael Tuexen for their review and helpful comments. Special thanks to Bob Briscoe, who contributed the Dual Three-Way Handshake in .

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. Informative References This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK] HPE HPE RFC5926 creates a list of cryptographic algorithms that can be used with TCP-AO. This document expands that list, adding two Message Authentication Code (MAC) algorithms, HMAC-SHA384 and KMAC384. For each MAC algorithm, a corresponding Key Derivation Function (KDF) is also added. The MAC algorithms described by this document produce 384-bit (i.e., 48-byte) MACs. When 48-byte MACs are encoded in TCP-AO, the TCP-AO consumes 52 bytes. This exceeds TCP's 40-byte option size limitation. Therefore, it depends on a solution that extends TCP Option space. BT This document describes an experimental method to extend the limited space for control options in every segment of a TCP connection. It can use a dual handshake so that, from the very first SYN segment, extra option space can immediately start to be used optimistically. At the same time a dual handshake prevents a legacy server from getting confused and sending the control options to the application as user-data. The dual handshake is only one strategy - a single handshake will usually suffice once deployment has got started. The protocol is designed to traverse most known middleboxes including connection splitters, because it sits wholly within the TCP Data. It also provides reliable ordered delivery for control options. Therefore, it should allow new TCP options to be introduced i) with minimal middlebox traversal problems; ii) with incremental deployment from legacy servers; iii) without an extra round of handshaking delay iv) without having to provide its own loss recovery and ordering mechanism and v) without arbitrary limits on available space. Internet Assigned Numbers Authority (IANA)

Dual Three-Way Handshake In this procedure an upgraded TCP client executes two three-way handshakes in parallel. One three-way handshake begins with a SYN-U while the other begins with a SYN-O. Both SYN segments have the same source address, destination address, and destination port. However, they use different source ports. So, while both SYN segments are directed to the same peer, they initiate different TCP sessions. The session that begins with a SYN-U is a TCP-U while the session that begins with SYN-O is a TCP-O. Having sent a SYN-U and a SYN-O, the client may receive:

• A SYN/ACK-U and a SYN/ACK-O, in that order
• A SYN/ACK-U but not a SYN/ACK-O
• A SYN/ACK-O and a SYN/ACK-U, in that order
• A SYN/ACK-O but not a SYN/ACK-U
• Neither a SYN/ACK-U nor a SYN/ACK-O

The following subsections describe each scenario.

SYN/ACK-U Arrives First, Then SYN/ACK-O

Dual Three-Way Handshake: SYN/ACK-U Then SYN/ACK-O | |---- SYN-O (src port Y) ---------------------------->| |<------------------------ SYN/ACK-U (dst port X) ----| |---- ACK-U ----------------------------------------->| |<------------------------ SYN/ACK-O (dst port Y) ----| |---- RST-O ----------------------------------------->| | | ]]>

In this scenario, TCP-U succeeds immediately. The client completes the TCP-U three-way handshake by sending ACK-U. When SYN/ACK-O arrives for the parallel TCP-O attempt, the client rejects that connection by sending RST-O. The client then uses the TCP-U connection for all subsequent data exchange.

SYN/ACK-U Arrives, SYN/ACK-O Does Not Arrive

Dual Three-Way Handshake: SYN/ACK-U Only | |---- SYN-O (src port Y) ---------------------------->| |<------------------------ SYN/ACK-U (dst port X) ----| |---- ACK-U ----------------------------------------->| | [no SYN/ACK-O observed] | | | ]]>

In this scenario, TCP-U succeeds and TCP-O is not established. The client completes the TCP-U three-way handshake and proceeds with TCP-U. The client silently abandons the TCP-O attempt. If a delayed SYN/ACK-O is received later, the client sends RST-O.

SYN/ACK-O Arrives First, Then SYN/ACK-U

Dual Three-Way Handshake: SYN/ACK-O Then SYN/ACK-U | |---- SYN-O (src port Y) ---------------------------->| |<------------------------ SYN/ACK-O (dst port Y) ----| | [wait briefly for preferred TCP-U] | |<------------------------ SYN/ACK-U (dst port X) ----| |---- ACK-U ----------------------------------------->| |---- RST-O ----------------------------------------->| | | ]]>

In this scenario, the ordinary handshake responds first but the updated handshake is preferred. Upon receiving SYN/ACK-O first, the client waits for a short, locally configured interval to allow SYN/ACK-U to arrive. If SYN/ACK-U arrives during that interval, the client completes TCP-U and send RST-O for the TCP-O attempt. If SYN/ACK-U does not arrive before the local interval expires, the client completes TCP-O instead.

SYN/ACK-O Arrives, SYN/ACK-U Does Not Arrive

Dual Three-Way Handshake: SYN/ACK-O Only | |---- SYN-O (src port Y) ---------------------------->| |<------------------------ SYN/ACK-O (dst port Y) ----| |---- ACK-O ----------------------------------------->| | [no SYN/ACK-U observed] | | | ]]>

In this scenario, only TCP-O succeeds. The client completes the TCP-O handshake and proceeds with a TCP-O connection. The TCP-U attempt is abandoned. If a delayed SYN/ACK-U arrives after TCP-O is selected, the client sends RST-U.

Scenario 5: Neither SYN/ACK-U Nor SYN/ACK-O Arrives

Dual Three-Way Handshake: No Response | |---- SYN-O (src port Y) ---------------------------->| | [no SYN/ACK-U observed] | | [no SYN/ACK-O observed] | | | ]]>

In this scenario, neither parallel connection attempt succeeds. The client retransmits SYN-U and SYN-O according to timer and retry behavior. If retries are exhausted without receiving either SYN/ACK-U or SYN/ACK-O, the connection attempt fails.