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 12:17:06PM +0200, Martin Burnicki wrote:
>> That means:
>>
>> - if a v4 server gets v3 request, it should respond with v3
>> - if a v4 server gets v4 request, it should respond with v4
>> - if a v4 server gets v5 request, it should respond with v4
>>
>> The latter should only work if a v5 base packet is compatible with a v4 base
>> packet. Otherwise a v4 server wouldn't even recognize and accept a request
>> from a v5 client.
> 
> The proposed NTPv5 header is not compatible with NTPv4. Servers can
> support multiple versions. If they support NTPv5, they should respond
> with NTPv5. If they don't support NTPv5, they shouldn't respond with
> anything.

What I was trying to describe is how the original ntpd used to handle 
such interaction between different versions in the past.

If not even the v5 base packet format is compatible, this of course 
doesn't work for NTPv5, and in this case of course the server needs to 
respond with a valid v5 packet.

> Servers that don't check the version field and respond with a NTPv4
> response marked as NTPv5 will be ignored by the clients as the client
> cookie will not match the request.

Yes, of course, if NTPv5 is basically different than NTPv4.

>> What does make sense, IMO, is a server which can handle *both* types of
>> extension fields, to be able to serve time to both old and new clients.
>>
>> So the server implementation could
>>
>> - check whether a request has extension fields at all
>> - if there are, check for plausibility of a chain of new EFs
>> - if check of the new EFs fails, try the old EFs
>> - use the new or old EF formats in responses to clients
> 
> There should be no ambiguity with extension fields. NTPv5 is expected
> to be compatible with NTPv4 extension fields. The main use case will
> be NTS. Autokey is insecure and should not be used.

I know that, and I agree, and I only used this as example for "legacy" 
extension fields.

> NTPv5 extension fields could be contained in NTPv4 packets if the
> length was divisible by 4 and it met the RFC7822 requirements, but I'm
> not sure why would an NTPv5-capable client talk with a NTPv5-capable
> server using NTPv4 with NTPv5 extension fields.

The use case I meant was with a v4 server and a v4 client.


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