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

Harlan Stenn <stenn@nwtime.org> Sat, 20 June 2020 10:15 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 C2D983A1120; Sat, 20 Jun 2020 03:15:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 8d07ApU8F0g3; Sat, 20 Jun 2020 03:15:30 -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 E9CBA3A1121; Sat, 20 Jun 2020 03:15:29 -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 49ps4d1rhkzL7c; Sat, 20 Jun 2020 10:15:29 +0000 (UTC)
To: Brian Haberman <brian@innovationslab.net>, Daniel Franke <dafranke@akamai.com>, secdir@ietf.org
Cc: draft-ietf-ntp-mode-6-cmds.all@ietf.org, last-call@ietf.org, ntp@ietf.org
References: <159206148916.27533.2080482554461273224@ietfa.amsl.com> <4251f262-22f7-3b7d-41d4-e0c3ef1da1b8@innovationslab.net> <ea8aff7c-35fa-6d64-3a75-21b31b45a9d9@nwtime.org> <0b850187-0596-c9fd-6667-e571f7ef5ef7@innovationslab.net>
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: <75f032e8-b899-3c96-c351-3cc9b49e165d@nwtime.org>
Date: Sat, 20 Jun 2020 03:15:28 -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: <0b850187-0596-c9fd-6667-e571f7ef5ef7@innovationslab.net>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/a7ZViu5edyKzSyoLPTZigCLak9Y>
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: Sat, 20 Jun 2020 10:15:34 -0000

Hi Brian,

On 6/15/2020 8:29 AM, Brian Haberman wrote:
> Hi Harlan,
> 
> On 6/13/20 8:26 PM, Harlan Stenn wrote:
> 
>>> 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
> 
> Interesting statement... After a cursory search, I found that Cisco
> implemented 5907 in 2012.

That was about 7 years' after my stint at Cisco.

Did they produce a general SNMP monitor for NTP, or did they just
support monitoring the NTP instances in their gear via SNMP?  I suspect
the latter, and I would also bet they used at least our libntpq library
and perhaps some of ntpsnmpd to make it all work.

I was also "loose" in my question above.  It doesn't surprise me that
somebody used 5907 to monitor ntpd running in their gear.  It would
surprise me greatly to learn that somebody wrote an SNMP listener that
talked with NTP instances.

>> 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!
> 
> Not sure why you would implement SNMP support via an NTP auxiliary
> protocol, but that is your choice.

Not what I was saying.  I was saying that it would be a huge amount of
trouble to add SNMP directly to an NTP instance and I haven't been able
to come up with any good reason for even trying to do that.

The easiest way to get SNMP support for NTP is to have your SNMP
listener query NTP for the data, and the only intended standard way to
do this is via mode 6.

>> 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?
>>
> 
> I would need someone from Cisco to verify, but it seems like their
> implementation is based on 5907.

Again, not what I was saying.  It's fine and expected that 5907 be used
for the SNMP mapping side of things, but without a mode 6 mapping to the
data values and interfaces inside NTP, there's no standard way to
connect SNMP with an NTP instance.

I'm also not saying anybody is required to implement mode 6, or 5907.

I *am* saying that there should be a Standard way to do it, with one or
more reference implementations.

Goes to demonstrably proving that the mechanism is complete and functional.

>> 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.
> 
> I am not going to dignify that demand with a response. The WG consensus
> is the WG consensus.

How did you interpret my request as a demand?

Should I take offense from your "I am not going to dignify..." line?

I could ask several questions about "WG consensus", but I really don't
see the point.

What is the point of a Standard if one cannot use it to implement
interoperable behaviors?

Are you saying the WG does not have a responsibility to promulgate a
complete, functional Standard?

I'm attempting to be very respectful here, Brian.

I see you are making statements as the editor (and author) of the
document.  For decades I have been deeply involved in the design,
implementation, deployment, and use of mode 6, and also the one who has
been fielding questions about and involved in discussion about mode 6.

You and those in the WG know my perspective on this.  I believe some
folks agree with me.  Clearly some do not, and I think it's worth
understanding "why".

The working group has gone thru many changes in the past several years,
and the WG will do what the WG will do.

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