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

[Miroslav Lichvar <[e-mail]>]

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.

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.

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

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.

-- 
Miroslav Lichvar