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

Harlan Stenn <stenn@nwtime.org> Sun, 14 June 2020 20:46 UTC

Return-Path: <stenn@nwtime.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECBC3A128A; Sun, 14 Jun 2020 13:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnXzzvNPCkL2; Sun, 14 Jun 2020 13:46:46 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8013A1230; Sun, 14 Jun 2020 13:46:46 -0700 (PDT)
Received: from [10.208.75.157] (075-139-194-196.res.spectrum.com [75.139.194.196]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 49lRMp04sfzL7c; Sun, 14 Jun 2020 20:46:45 +0000 (UTC)
To: Karen O'Donoghue <kodonog@gmail.com>
Cc: Brian Haberman <brian@innovationslab.net>, Daniel Franke <dafranke@akamai.com>, secdir@ietf.org, draft-ietf-ntp-mode-6-cmds.all@ietf.org, last-call@ietf.org, ntp@ietf.org
References: <ea8aff7c-35fa-6d64-3a75-21b31b45a9d9@nwtime.org> <13D6D5C7-090A-4C68-8F0B-EA6DE18FB1E9@gmail.com>
From: Harlan Stenn <stenn@nwtime.org>
Autocrypt: addr=stenn@nwtime.org; keydata= mQGNBFI2xmQBDACrPayw18eU4pIwCvKh7k0iMkAV9cvzs49kBppM+xoH+KKj4QWmkKELD39H ngQnT3RkKsTLlwxyLqPdUmeQNAY2M5fsOK+OF6EvwLPK9hbmE3Wx2moX+sbEUxJ2VzFhKSKb OPZALXwk1XxL0qBedz0xHYcDwaSAZZkEFXURv2pDIdrmnoUnq2gdC8GpoFJiXoUaCLSYzzaY ac4Njw7Mue8IqfzRQb70aMjXl/qmsmfmEVAyGXywDdc/ler4XSgiuYOV7Kf69bj9PFZZSMdJ MWgEyZH6lJ0TU5ccR2zp5ZRmWzQQkxJMyH2th7q0Nmz3aX4A0K4yE0Ba9/5Dr7ctpF15BrMF aEo4s5lwI6tUnkgMWo265mMzCz4mAPV/ac0w0OXQg7r9E2r0+dRapnzUlG43D0JLDqDr9uRR L6IrRQqoCWUC75lfmPYQYSlaTJaK68r3lXd0z1cXJUgVtEL5H3/Z71R2B20twcQVAnw2iIH6 L5vdrsIjHrMmkqRVbs9nNyEAEQEAAbQ5SGFybGFuIFN0ZW5uIChOZXR3b3JrIFRpbWUgRm91 bmRhdGlvbikgPHN0ZW5uQG53dGltZS5vcmc+iQG5BBMBAgAjBQJSNsblAhsvBwsJCAcDAgEG FQgCCQoLBBYCAwECHgECF4AACgkQyIwAt1pH+kBlzgv/QOg70vdj8wU/z97UPdlbxtN4THAB gfSX4N0VPKT5fjX1tFhuXZQAOv7wedR3Trh7TGteyg33TBAFf9A42mXZKi1IxAiQG118Hd8I 51rXwnugURIYQaIyQI+vbchRbwVyz+mVLTI/h6FdbsVzT4UFmir+ZMkb/XeZPu0HItk4OZHE 6hk+TuTiCnlqlCPLq371fXV54VOb91WZYD8EQFtK02QHGHsQqWvapdphiDVpYehmsPyiTESq NMKLVtjtyPkQ6S7QF3slSg+2q3j8lyxEA78Yl0MSFNU8B/BtKgzWP2itBOfi+rtUKg+jOY1V /s2uVk2kq2QmHJ/s5k5ldy3qVvoTpxvwBe0+EoBocTHYt+xxp0mTM6YY1xLiQpLznzluqg9z qtejX1gZOF4mgLiBIrhXzed3zsAazhTp5rNb1kn0brZFh6JC5Wk941eilnA4LqX8AWo0lmwo eb+mpwZK/5lNdage/anpVqft9wJ/8EcvST9TLUO4fPrmT3d/0LpWuQGNBFI2xmQBDADXLsBk I7CSa5UXlrNVFJQHER1VxRBKqjWWCh/8Qv9v3p3NrIc2UnhoZ1uWQ2voBGty5Xfy9k4afV5k WwDyRDUIb7PX+Tj4HjVVr7qvnOVe/0KzZpNq0Azd0ggFbsM+8mydktHIwJykW0NUsGwPRYuD OA0Lro0ohb5IiCt3sSQi1X1hYjo7O1Vmn8Gy/XYOnhnMux+5zDPO2yTkCNX5PocYi9IJJy6p Mq1yQV4Y2Dl8KtQzvtq55vCUxx6n0MMzFViGwNW6F4ge9ItO4tDScsgowDrHa208ehwOpv/i wjf93lCClQ6vaKmOBX872K/tdY/hwhxPPjgl1bcrOwMRYVemOPPehwnXH5bwclk1hvDQdkJQ 5pJOkE4VCryTF/iDAt4g2QnHocUwt3b6/ChUUWmj2GZ22OR12rbnCtLedwp0DpViKPUCQHBO vpgXdzE/L9zWar9fqM0EREMgfWbsJc9028qluCcFLIN1gYsq4cC+YGAcOu7HOI5orBBV4m9j XfsAEQEAAYkDPgQYAQIACQUCUjbGZAIbLgGpCRDIjAC3Wkf6QMDdIAQZAQIABgUCUjbGZAAK CRDfCQ/G52/8P/uWDACe7OEM+VETDRqjQgAwzX+RjCVPvtgrqc1SExS0fV7i1mUUxr/B8io3 Y1cRHFoFKmedxf8prHZq316Md5u4egjFdTT6ZqEqkK0hvv+i0pRpCa5EX9VIStcJStomZp8F cY34grA+EOWITaLQ4qNZUP7rf2e7gq1ubQTj7uLr6HZZvMZ5em+IvrOWEuWDI6yOiI6px04w RDfkoR2h6kgdw4V0PT4NjK9WYYKrVCf1bjLlVImNBEcXfvlUTrIYO8y6ptvoUsBQky5pQRvP 99Pn42WfyLy50aII6+vyudD4T0yLjXAz4KteUttxtIte64m/F9/7GEIZAxTUcLyOq/7bP4le h39jBckwc62iYzeK/VkU/bMMh2D68Z3QylMnhhcW27BcgQHPKsHhmFa2SNytYcuQiSdf9+pj 4i32ETz1nJAvYAAqgTF/0PL+8ZNQoEpe/n9woMKrlZrqD4EgFmhQ3bNVhlaXz1nuTZDrwPt1 yMxBuUNbCF4jFnaruwrSiGTRoIfUZQwAjQglahrV4/mcjfnvbNoseHX0PKd9q+wjg7MIjWqr f2CI8Fa6MdanqwYphz43I2yXANKFZuMWsWqyQYlvGuPUlUUcAL3stp24RkzDB1Q+JS0IZJST T2JSu0aTfUdWVNqr2UI19eX+zxbOTckSi3Ng14ezG8ZX194ZH10b8JzntQOwmA20pd5JDhug zQfASER+CZDiPPcQ4mvC4y7rMrfV6XGQbDynC3ekDxo8SC5SvjaczXMwXg6SZ8iFtEWmEwW9 r7zPjjIPDrX8w5LXBgxArM5o/HbERpc2EdAvMh1D7LC0SvmoE7fBKxsicVBe4h6vXjEZ+LLr /wuZiBld9OnxAUIpwptbBspO6WKTQYvgFH2OeDG27hiE5P4Xs4WSp5j9ez8OVB1iZnA2nCQ+ tNTjO8c+C/P92vPLx5+bpGRXTXMNaLh34PS3ZsYoUDkKZNhczRZUWJ7nynSbeeyF+QW7SLwA qY7O7dyk9LFTsfJqRQJ7tWnIAjJPCwmSgQ8Kl0UJ
Message-ID: <5689163e-1113-ff97-b94c-2d8d3550cafb@nwtime.org>
Date: Sun, 14 Jun 2020 13:46:45 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <13D6D5C7-090A-4C68-8F0B-EA6DE18FB1E9@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/zhuBvbiGb93BIejX2cNob44nK2E>
Subject: Re: [secdir] [Ntp] Secdir last call review of draft-ietf-ntp-mode-6-cmds-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Jun 2020 20:46:52 -0000


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.

I recall discussion about this in the WG meetings I attended.

Was the "final" decision made at the WG meeting I was unable to attend,
the meeting where all of the other proposals I had in various stages of
adoption were ... removed from consideration by the WG?

> As described, there were concerns about the solution.

I don't know what you mean by "the solution" - please clarify?

I also don't know what these "concerns" are.  Please clarify.

> The working group has gone back and forth between historic and informational.  

It should be Standards track, and optional implementation.

H
--
> Regards,
> Karen 
> 
>> On Jun 13, 2020, at 8:27 PM, Harlan Stenn <stenn@nwtime.org> 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
>>> ntp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ntp
>>>
>>
>> -- 
>> Harlan Stenn <stenn@nwtime.org>
>> http://networktimefoundation.org - be a member!
>>
>> _______________________________________________
>> ntp mailing list
>> ntp@ietf.org
>> https://www.ietf.org/mailman/listinfo/ntp
> 

-- 
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!