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

Harlan Stenn <stenn@nwtime.org> Sun, 14 June 2020 00:26 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 03FF03A0850; Sat, 13 Jun 2020 17:26:04 -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 g-9kAvNDnhSi; Sat, 13 Jun 2020 17:26:02 -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 513023A084F; Sat, 13 Jun 2020 17:26:02 -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)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 49kwHF5td5zL7c; Sun, 14 Jun 2020 00:26:01 +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>
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: <ea8aff7c-35fa-6d64-3a75-21b31b45a9d9@nwtime.org>
Date: Sat, 13 Jun 2020 17:26:00 -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: <4251f262-22f7-3b7d-41d4-e0c3ef1da1b8@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/41DI1xK-nrP5OUN3y0gwaDMSwUo>
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 00:26:04 -0000

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!