Summary

  • A DTLS Connection ID helps a receiver recover an existing security context; it does not validate the new source address carried by the enclosing UDP datagram.
  • Basic RRC checks the observed new address, while enhanced RRC first asks whether the old path remains preferred before it permits a new-path check.
  • A matching protected cookie supports a time-bounded binding decision. Path cause, symmetry, persistence, resumed packets and application outcome remain separate facts.

The packet was familiar; its address was not

A protected datagram arrives from an address the receiver has not bound to this connection. The Connection ID is familiar. It leads to an existing DTLS security context, and the record authenticates under that context. This is useful, but it is not the conclusion an operations screen is tempted to draw. The receiver has recognised the connection; it has not yet established that the peer can receive and answer at the observed address.

RFC 9853 occupies precisely that gap. It updates the DTLS 1.2 CID specification in RFC 9146 and DTLS 1.3 in RFC 9147 with a Return Routability Check, or RRC. The distinction is architectural. CID lookup answers which security context may interpret the record. RRC asks whether the peer at a particular address can complete a protected challenge exchange before the receiver changes its CID-to-address binding.

The specification never says why the address changed. A NAT mapping may have changed; a peer may have migrated deliberately; a duplicate genuine record may have been raced over another route; the network may have changed for some other reason outside the protocol's knowledge. The first evidence rule is therefore negative: do not turn an observed address difference into a causal label.

One content type, three different decisions

RRC is negotiated with extension code point 61 and can be used only when both peers exchanged the extension. Its ContentType is 27. Each message carries an eight-byte cookie with 64 bits of entropy and is authenticated and encrypted under the currently active DTLS context. IANA's TLS parameter registry records the three initial message values: path_challenge, path_response and path_drop.

Those names should not be flattened into “path validated.” A path_challenge creates a test. A path_response echoes the cookie and supplies the answer required by a particular branch of the algorithm. A path_drop says that an old path is alive but is no longer preferred, so the initiator must continue with a basic check of the new address. The same response type can also have different consequences depending on whether the exchange is basic or enhanced.

Cookies must be fresh. RFC 9853 warns that reuse, without replay protection, can let an attacker replay an earlier response and mislead the challenger. The useful receipt is therefore not a reusable “RRC passed” flag. It is a record of connection generation, challenge generation, cookie identifier, addresses, algorithm branch, timer and response.

Basic RRC authorises an update on the new address

In the basic procedure, the endpoint that observed the source-address change sends path_challenge(cookie) to that new address and starts timer T. The peer verifies the protected challenge and returns path_response(cookie) to the address from which the challenge arrived. When the initiator verifies the matching cookie, it updates the peer-address binding. If T expires, it does not.

The specification says returning the response on the challenge's incoming path ensures that the path is functional in both directions. That claim is bounded by the exchange: one protected challenge travelled out and one protected answer returned in the validation epoch. It does not establish that the forward and reverse routes use identical links. It does not measure how long either route will remain usable. It does not discover the reverse path's PMTU. It does not show that later application data crossed either direction.

Before validation, the receiver must stop sending buffered application data or keep output to the unvalidated address within the anti-amplification limit—three times the accepted data received from that address. This limits the receiver's ability to become an amplifier. It is not a continuity guarantee. In fact, the deliberate suspension is evidence that connection recognition and application delivery are different stages.

Enhanced RRC asks the old path a prior question

Basic validation is aimed at the spoofed-victim amplification problem. Enhanced validation considers a stronger off-path adversary: one that can observe genuine records and consistently race copies over a faster forwarding path. A copied record can appear to be a legitimate address change and, if accepted too quickly, move the connection onto the attacker's path.

The enhanced procedure therefore sends its first challenge to the previously valid address. If that old path is still preferred, the peer sends path_response; the initiator keeps the old binding and does not switch. If the old path is alive but no longer preferred, the peer sends path_drop; only then does the initiator run the basic new-address check. A timeout on the old path also leads to the basic check, without itself updating the binding.

This sequence prevents a crucial logging error. In enhanced mode, path_response can mean “do not update.” A metric that treats every matching response as a successful migration inverts the protocol decision.

It also exposes the limits of causal inference. In a NAT rebind, the initiating receiver sees a new path, while the responding peer still sees the old path as its preferred one. The peers do not share one path label. A path_drop requires the responder to know that it voluntarily migrated away from the old path. It is not the generic answer for every changed source address.

The enhanced defence is explicitly imperfect. If a forwarded route is reliably faster, it may be impossible to distinguish the attacker's path from an actual routing improvement. The RFC does not convert relative speed into benign intent.

Timers and nested changes define failure, not inconvenience

RRC permits multiple paced challenges to tolerate loss. In the absence of application-specific rules, it suggests one per RTT up to the anti-amplification limit. Where the old-path RTT is known, T should be three times that RTT; otherwise, it should be one second, subject to deployment profiles.

Those values are part of the meaning of a failure. A timeout says no acceptable answer arrived under the chosen timer and retry policy. It does not prove the peer was absent, the address was forged or the service was down. The new path may simply have a longer RTT.

Nested rebinding has sharper semantics. The algorithms are not designed for another address change while the first is under validation. In that case the response is dropped, validation times out, the binding is not updated, and new data triggers a fresh validation. An implementation that silently overwrites the pending challenge with the newest address destroys the generation boundary the RFC relies on.

Five receipts, not one green light

The first receipt belongs to connection lookup: DTLS version, negotiated RRC and CID capability, CID, security-context generation, protected record epoch and the address from which the change was observed.

The second belongs to validation: basic or enhanced mode, old or new path, challenge generation, a protected cookie reference, send and receive addresses, timer basis, retransmissions, message type and result. It must preserve whether a response authorised an update, preserved the old binding or merely triggered another check.

The third receipt is the binding act: previous address, selected address, decision time and endpoint. Without it, a successful exchange and a state mutation are only assumed to be the same event.

The fourth receipt covers resumed traffic. RFC 9853 says pending sends resume after validation to the bound peer address. The log must show the first protected packet accepted in each relevant direction, with epoch and reset provenance. A send call returning is not remote receipt.

The fifth receipt belongs to the application: a unique request was accepted, processed and answered before a declared deadline in the same evidence window. That is the service-continuity fact. No cookie can manufacture it.

Guidance is not an incident log

RFC 9853 strongly advises statistics on failed checks for SIEM and troubleshooting. It recommends logging multiple responses to one challenge because they could suggest an off-path attempt, and notes that frequent probing could indicate path instability. These are valuable logging recommendations. They are not reports that an attack or instability occurred.

DTLS version also changes what can be observed. In DTLS 1.2, an RRC message not wrapped in tls12_cid exposes its content type and may be dropped by a middlebox; the RFC recommends CID in both directions when that risk matters. DTLS 1.3 hides the record type from on-path observers. A failed validation record therefore needs version and record-format context before it is attributed to a hostile path.

The RFC Editor record and Datatracker history establish status and publication provenance. The errata page showed no matching errata at review time. None of these sources shows present deployment or service success.

Heng Lu's Running-Code Primacy supplies the governing order: a document defines deterministic compatibility, while operational truth comes from systems running it. Minimum Initial Specification keeps common claims narrow and locally verifiable. The essay on reality layers explains why a symbolic “validated” state cannot substitute for executable packet and application evidence.

Sources