[ntp:hackers] NTP cores in authistrustedip.

Magnus Danielson magnus at rubidium.dyndns.org
Mon Apr 25 09:26:51 UTC 2016


On 04/25/2016 09:31 AM, Martin Burnicki wrote:
> Magnus,
> Magnus Danielson wrote:
>> Hi,
>> On 04/22/2016 04:22 AM, Harlan Stenn wrote:
>>> Martin Burnicki writes:
>> 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.

Indeed. Especially when considering closed environments where external 
dependencies needs to be kept to a minimum for reliability and security 

>  From today's point of view it surely wasn't the best approach to use the
> autokey extension for it, but it just worked.

Yeah, it kinda 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.

This is also my understanding.

>>> 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
> prefered.


For my applications, the only reason we do autokey is to get the leap 
second info. While authentication is nice and I warmly recommend it, it 
is not a key selling or system point for us.

>>> 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.

Yes, a nice complementary service, but it does not always work for all 
scenarios, as I consider machines isolated from the Internet and 
possibly even from internal DNS. When you have DNS and also use DNSSEC, 
this is a lovely way to get signed and redundant information so that 
validation can be done. The redundancy can also be used to detect 
outliers, which helps to identify problems in the setup before the 
event, and I see the addition of the DNS for leap second event 
dissemination a nice complementary tool.

> 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).

Depends on where they sit. A primary server having a GPS recever, should 
use the information from the GPS receiver to update its leap second. DNS 
and other methods can be used to validate and provide redundancy for 
this information. Similarly can clients use this.

Which method is the right one depends on many parameters. IMHO operator 
errors can be a real problem.

> 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.

Indeed. Having redundancy for this piece of information is good, but 
building and engineering an separate infrastructure in parallel isn't 
what everybody manages to do, so being able to have this included into 
the core time distribution path is more robust for most uses.
The more advanced users can then add redundancy configuration matching 
their needs.


More information about the hackers mailing list