Skip to main content

Last Call Review of draft-ietf-ntp-port-randomization-06
review-ietf-ntp-port-randomization-06-tsvart-lc-trammell-2021-02-23-00

Request Review of draft-ietf-ntp-port-randomization
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2021-02-25
Requested 2021-02-11
Authors Fernando Gont , Guillermo Gont , Miroslav Lichvar
I-D last updated 2021-02-23
Completed reviews Tsvart Last Call review of -06 by Brian Trammell (diff)
Secdir Last Call review of -06 by Sean Turner (diff)
Genart Last Call review of -06 by Meral Shirazipour (diff)
Assignment Reviewer Brian Trammell
State Completed
Request Last Call review on draft-ietf-ntp-port-randomization by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/OyTABj6UQPbop9EZ0U189g_jWS8
Reviewed revision 06 (document currently at 08)
Result Ready w/nits
Completed 2021-02-23
review-ietf-ntp-port-randomization-06-tsvart-lc-trammell-2021-02-23-00
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.

This document is ready from a transport standpoint. It describes an
already-implemented, relatively-straightforward application of an existing BCP
to a well-understood protocol, and is clearly written. I especially appreciated
the complete set of considerations, covering situations in which NTP port
randomization could cause issues with certain deployment scenarios. The effect
of routing on NTP is well studied (one such study is cited in the draft), and
sections 3.3 and 3.4 discuss how this draft could interact with on-path
modification of NTP traffic. Herein lies my only nit with the draft: it would
be nice if 3.3 and 3.4 discussed how an NTP-speaking endpoint could detect and
react to issues caused by misconfigured filtering or NAT.