[ntp:hackers] NTP cores in authistrustedip.
martin.burnicki at burnicki.net
Mon Apr 25 07:31:14 UTC 2016
Magnus Danielson wrote:
> 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
>>> 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.
Again, I agree.
> Having to rely on autokey only for the leapsecond info is not elegant,
> but that is "the state of the art".
What I meant is that it's much more elegant to use the NTP protocol (or
an extension of it) to pass the TAI offset to the clients, instead of
having to provide each individual client with a leap second file and a
cron job (or something similar e.g. under Windows) which takes care to
update the file.
>From today's point of view it surely wasn't the best approach to use the
autokey extension for it, but it just worked.
Anyway, after autokey will have been replaced by NTS there will be no
way to pass the TAI offset to the clients via the protocol. Please
correct me if I'm wrong.
>> 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.
Yes. Currently a client can get the UTC time with or without crypto
signature, and with an optional TAI offset extension field the client
get the TAI offset in addition with or without crypto signature, as
>> 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.
Also the way PHK has encoded this in his approach to provide leap second
announcements and TAI ofsets via DNS is nice, IMO.
Using either the DNS approach or the leap second file for leap second
warnings is very good for primary NTP servers, but IMO for clients it's
less error prone to get all the information via the same (NTP) protocol,
admins only have to take care that announcements are updated on the
server(s), and all clients jus follow these server(s).
Otherwise, if on a client a cron job has died or unintentionally be
removed, or the DNS server has been changed, or has become unreachable,
but (only) UTC time is still updated by the basic NTP protocol then
operators may not easily notice there's a problem with one specific client.
More information about the hackers