TCP User Timeout Option
Extracted elements (27)
No negotiation mechanism for UTO support is defined during the three-way handshake. Studies showed only 3% of connections fail with unknown TCP options, and those failures result from non-compliant stacks already violating RFC 1122's requirement to ignore unknown options, so the failure rate does not warrant a negotiation round-trip.
No reliability handshake is defined for UTO option delivery because UTO is purely advisory and does not change processing of subsequent segments. A lost UTO option simply means the peer misses a chance to update its timeout, which is an acceptable outcome.
The Granularity bit allows the 15-bit User Timeout field to express values in seconds (1 s to ~9 hours) or minutes (1 min to ~22 days), providing fine granularity for short timeouts and extended range for mobile or intermittently connected scenarios without widening the field.
The recommended formula selects the maximum of the two endpoints' advertised user timeout values so that the connection survives longer periods without connectivity. The endpoint that advertised the lower value can still close or abort at will, so choosing the maximum does not prevent it from releasing state early.
Implementations can probe for UTO-stripping middleboxes by exchanging UTO options on the first data segments after the handshake. When UTO-carrying segments are persistently lost, UTO SHOULD be disabled for the connection; if the connection is reset, a transparent re-establishment without UTO may be attempted before any application data is exchanged.
Some TCP implementations (e.g., BSD) apply a different abort policy for TCP keep-alives than for user data, so keep-alives may abort a connection that a long UTO was intended to sustain. Requiring the keep-alive timer to exceed USER_TIMEOUT resolves this conflict.
Stateful firewalls that time out connection state based on inactivity may close connections regardless of UTO advertisements. Future firewalls might parse UTO options in unencrypted segments and adapt their state management accordingly.
A connection that has enabled UTO options SHOULD include a UTO option in the first packet that does not have the SYN flag set, minimizing state kept for non-synchronized connections and supporting SYN-cookie deployments.
A host that supports UTO SHOULD include a UTO option in the next possible outgoing segment whenever it starts using a new user timeout for the connection, so the peer can adapt accordingly.
A TCP implementation that does not support the UTO option MUST silently ignore it per RFC 1122, ensuring interoperability with non-UTO stacks.
If a connection enables both TCP keep-alives and the UTO option, the keep-alive timer MUST be set to a value larger than the adopted USER_TIMEOUT, otherwise keep-alives may abort connections that UTO intended to preserve.
If an application explicitly sets USER_TIMEOUT, CHANGEABLE MUST become false to prevent UTO options from the remote peer from overriding the application-specified value.
If CHANGEABLE is false, USER_TIMEOUT MUST NOT be changed regardless of the received UTO option; TCP SHOULD nonetheless notify the application of the peer's advertised user timeout value.
Implementations MUST impose upper and lower limits on the user timeout values they accept and use for a connection to protect against both connectivity loss and resource exhaustion.
Implementations MUST NOT assume that UTO options are transmitted reliably; no three-way handshake guarantees delivery, and local retransmission mechanisms only improve but cannot guarantee delivery.
The Kind field MUST be 28 and the Length field MUST be 4; a User Timeout value of zero (with either granularity) is reserved, MUST NOT be sent, and MUST be ignored on reception.
The lower limit L_LIMIT SHOULD be set to at least 100 seconds (consistent with RFC 1122's recommendation) and MUST be larger than the current retransmission timeout (RTO) to avoid unnecessarily aborting connections.
The UTO option carries the ADV_UTO value intended for synchronized connection states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK); connections in other states MUST use default timeout values from RFC 793 and RFC 1122.
Four per-connection state variables control UTO operation: USER_TIMEOUT (RFC 793 parameter), ADV_UTO (value advertised to peer), ENABLED (Boolean, defaults false, controls sending and receiving), and CHANGEABLE (Boolean, defaults true, controls whether USER_TIMEOUT may be adapted from received UTO options).
The recommended formula for computing the local USER_TIMEOUT when CHANGEABLE is true is: USER_TIMEOUT = min(U_LIMIT, max(ADV_UTO, REMOTE_UTO, L_LIMIT)), taking the maximum of the two advertised values clamped to configured upper and lower limits.
UTO option exchange is not a binding negotiation. Transmission of a UTO option is a suggestion that the other end consider adapting its user timeout; adaptation only occurs if both ENABLED and CHANGEABLE are true on the receiving side.
IANA allocated TCP option Kind number 28 from the 'TCP Option Kind Numbers' registry for the TCP User Timeout Option (UTO).
Load-shedding heuristics that reset long-idle connections first can harm trusted intermittently-connected peers that requested long UTOs; using peer trust level as a parameter in load-shedding decisions is recommended.
Long user timeouts amplify resource exhaustion attacks: an attacker that completes three-way handshakes can force servers to maintain connection state for extended durations, enabling lower-frequency attack traffic that is harder to detect.
Mitigations for resource exhaustion via long UTOs include: requiring prior peer authentication (IPsec, TCP-MD5/TCP-AO, or in-band TLS); per-peer limits on the number of high-UTO connections; and dynamically reducing accepted user timeouts as system resource utilization increases.
UTO does not worsen SYN-flood vulnerability because user timeouts advertised during the handshake only affect synchronized states (ESTABLISHED and beyond), which simple SYN floods never reach.
The TCP User Timeout Option is a 4-byte TCP option with Kind=28, Length=4, a 1-bit Granularity field (G), and a 15-bit unsigned integer User Timeout field. When G=1 the timeout is in minutes; when G=0 it is in seconds.