Change:
those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity. <del> 8. </del> <ins> 10. </ins> 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> <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. <del> 9. </del> <ins> 11. </ins> Issues against this document are tracked at https://github.com/tlswg/ dtls-rrc/issues <del> 10. </del> <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

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