Return Routability Check for DTLS 1.2 and 1.3
updates
Extracted elements (28)
The choice between basic and enhanced path validation depends on the threat model and other factors including implementation complexity, privacy concerns, and path-switch latency. The decision may be exposed as a configuration option to the TLS implementation user. Enhanced validation specifically counters off-path attackers racing packets to trigger address rebinding.
The RRC subprotocol is directly inspired by the QUIC path validation procedure (RFC 9000, Section 8.2). This addresses the gap left by RFC 9146, which described the threat of CID-based address spoofing but did not specify a concrete mechanism for verifying reachability at a new peer address.
In DTLS 1.3, the encrypted record type is opaque to on-path observers, making RRC messages immune to middlebox interference. In DTLS 1.2, if CID is not used in both directions, the return_routability_check content type appears in plaintext and is susceptible to middlebox dropping. CID should be enabled in both directions when middlebox interference is a concern in DTLS 1.2.
A client offering the connection_id extension SHOULD also offer the rrc extension, unless the application using DTLS has its own address validation mechanism.
A client offering the rrc extension MUST also offer the connection_id extension. If the client includes rrc but omits connection_id, the server MUST NOT include rrc in its ServerHello. The client and server MUST NOT use RRC unless both sides have successfully exchanged rrc extensions.
A receiver that observes the peer's address change MUST stop sending any buffered application data or limit data sent to the unvalidated address to the anti-amplification limit (three times the amount of data received from that address), then initiate a return routability check.
Each path_challenge message MUST contain random data. Multiple path_challenge messages SHOULD be placed in different transport packets and SHOULD be paced to decrease loss probability.
Implementations MUST be able to parse and understand all three RRC message types defined in this document. In addition, implementations MUST be able to parse and gracefully ignore messages with an unknown msg_type.
In the enhanced procedure, if the path through which the path_challenge was received is preferred, the responder MUST return path_response; if no longer preferred, the responder MUST return path_drop. In either case the cookie value is echoed.
In the enhanced procedure, when the initiator receives path_response it MUST continue using the previously valid address (no migration); when it receives path_drop it MUST perform a basic return routability check on the observed new address.
The responder MUST NOT delay sending elicited path_response or path_drop messages, MUST send exactly one per valid path_challenge, and MUST send it to the address from which the corresponding path_challenge was received. The initiator MUST silently discard any invalid path_response or path_drop.
The return_routability_check message MUST be authenticated and encrypted using the currently active security context.
When both CID and RRC have been successfully negotiated, if a record with CID is received with a source address different from the currently associated one, the receiver SHOULD perform a return routability check, unless an application-specific address validation mechanism is triggered instead.
When RTT information is available, timer T SHOULD be set to 3×RTT. If no RTT information is available, T SHOULD be set to 1 second. IoT deployment profiles MAY specify different values.
DTLS 1.2 does not support CID refresh during session lifetime, so deployments in multihoming environments SHOULD refuse CIDs with DTLS 1.2 and upgrade to DTLS 1.3 when CID correlation privacy is a concern.
When using DTLS 1.3, peers SHOULD avoid reusing the same CID on multiple network paths, especially during connection migration or new path probing, as an adversary can otherwise correlate communication across paths. Endpoints should proactively request new CIDs via RequestConnectionId before the spare pool is depleted.
The anti-amplification limit is defined as three times the amount of data received from an unvalidated address, including all DTLS records from that source (excluding discarded ones). This mirrors the QUIC definition from RFC 9000 applied to the DTLS context.
The RRC subprotocol introduces the return_routability_check content type (value 27) carrying three message types: path_challenge, path_response, and path_drop. Each message contains a Cookie field (uint64, 64 bits of entropy) and is identified by an rrc_msg_type field.
IANA allocated extension code point 61 for the rrc extension in the 'TLS ExtensionType Values' registry. It is defined for ClientHello and ServerHello (DTLS-Only=Y, Recommended=N).
IANA allocated return_routability_check (value 27) in the 'TLS ContentType' registry with DTLS_OK set to 'Y'. A note clarifies this content type is only applicable to DTLS 1.2 and 1.3.
IANA created the 'TLS RRC Message Types' registry (Expert Review) within TLS Parameters. Initial entries: path_challenge (0), path_response (1), path_drop (2), all DTLS-Only=Y and Recommended=Y; values 3-253 unassigned; 254-255 reserved for private use.
An off-path attacker can forward copied packets over a faster path to appear as a legitimate NAT rebinding, placing itself on-path. The enhanced path validation (Section 5.2) mitigates this by probing the old path first; if the old path is still functional and preferred, migration is suppressed.
Return routability checks do not protect against flooding of third parties when the attacker is on-path, since the attacker can redirect path_challenge messages to the real peer even though datagrams are cryptographically authenticated.
RRC cookies must be freshly generated using a reliable source of entropy (RFC 4086). Reusing a cookie without anti-replay protection allows an attacker to replay a previously sent path_response to mislead the challenger into switching to an attacker-controlled path.
RRC mitigates amplification attacks: when a packet arrives with a known CID but a different source address, the endpoint sends only a small path_challenge rather than a large response. Since a spoofed victim cannot decrypt and respond correctly, address validation fails and the original binding is preserved.
Basic path validation: initiator sends path_challenge with unpredictable cookie to the new address and starts timer T; responder echoes the cookie in a path_response; on receipt of matching path_response the initiator updates the peer address binding. If T expires, the binding is not updated.
Enhanced path validation: initiator sends path_challenge to the previously valid (old) address; if the old path is preferred the responder returns path_response (no migration); if the old path is no longer preferred it returns path_drop, triggering a basic check on the new address; if T expires, a basic check on the new address is also initiated.
The return_routability_check message encodes an rrc_msg_type enum (path_challenge=0, path_response=1, path_drop=2) followed by a uint64 Cookie. The Cookie carries 64 bits of entropy sourced from the implementation's CSPRNG.