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

[Danny Mayer <[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]> 
>>
>>
>>> 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.

Danny