Subject: Re: [Ntp] Antw: [EXT] Re: Public NTP servers already responds to NTPv5

From: Hal Murray <[email-masked]>
Date: Tue, 01 Dec 2020 13:45:34 -0800

[email-masked] said:
> IMHO a v4 server should _never_ answer a packet version it does not know
> about. I know you cannot change the past, however.

If a v4 server gets a v5 request, it could respond with a v4 reply.  That's 
the best it can do.  That might simplify the transition.  A client doesn't 
have to know if the server it is going to talk to is v5 or v4.

The first assumption is that the mode and version fields stay in the same 
place so a server can figure out that it is a v5 request.  It also assumes 
that the v4 servers planned ahead for something like that.  For the pool where 
most systems are reasonably well attended it may be possible to retrofit v4 
servers that don't get updated to v5.  Or we could split the pool into v4 and 
v5.

If a v5 client gets a v4 response, it could process it.  That's assuming there 
is enough overlap between v4 and v5 fundamental concepts so that the old 
response has enough data to be useful.

If the v4 packet format is different from v5, the above requires extra code.  
If the packet format is very close, the extra code could be small.  At worst 
it is 2x.  The server side is only a page or two so 2x isn't unreasonable.  I 
think the client side is similar but I haven't looked as carefully

30% of the traffic to a pool server is v3.

-- 
These are my opinions.  I hate spam.

---

From: Danny Mayer <[email-masked]>
Date: Tue, 1 Dec 2020 19:06:47 -0500

> 30% of the traffic to a pool server is v3.
That's because the clients making the queries haven't been upgraded in 
decades. That's not surprising because once NTP is set up you don't 
really need to change anything, what I call a set-and-forget 
application. There are routers and switches and all sorts of hardware 
out there which have been running for years and as long as they are 
working they don't get upgraded or replaced.

Noone is going to be bothering to update a NTPv4 client to deal with a 
server returning V5 packets. See above. The only way to support V4 
clients is to make the V5 packet a V4 packet plus extra stuff. It's 
unlikely that anything else would work.

It's essential that any NTPv5 document deal with interoperability with 
NTPv4 clients and servers. NTPv5 will fail without it.

Danny

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 2 Dec 2020 09:43:21 +0100

On Tue, Dec 01, 2020 at 07:06:47PM -0500, Danny Mayer wrote:
> It's essential that any NTPv5 document deal with interoperability with NTPv4
> clients and servers. NTPv5 will fail without it.

The only suggestion I have for that currently is do with TLS 1.3
did and have an extension with the version number in it, and still
have version 4 in the header.

Kurt

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Dec 2020 16:48:28 +0000

As Kurt probably knows, TLS 1.3 kept the 1.2 version number because middleboxes got in the way. As a result, the TLS 1.3 handshake looks like a TLS 1.2 handshake. This was a relatively late change, only because Google did some experimentation and found that doing it the "obvious" way would have prevent TLS 1.3 from reaching 1% of the network.  (That number is from memory.)

NTPv5 should keep this in mind, and think of planning experiments if we deviate too much from looking like NTPv4.