[ntp:hackers] NTP cores in authistrustedip.

Magnus Danielson magnus at rubidium.dyndns.org
Sun Apr 24 21:17:13 UTC 2016


On 04/22/2016 04:22 AM, Harlan Stenn wrote:
> Martin Burnicki writes:
>> A side-effect of autokey is that it transfers the current TAI offset to
>> the clients, and I know some folks who explicitly use autokey for this
>> purpose.
>> Harlan, I know this could also be achieved by using a leap second file,
>> and that there's a script somewhere which tries to download an upgrade
>> the leap second file automatically. ;-)
>> However, using autokey for this is much more elegant, IMO. Once you
>> have configured your server and clients properly you don't have to
>> care if there's a cron job which runs some script periodically, if the
>> download site is reachable via http or ftp, etc.
> With the known weaknesses of autokey, I don't see how *any* use of
> autokey can be considered "elegant".

The TAI-offset being carried of autokey is really a mistake in purpose, 
as it needed an extension field and autokey introduced an extension 
mechanism, autokey and leapsecond offset. Getting the leap-second info 
authenticated is very nice, but is really a separate issue, so when 
autokey as authentication mechanism becomes broken, the leapsecond gets 
thrown out with the bathwater. This shows that the way it was introduced 
and presented was not as elegant as you would like, the ambition to do 
both failed when one of them was broken.

Having to rely on autokey only for the leapsecond info is not elegant, 
but that is "the state of the art".

> But this is exactly the sort of thing that could go into a new extension
> field, and I'd love to see what other information we could usefully put
> there, too.

The way that the extension field could be added, without the autokey 
necessarily added, then allows for the independent leapsecond transfer 
as I recall it. However, it may be a good idea to look at it again.

> Right now the list of interesting items I can think of is:
> - TAI offset
> - a bit signifying "I'm in interleave mode"
> We don't have enough room to encode the TAI offset into a 4-byte EF, so
> if we use an 8-byte EF that gives us the low-order data byte for the TAI
> offset, and the high-order bit for interleave mode, and that gives us
> another 23 bits to use for other things.

The way that GPS encodes the GPS-UTC offset and changes could be a good 
source of inspiration. It encodes the current offset and indicate a 
future offset and when it is due.


More information about the hackers mailing list