Skip to main content

Last Call Review of draft-ietf-ntp-mode-6-cmds-08
review-ietf-ntp-mode-6-cmds-08-secdir-lc-franke-2020-06-13-00

Request Review of draft-ietf-ntp-mode-6-cmds
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-06-15
Requested 2020-06-01
Authors Brian Haberman
Draft last updated 2020-06-13
Completed reviews Opsdir Last Call review of -08 by Linda Dunbar (diff)
Secdir Last Call review of -08 by Daniel Fox Franke (diff)
Genart Last Call review of -09 by Vijay K. Gurbani (diff)
Assignment Reviewer Daniel Fox Franke
State Completed
Review review-ietf-ntp-mode-6-cmds-08-secdir-lc-franke-2020-06-13
Posted at https://mailarchive.ietf.org/arch/msg/secdir/4kfOQGt2mc0LJ3398b9Xf0yhnE0
Reviewed revision 08 (document currently at 11)
Result Ready
Completed 2020-06-13
review-ietf-ntp-mode-6-cmds-08-secdir-lc-franke-2020-06-13-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving security requirements and
considerations in IETF drafts.  Comments not addressed in last call may be
included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

This document describes a historic protocol whose design falls far short of
modern IETF standards. Its myriad issues are well-described in the Security
Considerations section.

There has been some debate as to whether the appropriate status for this
document is Historic or Informational. I believe the currently-intended
Historic status is more appropriate. The argument I have heard repeatedly in
favor of Informational status is that it is not appropriate to classify a
protocol as Historic until a better alternative exists with a published
specification. I believe that better alternative exists, which is to have no
standard at all. It's perfectly fine for NTP monitoring and management
protocols to be vendor-specific. In virtually all legitimate uses ("legitimate"
so as to exclude RDoS attacks), both sides of the protocol run on systems
managed by the same organization and the need for vendor-specific tools is not
a practical issue. Lack of standardization is the already the status quo, since
there are many widely-used NTP implementations out there but only the Network
Time Foundation implementation and its derivatives (such as NTPsec) support
this protocol. I know of nobody who has ever been inconvenienced by this;
standardization is a solution in search of a problem.