]> CMCC

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

Internet Network Working Group Internet-Draft This document defines the Session Recovery Option (SRO) for TCP. SRO improves the reliability of Source Network Address Translation (SNAT) and load balancing (LB) services and simplifies the implementation of elastically scaling SNAT/LB clusters. SRO enables a client and a server to exchange their identifiers during connection establishment. When a session needs to be recovered, an endpoint conveys the identifier of the peer to the network node, which uses it to locate the endpoint holding the session backup and recover the session. SRO is optional: endpoints that do not support it behave as if the option did not exist.

Introduction SNAT and LB are stateful services: session state resides on the serving node, and a single node cannot recover its sessions after a failure. To provide reliable service, operators deploy high-availability (HA) pairs or clusters. Existing elastically scaling SNAT/LB cluster designs are complex to implement, and the most complex part is session recovery and session migration. Moreover, these services are unfriendly to long-lived connections: an idle connection is typically cleaned up by the serving node after a timeout , breaking the connection. A novel approach to reliable service is to back up the session state to the client or server side, so that even a single serving node can recover a session after a failure. This approach is embodied in the Available Session Recovery Protocol (ASRP) , to which readers may refer for the details of session backup and recovery. A key challenge of this approach is locating the endpoint that holds the session backup. Other mechanisms exist, but the Session Recovery Option (SRO) defined in this document addresses this challenge in the most direct way: it locates the backup endpoint in a single step. Moreover, SRO is not limited to session recovery: any mechanism that needs to locate a client or a server can use it. SRO is a TCP option . During the TCP handshake, the client and the server exchange their identifiers; when a session needs to be recovered, an endpoint carries the identifier of the peer, and the network node uses it to locate the endpoint holding the session backup. SRO is lightweight: it is carried only in the SYN, the SYN-ACK, and segments sent on timeout retransmission, adding no overhead to normal data segments. Despite this small cost, SRO is important for the reliability of SNAT and LB services: it simplifies session recovery and session migration in elastically scaling SNAT/LB clusters, and makes them friendly to long-lived connections. With SRO, a session that has been cleaned up after an idle timeout is recovered as soon as a segment carrying the identifier arrives.

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. "SRO" refers to the Session Recovery Option defined in this document. "Client" refers to TCP's active open side, and "server" refers to TCP's passive open side. "Network node" refers to a device (e.g., a load balancer or a NAT gateway) that forwards packets and participates in session backup and recovery. "Client identifier" refers to a value, carried in the SRO option in a SYN segment, that identifies a client within a cluster. Its length is configurable and defaults to 4 octets. "Server identifier" refers to a value, carried in the SRO option in a SYN-ACK segment, that identifies a server within a cluster. Its length is configurable and defaults to 4 octets. "Session backup" refers to session state information stored on an endpoint for the purpose of session recovery.

The SRO Option SRO is negotiated during the TCP handshake, similar to other TCP options, e.g., the Window Scale option and TCP Fast Open . During the handshake, each endpoint carries its own identifier in the SRO option: a client includes the SRO option in the SYN segment, and a server that supports SRO includes it in the SYN-ACK segment. SRO is only in effect if both segments carry the option. After the handshake, an endpoint carries the identifier of the peer in the SRO option, which it stored during the handshake: a client carries the server identifier, and a server carries the client identifier.

Option Formats The SRO option carries an identifier. During the handshake, it carries the identifier of its sender: the client identifier in a SYN segment, and the server identifier in a SYN-ACK segment; on session recovery, it carries the identifier of the peer. The identifier length is configurable, from 2 to 8 octets, with a default of 4 octets. The 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.

Option Semantics A client MAY include the SRO option in a SYN segment; the client decides whether to use SRO. A server that supports SRO and receives a SYN segment with the SRO option SHOULD include the SRO option in the SYN-ACK segment. A server that does not support SRO MUST NOT include the SRO option in the SYN-ACK segment. The length of an identifier is configurable, from 2 to 8 octets, with a default of 4 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 SRO option in a SYN-ACK segment SHOULD store the server identifier for the lifetime of the connection. A server that receives the SRO option in a SYN segment SHOULD store the client identifier for the lifetime of the connection.

SRO Operation

Connection Establishment During the TCP handshake, the client and the server exchange the SRO option according to the rules in Section 3.2. After the handshake, each endpoint has stored the identifier of the peer and conveys it for session recovery as described in Section 4.2.

Session Recovery By default, 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) . In a SNAT cluster, where the session state is backed up to the client, a server conveys the client identifier on timeout retransmission. The network node uses the identifier to locate the client holding the backup and recover the session. 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, SRO does not depend on ASRP. The endpoint includes the identifier of the peer stored during the handshake in the retransmitted segment.

Per-Segment Mode In the per-segment mode, an endpoint MAY be configured to include the identifier of the peer in every segment of a connection, instead of only on timeout retransmission. The network node can then recover the session at any time, without depending on retransmission timing. This mode is intended only for services with extremely high requirements on both reliability and recovery speed; for most deployments, the default mode is sufficient and the per-segment mode is not needed. It is disabled by default, as it adds 2 + N octets to every segment.

Compatibility Clients that do not support SRO do not include the SRO option in the SYN segment, and servers that do not support SRO do not include it in the SYN-ACK segment. Such connections behave exactly as connections without SRO, and session recovery falls back to the mechanisms implemented by the network node. Similarly, if the SRO option is removed by an intermediate device, the endpoints operate without identifiers. SRO 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 SRO.

Security Considerations 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, and SHOULD rate-limit recovery queries (e.g., per session or per source) to mitigate flooding. An identifier SHOULD be randomly assigned or derived with a secret key, rather than being derived directly from the endpoint IP address, so that internal addressing information is not exposed to third parties.

IANA Considerations IANA is requested to allocate one TCP option Kind number from the TCP option kind registry for the Session Recovery Option: Kind Length Meaning Reference TBD variable SRO This document

&RFC2119; &RFC8174; &RFC9293; &RFC2663; &RFC5382; &RFC7323; &RFC7413; CMCC CMCC

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-00 Expanded SNAT and LB on first use and added an informative reference to RFC 2663. Consolidated the two option kinds into a single kind. Removed the MTU consideration in Section 4.2.