Subject: [Ntp] draft-ietf-ntp-mode-6-cmds : Issue 2

From: Brian Haberman <[email-masked]>
Date: Mon, 18 Sep 2017 13:13:35 -0400

Ulrich noted that there is currently no easy way to discover the version
of the NTP server being interrogated with mode 6 commands.

For people who have implemented or use mode 6 commands, do we want to
specify a mode 6 command that determines the version of the server being
queried?

Regards,
Brian

---

From: Greg Dowd <[email-masked]>
Date: Mon, 18 Sep 2017 17:35:06 +0000

As a user, I don't have much value to add.  Our typical use case, which is probably pretty widespread, is via loopback interface so version isn't much of an issue.

Thanks...Greg

-----Original Message-----
From: ntp [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: Monday, September 18, 2017 10:14 AM
To: [email-masked]
Subject: [Ntp] draft-ietf-ntp-mode-6-cmds : Issue 2

EXTERNAL EMAIL

Ulrich noted that there is currently no easy way to discover the version of the NTP server being interrogated with mode 6 commands.

For people who have implemented or use mode 6 commands, do we want to specify a mode 6 command that determines the version of the server being queried?

Regards,
Brian

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 18 Sep 2017 16:32:58 -0700

The protocol version is in the NTP header.  Granted, a V4 server can
issue V3 queries.

As for anything else:

- some will consider this sensitive information that should only be
  disclosed to authorized parties.

- we use: ntpq -c "rv 0 daemon_version"
  to query the daemon version.  There is no Standard way to get this
  information, and I'm open to an INFORMATIONAL list of system variables
  that folks might find interesting and/or useful.

H
--

On 9/18/2017 10:35 AM, Greg Dowd wrote:
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
> 

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

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 19 Sep 2017 09:03:02 +0200

>>> Greg Dowd <[email-masked]> schrieb am 18.09.2017 um 19:35 in Nachricht
<[email-masked]>:
> As a user, I don't have much value to add.  Our typical use case, which is 
> probably pretty widespread, is via loopback interface so version isn't much 
> of an issue.

Hi!

I wrote a utility that collects the performance data of our servers to provide some RRD graphs on a central server. One could configure the version for every server, of course, but naturally when upgrading, you easily forget to adjust the config elsewhere. Actually all of our HP-UX NTPv3 servers are gone now, but the tool knew how to handle them.

>From a "monlist" point of view, we still have a lot of NTPv3 clients, and once NTPv5 arrives, the issue will pop up again. I'm quite sure that NTPv5 will have some incompatibilities ;-)

Regards,
Ulrich

> Ulrich noted that there is currently no easy way to discover the version of 
> the NTP server being interrogated with mode 6 commands.
>

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 19 Sep 2017 09:26:28 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 19.09.2017 um 01:32 in Nachricht
> The protocol version is in the NTP header.  Granted, a V4 server can

Hi Harlan,

it seems you live in a simple world: Considering this tcpdump, what version of NTP mode 6 responses is the server sending?:
09:22:17.178611 IP 172.20.16.38.53514 > 172.20.16.35.123: NTP LI=0, VN=3, Mode=6, length=20
09:22:17.178842 IP 172.20.16.35.123 > 172.20.16.38.53514: NTP LI=0, VN=3, Mode=6, length=80
09:22:17.179593 IP 172.20.16.38.53514 > 172.20.16.35.123: NTP LI=0, VN=4, Mode=6, length=12
09:22:17.179842 IP 172.20.16.35.123 > 172.20.16.38.53514: NTP LI=0, VN=4, Mode=6, length=52

I have the suspect that the server just copies the version from the request to the response. As Brian pointed out some bits have a different meaning between NTPv3 and NTPv4, but this way you never find out what bits the server is really sending.

Regards,
Ulrich

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 19 Sep 2017 01:24:16 -0700

> I have the suspect that the server just copies the version from the request to the response. As Brian pointed out some bits have a different meaning between NTPv3 and NTPv4, but this way you never…

The word "version" is the issue there.

You don't mean "core protocol version", you want to know something else.

You *might* mean "what version of ntp software are you running?"

You might mean "what ntpq mode 6 protocol version are you running?"

For the last part, there are some "generally useful" values, and a
larger number of implementation-specific values.

The implementation-specific values can, and arguably should change from
time to time.

We've had a number of these changes over the years, mostly because
definitions have changed.  How far do you want to go with this?  Look at
bug 3067 for example - we've changed the value of root distance at least
twice over the years.

The refid was an IPv4 address for S2+ for a long time.  Then we started
using a hash for an IPv6 refid, and it became clear that it sometimes
caused problems.  Now we're looking at the NOT-YOU refid
(127.127.127.127), the SUGGEST-REFID option, and the IPv6 refid, which
is the previous hash except the first octet is set to 255.

In the reference implementation, to avoid perpetuating the fallacy that
a refid is "expected" to be in the IPv4 format, we have had the 'apeers'
command, which shows the association number in addition to the other
information, and makes room for this by displaying the refid as 8 hex
digits.

I'm interested in seeing what you propose to fix this - what some will
perceive as mandating consistency, others will see as perpetuating
broken behavior and limiting innovation.

H
--

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

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 19 Sep 2017 01:27:46 -0700

Oh, one more thing:

> I have the suspect that the server just copies the version from the request to the response. As Brian pointed out some bits have a different meaning between NTPv3 and NTPv4, but this way you never…

Yes, this is a problem that we have never addressed.

Should a v4 server that gets a v3 query send back "legacy" v3
information, or the updated v4 information?

There are good reasons for each choice, and please remember that by
asking a v4 server to send back a v[1-3] response you're asking for a
lot of extra code, and that baggage will grow and grow...

H
--

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 19 Sep 2017 10:54:51 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 19.09.2017 um 10:24 in Nachricht
<[email-masked]>:

>> it seems you live in a simple world: Considering this tcpdump, what version 
> of NTP mode 6 responses is the server sending?:
>> I have the suspect that the server just copies the version from the request 
> to the response. As Brian pointed out some bits have a different meaning 
> between NTPv3 and NTPv4, but this way you never find out what bits the server 
> is really sending.
> 

Hi Harlan,

as the control message format if different from the time format, it's not obvious that VN still has the same meaning. You think it's referring to the "core protocol version" without saying what that is (time messages?).

> You *might* mean "what version of ntp software are you running?"

The version of software is some vendor string, where you MAY be able to deduce the NTP core version from.

> You might mean "what ntpq mode 6 protocol version are you running?"

My guess was that NTPv3 support VN==3, and NTPv4 supports VN==4 (and maybe VN==3 for compatibility with old clients).

> The implementation-specific values can, and arguably should change from

why _should_ they change? It sound like a recommendation.

> The refid was an IPv4 address for S2+ for a long time.  Then we started

It was "_interpreted as_ an IPv4 address while the implementation used an IPv4 address, and one could deduce the server from it. The problem was to use and advertise the rfid as IPv4 address. That's overspecifying an ID.

> broken behavior and limiting innovation.

Use a V3 ntpq to query a V4 server: The status interpretation may be wrong.
Use a V4 ntpq to query a V3 server: The status interpretation may be wrong.

You think it's all right, and no need to fix things? I don't agree. Several things were messed up in the past, but that shouldn't be the strategy for the future.

Regards,
Ulrich

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 19 Sep 2017 02:32:40 -0700

Hi Ulrich,

> My guess was that NTPv3 support VN==3, and NTPv4 supports VN==4 (and maybe VN==3 for compatibility with old clients).

This again may mean many things.  It's one thing to know that the
protocol mode 6 "command" structure is supported.  It's another thing to
know what the implementation is willing to send.

> why _should_ they change? It sound like a recommendation.

Not intended as a recommendation.

See below.

> It was "_interpreted as_ an IPv4 address while the implementation used an IPv4 address, and one could deduce the server from it. The problem was to use and advertise the rfid as IPv4 address. That'…

So what are you trying to specify in this document?

> You think it's all right, and no need to fix things? I don't agree. Several things were messed up in the past, but that shouldn't be the strategy for the future.

No, I think that the situation you describe with the status
interpretation is wrong and should be addressed.  I haven't checked out
what you say, but I believe you.  But there are other things that
*should* be changed from time to time - new variables, changed
variables, etc.  We might be able to enumerate the list of core stuff
that folks MUST implement.  We can define things that implementors
SHOULD implement.  And there are many things that will be
implementation-specific, and implementors should be given free reign on
these implementation-specific items.

---

From: Hal Murray <[email-masked]>
Date: Tue, 19 Sep 2017 02:44:30 -0700

> why _should_ they change? It sound like a recommendation.

In this context, the version you are talking about is a major version.  There 
are also minor versions that don't show up in the protocol.  Things will 
change as new features are added or existing features are dropped.

I think that the basic functions won't change much(?) within a major version 
but minor functions will change and ntpq and friends need to be prepared for 
that.  To complicate things, the minor versions can be a tree rather than a 
line.

It might be possible to invent a meta protocol so you could ask a ntp server 
what it supports for mode 6.  I doubt if that would be worthwhile.  I could 
easily be wrong.

It might make sense to expect a ntp package to include documentation for what 
it supports for mode 6.

-- 
These are my opinions.  I hate spam.

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 19 Sep 2017 14:36:43 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 19.09.2017 um 11:32 in Nachricht
<[email-masked]>:

[...]
>> It was "_interpreted as_ an IPv4 address while the implementation used an 
> IPv4 address, and one could deduce the server from it. The problem was to use 
> and advertise the rfid as IPv4 address. That's overspecifying an ID.
> 

"An ID is a 32 bit value that is identical iff the servers are identical."
No more, no less. You could say an ID COULD be derived from the FQHN (for example).

[...]

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 19 Sep 2017 14:54:50 +0200

>>> Hal Murray <[email-masked]> schrieb am 19.09.2017 um 11:44 in

Hi!

There are some less-documented features like "sys_var_list" that returns the list of system variable names like this:
ntpq> rv 0 "sys_var_list"
sys_var_list="leap,stratum,precision,rootdelay,rootdisp,refid,reftime,tc,peer,offset,frequency,sys_jitter,clk_jitter,clock,processor,system,version,clk_wander,sys_var_list,tai,leapsec,expire,mintc,mru_enabled,mru_depth,mru_deepest,mru_mindepth,mru_maxage,mru_maxdepth,mru_mem,mru_maxmem,ss_uptime,ss_reset,ss_received,ss_thisver,ss_oldver,ss_badformat,ss_badauth,ss_declined,ss_restricted,ss_limited,ss_kodsent,ss_processed,peeradr,peermode,bcastdelay,authdelay"

But you (a program) cannot guess the meaning from the names.
Another problem is that the text format used for values is not specified at all: Things get interesting if you want to represent strings containing a comma or lists of similar values.

For example, this is how an mrulist is transferred (in three response packets):
        nonce=dd6b9112c3bf4c4d7c00d1aa, ct.0=377, last.0=0xdd6b896b.77aa8fc2,^M^
Jaddr.0=172.20.16.10:123, first.0=0xdd6516f8.771ac3a8, mv.0=36,^M^Jrs.0=0x188, _
W].0=18446744073709529092, rs.1=0x188, ct.1=374,^M^Jlast.1=0xdd6b8a33.77bfc0d6,
mv.1=36, addr.1=172.20.16.4:123,^M^Jfirst.1=0xdd6516f8.76df78d9, addr.2=172.20.1
6.6:123,^M^Jlast.2=0xdd6b8f4f.7781c282, first.2=0xdd6516f8.76e30e5f, ct.2=367,^M
^Jmv.2=36, rs.2=0x188, ct.3=373, first.3=0xdd6516f8.77d02e9e,^M^Jaddr.3=172.20.1
6.1:123, mv.3=36, last.3=0xdd6b8f82.778bcf2a, rs.3=0x188,^M^Jlast.4=0xdd6b8fd7.778
592d1, first.4=0xdd6516f8.76e3dc21, rs.4=0x188,^M^Jct.4=377, mv.4=36, addr.4=172
.20.16.5:123, last.5=0xdd6b903b.7774c6c9,^M^Jfirst.5=0xdd6516f8.76e1c053, ct.5=3
71, addr.5=172.20.16.3:123, mv.5=36,^M^Jrs.5=0x188, ct.6=373, last.6=0xdd6b90b2.
7784ee72, mv.6=36,^M^Jfirst.6=0xdd6516f8.77bbd81f, rs.6=0x188, addr.6=172.20.16.
2:123,^M^Jlast.7=0xdd6b90ee.777b2c6e, first.7=0xdd6516f8.76e45fae, ct.7=375,^M^J
addr.7=172.20.16.7:123, mv.7=36, rs.7=0x188, ]HS.7=18446744073709529383,^M^Jnow=0x
dd6b9112.c3c68d55, last.newest=0xdd6b90ee.777b2c6e^M^J

For a human it might be helpful if the sever could also give a description of the variable, but for a program something else would be needed.

If you look at SNMP or LDAP, TIFF tags or ASN.1 BER they all tell you the type of data sent at least...

Regards,
Ulrich