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

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

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

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

-- 
Miroslav Lichvar