[ntp:hackers] 1. ntpd's sync state (Harlan Stenn)
mayer at ntp.isc.org
Sun Jun 1 01:48:04 UTC 2008
Judah Levine wrote:
>> There is a need to be able to easily and consistently determine if
>> system clock and/or ntpd's idea of its internal state and the system
>> clock are "correct" (for some definition of correct).
>> To offer this ability, it seems to me that the first thing we need to
>> nail down is the definition and specification of "correct".
>> How about the following:
>> - ntpd's system status bits are not 11
>> - any slew adjustment in-process is under X (where X is configurable)
> I am writing to support this idea and to add three suggestions:
> 1. The method should include a periodic message that the system
> is healthy and has passed whatever tests are part of the protocol.
> I use this idea in the NIST servers and it has been very useful in
> providing authoritative answers to the e-mails that I get that start
> with "Your server is not working because ..." Almost every one of
> these problems is due either to a new firewall or a network configuration
> error by the user, and providing authoritative answers that the server is
> working (or not working) is very useful. In addition, if the test does not
> produce a periodic message that the system is healthy, then proving
> that the system was healthy at some point in the past will be more
> difficult since you will have only an empty log file, and you must then
> prove that the testing system was active.
> 2. The testing protocol should include the source of the time
> synchronization and the last measured time offset with respect to
> that source. As above, this information will be extremely valuable
> if your system is ever involved in an adversary proceeding where
> its time is important.
> It is possible to extract this sort of information from the existing
> log files, but my observation is that most users do not use them,
> possibly because they are too verbose. This leads to my last
> 3. I suggest that at least some minimal version of this capability
> be turned on by default. My experience is that many users don't
> realize that they needed this information until it is way too late.
If you have a specific list of data that you want in a log file can you
provide that list along with criteria for appending to such a log file?
I assume that logging when the server is no longer synched is what you
mean about sending notification messages?
What else is needed? Whenever it changes preferred server, but what else
should be logged?
> Judah Levine
> Time and Frequency Division
> NIST Boulder
More information about the hackers