Draft: draft-ietf-tls-dtls-rrc

Commentary: Signed - off - by :   
 cc 
 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 " : do n'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     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 .
RRC offers an in-protocol mechanism to perform peer address
validation, thus complementing the "peer address update" procedure
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
datagram different from the one currently associated with that CID
value, the receiver SHOULD perform a return routability check as
described in path-validation, unless an application layer specific
address validation mechanism can be triggered instead.
RRC offers an in-protocol mechanism to perform peer address
validation that complements the "peer address update" procedure
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
datagram different from the one currently associated with that CID
value, the receiver SHOULD perform a return routability check as
described in path-validation, unless an application layer specific
address validation mechanism can be triggered instead.
Off-path attackers that try to put themselves on-path (off-path) -
provided that the enhanced path validation algorithm is used, see
enhanced.
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.
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.
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.
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.
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.
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).
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.