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

[Harlan Stenn <[e-mail]>]

On 8/9/2022 2:48 AM, 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.

How would an NTPv3 system negotiate Autokey?

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

That's fine.  Is there an issue with this?

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

That is true.

And at least some of us believe those sort of incompatible changes are a 
Bad Idea.

Dave Mills and I have each wondered what your NTPv5 proposals will do 
that cannot be implemented by using the v4 packet format and extension 
fields.

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

So go ahead and re-use them, if you want.  Who is stopping you?

Folks here have also said that they expect "separate engines" for v4 and 
v5 packets in their NTP code.  If that's the case, who cares if the EFs 
are the same or if they're different?

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

Some consider this a bug, some consider this a feature.

I thought implementations had the choice to ignore stuff they didn't 
understand, or drop packets they don't understand.  It's no big stretch 
to return a crypto NAK in this case, too.

In fact, I have found the "crypto NAK on unknown post-base-packet data" 
to be very helpful.

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!