Original text:
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>  The "return_routability_check" message MUST be authenticated and encrypted using the currently active security context. 5.  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>  The message is sent to the observed new address and a timer T (see <del> timer-choice) is started; </del>  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>  When the initiator receives and verifies the "return_routability_check" message contains the sent cookie, it <del> updates the peer address binding; </del>  If T expires, or the address confirmation fails, the peer address binding is not updated. for the initiator and responder roles, broken down per protocol phase. <del> 5.1. </del>  The initiator MAY send multiple "return_routability_check" messages of type path_challenge to cater for packet loss on the sending direction) up to the anti-amplification limit to probe if the path MTU (PMTU) for the new path is still acceptable. <del> 5.2. </del>  <del> The responder MUST NOT delay sending an elicited path_response message. </del>  <del> The responder MUST send exactly one path_response messages for each received path_request. </del>  <del> The responder MUST send the path_response on the network path where the corresponding path_challenge has been received, so that validation succeeds only if the path is functional in both directions. The initiator MUST NOT enforce this behaviour </del>  The initiator MUST silently discard any invalid path_response it receives. If the responder wants to do PMTU discovery using RRC, it should initiate a new path validation procedure. <del> 5.3. </del>  When setting T, implementations are cautioned that the new path could have a longer round-trip time (RTT) than the original. constrained networks I-D.ietf-uta-tls13-iot-profile - MAY specify a different, more suitable value. <del> 6. </del>  The example TLS 1.3 handshake shown in fig-handshake shows a client and a server negotiating the support for CID and for the RRC However, the server wants to test the reachability of the client at his new IP address. <del> 7. </del>  Note that the return routability checks do not protect against flooding of third-parties if the attacker is on-path, as the attacker those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity. <del> 8. </del>  IANA is requested to allocate an entry to the TLS "ContentType" <del> registry, for the "return_routability_check(TBD2)" defined in this document.  The "return_routability_check" content type is only </del>  applicable to DTLS 1.2 and 1.3. IANA is requested to allocate the extension code point (TBD1) for the "rrc" extension to the "TLS ExtensionType Values" registry as described in tbl-ext. <del> 9. </del>  Issues against this document are tracked at https://github.com/tlswg/ dtls-rrc/issues <del> 10. </del>  We would like to thank Achim Kraus, Hanno Becker, Hanno Boeck, Manuel Pegourie-Gonnard, Mohit Sahni and Rich Salz for their input to this

Reviewer comments:
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

Revised text:
before cryptographically validating the enclosed record(s) but instead perform a return routability check.  <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:  <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  <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  <ins> path_response. </ins> When the initiator receives and verifies the "return_routability_check" message contains the sent cookie, it  <ins> updates the peer address binding. </ins> If T expires, or the address confirmation fails, the peer address binding is not updated. for the initiator and responder roles, broken down per protocol phase.  <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 sending direction) up to the anti-amplification limit to probe if the path MTU (PMTU) for the new path is still acceptable.  <ins> 7.2. </ins>  <ins> The responder MUST NOT delay sending an elicited path_response or path_delete messages. </ins>  <ins> The responder MUST send exactly one path_response or path_delete message for each received path_challenge. </ins>  <ins> The responder MUST send the path_response or the path_delete on the path where the corresponding path_challenge has been received, so that validation succeeds only if the path is functional in both directions.  The initiator MUST NOT enforce this behaviour. </ins> The initiator MUST silently discard any invalid path_response it receives. If the responder wants to do PMTU discovery using RRC, it should initiate a new path validation procedure.  <ins> 7.3. </ins> When setting T, implementations are cautioned that the new path could have a longer round-trip time (RTT) than the original. constrained networks I-D.ietf-uta-tls13-iot-profile - MAY specify a different, more suitable value.  <ins> 8. </ins> The example TLS 1.3 handshake shown in fig-handshake shows a client and a server negotiating the support for CID and for the RRC However, the server wants to test the reachability of the client at his new IP address.  <ins> 9. </ins> Note that the return routability checks do not protect against flooding of third-parties if the attacker is on-path, as the attacker those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity.  <ins> 10. </ins> IANA is requested to allocate an entry to the TLS "ContentType"  <ins> registry, for the "return_routability_check(TBD2)" message defined in this document.  The "return_routability_check" content type is only </ins> applicable to DTLS 1.2 and 1.3. IANA is requested to allocate the extension code point (TBD1) for the "rrc" extension to the "TLS ExtensionType Values" registry as described in tbl-ext.  <ins> 11. </ins> Issues against this document are tracked at https://github.com/tlswg/ dtls-rrc/issues  <ins> 12. </ins> We would like to thank Achim Kraus, Hanno Becker, Hanno Boeck, Manuel Pegourie-Gonnard, Mohit Sahni and Rich Salz for their input to this