Respect keep-alives, middleboxes and resources

With keep-alives and UTO enabled, the keep-alive timer MUST exceed the adopted USER_TIMEOUT.

• An implementation using keep-alives with UTO MUST set the keep-alive timer to a value larger than the adopted USER_TIMEOUT (§4.2). This prevents that keep-alive policy from aborting a connection that the longer user timeout was meant to preserve.
• The invalid example uses keep-alive 300 seconds with USER_TIMEOUT 600; the valid example uses 900 > 600. These are illustrative timer values, not a default or universal tuning recommendation.
• A stateful firewall can discard connection state after inactivity regardless of endpoint UTO values (§4.1). The separate firewall example expires after 120 seconds even though endpoints are willing to wait 600. UTO does not repair the path or refresh every middlebox.
• Long user timeouts retain established connection state and can amplify resource exhaustion when an attacker completes handshakes (§6). They do not lengthen the unsynchronized wait used by simple SYN floods (§3.3).
• Upper/lower limits, appropriate trust decisions and resource-sensitive policies can reduce the impact. Per-peer limits alone do not protect against distributed attacks. Hosts may close or reset connections to shed load; the advertised timeout is not a reservation.
• The RFC’s historical references to authentication mechanisms are context, not a mandate to deploy TCP-MD5 or old TLS. This guide models no authentication, cryptography, firewall or full security policy.

The resource queue and firewall are schematic examples. The option does not establish trust, encrypt data, guarantee a connection survives, or specify a portable operating-system socket API.