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

From: Danny Mayer <[email-masked]>
Date: Tue, 1 Dec 2020 11:48:20 -0500

On 12/1/20 2:36 AM, Ulrich Windl wrote:
>>>> Danny Mayer <[email-masked]> schrieb am 30.11.2020 um 17:09 in Nachricht
> <[email-masked]>:
>
>> On 11/30/20 9:42 AM, Danny Mayer wrote:
>>> On 11/30/20 7:45 AM, Harlan Stenn wrote:
>>>> On 11/30/2020 4:30 AM, Miroslav Lichvar wrote:
>>>>> On Mon, Nov 30, 2020 at 04:14:10AM -0800, Harlan Stenn wrote:
>>>>>>>> - 65% response: NTPv4 format packet that version field is 5
>>>>>>> This seems to be mostly the ntp.org ntpd.
>>>>>> Dave has long insisted this is a feature.  I'll discuss this with him
>>>>>> more. I believe he has always intended that any changes to the packet
>>>>>> format would *extend* the packet, so if v5 needed more fields they
>>>>>> would
>>>>>> be after the v4 payload, so if a request came in to a v4 server with a
>>>>>> v5 (or greater) version, the client would respond with the same
>>>>>> version
>>>>>> from the other side, and that side would know how to deal with it
>>>>>> because of the packet length.
>>>>> FWIW, ntpd doesn't respond to any longer packet. At most it responds
>>>>> with a crypto NAK if it looks like a MAC with specific length.
>>>> Yes.
>>>>
>>>>> >From the code it looks like a bug. NTPv5 packets are classified as
>>>>> "previous version", with no case handling future versions.
>>>>>
>>>>>           } else if (   !(restrict_mask & RES_VERSION)
>>>>>                      && hisversion >= NTP_OLDVERSION) {
>>>>>                   sys_oldversion++;               /* previous version */
>>>> It's a bug that we don't properly count newer versions.
>>> My understanding was that you only should respond with the current
>>> version that the server is running and MAY respond to the previous
>>> version. All other version numbers should be ignored and the packets
>>> dropped. I don't think we have been doing this and I don't think it's
>>> documented in any RFC but I think that SHOULD be the behavior. This
>>> will force bad implementations to fix their code.
>>>
>>> Different packet sizes for different versions is a separate issue and
>>> with extension fields possibly present in the packet that can cause an
>>> previous version to have a larger packet size than the current
>>> version. That may well be the case for a NTPv5 and don't forget that
>>> NTPv4 will be around for many years after NTPv5 finally arrives.
>>>
>> I forgot to add that we should include in the document whether or not a
>> NTPv5 server should reply to an NTPv4 request with a NTPv4 response and
>> not an NTPv5 response. Whether you can respond with NTPv5 packets to an
>> NTPv4 request depends whether or not the NTPv5 packet is a proper
>> superset of an NTPv4 packet.
> Hi!
>
> You mean a NTPv5 packet with a version 4 in the header? What sense does that make?
> Thge best the client can do is ignore the packet realizing it cannot handle it. How can an old v4 client know how a future v5 packet will look like? Accepting a v5 packet needs to know exactly that.

No, I mean should a NTPv5 server respond with an NTPv4 packet if it gets 
one? How would it signal that it supports v5? If a client is V5 capable 
should it try first with V5 and if it fails, to retry with V4? If the 
server responds to a V5 packet as a response to a V4 request, the client 
would only be able to use the packet if the V5 packet is a proper 
superset of the V4 packet.

>> Separately you need to decide how to deal with a NTPv5 request coming to
>> an NTPv4 server and how it should respond.
> It has two choices: Not responding or responding with a proper v4 packet. However then the client has the same problem: Sending v5, but receiving v4: Ignore or accept?
>
> IMHO a v4 server should _never_ answer a packet version it does not know about. I know you cannot change the past, however.
>
Then that behaviour needs to be documented. I would not want a V5 server 
to respond in any case to a packet lower than V4. There are rogue 
clients out there which never set the packet version and send a version 
0 packet.

Danny

---

From: Watson Ladd <[email-masked]>
Date: Tue, 1 Dec 2020 17:32:42 -0800

> > will force bad implementations to fix their code.

My concern with this mechanism is that packet loss can trigger down
negotiation and it's not clear how to upnegotiate from that position.

A proper version negotiation mechanism is needed. Perhaps another
extension with client advertisement and server selection.

> superset of an NTPv4 packet.

Obviously v4.

> an NTPv4 server and how it should respond.

We need to be able to negotiate, so I would say it shouldn't say v5.

Sincerely,
Watson Ladd

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

---

From: James Browning <[email-masked]>
Date: Tue, 1 Dec 2020 18:24:41 -0800

> extension with client advertisement and server selection.

Maybe a kiss code something like VER or drop the connection if that's
unsupported.

Also, IIRC the ntp messsage contents have changed every version since 0
which didn't have a version field.

My opinion is that implementers should be free to support as far back as
they can or not.

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 02 Dec 2020 09:27:29 +0100

>>> Danny Mayer <[email-masked]> schrieb am 01.12.2020 um 17:48 in Nachricht
<[email-masked]>:

>> Thge best the client can do is ignore the packet realizing it cannot handle 
> it. How can an old v4 client know how a future v5 packet will look like? 
> Accepting a v5 packet needs to know exactly that.
> 

I think such auto-detection was never specified, probably with the assumption that the admin knows the servers he/she configures.
With mode6 packets one could implement such a feature query, but mode6 is optional.

>> It has two choices: Not responding or responding with a proper v4 packet. 
> However then the client has the same problem: Sending v5, but receiving v4: 
> Ignore or accept?
>>
>> IMHO a v4 server should _never_ answer a packet version it does not know 
> about. I know you cannot change the past, however.
>>

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 2 Dec 2020 09:48:14 +0100

> extension with client advertisement and server selection.

It would be nice to have an NTPv4 extension field to allow the client
to check for the server's NTPv5 support. However, the majority of
existing servers don't respond to unknown extension fields, so the
client would still not know if the packet was dropped in the network
or the server didn't understand the request.

We could specify a hack using fields in the header, e.g. the reference
timestamp, which is normally unused and has predictable content. If
the server sees that the field contains a magic constant, it could
respond with a different magic constant meaning: "yes, I support
NTPv5".

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 02 Dec 2020 09:48:53 +0100

>>> Hal Murray <[email-masked]> schrieb am 01.12.2020 um 22:45 in
Nachricht <[email-masked]>:

> [email-masked]‑regensburg.de said:
> 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.

OTOH if you get no response for v5, but a response for v4, you know that the
server is speaking v4. Or the other ways 'round: If the server answers v5, you
know it can understand v5 at least.

I'm against "silent protocol downgrade".

> 
> 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.

That's still to specify.

> 
> 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.

Basically I think it's nice to have compatible packet formats, BUT with the
invention of extension fields in NTPv4 the whole format became such a mess that
I think we should NOT "build on that". Instead redesign.

Regards,
Ulrich

> 
> 
> ‑‑ 
> These are my opinions.  I hate spam.
> 
> 
>

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 02 Dec 2020 10:03:05 +0100

>>> James Browning <[email-masked]> schrieb am 02.12.2020 um 03:24 in
Nachricht
> Maybe a kiss code something like VER or drop the connection if that's

The thing is that you can use the negotiation mechanism introduced in version X not berfore version X, and for version X it does not help much ;-)
So if we introduce a negotiation for v5, v5 and v6 will benefit from it, but not existing v4 or v3.

> My opinion is that implementers should be free to support as far back as

MUST v4
SHOULD v3
SHOULD NOT v2
MUST NOT v1 or older
?

Regards,
Ulrich

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Dec 2020 15:10:27 +0000

>    I'm against "silent protocol downgrade".

I totally agree, and I think the mechanism you described would address that.  One concern about downgrade is if an attacker can force the downgrade to a protocol or implementation that has security issues.  But preventing that means that everything has to be cryptographically protected from tampering, which is part of why I think NTPv5 should be secure.

---

From: Hal Murray <[email-masked]>
Date: Wed, 02 Dec 2020 10:30:07 -0800

[email-masked] said:
> It would be nice to have an NTPv4 extension field to allow the client to
> check for the server's NTPv5 support.

I think we should put that on the must-have list for NTPv5.  There should be 
some way for  a server to signal that it supports NTPv6 in a vanilla NTPv5 
response packet (no extensions or such).

"Must have" is a little too strong, but not by much.

If you want to get into the details, it doesn't have to be a whole bit.  It 
could be a particular value in a larger field.  If we continue the tradition 
of the response looking like the request, the same field turns into a "do 
you?" slot on a request.

If we have a slot for things like "do you support NTPv6?", we should reserve 2 
values for "no" and "I don't know what you are talking about".

---

From: Doug Arnold <[email-masked]>
Date: Wed, 2 Dec 2020 20:36:31 +0000

It might be a good idea to put a statement in ntpv5 something like this:

Legacy NTP Version Support
An ntpv5 server MAY support previous versions of ntp.  The server SHALL always respond with the same version of ntp as the request.  Requests with unsupported versions of ntp SHALL be discarded.

Doug

---

From: Doug Arnold <[email-masked]>
Date: Wed, 2 Dec 2020 20:44:17 +0000

Auto-negotiation could be simple, if start up time is not a big deal.  A client starts with the highest version of ntp that it supports.  If it does not get a response from a server in some configured period of time and after a few tries, it goes to the next highest version of ntp.  Servers don't even have to know they are auto negotiating.

Doug

On 12/2/20, 3:48 AM, "ntp on behalf of Miroslav Lichvar" <[email-masked] on behalf of [email-masked]> wrote:

    -- 
    Miroslav Lichvar

---

From: Philip Prindeville <[email-masked]>
Date: Wed, 2 Dec 2020 13:48:25 -0700

I’m guessing that servers will typically not be the laggards, but rather legacy desktops and IoT’s that haven’t gotten the NTPv5 memo…

Servers are the smaller population and, because of the security requirements implicit in time services, the ones more likely to be patched/updated in a timely fashion.

> On Dec 2, 2020, at 1:44 PM, Doug Arnold <[email-masked]> wrote:
>

---

From: Doug Arnold <[email-masked]>
Date: Wed, 2 Dec 2020 20:50:20 +0000

It would be part of the a server selection standard and client configuration to decide which versions of ntp it is willing to work with, rather than switching to another server.  For example, a client could refuse to degrade to ntp versions below 4 because it wants only secure ntp.  

Doug

On 12/2/20, 3:44 PM, "ntp on behalf of Doug Arnold" <[email-masked] on behalf of [email-masked]> wrote:

    Doug

        -- 
        Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 03 Dec 2020 08:53:08 +0100

>>> Doug Arnold <[email-masked]> schrieb am 02.12.2020 um 21:44
in
Nachricht <[email-masked]>:
> Auto-negotiation could be simple, if start up time is not a big deal.  A 
> client starts with the highest version of ntp that it supports.  If it does

> not get a response from a server in some configured period of time and after

> a few tries, it goes to the next highest version of ntp.  Servers don't even

> have to know they are auto negotiating.

Hi!

I had a similar idea: Instead of specifying "version=n" for a client, an
implementation might allow "versions=5,4" or "verlist=5,4" or
"version_list=5,4" to specify that it would like to use NTPv5, but if that
fails (more than one packet, please!) try NTPv4; if that fails, trat the server
as unreachable. Of course the list could also include NTPv3...

Regards,
Ulrich

> 
> Doug
> 
> On 12/2/20, 3:48 AM, "ntp on behalf of Miroslav Lichvar" 
> <[email-masked] on behalf of [email-masked]> wrote:
>

---

From: Hal Murray <[email-masked]>
Date: Thu, 03 Dec 2020 00:16:42 -0800

[email-masked] said:
> fails (more than one packet, please!) try NTPv4; if that fails, trat the
> server as unreachable. Of course the list could also include NTPv3... 

That doesn't effect the on-the-wire protocol.

It's a good idea and should probably be mentioned in any NTPv5 documentation 
if only to make sure that people think about it since much of the current code 
doesn't work that way and our thinking might get stuck in a rut.  But it 
should be off in a notes-to-implementers footnote rather than the main 
protocol description.

Have we identified any protocol features where somebody might want to do that?

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 03 Dec 2020 09:23:51 +0100

>>> Hal Murray <[email-masked]> schrieb am 03.12.2020 um 09:16 in
Nachricht <[email-masked]>:

> That doesn't effect the on‑the‑wire protocol.
> 

> should be off in a notes‑to‑implementers footnote rather than the main 
> protocol description.

Sure: I wanted to point out a possible mechanism how to handle multiple
versions. The spec should not contain configuration syntax, but algorithms. So
maybe there should be a sub-section on "Compatibility" like "Selecting the
protocol version to use".

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 3 Dec 2020 16:21:33 +0000

>    That doesn't effect the on-the-wire protocol.

It might.  If it turns out (as happened with TLS 1.3), you have to make NTPv5 look like NTPv4 so that packets aren't blocked, you'll want to put the extra information into the extensions area.

---

From: Philip Prindeville <[email-masked]>
Date: Wed, 9 Dec 2020 17:39:25 -0700

> On Dec 2, 2020, at 11:30 AM, Hal Murray <[email-masked]> wrote:
> 
> 
> values for "no" and "I don't know what you are talking about”.

I’m missing the distinction in the difference between “no” an “I don’t know what you are talking about”.

If you don’t know what I’m talking about, then you probably don’t.

---

From: Hal Murray <[email-masked]>
Date: Wed, 09 Dec 2020 17:06:40 -0800

> If you don’t know what I’m talking about, then you probably don’t. 

"no" means that I do understand what you asked about and the answer is "no".

---

From: Philip Prindeville <[email-masked]>
Date: Wed, 9 Dec 2020 18:27:32 -0700

> On Dec 9, 2020, at 6:06 PM, Hal Murray <[email-masked]> wrote:
> 
> 
> "no" means that I do understand what you asked about and the answer is "no”.

But in both cases, you’re not doing it, so it’s a difference without a distinction, no?

Telnet has WILL and WONT…  There’s no “I-COULD-BUT-IM-NOT-GOING-TO”.

---

From: Hal Murray <[email-masked]>
Date: Wed, 09 Dec 2020 18:19:31 -0800

> Telnet has WILL and WONT…  There’s no “I-COULD-BUT-IM-NOT-GOING-TO”. 

I was thinking of a broader set of questions.  You are thinking of "Do you 
support X?".

I'm thinking of things like "Is it raining?"

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 10 Dec 2020 02:46:08 +0000

>    But in both cases, you’re not doing it, so it’s a difference without a distinction, no?

X509 certificates have a "critical" bit.  In general you can ignore extensions you don't know, but if one of them has the critical bit set, then you can ignore it if you know what it is, but if you don't know what it is you are supposed to treat it as an error.

TLS has the concept that clients send extensions in the hello message, and the server responds with values for the extensions it knows about.

SQL can distinguish between true/false/no-value, 0/null, etc.

---

From: [email-masked]
Date: Thu, 10 Dec 2020 09:39:11 +0100

Is there ever a scenario in which getting an answer "I know it but don't support it." as opposed to a "What even is that? I don't support it." makes a difference in how a requester (supposedly a client) behaves?
If not, I don't think we should make it part of the information flow.

Best regards,

Kristof

-----"ntp" <[email-masked]> schrieb: -----

An: "Hal Murray" <[email-masked]>
Von: "Philip Prindeville"
Gesendet von: "ntp"
Datum: 10.12.2020 02:27
Kopie: "Miroslav Lichvar" <[email-masked]>, "NTP WG" <[email-masked]>
Betreff: Re: [Ntp] Public NTP servers already responds to NTPv5