Subject: [Last-Call] Secdir last call review of draft-ietf-ntp-mode-6-cmds-08

From: Daniel Franke via Datatracker <[email-masked]>
Date: Sat, 13 Jun 2020 08:18:09 -0700

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.

---

From: Brian Haberman <[email-masked]>
Date: Sat, 13 Jun 2020 14:15:21 -0400

Thanks for the review, Daniel. A quick follow-up below for those of you
playing along at home...

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

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.

Regards,
Brian

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 13 Jun 2020 17:26:00 -0700

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

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
> 

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

---

From: Karen O'Donoghue <[email-masked]>
Date: Sun, 14 Jun 2020 00:10:27 -0400

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 <[email-masked]> wrote:
>

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 13 Jun 2020 21:53:55 -0700

The working group consensus is wrong, at least in this case.

H

---

From: Brian Haberman <[email-masked]>
Date: Sun, 14 Jun 2020 09:40:51 -0400

> The working group consensus is wrong, at least in this case.

That is for the shepherding AD and IESG to decide.

---

From: Harlan Stenn <[email-masked]>
Date: Sun, 14 Jun 2020 13:46:45 -0700

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

---

From: Brian Haberman <[email-masked]>
Date: Mon, 15 Jun 2020 11:29:43 -0400

Hi Harlan,

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

> reports of it being used.  Furthermore, it was implemented USING MODE 6

Not sure why you would implement SNMP support via an NTP auxiliary
protocol, but that is your choice.

> implementations to they work on?

I would need someone from Cisco to verify, but it seems like their
implementation is based on 5907.

> that do the same with ntpq.

I am not going to dignify that demand with a response. The WG consensus
is the WG consensus.

Regards,
Brian

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 20 Jun 2020 03:15:28 -0700

Hi Brian,

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

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

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

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