Draft: draft-ietf-tls-dtls-rrc

Commentary: Update DTLS 1.3 and CID refs Make the pictures SVG - friendly ( see and below . ) ( Also , see for installation instructions . )
A CID is an identifier carried in the record layer header of a DTLS
datagram that gives the receiver additional information for selecting
the appropriate security context.  The CID mechanism has been
specified in I-D.ietf-tls-dtls-connection-id for DTLS 1.2 and in I-
D.ietf-tls-dtls13 for DTLS 1.3.
Section 6 of I-D.ietf-tls-dtls-connection-id describes how the use of
CID increases the attack surface by providing both on-path and off-
path attackers an opportunity for (D)DoS.  It then goes on describing
the steps a DTLS principal must take when a record with a CID is
received that has a source address (and/or port) different from the
one currently associated with the DTLS connection.  However, the
actual mechanism for ensuring that the new peer address is willing to
receive and process DTLS records is left open.  This document
standardizes a return routability check (RRC) as part of the DTLS
protocol itself.
A CID is an identifier carried in the record layer header of a DTLS
datagram that gives the receiver additional information for selecting
the appropriate security context.  The CID mechanism has been
specified in RFC9146 for DTLS 1.2 and in RFC9147 for DTLS 1.3.
Section 6 of RFC9146 describes how the use of CID increases the
attack surface by providing both on-path and off-path attackers an
opportunity for (D)DoS.  It then goes on describing the steps a DTLS
principal must take when a record with a CID is received that has a
source address (and/or port) different from the one currently
associated with the DTLS connection.  However, the actual mechanism
for ensuring that the new peer address is willing to receive and
process DTLS records is left open.  This document standardizes a
return routability check (RRC) as part of the DTLS protocol itself.
This document assumes familiarity with the CID format and protocol
defined for DTLS 1.2 I-D.ietf-tls-dtls-connection-id and for DTLS 1.3
I-D.ietf-tls-dtls13.  The presentation language used in this document
is described in Section 4 of RFC8446.
This document assumes familiarity with the CID format and protocol
defined for DTLS 1.2 RFC9146 and for DTLS 1.3 RFC9147.  The
presentation language used in this document is described in Section 4
of RFC8446.
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.
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.
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.
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.
An off-path attacker that can observe packets might forward copies of
genuine packets to endpoints over a different path.  If the copied
packet arrives before the genuine packet, this will appear as a path
change, like in a genuine NAT rebinding occurrence.  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 the
same or better characteristics (e.g., due to a more favourable
service level agreements) 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.  Therefore, eliciting packets on this path increases
the likelihood that the attack is unsuccessful.  Note however that,
unlike QUIC, DTLS has no "non-probing" packets so this would require
application specific mechanisms.
fig-off-path illustrates the case where a receiver receives a packet
with a new source IP address and/or new port number.  In order to
determine whether this path change was not triggered by an off-path
attacker, the receiver will send a RRC message of type
"path_challenge" (1) on the old path.
Case 1: The old path is dead (e.g., due to a NAT rebinding), which
leads to a timeout of (1).
As shown in fig-old-path-dead, a "path_challenge" (2) needs to be
sent on the new path.  If the sender replies with a "path_response"
on the new path (3), the switch to the new path is considered
legitimate.
This case is shown in fig-old-path-not-preferred whereby the sender
replies with a "path_delete" message (2) on the old path.  This
triggers the receiver to send a "path_challenge" (3) on the new path.
The sender will reply with a "path_response" (4) on the new path,
thus providing confirmation for the path migration.
This is most likely the result of an off-path attacker trying to
place itself on path.  The receiver sends a "path_challenge" on the
old path and the sender replies with a "path_response" (2) on the old
path.  The interaction is shown in fig-old-path-preferred.  This
results in the connection not being migrated to the new path, thus
thwarting the attack.
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.
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
path_response.
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
"path_response".
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.
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.
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.
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.
The initiator MAY send multiple "return_routability_check"
messages of type path_challenge to cater for packet loss on the
probed path.
The transmission of subsequent path_challenge messages SHOULD
be paced to decrease the chance of loss.
Each path_challenge message MUST contain random data.
The initiator MAY send multiple "return_routability_check"
messages of type "path_challenge" to cater for packet loss on the
probed path.
The transmission of subsequent "path_challenge" messages SHOULD
be paced to decrease the chance of loss.
Each "path_challenge" message MUST contain random data.
The responder MUST NOT delay sending an elicited path_response or
path_delete messages.
The responder MUST send exactly one path_response or path_delete
message for each received path_challenge.
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.
The initiator MUST silently discard any invalid path_response it
receives.
The responder MUST NOT delay sending an elicited "path_response"
or "path_delete" messages.
The responder MUST send exactly one "path_response" or
"path_delete" message for each received "path_challenge".
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.
The initiator MUST silently discard any invalid "path_response" it
receives.