[ntp:hackers] 1. ntpd's sync state (Harlan Stenn)

TS Glassey 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 
INITIALIZATION EVENT.

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

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

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.

>
> Danny
>
> Judah Levine wrote:
>> Hello,
>>     Sure. There are lots of way of doing it with the existing software. 
>> The
>> trouble is that they are not used in the real world, especially in 
>> financial
>> 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
>>
>>
>>>> Hello,
>>>>
>>>>> 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 
>>> dis-
>>>      tance) and estimated error (dispersion) to client user application 
>>> pro-
>>>      grams.
>>>
>>> --
>>> 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 
>>> incompetence.
>>
>> Judah Levine
>> Time and Frequency Division
>> NIST Boulder
>>
>>
>> _______________________________________________
>> hackers mailing list
>> hackers at lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/hackers
>>
>
> _______________________________________________
> hackers mailing list
> hackers at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/hackers 



More information about the hackers mailing list