[LEAPSECS] Leap seconds ain't broken, but most implementations are broken

[Tony Finch]

Martin Burnicki <martin.burnicki at burnicki.net> wrote:
>
> Please note that NTP servers not necessarily need to be providers for
> leap second files. There are some well known sites which provide this
> file, and the NTP software package from ntp.org comes with a script
> which can be used to update the file automatically.

I was thinking more that an NTP client or server would use its leapseconds
file for validating LI bits from servers and for determining when they
should leap.

My thinking is that routine software patching and security updates happen
often enough that maybe NTP can get leap second more reliably out-of-band
instead of using in-band leap indicators from upstream servers.
Lower-stratum devices could use their own leap second information to
correct for operational or implementation errors upstream.

> The potential approach with tzdist or special DNS allowed for a
> distributed system, where the special DNS can only provide leap second
> warning and the current TAI offset, while tzdist also provides the leap
> second history, and a way to update time zone rules, so it could be
> generally used to keep also conversion to local time correct.

Oh, I forgot about the DNS publication scheme. That would also help a lot
if it were implemented. And maybe better than relying on sufficiently
frequent software updates.

> Comparing to your example with DNS: If a root server has a software bug
> which lets it deliver a wrong IP address, how should your local DNS
> resolver detect this?

My analogy was more along the lines of, when a root server IP address
changes, the DNS server notices and logs that it has out of date hints.
It's not a great analogy though, because if the DNS server has the wrong
data about one root server, it can recover using the other 12, but if an
NTP server has wrong data about the next leap second, it's screwed.

> > I wonder if it would be better to set the leap indicator bits to NOSYNC if
> > the configured leap seconds file has expired.
>
> Sounds good at the first glance, but I think this would cause much bad
> surprise if you have a company network and suddenly all NTP clients stop
> to be synchronized.

Well, at that point (end of June or December) they don't know if there
should be a leap second or not, so they can't reliably tell the right
time.

Maybe they should fall back to relying on leap indicators from upstream,
but they need some way to make it obvious they might fail.

> The basic problem is more with a stratum-1 server which in many cases
> gets its time only from a GPS receiver. If the GPS receiver provides
> faulty leap second information then the NTP server can hardly detect
> this. Even if it has a current leap second file this wouldn't work.

I don't understand. If it has a current leap second file, it can use that
to detect that its GPS receiver screwed up the leap second. It should then
go NOSYNC.

> For a pure client there should be no problem if the client has several
> upstream servers configured. Before the leap second, the NTP daemon
> accepts a leap second warning only if a majority of the configured
> upstream servers provide this warning. However, the time from the faulty
> server is still correct. Otherwise it wouldn't have been classified as
> good candidate.
>
> When the leap second occurs then all upstream servers as well as our
> server insert the leap second, but faulty servers don't. So the faulty
> servers which haven't done the leap second are off by 1 s afterwards and
> are *then* classified as false tickers.
>
> Of course this also doesn't work correctly if the *majority* of the
> configured upstream servers get the leap second wrong, but in the past
> we have seen that fortunately most public servers get it right.

That seems fairly reasonable, but maybe you could make it more reliable
using a leap seconds file to deal with cases when too many of the
upstreams are wrong.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Thames, Dover: North, veering southeast, 4 or 5, increasing 6 at times. Slight
or moderate, occasionally rough at first in Thames. Showers. Good,
occasionally poor later.