Original text:
5. RRC offers an in-protocol mechanism to perform peer address <del> validation, thus complementing the "peer address update" procedure </del>  described in RFC9146.  Specifically, when both CID RFC9146 and RRC have been successfully negotiated for the session, if a record with CID is received that has the source address of the enclosing UDP 6. <del> RRC is designed to withstand the following attacks: </del>  <del> On-path attackers that try to trigger a connection migration (on- path); </del>  <del> Off-path attackers that try to put themselves on-path (off-path) - provided that the enhanced path validation algorithm is used, see enhanced. </del>  <del> It is not possible for RRC to counter a man-in-the-middle attacker that is indistinguishable from a genuine network device.  Such an attacker could, for example, drop, reorder or delay records at will. Man-in-the-middle attackers cannot craft DTLS records that would successfully pass verification due to the cryptographic protections applied by the DTLS record layer. </del>  6.1. <del> An on-path attacker could make a copy of a packet, replace the source address with a spoofed one and forward it to the original destination.  If the spoofed packet arrives before the original it will be regarded as a migration, while the original packet will be flagged as a duplicate and dropped. The subsequent path validation (path-validation) will fail because the entity at the (spoofed) source address does not have the cryptographic keys needed to decode the "path_challenge" message that is sent to it, and therefore to produce the corresponding "path_response".  Since the path validation fails, the address binding is not altered, thus thwarting the attack. </del>  6.2.

Reviewer comments:
Signed-off-by: Thomas Fossati
cc NAME
From my side LGTM.
For me, "man-in-the-middle" is a synonym for "on-path". If that text addresses the general "on-path" attacks in order to clarify, that RRC is no mitigation for these general "on-path-attacks", I think we should try to find an other text. As idea, we may also refer to ideas to mitigate them, but explicitly exclude that from this draft. e.g.: "reorder": don't use the record sequence number window, just drop all packets with no higher number (that drops then reordered packets). "delay records": maybe the first idea for an extension: execute a fresh RRC exchange and the next ip-packet must have a record sequence number higher as the one of the RRC message.
Right, we need to align the terminology. I propose we use the with its three levels: Inspect Inject Reorder injected ——— Off-path ——— Reorder original Modify un-authenticated portions ——— Limited on-path ——— Delay Drop Manipulating the packetization layer ——— On-path ——— and work from there.
I miss, that I'm not sure, if we should "repeat" that. Do you know, if it's possible to just refer to that?
If it works for us as-is we can just reference the relevant sections. We need to check that everything applies -- in particular whether we want to make the distinction between "on-path" and "limited on-path".
In difference to the on-path attack, where the original packet (with the original source address) simply may get dropped, and so never reaches the destination, the off-path attack is not able to drop that original packet. Though also this attack is based on a response to that "malicious source address", a implementation may use the "internal processing delay" and check, if the same packet with the original address arrives. If so, and if that address matches the previously associated address, then the implementation may chose to use the previously associated address.
For me this looks more like the off-path case. On-path attacker may just replace the original package and only forward the spoofed one.
See also my comment on . We need to rework this section starting from establishing shared terminology.

Revised text:
5. RRC offers an in-protocol mechanism to perform peer address  <ins> validation that complements the "peer address update" procedure </ins> described in RFC9146.  Specifically, when both CID RFC9146 and RRC have been successfully negotiated for the session, if a record with CID is received that has the source address of the enclosing UDP 6.  <ins> We define two classes of attackers, off-path and on-path, with increasing capabilities (see fig-attacker-capabilities) partly following terminology introduced in QUIC RFC9000: </ins>  <ins> An off-path attacker is not on the original path between the DTLS peers, but is able to observe packets on the original path and has faster routing compared to the DTLS peers, which allows it to make copies of the observed packets, race its copies to either peer and consistently win the race. </ins>  <ins> An on-path attacker is on the original path between the DTLS peers and is therefore capable, compared to the off-path attacker, to also drop and delay records at will. </ins>  <ins> Note that in general, attackers cannot craft DTLS records in a way that would successfully pass verification due to the cryptographic protections applied by the DTLS record layer. RRC is designed to defend against the following attacks: On-path and off-path attackers that try to create an amplification attack by spoofing the source address of the victim (sec- amplification). Off-path attackers that try to put themselves on-path (off-path), provided that the enhanced path validation algorithm is used (enhanced). </ins> 6.1.  <ins> Both on-path and off-path attackers can send a packet (either by modifying it on the fly, or by copying, injecting and racing it, respectively) with the source address modified to that of a victim host.  If the traffic generated by the server in response is larger compared to the received packet (e.g., a CoAP server returning an MTU's worth of data from a 20-bytes GET request) the attacker can use the server as a traffic amplifier toward the victim. When receiving a packet with a known CID and a spoofed source address, an RRC-capable endpoint will not send a (potentially large) response but instead a small "path_challenge" message to the victim host.  Since the host is not able to decrypt it and generate a valid "path_response", the address validation fails, which in turn keeps the original address binding unaltered. Note that in case of an off-path attacker, the original packet still reaches the intended destination; therefore, an implementation could use a different strategy to mitigate the attack. </ins> 6.2.