[ntp:hackers] 1. ntpd's sync state (Harlan Stenn)
tglassey at earthlink.net
Sun Jun 1 15:18:15 UTC 2008
Danny - I can give you that info from an Auditor's perspective.
----- Original Message -----
From: "Danny Mayer" <mayer at ntp.isc.org>
To: "Judah Levine" <jlevine at boulder.nist.gov>
Cc: "Poul-Henning Kamp" <phk at phk.freebsd.dk>; <hackers at lists.ntp.org>
Sent: Saturday, May 31, 2008 7:21 PM
Subject: Re: [ntp:hackers] 1. ntpd's sync state (Harlan Stenn)
> What should such a log file contain?
1) State information on the current system.
Includes TOD, Jitter, Drift, Time of Last Setting,
Last-Setting's Client's AutoKEY PKI.
This data can be used to generate a trail/history of time-setting events.
The System Configuration itslef should be read into the log file each time
the system is restarted to insure that the policy controls for that session
are documented. We refer to the initialization of the System as the
2) Difference Information - inluding any Policy Controls' including
"Statement's of Offset" - i..e. log data showing the difference in this site
from its master set of servers. There are a number of ways to generate this
today but I was thinking that it would be better to not have to manually
generate this data and that the Time Manager took care of this. (I use the
phrase "TIME MANAGER" to pertain to Administrative Deamon's or other
services which are layered on the time-transfer mechanism that NTP
This will be key in documenting whether the NTPD server is properly
operating retrospectively since each timesetting event would need to be
documented ass a STEERING or JAMSET EVENT.
3) Periodic TST Data from Source (the Server's) Systems so that current
systems logs can be reconciled after the fact & not inline (As to why - this
is a key feature in Securities trading who by law and process can only set
their TOD prior to the commencement of the trading day). As such Securities
Firms cannot use Steering to keep their clocks in-line. The idea is for
those systems to be able show monotonic incremental steps in their log files
Otherwise new INITIALIZATION EVENTS would have to be done in the day's flow
of transactions and we all know that isnt too likely to happen.
> If you can define it we can
> implement it. However I don't see how it can be made automatic since you
> need to have a directory to write to and that's not such a simple
> question especially with embedded systems.
It will be though with the availability of massive FLASH based disk and
local storage. So this is only specific to Legacy Systems IMHO.
> The only file that's written
> by default as far as I'm aware is the drift file.
The Logging Files should be done through Syslog/Event Log or the other
systems log interface. It (the Logging System) should allow being secured
and should offer the ability to log in Binary (locally digitally signed
copies - with that entitie's AutoKEY), or through XML message formats.
Again - the Logging Information needs to be secured to a level never before
done with NTP and that means rethinking it. I personally want to see a
TCP/SSL tunnel being used to insure the integrity of the connection and the
content being moved through it.
> Judah Levine wrote:
>> Sure. There are lots of way of doing it with the existing software.
>> trouble is that they are not used in the real world, especially in
>> and commercial servers, where the data may be needed in a future
>> adversary proceeding. My suggestion was to link the capability into a
>> relatively simple and small log file that was turned on by default. This
>> is particularly important for many of the commercial NTP-only boxes
>> that are sold by various companies. The user is usually unable to
>> change the internal firmware on these systems and the log files are
>> either turned off completely or inadequate.
>> Best wishes,
>> Judah Levine
>>>>> 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).
>>> Isn't this exactly what the ntp_gettime() systemcall is for ?
>>> The ntp_gettime() function provides the time, maximum error (sync
>>> tance) and estimated error (dispersion) to client user application
>>> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
>>> phk at FreeBSD.ORG | TCP/IP since RFC 956
>>> FreeBSD committer | BSD since 4.3-tahoe
>>> Never attribute to malice what can adequately be explained by
>> Judah Levine
>> Time and Frequency Division
>> NIST Boulder
>> hackers mailing list
>> hackers at lists.ntp.org
> hackers mailing list
> hackers at lists.ntp.org
More information about the hackers