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 tsv-art@ietf.org 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