Re: [Ntp] New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt

[Dieter Sibold <[e-mail]>]

On 18 Oct 2021, at 16:33, Miroslav Lichvar wrote:

> On Fri, Oct 15, 2021 at 11:27:20AM +0200, James wrote:
>>> On 15 Oct 2021, at 00:45, Doug Arnold <[e-mail]> wrote:
>>> Encryption and authentication MUST be provided by the protocol specification as a default and MUST be resistant to downgrade attacks...
>>
>> To put this another way, I think the specification must provide confidentiality as well as authentication, and that if either is applied they cannot be removed from a connection (aka a security downgrade) which makes authentication the minimum and doesn’t necessarily mandate confidentiality.
>
> I still don't understand this part. What do "as a default" and
> "authentication the minimum" exactly mean? What information needs to
> be encrypted? Everything? The first octet cannot be encrypted to allow
> detection of NTPv5 packets on the port 123.
>
> For NTPv5 to be successful in replacing NTPv4, I think it needs to
> support no authentication, symmetric keys and NTS.
>
>> This section in particular could probably use some editing and clarification to better explain this [1] as we’ll likely need consensus calls made.
>>
>>> 2. I think that it is better to allow leap smearing and make it a visible part of the protocol than to pretend it is not going to happen.  On this topic I think that Miroslav’s proposal was more realistic.  Data center network architects tell me they definitely plan to continue to do leap smearing.
>>
>> In other use cases such as publicly accessible NTP, leap smearing has effectively fragmented the pools of services a given host can use as mixing smeared and non-smeared services is not a good idea, in addition to the start/end and cadence of smearing being inconsistent between providers [2]. I think that having a “linear, monotonic timescale” and leap smearing together are contradictory and so having smearing in the wire format would requiring changing that. My proposal doesn’t prevent smearing of a clock being synchronised, it’s about removing the smear from the wire.
>
> They can be supported both as different timescales, server responding
> in the one that the client has requested.
>
> If you don't allow leap smearing in NTPv5 at all, I suspect people
> will either stick to NTPv4, missing the important improvements in
> NTPv5, or ignore the specification and use a leap-smeared version of
> NTPv5 anyway.
>
> Same for UTC vs TAI.

Many National Metrology Instituts (NMI) are using NTP to disseminate the legal time, which always is based on UTC. I suppose NMIs will appreciate if NTPv5 servers will have the option to disseminate UTC.

>
> It seems we need to agree on some very high level goals for NTPv5. Is
> it supposed to replace most NTPv4 use cases? Is it supposed to be
> implementable on current operating systems?
>
> -- 
> Miroslav Lichvar
>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp