Draft: draft-ietf-tls-dtls-rrc

Commentary: Address 
    ballot comment on draft - ietf - dtls - connection - id referenced the procedures of ( 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 does n'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
The newly introduced "return_routability_check" message contains a
cookie.  The cookie is a 8-byte field containing arbitrary data.
The cookie is a 8-byte field containing arbitrary data.
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.
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.
Note: This algorithm does not take the off-path scenario into
account.
The message is sent to the observed new address and a timer T (see
timer-choice) is started.
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.
When the initiator receives and verifies the
"return_routability_check" message contains the sent cookie, it
updates the peer address binding.
Note: This algorithm also takes the off-path scenario into account.
The message is sent to the previously valid address, which
corresponds to the old path.  Additionally, a timer T, see timer-
choice, is started.
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.
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.
The responder MUST NOT delay sending an elicited path_response
message.
The responder MUST send exactly one path_response messages for
each received path_request.
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 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.
IANA is requested to allocate an entry to the TLS "ContentType"
registry, for the "return_routability_check(TBD2)" defined in this
document.  The "return_routability_check" content type is only
applicable to DTLS 1.2 and 1.3.
IANA is requested to allocate an entry to the TLS "ContentType"
registry, for the "return_routability_check(TBD2)" message defined in
this document.  The "return_routability_check" content type is only
applicable to DTLS 1.2 and 1.3.