Hi Colin, thanks very much for your thorough review. On Thu, Jun 12, 2025 at 05:34:57AM +0100, Colin Perkins via Datatracker wrote:
[...] 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.
At present, we do not have sufficient operational experience to make a recommendation.
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.
Great suggestion. https://github.com/tlswg/dtls-rrc/pull/94/commits/cfd08fac2fc4f44104f4f
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.
Both should work fine.
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.
Good catch! What happened is that very early in the history of the document, we had that statement to mean that the initiator should keep quiet if the responder was doing funky stuff (i.e., sending on another path than the one from where it received the challenge.) To clarify it, we added the line below: "The initiator MUST silently discard [...]" but then forgot to remove that one :-( https://github.com/tlswg/dtls-rrc/pull/94/commits/d074a77565eb33d8885c8
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?
The current algorithm is not designed to handle nested rebindings. If this occurs (hopefully rarely), the path_response message is dropped, and path validation eventually times out. The address is not updated, and a new path validation will be triggered when new data is received.
In Section 6.5, clarify whether the “active path” refers to the old path or the new path.
It's the old. https://github.com/tlswg/dtls-rrc/pull/94/commits/43ff37957017e123ee154 You can take a look at the rfcdiff of the cumulative changes here: https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-tls-dtls-rrc&url_2=https://tlswg.github.io/dtls-rrc/tsvart/draft-ietf-tls-dtls-rrc.txt cheers, thanks again! -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
