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

[Ulrich Windl <[e-mail]>]

>>> Doug Arnold <doug.arnold=[e-mail]> schrieb am
15.10.2021 um 17:53 in Nachricht
<[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?

Hi!

I guess the standard C library needs new functions to get the correct time
first ;-)
time_t has a problem.

Amazingly gettimeofday can use struct timezone, while clock_gettime() can't.
So adding the TAI offset to struct timezone would not help much.

Regards,
Ulrich

> 
> Doug
> 
> From: James <[e-mail]>
> Date: Friday, October 15, 2021 at 5:27 AM
> To: Doug Arnold <doug.arnold@meinberg‑usa.com>
> 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 
> <doug.arnold@meinberg‑usa.com<mailto:doug.arnold@meinberg‑usa.com>> 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/