Subject: Re: [Ntp] Mode 6 commands draft

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 15 Aug 2018 21:10:03 +0000

Folks,

Dieter and I have reviewed the below referenced email thread. From this along with the IETF 102 discussions and the WGLC discussion, we have concluded that the working group consensus is as follows: 

Publish the document with a status of Informational. As a result, we will be submitting this document as is to the IESG shortly. 

Additionally, no implementations beyond the reference implementation have identified themselves as having implemented Mode 6 commands. 

Regards,
Karen

> On Jul 18, 2018, at 10:19 AM, Brian Haberman <[email-masked]> wrote:
> 
> 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
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Aug 2018 23:02:33 +0000

>    Additionally, no implementations beyond the reference implementation have identified themselves as having implemented Mode 6 commands. 
 
Is there another name we can use instead of "reference implementation"?   Harlan, any suggestions?

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 15 Aug 2018 16:05:08 -0700

The ntp.org implementation is the *only* reference implementation I'm
aware of.   None of the others qualify.

So it continues to be an appropriate way to refer to the implementation
from the NTP Project.

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!

---

From: Daniel Franke <[email-masked]>
Date: Wed, 15 Aug 2018 19:05:35 -0400

"NTF implementation"?

I agree, the phrase "reference implementation" should be reserved for
the code listed in Appendix A of RFC 5905 — which is derived from the
NTF implementation, but not identical with it.
On Wed, Aug 15, 2018 at 7:02 PM Salz, Rich

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Aug 2018 23:12:15 +0000

There are many implementations of NTP, and designating one as "the" reference implementation seems wrong.  

I would prefer another name.

On 8/15/18, 7:05 PM, "Harlan Stenn" <[email-masked]> wrote:

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 15 Aug 2018 16:14:27 -0700

> There are many implementations of NTP, and designating one as "the" reference implementation seems wrong.  

NONE of the others are complete reference implementations.

H
--

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

---

From: Daniel Franke <[email-masked]>
Date: Wed, 15 Aug 2018 19:15:57 -0400

Neither is yours, any more, since much of it has long ago diverged
from what's specified in RFC 5905.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Aug 2018 23:16:15 +0000

There is NO reference implementation.

I think we need another name for your code.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 15 Aug 2018 16:17:15 -0700

> from what's specified in RFC 5905.

Please support this claim.

H
==

---

From: Jared Mauch <[email-masked]>
Date: Wed, 15 Aug 2018 19:17:35 -0400

> On Aug 15, 2018, at 7:05 PM, Daniel Franke <[email-masked]> wrote:
> 
> "NTF implementation"?
> 

One of the challenges we have here is that the ntp.org/NTF implementation is one of very few NTP implementations that does more than simple client/server type stuff.

Some of this was likely desirable early on to help troubleshoot, but I would suggest that until there’s other implementations it remain informational..

- Jared

---

From: Daniel Franke <[email-masked]>
Date: Wed, 15 Aug 2018 19:28:50 -0400

I'm sure that with some code spelunking I could find many more
examples, but the two that come to mind readily are the change in
root_distance calculation
(https://lists.ntp.org/pipermail/questions/2011-December/031229.html;
"The NTP v4 reference implementation continues to evolve and improve
upon the RFC 5905 design intentionally") and changing MAXDIST from 1.0
to 1.5.

---

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 15 Aug 2018 23:37:11 +0000

Folks,

Since my message from an NTP wg chair perspective on” started this chain of messages, I would like to clarify my text because this is not a productive conversation. 

Henceforth, in the context of the IETF NTP working group mailing list, I will not refer to any implementation as the reference implementation. Please consider my statement below to be modified as follows: 

Additionally, no implementations beyond the NTF NTP implementation have identified themselves as having implemented Mode 6 commands.

Please note that I did not say that no one else had implemented them, just that none had identified that they had done so. As part of our working group efforts, I am interested in identifying and classifying all implementations of NTP. Please feel free to send me details of your implementation. 

Karen

> On Aug 15, 2018, at 7:17 PM, Harlan Stenn <[email-masked]> wrote:
> 
> 
>

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 15 Aug 2018 16:47:49 -0700

OK, so are you complaining that the ntp.org codebase is improving and
evolving the specification that came from the codebase?

Regardless, I'll work on addressing the discrepancies below.

H

---

From: Daniel Franke <[email-masked]>
Date: Wed, 15 Aug 2018 19:49:36 -0400

I'm not complaining about anything except the "reference
implementation" moniker. You can be a reference implementation, or you
can "improve and evolve" from the spec. Both have value, but you can't
have both at once.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 15 Aug 2018 16:50:29 -0700

> can "improve and evolve" from the spec. Both have value, but you can't

Huh.

H
--

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 16 Aug 2018 08:56:27 +0200

>>> "Salz, Rich" <rsalz=[email-masked]> schrieb am 16.08.2018 um 01:02
in Nachricht <[email-masked]>:
>>     Additionally, no implementations beyond the reference implementation have 
> identified themselves as having implemented Mode 6 commands. 
>  
> Is there another name we can use instead of "reference implementation"?   

Maybe add some footnote on the first occurrence, explaining what reference implementation refers to. I have no problem with the name "reference implementation" per se.

> Harlan, any suggestions?

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 16 Aug 2018 08:59:00 +0200

>>> "Salz, Rich" <rsalz=[email-masked]> schrieb am 16.08.2018 um
01:12
in Nachricht <[email-masked]>:
> There are many implementations of NTP, and designating one as "the"
reference 
> implementation seems wrong.  

But due to the fact that the implementaion always came before specification,
other implementations have to follow either the code or the specification
later. I would not call these other implementations "reference"
implementations...

>     >>    Additionally, no implementations beyond the reference
implementation 
> have identified themselves as having implemented Mode 6 commands. 
>     >

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 16 Aug 2018 11:01:20 +0200

> can "improve and evolve" from the spec. Both have value, but you can't

Hm, so I wonder what will happen if after the release of the original
NTS spec there are some ideas how to improve the functionality, without
breaking compatibility, but differ in details from the existing spec.

Are you sure you will first update the RFC, and months later, after the
updated RFC has been accepted, you start updating your code?

For many years the NTP implementation at ntp.org has been the only one
where new features were developed, and changes were made if the
performance of time synchronization could be improved.

That happened long before other implementations were introduced, which
supported only a subset of the features invented by the NTP project, or
simply forked it.

In the past I have seen several RFCs which weren't written using an
exact wording, for example using the term "midnight" without saying if
they mean "UTC midnight" or "midnight at local time". That resulted in
different implementations which were not fully compatible to each other,
and thus I always thought it would be good to write things down more
exactly.

However, if that means that, once an RFC has been released, you are
unable to make improvements in an implementation that can *later* be
picked up for an updated RFC to reflect new insights, that would suggest
that it would be better to *not* specify too many details in an RFC. :-(

So I think it's still OK to call the implementation at ntp.org the
reference implementation.

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: Martin Burnicki <[email-masked]>
Date: Thu, 16 Aug 2018 11:16:16 +0200

> Additionally, no implementations beyond the NTF NTP implementation have identified themselves as having implemented Mode 6 commands.

Maybe this is simply because the mode 6 commands have been invented many
years ago, when other implementations like w32time or chrony didn't even
exist.

When w32time was introduced the folks at Microsoft decided implement a
different way to monitor and configure the service that runs in the
background, and so does chrony, AFAIK.

Are there any RFCs, where those ways are specified? Would you call such
RFCs "informational", or would you call them "historic" or "deprecated",
since no other software does it the way as w32time does, or the way that
chrony does?

Mode 6 packets are widely used today, and it's good if there is an RFC
for the existing commands, and I don't think the NTP project is to blame
that no other project that implements an NTP server or client has picked
this up.

> Please note that I did not say that no one else had implemented them, just that none had identified that they had done so. As part of our working group efforts, I am interested in identifying and c…

Do you care about w32time, which has been implemented by Microsoft, and
is probably the most often used NTP implementation in the Windows world?

That program has evolved from a very simple implementation to a pretty
good one in current Windows versions, which tries to duplicated the
behavior of ntpd in certain conditions, which have turned out to be very
useful.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 16 Aug 2018 11:20:49 +0200

Hi!

Martin brought up an interesting point (that is only tied loosely to RFCs):
Would it be a good idea to provide a modified copy of the corresponding RFCs
with the sources of NTP that describe the changes done? The idea is not to
start another RFC cycle, but to document the changes. Such "RFCs" should be
clearly marked to show that they are not official. I think the OpenLDAP project
has done things like that...

There was always a desire to keep code and documentation in sync...

Regards,
Ulrich

>>> Martin Burnicki <[email-masked]> schrieb am 16.08.2018 um
11:01 in

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 16 Aug 2018 11:23:07 +0200

> There was always a desire to keep code and documentation in sync...

That really sounds like a good idea, IMO ...

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 16 Aug 2018 11:24:52 +0200

> later. I would not call these other implementations "reference"

For me, "reference implementation" is the implementation on which
was based the specification (RFC 5905) and where people need to look
when some detail in the specification is missing/ambiguous. I'm not
sure if it is possible to write a good NTP implementation just from
RFC 5905 alone.

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 16 Aug 2018 11:37:34 +0200

Hi!

Another vote for "informational" status: In its enterprise Linux distribution
SUSE decided to replace ntpd with chrony in SLES15, so users have to deal with
the change.
Having a look at it, I noticed that the command to monitor the status of the
daemon is different; so are the individual commands and the output format.
Obviously there is a desire to keep things similar even for monitoring, and an
informational description of existing stuff may be helpful.
I'm not arguing which commands or output formats are preferable, I'm just
saying that variety may not be desired in some cases.

For demonstration, I'm comparing the commands to show the status of
synchronization for both implementations:

# ntpq -c sysi
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
system peer:        server-name.uni-regensburg.de:123
system peer mode:   client
leap indicator:     00
stratum:            2
log2 precision:     -18
root delay:         0.242
root dispersion:    20.511
reference ID:       172.20.2.25
reference time:     df1fc176.92f24fdb  Thu, Aug 16 2018 11:25:10.574
system jitter:      3.418804
clock jitter:       0.412
clock wander:       0.046
broadcast delay:    -50.000
symm. auth. delay:  0.035

# chronyc tracking
Reference ID    : AC14100A (server-name.uni-regensburg.de)
Stratum         : 3
Ref time (UTC)  : Thu Aug 16 09:27:39 2018
System time     : 0.000183949 seconds fast of NTP time
Last offset     : +0.000017340 seconds
RMS offset      : 0.000140301 seconds
Frequency       : 20.676 ppm slow
Residual freq   : -0.000 ppm
Skew            : 0.015 ppm
Root delay      : 0.000757746 seconds
Root dispersion : 0.007301250 seconds
Update interval : 65.3 seconds
Leap status     : Normal

And the protocol chrony uses is not documented in the manual pages, either
(nor is there a reference to such docs)

Regards,
Ulrich

>>> Martin Burnicki <[email-masked]> schrieb am 16.08.2018 um
11:16 in
Nachricht <[email-masked]>:
> Karen O'Donoghue wrote:
>> Folks,
>> 
>> Since my message from an NTP wg chair perspective on” started this chain of

> messages, I would like to clarify my text because this is not a productive 
> conversation. 
>> 
>> Henceforth, in the context of the IETF NTP working group mailing list, I 
> will not refer to any implementation as the reference implementation. Please

> consider my statement below to be modified as follows: 
>> 
>> Additionally, no implementations beyond the NTF NTP implementation have 
>> Please note that I did not say that no one else had implemented them, just

> that none had identified that they had done so. As part of our working group

> efforts, I am interested in identifying and classifying all implementations

> of NTP. Please feel free to send me details of your implementation. 
>

---

From: Brian Haberman <[email-masked]>
Date: Thu, 16 Aug 2018 07:55:00 -0400

Hi Martin,

> since no other software does it the way as w32time does, or the way that

It is rather common within the IETF for people to publish Informational
RFCs that describe how they implement certain
protocols/features/capabilities. This is generally done to provide a way
for others to interoperate with them.

I see the mode 6 draft as doing the same thing.

> that no other project that implements an NTP server or client has picked

Agreed.

Regards,
Brian

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 16 Aug 2018 14:54:59 +0200

> years ago, when other implementations like w32time or chrony didn't even

If they were written when the mode 6 already existed and was
specified, doesn't it say something that they didn't adopt when they
easily could?

> since no other software does it the way as w32time does, or the way that

At least in my case, the suggestion for "historic" was not made
because nothing else is using it, but rather because it has a number
of known security issues that have an impact on the use of the other
modes supported by NTP.

I think we all agree here that new NTP implementations should use a
different protocol for monitoring and management separately from NTP.
As long as this is clear from the document, I don't really care what
status it has.

The only reason that this draft has been written seems to be that RFC
1119 and RFC 1305 specified the mode 6, but RFC 5905 doesn't. I'm
wondering what will happen when the WG starts working on the NTPv5
specification. Will NTP carry the mode 6 forever? 

> that no other project that implements an NTP server or client has picked

There might be few client implementations of mode 6 other than the
ntpq program. The ntpstat utility was one of them, but its support for
the protocol was very limited and it talked only to ntpd running on
localhost.

-- 
Miroslav Lichvar

---

From: [email-masked]
Date: Thu, 16 Aug 2018 15:00:40 +0200

"ntp" <[email-masked]> schrieb am 16.08.2018 14:54:59:

> Von: "Miroslav Lichvar" <[email-masked]>
> An: [email-masked]
> Datum: 16.08.2018 14:55
> Betreff: Re: [Ntp] NTP implementations (Was: Mode 6 commands draft)
> Gesendet von: "ntp" <[email-masked]>
> 
> > > Additionally, no implementations beyond the NTF NTP 
> implementation have identified themselves as having implemented Mode
> 6 commands.
> > 

I agree. My hope is that the Yang approach will an appropriate replacement 
of 
the mode 6 cmds. That was already mentioned in this thread, as far as I 
remember.

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 16 Aug 2018 16:35:39 +0200

> of known security issues that have an impact on the use of the other

Hm, is this still the case for the current implementation? I know about
the potential problem with ntpdc's "monlist" feature, which could even
be avoided by som "restrict" settings, but AFAIK this can't happen
anymore with ntpq's new "mrulist" command.

> specification. Will NTP carry the mode 6 forever? 

I think you mean ntpd, not NTP in general. ;-)

Of course it would be good to have a common way to monitor the status of
different programs like chrony, ntpd, openntpd (and even w32time?) in
the same way.

However, the problems I see is that

1.) there needs to be a specification which type of information a
generic monitoring tool should be able to retrieve

2.) maintainers of different implementations needed to accept this,
instead of (only) implementing their own monitoring tools

And it would be even better if PTP and other time synchronization
protocols would be supported, too.

For example, on Linux (and probably some more Unix-like systems) you can
actually use adjtimex or a similar tool to retrieve the status of the
kernel timekeeping in a uniform way, regardless whether the system time
is disciplined by ntpd, ptpd, or something else.

> the protocol was very limited and it talked only to ntpd running on

OK, I've never used ntpstat, and didn't know it uses mode 6 packets
directly rather than parsing the output of some ntpq commands.

Generally it would be good if there was a common way to monitor the time
synchronization performance, but mode 6 commands for ntpd should be
deprecated only if there is a good replacement.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 16 Aug 2018 18:32:02 +0200

> anymore with ntpq's new "mrulist" command.

Yes, mrulist replaced the mode-7 monlist command and it requires a
nonce from the client, so it can't be easily used for amplification
attacks. However, the other commands still work. For instance, the
'readvar $ASSOCID' command has an amplification factor of about 9,
which can still be attractive for attackers.

Try removing noquery on a public server and see how long it will take
before someone tries to exploit it. On my servers I see few hundred
of mode-6 requests every day, even though the servers never responded
to them. Apparently, people are still interested.

> different programs like chrony, ntpd, openntpd (and even w32time?) in

Ideally using an existing general-purpose protocol separately from
NTP.

> generic monitoring tool should be able to retrieve

That will be the difficult part. Different implementations have
different variables that could be reported and they may change over
time.

-- 
Miroslav Lichvar

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 17 Aug 2018 09:49:22 +0200

> which can still be attractive for attackers.

OK.

> to them. Apparently, people are still interested.

... which doesn't necessariliy mean that it's an attack. It can simply
be curiosity. ;-)

But seriously, instead of explicitly having to define *restrictions*, it
would be generally better to have the highest level of restrictions by
default, and access rights needed to be defined for those who should be
allowed to do some monitoring.

> different variables that could be reported and they may change over

Yes. Unfortunately we also see for different protocol daemons (DNS,
DHCP, ...) that there are monitoring tools that are very specific to the
implementation, so in fact I don't have much hope to ever see a generic
monitoring tool for time synchronization.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 20 Aug 2018 08:17:57 +0200

>>> Martin Burnicki <[email-masked]> schrieb am 17.08.2018 um
09:49 in
> allowed to do some monitoring.

Another idea is: If the TTL for such responses could be set (maybe like 3 in a
typical company), wouldn't most such denial-pof-sevice-attacks vanish before
they reach the target (hoping people will stop to try such, then)?