Subject: [Ntp] I-D Action: draft-ietf-ntp-mode-6-cmds-11.txt

From: [email-masked]
Date: Tue, 15 Feb 2022 09:57:47 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Time Protocols WG of the IETF.

        Title           : Control Messages Protocol for Use with Network Time Protocol Version 4
        Author          : Brian Haberman
	Filename        : draft-ietf-ntp-mode-6-cmds-11.txt
	Pages           : 22
	Date            : 2022-02-15

Abstract:
   This document describes the structure of the control messages that
   were historically used with the Network Time Protocol before the
   advent of more modern control and management approaches.  These
   control messages have been used to monitor and control the Network
   Time Protocol application running on any IP network attached
   computer.  The information in this document was originally described
   in Appendix B of RFC 1305.  The goal of this document is to provide
   an updated description of the control messages described in RFC 1305
   in order to conform with the updated Network Time Protocol
   specification documented in RFC 5905.

   The publication of this document is not meant to encourage the
   development and deployment of these control messages.  This document
   is only providing a current reference for these control messages
   given the current status of RFC 1305.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ntp-mode-6-cmds/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-mode-6-cmds-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-mode-6-cmds-11

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 15 Feb 2022 19:07:02 -0800

Brian,

>     specification documented in RFC 5905.

Yup...

>     given the current status of RFC 1305.

I'm curious why you write the preceding paragraph.

Mode 6 is still the preferred way to handle monitoring and control of an 
NTP daemon.  Mode 6 was designed to be a vendor-neutral way to 
accomplish this.

The only implementation I know of for NTP+SNMP is ntpsnmpd, in the 
Reference Implementation, and that daemon translates SNMP in to mode 6 
directives.

The NTP Yang Data Model is still a draft document, and from what I have 
seen there is no reference implementation of it.  If and when the NTP 
Project provides this capability, it will very likely be done the same 
way - using mode 6 messages to the NTP daemon.

> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
> 

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

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 16 Feb 2022 10:12:56 +0100

On Tue, Feb 15, 2022 at 07:07:02PM -0800, Harlan Stenn wrote:
> Mode 6 is still the preferred way to handle monitoring and control of an NTP
> daemon.  Mode 6 was designed to be a vendor-neutral way to accomplish this.

Do you have an example of an NTP implementation that fully supports or
is planning to support the mode 6, that is not based on the ntp.org
code?

I don't think that is possible as other implementations have different
variables, states, and syntax of their configuration files.

> The only implementation I know of for NTP+SNMP is ntpsnmpd, in the Reference
> Implementation, and that daemon translates SNMP in to mode 6 directives.

Ok, but how is that relevant to your objection? For internal
communication between your components, you can use any protocol you
like. It doesn't have to be standardized.

SNMP has a nice advantage over mode 6 that it is running on a
different port and can be easily blocked without blocking
synchronization of clocks. I think at this point, most people here
will agree that monitoring and management should have never been
combined with the rest of NTP.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 16 Feb 2022 02:28:02 -0800

> variables, states, and syntax of their configuration files.

This is something that should be discussed.

We (Dave Mills and the NTP Project) have long held the position that the 
Network Time Protocol is a combination of the on-wire protocol and the 
algorithms.

This is because, and I am not phrasing this in the best possible way, 
the purpose of NTP is to synchronize time, and a SIGNIFICANT component 
of that time is (well) defined "impulse response".

I submit that in order to observe and validate proper behavior, one must 
be able to query an NTP server for some set of variables that can be 
used to demonstrate that the server is following the prescribed behavior.

I expect that this goal will be somewhat elusive, or at best will 
require a means to know what (sub)set of variables are available.
I full well expect that the list will change and evolve over time.

> like. It doesn't have to be standardized.

It goes to refute the claim that mode 6 is not needed because the 
(unspecified) "other means" to determine the ongoing behavior of an NTP 
instance is sufficient to demonstrate proper behavior, in the general case.

> combined with the rest of NTP.

So what?  What is this other generally available, defined, and useful 
way to monitor and control NTP besides mode 6?

Mode 6 has been around and useful for about as long as NTP has been in 
use.  For a big chunk of that time, there was good overlap between mode 
6 (which was trying to be a "standard" way to do monitoring and control) 
and mode 7 (which was always advertised as "vendor-specific").

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 16 Feb 2022 12:01:34 +0100

>>> Harlan Stenn <[email-masked]> schrieb am 16.02.2022 um 04:07 in
Nachricht
<[email-masked]>:
> Brian,
> 
> On 2/15/2022 9:57 AM, internet‑[email-masked] wrote:
>> 
>> A New Internet‑Draft is available from the on‑line Internet‑Drafts
directories.
>> 	Filename        : draft‑ietf‑ntp‑mode‑6‑cmds‑11.txt
>> 	Pages           : 22
>> 	Date            : 2022‑02‑15
>> 
>> Abstract:

Maybe it's like alcohol: Government does not want you to drink, but people
like to do so from time to time ;-)

> NTP daemon.  Mode 6 was designed to be a vendor‑neutral way to 
> accomplish this.
> 
> way ‑ using mode 6 messages to the NTP daemon.
> 
>> 
>> https://datatracker.ietf.org/doc/draft‑ietf‑ntp‑mode‑6‑cmds/ 
>> 
>> https://datatracker.ietf.org/doc/html/draft‑ietf‑ntp‑mode‑6‑cmds‑11 
>> 
>> https://www.ietf.org/rfcdiff?url2=draft‑ietf‑ntp‑mode‑6‑cmds‑11 
>> 
>> 
>> Internet‑Drafts are also available by rsync at
rsync.ietf.org::internet‑drafts
> ‑‑ 
> http://networktimefoundation.org ‑ be a member!
>

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 16 Feb 2022 12:32:52 +0100

>>> Miroslav Lichvar <[email-masked]> schrieb am 16.02.2022 um 10:12 in
Nachricht <YgzAGLjgPjJXxhzi@localhost>:
> On Tue, Feb 15, 2022 at 07:07:02PM ‑0800, Harlan Stenn wrote:
NTP
>> daemon.  Mode 6 was designed to be a vendor‑neutral way to accomplish
this.
> is planning to support the mode 6, that is not based on the ntp.org

Do you have an example of any other NTP implementation that has a published
management protocol?
chrony definitely not!

> variables, states, and syntax of their configuration files.

If both are NTP, there should be a common subset, I guess.

>> The only implementation I know of for NTP+SNMP is ntpsnmpd, in the
Reference
>> Implementation, and that daemon translates SNMP in to mode 6 directives.

SNMP in NTP would be overkill IMHO.

> like. It doesn't have to be standardized.

I object: If you want to monitor multiple NTP servers efficiently from remote,
mode 6 messages are very efficient.

> combined with the rest of NTP.

You can ignore mode 6 packets with ntpd, also, even when using the same port.
I don't know whether people are having fun flooding a port with messages that
are being ignored or denied.

Regards,
Ulrich

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 16 Feb 2022 12:42:42 +0100

> Network Time Protocol is a combination of the on-wire protocol and the

Yes, you made that clear. This was discussed many times before and to
me it doesn't look like the rest of the WG agrees with that.

> This is because, and I am not phrasing this in the best possible way, the
> purpose of NTP is to synchronize time, and a SIGNIFICANT component of that
> time is (well) defined "impulse response".

Most of the algorithms specified in RFC 5905, like the clock filter,
source selection and combining, don't have anything to do with the
impulse response.

What is the point of specifying the algoritms when no implementation
follows them exactly, not even the one on which the specification was
based on?

The ntp.org implementation by default uses the kernel discipline,
which is different from the loop specified in RFC 5905 and has a poor
impulse response. But you insist that others follow it?

> Mode 6 has been around and useful for about as long as NTP has been in use.
> For a big chunk of that time, there was good overlap between mode 6 (which
> was trying to be a "standard" way to do monitoring and control) and mode 7
> (which was always advertised as "vendor-specific").

If mode 6 has been around for so long and it was so useful, I'd expect
to see it adopted in other implementations.

The trouble is that its security issues are causing major problems for
everyone. Other implementations have their own protocols for
monitoring and management, but they are separate from NTP. I think
that is how it should be. A common protocol for everything is not
possible.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 16 Feb 2022 12:58:47 +0100

> Do you have an example of any other NTP implementation that has a published

Right, but I'm not expecting others to implement it. As mode 6, it is
specific to one implementation.
> If both are NTP, there should be a common subset, I guess.

If you can cover only a subset, what do you do with the rest?

> are being ignored or denied.

Yes, ntpd can be and should be configured to ignore all mode 6
messages from Internet. But not everyone does that, and at least some
major ISPs are not able to specifically block only mode 6. 

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Wed, 16 Feb 2022 05:35:29 -0800

> I submit that in order to observe and validate proper behavior, one must  be
> able to query an NTP server for some set of variables that can be used to
> demonstrate that the server is following the prescribed behavior. 

My math geekiness for this sort of stuff is stale.

Why not inject a step in the system time via some back door and monitor the 
response by looking at the system time with NTP mode 3/4 packets?

Or make a step on one of the servers a system is using ...

-------

Is there a good writeup of the requirements for the impulse response?

-- 
These are my opinions.  I hate spam.

---

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 16 Feb 2022 13:40:26 +0000

NTP working group members,

Please remember that we have previously agreed that this document is a historic document. It has been throught the IETF Last Call process and has been in the IESG publication queue for over a year now. This update is just to implement the final language agreed to during that process. Please do not relitigate this document at this time.

Regards,
Karen
________________________________
From: ntp <[email-masked]> on behalf of Miroslav Lichvar <[email-masked]>
Sent: Wednesday, February 16, 2022 6:58 AM
To: Ulrich Windl <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Ntp] Antw: [EXT] Re: I‑D Action: draft‑ietf‑ntp‑mode‑6‑cmds‑11.txt

--
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 16 Feb 2022 13:17:17 -0800

We need a current, proper specification of mode 6 (and mode 7).

On 2/16/2022 5:40 AM, Karen O'Donoghue wrote:
> Please remember that we have previously agreed that this document is a 
> historic document. It has been throught the IETF Last Call process and 
> has been in the IESG publication queue for over a year now. This update 
> is just to implement the final language agreed to during that process. 
> Please do not relitigate this document at this time.
> 
> Regards,
> Karen
> ------------------------------------------------------------------------
> *From:* ntp <[email-masked]> on behalf of Miroslav Lichvar 
> <[email-masked]>
> *Sent:* Wednesday, February 16, 2022 6:58 AM
> *To:* Ulrich Windl <[email-masked]>
> *Cc:* [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
> *Subject:* Re: [Ntp] Antw: [EXT] Re: I‑D Action: 
> draft‑ietf‑ntp‑mode‑6‑cmds‑11.txt
> <https://www.ietf.org/mailman/listinfo/ntp>

---

From: Danny Mayer <[email-masked]>
Date: Wed, 16 Feb 2022 17:58:22 -0500

On 2/16/22 5:28 AM, Harlan Stenn wrote:
> We (Dave Mills and the NTP Project) have long held the position that 
> the Network Time Protocol is a combination of the on-wire protocol and 
> the algorithms.

I have a somewhat different take on this. The network protocol is 
separate from the NTP decision engine but EVERYTHING that the server 
needs is in the NTP packet. The packet is designed to provide all the 
information that the NTP time source has to the receiving NTP server in 
order for that server to do calculations and decide on the best decision 
possible as to a) the best current truechimer and b) the best estimate 
of what the time should be so that the clock can be disciplined in the 
best possible way to provide the most accurate time with as small an 
estimated error as possible.

So the network protocol and the NTP server are tightly intertwined but 
are separate components of the whole.

> I submit that in order to observe and validate proper behavior, one 
> must be able to query an NTP server for some set of variables that can 
> be used to demonstrate that the server is following the prescribed 
> behavior.
>

I agree that it is necessary to monitor the server for information about 
its performance and potential issues and you can't get that kind of 
information from logging. It doesn't mean that it has to be over UDP. 
There is nothing wrong with creating a TCP interface to the server and 
having it done that way. 123/TCP is available...

I haven't heard of other implementations of the NTP protocol providing 
any sort of management interface, even though it is not hard to do.

Danny