Change:
before cryptographically validating the enclosed record(s) but instead perform a return routability check. <del> The newly introduced "return_routability_check" message contains a cookie.  The cookie is a 8-byte field containing arbitrary data. </del> <ins> The cookie is a 8-byte field containing arbitrary data. </ins> The "return_routability_check" message MUST be authenticated and encrypted using the currently active security context. 5. <ins> An off-path attacker that can observe packets might forward copies of genuine packets to endpoints.  If the copied packet arrives before the genuine packet, this will appear as a NAT rebinding.  Any genuine packet will be discarded as a duplicate.  If the attacker is able to continue forwarding packets, it might be able to cause migration to a path via the attacker.  This places the attacker on-path, giving it the ability to observe or drop all subsequent packets. This style of attack relies on the attacker using a path that has approximately the same characteristics as the direct path between endpoints.  The attack is more reliable if relatively few packets are sent or if packet loss coincides with the attempted attack. A data packet received on the original path that increases the maximum received packet number will cause the endpoint to move back to that path.  Eliciting packets on this path increases the likelihood that the attack is unsuccessful. fig-off-path demonstrates the case where a receiver receives a packet with a new source IP address and/or new port number.  The receiver needs to determine whether this path change is caused by an attacker and will send a RRC message of type path_challenge (RRC-1) on the old path. Three cases need to be considered: Case 1: The old path is dead, which leads to a timeout of RRC-1. As shown in fig-old-path-dead, a RRC message of type path_challenge (RRC-2) needs to be sent on the new path.  In this situation the switch to the new path is considered legitimate.  The sender will reply with RRC-3 containing a path_response on the new path. Case 2: The old path is alive but not preferred. This case is shown in fig-old-path-not-preferred whereby the sender replies with a RRC-2 path_delete message on the old path.  This triggers the receiver to send RRC-3 with a path-challenge along the new path.  The sender will reply with RRC-4 containing a path_response along the new path. Case 3: The old path is alive and preferred. This is most likely the result of an attacker.  The sender replies with RRC-2 containing a path_response along the old path.  The interaction is shown in fig-old-path-preferred.  This results in the connection being migrated back to the old path. Note that this defense is imperfect, but this is not considered a serious problem.  If the path via the attack is reliably faster than the old path despite multiple attempts to use that old path, it is not possible to distinguish between an attack and an improvement in routing. An endpoint could also use heuristics to improve detection of this style of attack.  For instance, NAT rebinding is improbable if packets were recently received on the old path; similarly, rebinding is rare on IPv6 paths.  Endpoints can also look for duplicated packets.  Conversely, a change in connection ID is more likely to indicate an intentional migration rather than an attack.  Note, however, changes in connection IDs are only supported in DTLS 1.3 but not in DTLS 1.2. 6. Note: This algorithm does not take the off-path scenario into account. </ins> The receiver that observes the peer's address or port update MUST stop sending any buffered application data (or limit the data sent to the unvalidated address to the anti-amplification limit) and initiate the return routability check that proceeds as follows: <del> An unpredictable cookie is placed in a "return_routability_check" message of type path_challenge; </del> <ins> The receiver creates a "return_routability_check" message of type path_challenge and places the unpredictable cookie into the message. </ins> The message is sent to the observed new address and a timer T (see <del> timer-choice) is started; </del> <ins> timer-choice) is started. </ins> The peer endpoint, after successfully verifying the received "return_routability_check" message responds by echoing the cookie value in a "return_routability_check" message of type <del> path_response; </del> <ins> path_response. </ins> When the initiator receives and verifies the "return_routability_check" message contains the sent cookie, it <del> updates the peer address binding; </del> <ins> updates the peer address binding. </ins> If T expires, or the address confirmation fails, the peer address binding is not updated.

Discussion:
Address
Martin Duke's ballot comment on draft-ietf-dtls-connection-id referenced the procedures of URL (which operates in essentially the same security model as DTLS) including the use of a path challenge for both old and new paths. We may want to have some similar discussion in this document.
The idea of that probe was to check, if the old address is also still valid. That would prevent an attack, where both peers are using CID and an eye-spotting attacker with high SLA prepares to get on path in order to drop then the traffic. With that, I would prefer, to have this as choice, to check this either always, or only, if the peer doesn't respond on the new path.
Copy from RFC 9000: Off-Path Packet Forwarding An off-path attacker that can observe packets might forward copies of genuine packets to endpoints. If the copied packet arrives before the genuine packet, this will appear as a NAT rebinding. Any genuine packet will be discarded as a duplicate. If the attacker is able to continue forwarding packets, it might be able to cause migration to a path via the attacker. This places the attacker on-path, giving it the ability to observe or drop all subsequent packets. This style of attack relies on the attacker using a path that has approximately the same characteristics as the direct path between endpoints. The attack is more reliable if relatively few packets are sent or if packet loss coincides with the attempted attack. A non-probing packet received on the original path that increases the maximum received packet number will cause the endpoint to move back to that path. Eliciting packets on this path increases the likelihood that the attack is unsuccessful. Therefore, mitigation of this attack relies on triggering the exchange of packets. In response to an apparent migration, endpoints MUST validate the previously active path using a PATHCHALLENGE frame. This induces the sending of new packets on that path. If the path is no longer viable, the validation attempt will time out and fail; if the path is viable but no longer desired, the validation will succeed but only results in probing packets being sent on the path. An endpoint that receives a PATHCHALLENGE on an active path SHOULD send a non-probing packet in response. If the non-probing packet arrives before any copy made by an attacker, this results in the connection being migrated back to the original path.

Any subsequent migration to another path restarts this entire process. This defense is imperfect, but this is not considered a serious problem. If the path via the attack is reliably faster than the original path despite multiple attempts to use that original path, it is not possible to distinguish between an attack and an improvement in routing. An endpoint could also use heuristics to improve detection of this style of attack. For instance, NAT rebinding is improbable if packets were recently received on the old path; similarly, rebinding is rare on IPv6 paths. Endpoints can also look for duplicated packets. Conversely, a change in connection ID is more likely to indicate an intentional migration rather than an attack.
There are no available "non-probing" packets in DTLS. Should we mint a new "no-op" record type for this?
Addressed by