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

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

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

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

-- 
Miroslav Lichvar