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

[Doug Arnold <[e-mail]>]

Hello James,

I agree that leap smearing is a clumsy and dangerous way to avoid the complication of correctly handling leap seconds in distributed database software.  And if it was up to me all IT equipment would use TAI for all timing except what is displayed to humans.  But it is not up to me.  The people who are making the call tell me that they believe that leap seconds is less bad than either moving everything from UTC to TAI, or writing and debugging database software that manages leap seconds properly.

So given that state of affairs.  What do we do?

Doug

From: James <[e-mail]>
Date: Friday, October 15, 2021 at 5:27 AM
To: Doug Arnold <[e-mail]>
Cc: NTP WG <[e-mail]>
Subject: Re: [Ntp] New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt
Doug,
Thanks for the feedback, responses inline.


On 15 Oct 2021, at 00:45, Doug Arnold <[e-mail]<mailto:[e-mail]>> wrote:

Thanks James,

I think that this is pretty close to what is needed for ntpv5.  I like the separation of protocol and algorithms, and the use of monotonic timescale for timestamp fields (at least by default), and the insistence on security.

I have two comments:
1. Why do you think that encryption should be the default mode? People often consider timing information to be critical but not secret.  Also it is likely to affect accuracy in implementations by adding a variable delay to encrypt.

We’ve had a few discussions on list on the subject in the past, and the draft says:

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

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.

- J

1: https://github.com/fiestajetsam/draft-gruessing-ntp-ntpv5-requirements/issues/4
2: https://mailarchive.ietf.org/arch/msg/ntp/hJTpPJ1L5bzBPhLtiQzL3bk75LM/