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

[Harlan Stenn <[e-mail]>]

On 8/11/2022 3:41 AM, Miroslav Lichvar wrote:
> On Thu, Aug 11, 2022 at 03:02:16AM -0700, Harlan Stenn wrote:
>> 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?
> 
> An NTPv3 client cannot use Autokey, but when ntpd is configured with
> "version 3", it sends and accepts invalid NTPv3 messages with Autokey
> extension fields. That's a bug.

Perhaps.

What happened to "be conservative in what you send and liberal in what 
you receive"?

I agree it's certainly fine for one side or the other to either allow or 
reject it.

I don't agree that it's a bug.

>>> Some client implementations support NTPv4 only and don't accept an
>>> NTPv3 response.
>>
>> That's fine.  Is there an issue with this?
> 
> It doesn't work with servers that respond with NTPv3, i.e. the "which
> works perfectly with V4 clients" quoted at the beginning of this email
> is not true.

I still don't see the problem.

We have responsibilities *to* others, not *for* them.

The reference implementation follows the pseudocode I previously cited 
regarding how responses are made - it responds with the same version 
that the client packet used.

So it doesn't do this.

If some other implementation does, bring it up with them.

>> 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.
> 
> Nothing. You could do everything with new NTPv4 extension fields.
> There was even a proposal in that direction to get around RFC7822:
> 
> https://datatracker.ietf.org/doc/html/draft-mlichvar-ntp-short-extension-fields-01
> 
> But there seems to be a consensus we should make a clean break and
> address the issues properly instead of doing ugly hacks.

Beauty is in the eye of the beholder.

7822 needlessly (IMO) increases the size of some NTP packets.  If 
somebody decides to implement a legacy MAC with a bigger payload, 7822 
will not help.

>> 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?
> 
> It will simplify the implementations that want to support both. The
> code that looks for extension fields in an NTP message can be separate
> from the code that generates or parses the actual extension fields.

That may be true for *some* implementations.

Again, it depends on the direction future packet versions take.

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