On 6/13/2020 11:15 AM, Brian Haberman wrote:
> Thanks for the review, Daniel. A quick follow-up below for those of you
> playing along at home...
>
> On 6/13/20 11:18 AM, Daniel Franke via Datatracker wrote:
>> Reviewer: Daniel Franke
>> Review result: Ready
>>
>> 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.
>>
>>
>
> Interestingly enough, RFC 1305 actually says this...
>
> "Ordinarily, these functions can be implemented using a
> network-management protocol such as SNMP and suitable extensions to the
> MIB database. However, in those cases where such facilities are not
> available, these functions can be implemented using special NTP control
> messages described herein."
Why is RFC 1305 even being brought up in this situation?
NTPv3 was updated to NTPv4.
During that update, mode 6 and mode 7 were inadvertently not included.
RFC 5905 was developed, as was 5906 and 5907. But mode 6 is still in
active use and deserves a proper, updated specification.
> SNMP exists and the NTP WG published RFC 5907 to cover the MIB support
> needed by NTP. I believe that also counts as a better alternative.
Unbelievable.
TTBOMK, the only implementation of 5907 is the one in the reference
implementation, and in the 12 years it has been out there we have had NO
reports of it being used. Furthermore, it was implemented USING MODE 6
PACKETS!
The only known SNMP interface to ntpd, ntpsnmpd has not seen significant
updates since 2010.
The mode 6 interface to ntpd, ntpq, remains in continuous development
and evolution.
Please identify any other implementations of 5907. If you find any, how
significant are they? Are they proprietary 5907 implementations? What
implementations to they work on?
Please show how SNMP is a better way to monitor and control NTP than ntpq.
Please show me a working deployment of SNMP controlling NTP, and then
please compare the number and quality of these deployments with those
that do the same with ntpq.
> Regards,
> Brian
>
>
> _______________________________________________
> ntp mailing list
> ntp@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ntp
>
--
Harlan Stenn <stenn@xxxxxxxxxx>
http://networktimefoundation.org - be a member!
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
