Change:
for the initiator and responder roles, broken down per protocol phase. <del> 5.1. </del> <ins> 7. Note: This algorithm also takes the off-path scenario into account. 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: The receiver creates a "return_routability_check" message of type path_challenge and places the unpredictable cookie into the message. The message is sent to the previously valid address, which corresponds to the old path.  Additionally, a timer T, see timer- choice, is started. The peer endpoint verifies the received "return_routability_check" message.  The action to be taken depends on the preference of the path through which the message was received: If the path through which the message was received is preferred, a "return_routability_check" message of type path_response MUST be returned. If the path through which the message was received is not preferred, a "return_routability_check" message of type path_delete MUST be returned.  In either case, the peer endpoint echoes the cookie value in the response. The initiator receives and verifies that the "return_routability_check" message contains the previously sent cookie.  The actions taken by the initiator differ based on the received message: When a "return_routability_check" message of type path_response was received, the initiator MUST continue using the previously valid address, i.e. no switch to the new path takes place and the peer address binding is not updated. When a "return_routability_check" message of type path_delete was received, the initiator MUST perform a return routability check on the observed new address, as described in regular. If T expires, or the address confirmation fails, the peer address binding is not updated.  In this case, the initiator MUST perform a return routability check on the observed new address, as described in regular. After the path validation procedure is completed, any pending send operation is resumed to the bound peer address. path-challenge-reqs and path-response-reqs contain the requirements for the initiator and responder roles, broken down per protocol phase. 7.1. </ins> The initiator MAY send multiple "return_routability_check" messages of type path_challenge to cater for packet loss on the

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