Re: [Ntp] Antw: [EXT] Re: Quick review of WGLC for status change for draft‑ietf‑ntp‑update‑registries

[Martin Burnicki <[e-mail]>]

Miroslav Lichvar wrote:
> On Tue, Aug 09, 2022 at 02:22:32AM -0700, Harlan Stenn wrote:
>> On 8/9/2022 1:13 AM, Miroslav Lichvar wrote:
>>> On Mon, Aug 08, 2022 at 10:33:12PM -0700, Harlan Stenn wrote:
>>>>> NIST servers respond to NTPV4 requests with NTPv3.
>>>>
>>>> which works perfectly with V4 clients, and it works because of the way the
>>>> protocol was designed and has worked for ntp V1-V4.
>>>
>>> It works only with clients that support NTPv3. Not all clients do
>>> that. And v1 is not compatible with v2-v4. There is no mode field yet.
>>
>> I don't understand "clients that support NTPv3".  I know that ntpd (which
>> has been v4 for nearly 25 years' time) talks with NIST just fine.
> 
> Because ntpd kept the NTPv3 support when it added NTPv4. The NTPv3
> support is broken in some ways, e.g. it accepts Autokey extension
> fields which is not possible in NTPv3.

Hm, your statement is basically correct. However, given the explanation 
from the email I wrote just a minute ago, there are 2 possible reasons 
why a client may receive a v3 response from a server in practice:

1.) The client is v3, in which case it doesn't support autokey at all, 
and won't send requests with autokey extensions to the server.

2.) The server is v3, in which case it supports symmetric keys, but not 
autokey. So it is unable to send a response with autokey extensions.

Of course you can have a real v4 client use autokey but send a faked v3 
version, in which case it might get a v3 response with autokey extensions.

I've never heard that this caused any problem. On the contrary, the high 
level of compatibility between v3 and v4 made the slow changeover from 
v3 to v4 very user-friendly.

> Some client implementations support NTPv4 only and don't accept an
> NTPv3 response.

Unless there is some faking around, the server runs a v3 implementation 
in this case. If the client doesn't accept this, the admin has to 
configure the client to use a different server that supports v4.

The same thing will happen if v5 is not compatible with v4, and a 
v5-only client is configured to use a v4-only server.

>>> NTPv5 needs to be designed in such a way that if it is misinterpreted
>>> as NTPv3 or NTPv4, it will produce an invalid response that will be
>>> ignored by the client. The current proposal has that property.
>>
>> I submit better behavior would be for a v3 or v4 client to be able to *use*
>> a v5 response.
> 
> That is not possible if we want to make incompatible changes in NTPv5.

Yes, that's why I believe the acceptance of v5 will grow very much 
slower than the acceptance of v4.

>>>> It sure looks to me like the NTPv5 work will be breaking this.
>>>
>>> Well, if NTPv5 is expected to have incompatible changes like shorter
>>> extension fields, it cannot be compabile with NTPv4. If it was
>>> compatible with NTPv4, it wouldn't have to change to NTPv5.
>>
>> Where is it written that a v4 EF must be compatible with a v5 packet?
> 
> It's not written anywhere. It will save us a lot of work if we can
> reuse the existing EFs (e.g. NTS) as they are specified for NTPv4.
> 
>> And if one requires 7822 header lengths for compatibility, great.
>>
>> The reference implementation supports both, but we do not require 7822
>> minimum lengths because they are demonstrably not needed.
> 
> As I understand it, ntpd doesn't support 7822 yet. It is still
> responding to unknown extension fields with a crypto NAK.

I still don't see why it should not be possible at the server to first 
try to decode the new EF (chain), and if that fails, try the old format, 
as I explained in my previous email.

Of course the server implementation has to support the new EFs, too. 
Otherwise it can only send a crypto NAK when it receives an extension 
field that it doesn't understand.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [e-mail]
Phone: [phone]
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