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

[Miroslav Lichvar <[e-mail]>]

On Thu, Aug 11, 2022 at 03:16:05AM -0700, Harlan Stenn wrote:
> On 8/9/2022 3:36 AM, Miroslav Lichvar wrote:
> > 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.
> 
> We disagree.  That's not a problem.  What's wrong with that choice being a
> local policy choice on the part of either the implementation or the
> responding system?

You don't see a problem with sending messages marked as being in one
version, but conforming to another version?

All servers that currently respond to NTPv5 requests are broken. There
is no NTPv5 specified yet. Unfortunately there is a large number of
them, so we need to make sure NTPv5 clients will not accept these
responses.

> > 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 don't understand.  Are you saying that if a v4 client sends an NTS packet
> to a v5 server and that packet "passes the checks" then the v5 server should
> respond with a v4 response?

If the v5 server supports v4, then yes. If it supports v5 only, it
should not respond.

> I think that's what you're saying, and in that
> case the issue of compatibility is moot - the v5 server is not responding
> with v5 EFs.

The compatibility I mentioned makes it easier for existing NTS
implementations to support NTPv5 in addition to NTPv4. I don't expect
there to be any NTPv5-exclusive implementations, at least in near
future.

-- 
Miroslav Lichvar