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

[Ulrich Windl <[e-mail]>]

>>> Danny Mayer <[e-mail]> schrieb am 22.10.2021 um 13:43 in
Nachricht <[e-mail]>:

> On 10/22/21 6:00 AM, Martin Burnicki wrote:
>> Am 22.10.21 um 10:02 schrieb Ulrich Windl:
>>>>>> Doug Arnold <doug.arnold=[e-mail]> 
>>>>>> schrieb am
>>> 21.10.2021 um 15:36 in Nachricht
>>> 
><[e-mail] 
> m> 
>>>
>>>
>>>> One thing to keep in mind is that the use case for leap smearing is 
>>>> that it
>>>> happens in a private network, where all Stratum 1 servers are 
>>>> configured the
>>>> same.  I still consider it dangerous, though.
>>
>> I fully agree. Smearing is just a hack to circumvent limitations of 
>> the underlying time synchronization, and avoid even worse problem that 
>> would occur without smearing.
>>
>> The main problem is with applications that get confused when the 
>> system time (UTC, or a local time derived from it) unexpectedly steps 
>> back by 1 second if a leap second is introduced.
>>
>> In my opinion it doesn't really help if the system clock runs on TAI 
>> because unless applications have explicitly designed to take care of 
>> leap seconds would still request UTC or local time from the operating 
>> system, and thus would observe the same, unexpected time step back if 
>> the kernel clock runs TAI and adds the TAI/UTC offset in the reply to 
>> the query.
>>
>> The only ways to avoid the problems would be to either abolish leap 
>> seconds, or fix all applications to work with TAI and convert to UTC 
>> or local time themselves, or to be aware the time steps back due to a 
>> leap second are a normal case that needs to be handled, similar as the 
>> local time step back at the end of DST.
>>
>>> We could demand that a smearing server may only respond to 
>>> authenticated packets (maybe even specific keys), so clients 
>>> expecting leap smear would have to provide some cryptographic key to 
>>> the server.
>>> A clients querying the server by mistake wuld not get a response then.
>>
>> No. Exactly the other way round. Smearing is to hide the leap second 
>> from downstream nodes, even from dumb clients.
>>
>> As I've tried to point out earlier, in any case it's the task of an 
>> administrator to ensure a proper configuration:
>>
>> - If there are smearing and not-smearing servers, he has to configure 
>> which clients should query the time from which servers.
>>
>> - If the clients should do the smearing, he had to configure each 
>> individual client whether to smear, or not.
>>
>> - If a smearing server would only reply to authenticated requests, he 
>> had to configure on each client which server(s) to use, and which 
>> keys, and it wouldn't even be possible to hide the leap second from 
>> dumb clients.
>>
> You also need to worry about the cascading effects of a server accepting 
> smeared time turning around a sending out smeared timestamps in response 
> to requests from downstream clients. Smearing cannot be considered in 
> isolation.

That's what my original point was about.

Ulrich

> 
> Danny