Re: [Ntp] [EXT] Re: Secdir last call review of draft-ietf-ntp-mode-6-cmds-08

[Ulrich Windl <[e-mail]>]

On 6/14/20 2:26 AM, Harlan Stenn wrote:
> 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.

SNMP may be more standard _if_ there is a stable set of NTP operations 
established, but the latter obviously is not the case.

> 
> 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.

With the instability of mode 6 commands this is not a fair comparison IMHO.

> 
>> Regards,
>> Brian
>>
>>
>> _______________________________________________
>> ntp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ntp
>>
>