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

[Harlan Stenn <[e-mail]>]

On 6/14/2020 1:04 PM, Ulrich Windl wrote:
> 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.

Daniel, you really want people to believe that 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.

Exactly what are you proposing regarding replacing mode 6 with SNMP?

How would this work?  Would you want to add all the needed SNMP bits to
ntpd?  If not, how would the external SNMP beast communicate with ntpd?

Mode 6 operations have not changed very much over the years.  I do
recall many years ago when Dave changed jitter to dispersion, as I
recall.  We've added more items, to be sure.

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

Please clarify "instability".

And regardless, as I ask above, where do you propose the SNTP machinery
would live?

I've long advocated for improvements in the mode 6 setup.  We have
several scheduled for an upcoming release of the Reference Implementation.

>>
>>> Regards,
>>> Brian

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!