]> CMCC

No. 58 Kunlunshan Road Suzhou 215000 China lluozy@yeah.net

CMCC

No. 58 Kunlunshan Road Suzhou 215000 China yanhaishuang_yewu@cmss.chinamobile.com

Internet Network Working Group Internet-Draft This document defines the Session Identifier Option (SIO), carried as a TCP option for TCP connections and as a UDP option for UDP datagrams. The option lets the endpoints of a connection or flow publish identifiers at the transport layer, where network functions on the path - load balancers, NAT gateways, firewalls - can read them without per-flow state and without payload inspection. Network functions of all kinds can benefit from it: session recovery in load-balancing and NAT clusters, stateless forwarding, connection-tracking recovery, and telemetry. The option adds only a few octets, and only to the packets that carry it; which packets carry it is a deployment choice. Endpoints that do not support it behave as if the option did not exist.

Introduction Almost every transport option standardized to date serves the two endpoints of a connection: MSS, Window Scale, SACK , and timestamps tune the transport between the two stacks. The network between the endpoints has evolved differently. Load balancers, NAT gateways, and firewalls are deployed at scale on virtually every path, and they maintain per-connection state that the endpoints are unaware of; yet no TCP option serves this middle tier, UDP has only recently gained an options mechanism at all , and the session management of this middle tier is implemented privately by every product. The option defined in this document fills this gap: endpoints voluntarily publish, at the transport layer, the identifier of the endpoint a flow belongs to, so that on-path network functions can consume this information without per-flow state and without payload inspection. This follows the direction the IETF set for middleboxes : middleboxes are a fact of the Internet, and the alternative to standardizing endpoint-middlebox cooperation is not its absence but its proliferation in private forms. The cooperation stays consensual: identifiers are published voluntarily by the endpoints, are read-only on path, and the end-to-end semantics of the transports are unchanged. Identifier-based forwarding has already been standardized for QUIC: QUIC-LB encodes routing information in the connection ID, validating the pattern at working-group level, but only for QUIC. TCP and UDP have no corresponding mechanism. The SIO provides one - a standard channel between the endpoints and on-path network functions, on which richer cooperation can be built. The SIO is carried as a TCP option and as a UDP option . On TCP, the client and the server exchange their identifiers during the handshake; afterwards, designated segments carry the identifier of the peer, so that a network function that encounters a connection it does not know can learn, from the segment itself, which endpoint the connection belongs to. On UDP there is no handshake and no retransmission; each endpoint includes the SIO in every datagram, so that a network function that encounters a flow it does not know can learn the same from any datagram. The SIO is lightweight: it adds only a few octets to a packet, whichever carrying mode is used (). Beyond session recovery, the channel serves network functions of every kind: a load balancer can read the backend identifier from every packet and forward without any session table at all; on-path measurement can attribute traffic to individual backends from the identifiers alone; a network element can use an identifier as an opaque anchor so that traffic follows a stable path with no per-flow state (). For session recovery itself, the option lets elastically scaling clusters keep long-lived connections through session loss, and the Available Session Recovery Protocol (ASRP) builds full session backup and recovery on it.

Terminology 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 BCP 14 when, and only when, they appear in all capitals, as shown here. "SIO" refers to one of the two Session Identifier options defined in this document: the LOCAL-ID option, which carries the identifier of its sender, and the PEER-ID option, which carries the identifier of the sender's peer. "Client" refers to the endpoint that initiates a connection or flow: the active open side of a TCP connection, or the sender of the first datagram of a UDP flow. "Server" refers to the other endpoint. "Network node" refers to an on-path device (e.g., a load balancer, a NAT gateway, or a firewall) that forwards packets; in the session-recovery use, it also participates in session backup and recovery. "Client identifier" and "server identifier" refer to values that identify the client or the server within a cluster. The length of an identifier is configurable, from 0 to 8 octets. "Session backup" refers to session state information stored on an endpoint for the purpose of session recovery.

The SIO Option The SIO comes in two kinds, so that each option is self-describing: the LOCAL-ID option carries the identifier of its sender, and the PEER-ID option carries the identifier of the sender's peer. On TCP, the options are negotiated during the handshake, similar to other TCP options, e.g., the Window Scale option , SACK , the Authentication Option (TCP-AO) , and TCP Fast Open : a client includes the LOCAL-ID option in the SYN segment, a server that supports the SIO includes the LOCAL-ID option in the SYN-ACK segment, and the options are in effect only if both segments carry one. After the handshake, an endpoint includes the PEER-ID option, carrying the identifier of the peer it stored during the handshake: a client carries the server identifier, and a server carries the client identifier. On UDP there is no handshake; each endpoint includes the options in every datagram according to the rules in .

Option Formats Each SIO carries one identifier: the LOCAL-ID option carries the identifier of its sender, and the PEER-ID option carries the identifier of the sender's peer. The identifier length is configurable, from 0 to 8 octets. Each option is 2 + N octets long: 1 octet for the Kind, 1 octet for the Length (Length = N + 2), and N octets for the identifier. A zero-length identifier indicates that the endpoint supports the SIO but has no identifier. On TCP, the options are TCP options; on UDP, they are carried as UDP options in the datagram's option area.

Option Semantics Each endpoint decides whether to use the SIO. On TCP, the options are in effect only when both endpoints have offered them; on UDP, there is no negotiation and the UDP rules below apply unilaterally.

TCP A client MAY include the LOCAL-ID option in a SYN segment; the client decides whether to use the SIO. A server that supports the SIO and receives a SYN segment with the LOCAL-ID option SHOULD include the LOCAL-ID option in the SYN-ACK segment, carrying its own identifier. A server MUST NOT include the LOCAL-ID option in a SYN-ACK segment if the corresponding SYN segment did not include the LOCAL-ID option. A client that receives a SYN-ACK segment without the LOCAL-ID option MUST NOT include the PEER-ID option in subsequent segments of that connection. The length of an identifier is configurable, from 0 to 8 octets; each endpoint determines the length of its own identifier. The Length field MUST equal the identifier length plus 2. A client that receives the LOCAL-ID option in a SYN-ACK segment SHOULD store the server identifier at least for the lifetime of the connection. A server that receives the LOCAL-ID option in a SYN segment SHOULD store the client identifier at least for the lifetime of the connection. After the handshake, each endpoint conveys the stored identifier of the peer in the PEER-ID option, in the segments designated by its carrying mode ().

UDP UDP has no handshake and no retransmission: any datagram may be the one that arrives after a session is lost, so an endpoint includes the SIO in every datagram it sends. The two kinds make each option self-describing, and their use follows three rules: An endpoint includes the LOCAL-ID option, carrying its own identifier, in every datagram it sends. Once an endpoint has learned the peer's identifier from the peer's LOCAL-ID option, it additionally includes the PEER-ID option, carrying the peer's identifier, in every datagram it sends. A PEER-ID option carrying the endpoint's own identifier is an echo: it proves the peer has learned the identifier. An endpoint that has received an echo MAY stop including the LOCAL-ID option; once it stops, its datagrams carry only the PEER-ID option. A datagram MAY carry both options during the transition. An endpoint of a one-way flow never receives anything from the peer: it never learns the peer's identifier and continues to carry the LOCAL-ID option indefinitely, which is the intended behavior - the peer still needs to be taught. Recovery for such flows falls back to the network node's local handling, since the forward path never carries the peer's identifier.

Identifier Management An identifier is an opaque octet string carried in the SIO. This document defines how identifiers are carried; it assigns them no meaning and does not standardize how they are generated. Identifiers serve many uses - session recovery, routing, packet marking, measurement - and each use imposes its own requirements on generation. How identifiers are generated, managed, and assigned is decided by the deployment; see the Security Considerations for how the choice of derivation affects exposure. Only a function that interprets identifiers - resolves them to endpoints, routes, or classes - needs to know how they are generated in the deployment it serves; a function that merely uses an identifier as an opaque value, e.g., for hashing, marking, or counting, needs no such knowledge. In a load-balancing deployment, for example, a load balancer that recovers sessions by identifier needs to know how the backends generate their identifiers. When the SIO is used with a mechanism that resolves identifiers to endpoint addresses, e.g., ASRP , the deployment MUST ensure that the network nodes can perform this resolution. A future specification may standardize the generation of identifiers for a specific use, as QUIC-LB standardizes the encoding of routing information in the QUIC connection ID. Uniqueness: Whether identifiers need to be unique depends on the use. In the session-recovery use, an identifier SHOULD be unique among the endpoints of the cluster it serves, because the network node locates the backup holder by the identifier. Stability: An identifier MUST remain stable for the lifetime of the connections that carry it, and SHOULD remain stable across reboots. Session recovery relies on the identifier of the backup holder: an identifier that changes after a restart leaves the backups associated with the earlier identifier unreachable.

SIO Option Operation

Flow Establishment On TCP, the client and the server exchange the LOCAL-ID option during the handshake according to the rules in . After the handshake, each endpoint has stored the identifier of the peer and conveys it in the segments designated by its carrying mode (). On UDP, there is no handshake: each endpoint begins including the LOCAL-ID option in the first datagram it sends, and the option use follows the rules in as the flow progresses.

Carrying Modes On TCP, the identifier of the peer is conveyed in one of two modes. Which mode applies is a deployment choice: Retransmission mode: The identifier is carried only in segments sent on timeout retransmission; normal data segments carry no overhead at all. Per-segment mode: The identifier is carried in every segment of the connection. This is the enabling mode for stateless forwarding (): a load balancer that forwards segments without any session table needs the identifier on every segment. It adds 2 + N octets to every segment. Deployments that consume the identifier on the forwarding path, e.g., stateless load balancing, SHOULD use the per-segment mode; for session recovery alone, the retransmission mode suffices. UDP has a single carrying mode: every datagram carries the SIO (). UDP has no retransmission, so any datagram may be the one that arrives after a session is lost, and the identifier must be present on it.

Uses The SIO defines how identifiers are exchanged and carried, not what consumes them. The uses below are independent of each other, and none is required by the option itself. Session recovery, the use for which the option was first proposed, is described first.

Session Recovery On TCP, an endpoint conveys the identifier on timeout retransmission. In a load-balancing cluster, where the session state is backed up to the server, a client conveys the server identifier on timeout retransmission. The network node uses the identifier to locate the server holding the backup and recover the session.

| ----- SYN + Client-ID ------> | | <---- SYN-ACK + Server-ID --- | <--- SYN-ACK + Server-ID ---- | | | | | <---------- data -----------> | <---------- data -----------> | | | | | - - - (session lost) - - - x|x - - - (session lost) - - - | | | | | | | | retransmission | | | ------------ + -------------> | | | Server-ID | | | | | | | ------ recovery query ------> | | | <----- session state -------- | | | (session recovered) | | | | | <---------- data -----------> | <---------- data -----------> | ]]>

shows the recovery flow in a load-balancing cluster, where the client conveys the server identifier. The flow in a SNAT cluster is symmetric: the server conveys the client identifier, and the network node locates the client holding the backup. The detailed recovery procedures are described in the Available Session Recovery Protocol (ASRP) . How the network node recovers a session is out of the scope of this document. It is suggested that the node use the Available Session Recovery Protocol (ASRP) to recover the session; however, the SIO does not depend on ASRP. On UDP, every datagram carries the identifier (): a network node that encounters a datagram of a flow it does not hold can recover the flow from that datagram alone, without waiting for a retransmission.

Stateless Forwarding In deployments where the load balancer forwards only the client-to-server direction (e.g., DSR and one-way DNAT), the load balancer can read the backend identifier from every packet and forward accordingly, with no session table at all; this greatly simplifies its implementation. It requires the per-segment mode () on TCP, so that the identifier is present on every segment; on UDP, every datagram carries an option by definition. In deployments that keep a session table for other processing, the table is reduced to a cache that accelerates the common case: on a miss, the packet is still forwarded correctly.

Connection-Tracking Recovery A firewall or NAT gateway that loses its connection table normally drops established connections and flows. With the SIO, a packet carrying the identifier lets the middlebox rebuild its entry, or locate the backup as in the recovery flow of .

Per-Backend Telemetry On-path measurement can attribute traffic to individual backends from the identifiers alone, without inspecting the application payload.

Opaque Affinity A network element need not resolve an identifier to an endpoint at all: it can use the identifier as an opaque anchor, e.g., as a hash key that assigns flows to nodes, so that traffic carrying the same identifier follows a stable path without any per-flow state or mapping to maintain.

Elastic Virtual Network Functions Virtualized middleboxes - load balancers, NAT gateways, firewalls, virtual switches, SD-WAN gateways, service-chain classifiers - are created, rescheduled, and replaced at high frequency, and any per-connection state they must maintain turns instance replacement into a state-migration problem. With the SIO providing the index, instances can obtain the connection context and be replaced freely. These functions can benefit from the option once it is available; the uses above apply to them as they apply to their physical counterparts.

Compatibility Clients that do not support the SIO do not include the LOCAL-ID option in the SYN segment, and servers that do not support it do not include the LOCAL-ID option in the SYN-ACK segment. Such connections behave exactly as connections without the SIO, and session recovery falls back to the mechanisms implemented by the network node. Similarly, if the SIO is removed by an intermediate device, the endpoints operate without identifiers. On UDP, no negotiation is needed: a receiver that does not support UDP options ignores the datagram's option area, and a receiver that supports UDP options but not the SIO ignores them, so an endpoint that includes the options affects no one. The SIO is designed for the common deployment where a single tier of SNAT or LB nodes sits between the client and the server; in multi-tier deployments, only the tier closest to the client or the server can use the SIO.

Security Considerations The SIO only exchanges endpoint identifiers. It carries no session state and no authentication information; the SIO itself performs no validation and promises none. Connections that require integrity protection can use TCP-AO alongside the SIO; the two are independent and can coexist on the same connection. The security of mechanisms built on the identifiers relies on the validation performed by the framework that consumes them. When the SIO is used with ASRP , the message validation described there applies: a network node verifies that a recovery response matches its outstanding request (cookie-based validation) and that the session referenced by the message is legitimate (session-legitimacy validation). A forged identifier cannot recover a non-existent session, because recovery succeeds only if the session backup actually exists on the identified endpoint. A segment carrying an identifier triggers at most one recovery query, which is no more than the number of queries triggered by other recovery mechanisms. How a network node maps an identifier to an endpoint address is an implementation matter. A node SHOULD ignore an identifier that it cannot map to a known endpoint. How an identifier is derived is a deployment choice: it MAY be random, a keyed function of the address, or the address itself. Deriving it directly from the address is simple and functional, but exposes internal addressing information to on-path observers; where that exposure matters, a random or keyed assignment avoids it.

IANA Considerations IANA is requested to allocate two TCP option Kind numbers from the TCP option kind registry for the Session Identifier options: Kind Length Meaning Reference TBD variable SIO LOCAL-ID This document TBD variable SIO PEER-ID This document and two UDP option Kind numbers from the "UDP Option Kind Numbers" registry : Kind Length Meaning Reference TBD variable SIO LOCAL-ID This document TBD variable SIO PEER-ID This document

Experimental Use Prior to IANA assignment of permanent option Kind values, implementations deployed for experimentation or interoperability testing SHOULD use the option Kind values reserved for experimental use, together with an Experiment Identifier (ExID), as described in for TCP and for UDP.

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. Transport protocols are extended through the use of transport header options. This document updates RFC 768 (UDP) by indicating the location, syntax, and semantics for UDP transport layer options within the surplus area after the end of the UDP user data but before the end of the IP datagram. This document is intended as part of an IETF discussion about "middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive. This memo provides information for the Internet community. 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] This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection, using a new IANA TCP experiment identifier. This approach is robust to experiments that are not registered and to those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints. This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein. This document obsoletes RFC 1323 and describes changes from it. This document describes an experimental TCP mechanism called TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section. Google Microsoft Private Octopus Inc. QUIC address migration allows clients to change their IP address while maintaining connection state. To reduce the ability of an observer to link two IP addresses, clients and servers use new connection IDs when they communicate via different client addresses. This poses a problem for traditional "layer-4" load balancers that route packets via the IP address and port 4-tuple. This specification provides a standardized means of securely encoding routing information in the server's connection IDs so that a properly configured load balancer can route packets with migrated addresses correctly. As it proposes a structured connection ID format, it also provides a means of connection IDs self-encoding their length to aid some hardware offloads. CMCC CMCC This document describes an experimental protocol named the Available Session Recovery Protocol (ASRP). The protocol is designed to optimize high-availability network cluster architectures, providing a superior high-availability solution for clusters offering stateful network services such as load balancing and Network Address Translation (NAT [RFC4787]). ASRP defines the procedures for session backup and recovery, as well as the message formats used during these interactions, enabling efficient and streamlined session state management. In contrast to traditional high-availability techniques that back up session state within the cluster itself, the core innovation of ASRP lies in its distributed backup of state information to the client or server side. This approach offers multiple advantages: theoretically unlimited elastic scaling capacity; support for rapid recovery from multi-point failures; reduction of resource redundancy through the elimination of centralized backup nodes; and significant simplification of cluster implementation complexity. The ASRP protocol provides a standardized method for constructing elastic service clusters, facilitating broader participation from software and hardware developers in building elastic cloud network service clusters.

Implementation Status Note to the RFC Editor: Please remove this section before publication. The SIO has been implemented twice and the implementations have been interoperability tested on a three-node testbed (client, load balancer, server): An eBPF implementation based on traffic-control programs on the endpoints: LOCAL-ID option insertion in the SYN and SYN-ACK, per-connection storage of the peer identifier, and the retransmission mode, where the PEER-ID option is carried in retransmitted segments, verified on the wire; on UDP, per-datagram option insertion with the LOCAL-ID/PEER-ID rules of . A Linux kernel module extending IPVS on the load balancer: extraction of the identifiers from packets and resolution to the backend for session recovery. The testbed exercised session recovery after load-balancer session-table loss and the identifier conveyance described in .

Acknowledgments The authors would like to thank all individuals who have provided valuable feedback and contributions during the development of this document, especially Mike Heard and Michael Tuexen for their detailed review comments.

Changes since draft-cmcc-tcp-sro-02 Added UDP support via UDP options , with per-datagram carrying and no negotiation; split the option into the LOCAL-ID and PEER-ID kinds so that each option is self-describing on both transports; restructured the document around the option as a general channel between endpoints and on-path network functions, with session recovery as the first of several uses; added the QUIC-LB precedent, an implementation status section, and applicability to virtual network functions; reworked the Introduction around the standard-channel positioning and softened the identifier-derivation wording. Renamed the option from the Session Recovery (SR) option to the Session Identifier Option (SIO).