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

[Harlan Stenn <[e-mail]>]

On 6/14/2020 2:08 PM, Ulrich Windl wrote:
> On 6/14/20 6:53 AM, Harlan Stenn wrote:
>> The working group consensus is wrong, at least in this case.
>>
> 
> Harlan,
> 
> some times even the president is wrong... ;-)

Yes.  So what?

H
--
> Ulrich
> 
>> H
>>
>> On 6/13/2020 9:10 PM, Karen O'Donoghue wrote:
>>> Folks,
>>>
>>> All of this was discussed during the development of this document.
>>> There was strong working group consensus to not publish as Standards
>>> Track. As described, there were concerns about the solution. The
>>> working group has gone back and forth between historic and
>>> informational.
>>>
>>> Regards,
>>> Karen
>>>
>>>> On Jun 13, 2020, at 8:27 PM, Harlan Stenn <[e-mail]> 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.
>>>>
>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ntp
>>>>>
>>>>
>>>> -- 
>>>> Harlan Stenn <[e-mail]>
>>>> http://networktimefoundation.org - be a member!
>>>>
>>>> _______________________________________________
>>>> ntp mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ntp
>>>
>>
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp

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