[TLS] draft-ietf-tls-dtls-rrc-15 ietf last call Tsvart review

[Colin Perkins via Datatracker <[e-mail]>]

Document: draft-ietf-tls-dtls-rrc
Title: Return Routability Check for DTLS 1.2 and DTLS 1.3
Reviewer: Colin Perkins
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[e-mail] if you reply to or forward this review.

Thank you for a well-written document that clearly explains the issue to be
addressed and provides a clear description of the solution. Overall, this seems
ready to progress, but I do have a few minor comments to consider.

Section 6 describes the basic and enhanced path validation procedures, and
states that “The decision on what strategy to choose depends mainly on the
threat model, but may also be influenced by other considerations. Examples of
impacting factors include: the need to minimise implementation complexity,
privacy concerns, and the need to reduce the time it takes to switch path. The
choice may be offered as a configuration option to the user of the TLS
implementation”. I agree that those factors influence the decision on what to
implement, but I was surprised that the draft did not give clearer guidance on
whether the basic or enhanced check was recommended.

Section 6.3 states that the return_routability_check messages MAY be sent
multiple times to account for packet loss. This is appropriate, but I would
expect to see some guidance on how often and how frequently these packets
should be resent. For example, should the initiator send the message when the
timer expires, or after one RTT, or more often? Appropriate timing is likely to
be application dependent, since some applications are more sensitive to path
change latency than others, but some guidance (perhaps once per RTT, up to the
anti-amplification limit?) might be appropriate.

Section 6.3 states that “Each path_challenge message MUST contain random data”.
I presume the intent is that each path_challenge message contains a new cookie
with random contents, rather than a single random cookie being generated once
and resent in each retransmission, but it would be helpful to clarify.

Section 6.4 states “The initiator MUST NOT enforce this behaviour”, but I
didn’t understand how the initiator could enforce the behaviour, since it seems
that the responder that makes the decision. Suggest to either remove or clarify
the intent.

Section 6.4 states that “The initiator MUST silently discard any invalid
path_response or path_drop it receives” – this is appropriate, but I wonder
what would happen if another NAT rebinding occurred while the check was
ongoing, such that the path_response arrived from neither the original address
nor the new address but rather from a third address? Would this be counted as
invalid, would it move the path to the third address, or would it trigger
another check?

In Section 6.5, clarify whether the “active path” refers to the old path or the
new path.

Cheers,
Colin