Subject: [Ntp] Mode 6 commands draft

From: Brian Haberman <[email-masked]>
Date: Wed, 18 Jul 2018 10:19:51 -0400

All,
     In the NTP session two question arose on the mode 6 commands draft.

     The first question is about the appropriate status for this
document. The draft is currently listed as Informational as the
functionality is in current use by some implementations.

     Changing the status of the document to Historic would be an
indication that the IETF believes the approach has either been
superseded by another specification or is otherwise obsolete. The exact
definition can be found at:
https://tools.ietf.org/html/rfc2026#section-4.2.4

     Given the above, are there people who believe the status should be
changed to Historic?

     The second question relates to the genesis of NTP implementations
that do not support the mode 6 commands. Are any of those
implementations derived from the reference implementation of NTP?

Regards,
Brian

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Wed, 18 Jul 2018 10:45:06 -0400

> On Jul 18, 2018, at 10:19, Brian Haberman <[email-masked]> wrote:
> 

I think that’d be more appropriate.

Ask

-- 
http://askask.com/

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 18 Jul 2018 07:52:51 -0700

I completely disagree.  This document should be at least Informational.

Standards track would be even better, but Informational at least.

The point here is that different implementations need to be able to
perform monitoring between allowed parties, and that requires
standardization.

If somebody does not want to allow that access, that's a "local policy"
choice.  But if it is allowed, it must be standardized (a "mechanism"
choice).

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

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Wed, 18 Jul 2018 11:27:30 -0400

> I think that’d be more appropriate.

Ulrich Windl politely pointed out that it might be helpful to justify my opinion a bit.

I understand the desire to have a standard way to get status information from an ntp server, but anything that’s made today should:

- not use UDP as the application API
- have built-in security
- not be full of details specific to one implementation
- probably build on more modern technologies

Nobody implementing this (as far as I know) and it being disabled in much networks (even causing ntp itself to get disabled in many networks) seems to me to be clear signals that it’s not the right direction.

Ask

-- 
http://askask.com/

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 18 Jul 2018 09:08:25 -0700

> - not use UDP as the application API

For many situations, UDP is just fine for this.

For other situations, that's why I proposed the top-level
draft-stenn-ntp-tcp-services document.

> - have built-in security

Yes, authentication *and* authorization.

> - not be full of details specific to one implementation

The current proposal is not specific to one implementation, it's an
implementation of what was in 1305 that got inadvertently "not included"
in 5905.

Mode 6 is the *standard* query/control mechanism.

Mode 7 is the *vendor-specific* mechanism.

Please also see RFC5907.

Note that I would expect the upcoming YANG proposals to also have this
level of detail on exactly what is offered/required, and how that
information is "presented".

> - probably build on more modern technologies

I'm curious what that means, given in the case of a UDP response that we
have some significant length limitations.

> Nobody implementing this (as far as I know) and it being disabled in much networks (even causing ntp itself to get disabled in many networks) seems to me to be clear signals that it’s not the right…

I see it in fairly heavy use inside the enterprise.  And we have long
supported the requirement for authentication on mode 6 packets, so this
goes more towards people being sloppy with deployments.

---

From: Jared Mauch <[email-masked]>
Date: Wed, 18 Jul 2018 12:20:29 -0400

I would disagree. Most of these are a security threat and should not be exposed to anything but localhost or perhaps a Unix domain socket. 

Look at how bind or nsd handle this for querying diagnostic information. These are good examples that can be replicated easily. 

If we look at the other methods of publishing data take a peek at the pub/sub models used in other applications as well. 

Straight up UDP poses a number of challenges for what is management traffic. 

Jared Mauch

> On Jul 18, 2018, at 12:08 PM, Harlan Stenn <[email-masked]> wrote:
>

---

From: Thomas Peterson <[email-masked]>
Date: Wed, 18 Jul 2018 17:38:00 +0100

I also disagree on the point that UDP is a suitable protocol for query and control operations. 

Whilst client implementations may supply binaries and tools that can communicate on this channel, by choosing a more widely supported and understood protocol we open the doors to much better monitoring and management of time services (something I feel is quite lacking in comparison to tools for managing other services within my networks). I also agree to Jared's comments about traffic management - greater separation of query and command from time synchronisation would be more desirable. DNS is a good example of this, with command functionality (AXFR/IXFR) operating on TCP 53, and querying on UDP 53.

Regards

-----Original Message-----
From: ntp <[email-masked]> on behalf of Harlan Stenn <[email-masked]>
Date: Wednesday, 18 July 2018 at 16:08
To: <[email-masked]>
Subject: Re: [Ntp] Mode 6 commands draft

    

    

    

    Please also see RFC5907.

    

    

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

---

From: Richard Welty <[email-masked]>
Date: Wed, 18 Jul 2018 14:55:18 -0400

> functionality is in current use by some implementations.

mode 6 is in active use. informational is appropriate.

richard

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 19 Jul 2018 07:46:18 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 18.07.2018 um 16:52 in
Nachricht
> choice.  But if it is allowed, it must be standardized (a "mechanism"

s/must/should/

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 19 Jul 2018 07:55:40 +0200

>>> Ask Bjørn Hansen <[email-masked]> schrieb am 18.07.2018 um 17:27 in
Nachricht <[email-masked]>:

> I understand the desire to have a standard way to get status information 
> from an ntp server, but anything that’s made today should:
> 

I think if the protocol is well designed, UDP is acceptable.

> Nobody implementing this (as far as I know) and it being disabled in much 
> networks (even causing ntp itself to get disabled in many networks) seems to

> me to be clear signals that it’s not the right direction.

Sometimes it's over-reaction and panic. When the first internat worm spread,
many admins pulled out the cables in panic... Glady, nobody did suggest to
abandon networking... ;-)

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 19 Jul 2018 10:08:53 +0200

> mode 6 is in active use. informational is appropriate.

I absolutely agree.

ntpd is very widely used, and using mode 6 packets is the default way to
at least monitor the daemon's status.

Some Linux distros even use mode 6 packets to change ntpd's
configuration at runtime. For example if a DHCP client receives NTP
server addresses from the DHCP server, the server is configured
dynamically in ntpd via mode 6 packets, so no manual configuration is
required in huge networks.

Of course it would be great to define a standard way to do all this,
which is compatible with and supported by other implementations, but as
long as there is no such standard way you have to rely on what each
implementation supports. For example:

- Microsoft's NTP implementation w32time uses the "w32tm" tool to
monitor the service status. I'm not aware of a public API that can be
used directly by 3rd party applications.

- chrony uses the "chronyc" tool, but I have to admit that I haven't
investigated how chronyc communicates with its daemon.

- ntpd uses "ntpq", which is based on the mode 6 packets discussed here.

So most implementations use their specific way for monitoring, and if
the document discussed here is "informational" then this is at least a
good documentation how this is currently implemented for ntpd, and thus
shouldn't be labeled "historic".

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [email-masked]
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 19 Jul 2018 11:57:58 +0200

> For many situations, UDP is just fine for this.

UDP might be fine if used carefully, but that's not the case of the
mode 6 protocol. The traffic amplification is a serious problem. As
monitoring and control are not specific to NTP, I think it should be
separated from NTP. NTP is about synchronizing clocks. We don't want
NTP to be blocked in networks just because it has a rarely used mode
that can be exploited.

> implementation of what was in 1305 that got inadvertently "not included"

I think it is very specific to ntpd.

The status codes map 1:1 to the internal ntpd state. Other
implementations may have other states.

The Configure command (8) accepts a string that should be parsed as
the configuration file of the daemon. If an implementation of mode 6
wanted to be compatible with ntpd, it would have to support the
syntax of ntp.conf.

The draft says that the system and peer variables exchanged in the
protocol are either specified in RFC 5905, or include special
characters in their names to be considered "extramural". Here is a
list of variables I get with an ntpq readvar command from a recent
version of ntpd. How many of them do you see in RFC5905?

  associd clk_jitter clk_wander clock delay dispersion dstadr dstport
  filtdelay filtdisp filtoffset flash frequency headway hmode hpoll
  jitter keyid leap mintc offset peer pmode ppoll precision processor
  reach rec refid reftime rootdelay rootdisp srcadr srcport stratum
  sys_jitter system tc ttl unreach version xleave

In the ntp_control.c file it seems there are defined 102 system
variables and 58 peer variables. Where are they specified?

> Please also see RFC5907.

So, could we just say that the "lost" part of RFC1305 was superseded
by RFC5907?

-- 
Miroslav Lichvar

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 19 Jul 2018 12:33:56 +0200

> implementations may have other states.

Agreed.

However, this has basically been introduced long before comparable
applications with comparable features were published.

Even "mode 6" refers to a specific feature of ntpd. So why shouldn't
this document describe how this is actually being used?

As mentioned earlier, it would of course be good to have a standard API
to query/monitor the time synchronization status, but this had to be
adapted by other NTP implementations as well, and it would be even
better if that API was also supported by other time synchronization
protocols, e.g. PTP, which currently also uses specific management
messages that were introduced with the first PTP implementations.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Denis Reilly <[email-masked]>
Date: Thu, 19 Jul 2018 11:59:03 +0000

All,

Given the definition that Brian linked to, I think I am in favor of keeping this document in "informational" status.

In spite of their flaws, these commands are in active use, and nothing has broadly superseded them. 

I understand the arguments that if this were designed today, it would probably look different and be more robust. Once a new design appears that achieves some level of adoption across different implementations, maybe this current approach can be formally obsoleted. But for now, I would keep it as "informational". 

--
Denis Reilly  |  Lead Engineer  |  [email-masked]  (585)321-5837

-----Original Message-----
From: ntp [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: Wednesday, July 18, 2018 10:20 AM
To: [email-masked]
Subject: [Ntp] Mode 6 commands draft

All,

     The first question is about the appropriate status for this document. The draft is currently listed as Informational as the functionality is in current use by some implementations.

     Changing the status of the document to Historic would be an indication that the IETF believes the approach has either been superseded by another specification or is otherwise obsolete. The exact definition can be found at:
https://tools.ietf.org/html/rfc2026#section-4.2.4

     Given the above, are there people who believe the status should be changed to Historic?

     The second question relates to the genesis of NTP implementations that do not support the mode 6 commands. Are any of those implementations derived from the reference implementation of NTP?

Regards,
Brian

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 19 Jul 2018 14:17:37 +0200

> this document describe how this is actually being used?

As long as it is clear that it's not intended for new applications and
interoperability, I'm ok with that. I think the new paragraph in the
abstract of the proposed -06 makes it clear.

> messages that were introduced with the first PTP implementations.

That would be nice, but I suspect it will be difficult. Even in PTP,
implementations define their own management IDs.

-- 
Miroslav Lichvar

---

From: Brian Haberman <[email-masked]>
Date: Thu, 19 Jul 2018 09:24:45 -0400

Hi Denis,

> I understand the arguments that if this were designed today, it would probably look different and be more robust. Once a new design appears that achieves some level of adoption across different imp…

It was mentioned in passing further up-thread, but my view is that the
"new design" should be a YANG-based approach so that we can leverage the
NETCONF/RESTCONF model of configuration and monitoring. We have a start
of a YANG-based model, so I would encourage people to ensure that the
capabilities used in mode 6/7 commands are included in that model.

Regards,
Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Jul 2018 13:26:53 +0000

"new design" should be a YANG-based approach so that we can leverage the
    NETCONF/RESTCONF model of configuration and monitoring.

Very strong +1!

---

From: Denis Reilly <[email-masked]>
Date: Thu, 19 Jul 2018 13:34:24 +0000

I am in favor of this approach for monitoring, but I am also in favor of marking the current Mode 6 draft as "informational" until any new design is far enough along to be considered as a functional replacement.

-----Original Message-----
From: ntp [mailto:[email-masked]] On Behalf Of Salz, Rich
Sent: Thursday, July 19, 2018 9:27 AM
To: Brian Haberman <[email-masked]>; [email-masked]
Subject: Re: [Ntp] Mode 6 commands draft

Very strong +1!

---

From: Brian Haberman <[email-masked]>
Date: Thu, 19 Jul 2018 09:34:57 -0400

> I am in favor of this approach for monitoring, but I am also in favor of marking the current Mode 6 draft as "informational" until any new design is far enough along to be considered as a functiona…

Agreed. The current state of the YANG work should have no impact on the
status of the mode 6 draft.

Brian

---

From: Daniel Franke <[email-masked]>
Date: Thu, 19 Jul 2018 09:41:49 -0400

> implementations derived from the reference implementation of NTP?

Actually the second question was, are there any implementations *not*
derived from NTF which *do* support mode 6.

If the answer is no, and if we have consensus that we don't want to
encourage further adoption of mode 6, then there is an argument that this
should not be an IETF document at all, but rather just a part of NTF's
documentation. The counterargument is that we still have a gap in RFC5905
in that it neglects to specify what mode 6 packets mean and that we still
ought to rectify that. But if this is our sole motivation then Historic
status is appropriate.