From: jbrainard@securid.com
Date: Wed, 26 Mar 1997 09:41:11 -0600 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Which time protocol NTP or DTS [-/+]
X-Keywords: authentication [-/+]
In article <333853E4.30D1@platsol.com>,
hal@platsol.com wrote:
>
> My understanding of the attack on SecurID (which may not be correct) was
> that some attackers had captured some authentication messages and later
> altered the time on some systems, including the SecurID (ACE) server and
> resent the messages, allowing them to authenticate under someone else's
> id. I was told that the method of altering the time was to impersonate
> (or spoof) the identity of an NTP server.
>
> Vin McLellan (who apparently is an employee of Security Dynamics) has
> written that this attack should not work, because the ACE server keeps a
> copy of every previous used authentication string. I am in no position
> to dispute this, but it seems to me that after a couple of years you
> would have a pretty big database to search.
>
Just to clarify, the ACE server does not store each PASSCODE used to
authenticate. It stores, in the database record for each user, the time
corresponding to the PASSCODE used for the last successful
authentication. The server, on subsequent authentications, will reject
any PASSCODE which corresponds to any time equal to or earlier than the
stored time.
The replay-prevention scheme described above has been in every SecurID
product shipped. The rumours of this "attack" belong in the "urban
legend" category.
Caveat: I'm a little biased on the subject, since I was one of the
original designers of the system. :-)
- John B.
John G. Brainard
Principal Research Engineer
RSA Laboratories
jbrainard@rsa.com
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
From: vin@shore.net (Vin McLellan) [-/+]
Date: Wed, 26 Mar 1997 16:29:08 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp,comp.soft-sys.dce,ibm.austin.dce
Subject: Re: Which time protocol NTP or DTS [-/+]
X-Keywords: authentication [-/+] DTS [-/+] FAQ [-/+]
Awhile back, Harold Lockhart <hal@platsol.com> wrote:
> > > The
> > > major advantage of DTS is that time is authenticated. This is not a
> > > theoretical problem, a couple of years ago some attackers defeated a
> > > Securid system by spoofing NTP and doing a replay.
And recently, after to and fro from the rest of us, Hal added:
> The incident I referred to was mentioned to me in casual conversation by
> a knowledgable person. Since this has aroused so much interest, I am
> trying to verify the incident and get more details.
>
> Securid, is a distributed authentication system. Like many other
> distributed authentication systems, including Kerberos and any Public
> Key system that use CRLs, it depends on the various computers in the
> network having roughly the same idea of what the current date and time
> is. SecurID uses the current time as a part of the cryptographic hash it
> computes both in the token card and at the authentication server.
>
> My understanding of the attack on SecurID (which may not be correct) was
> that some attackers had captured some authentication messages and later
> altered the time on some systems, including the SecurID (ACE) server and
> resent the messages, allowing them to authenticate under someone else's
> id. I was told that the method of altering the time was to impersonate
> (or spoof) the identity of an NTP server.
Interesting thought: the dependency of public-key systems on time in
order to maintain their CRL (cancelled cert list) -- something I hadn't
thought about. Time signals will be even more vital in a PKI environment,
then -- because PKC private-keys are so much more powerful than mere
authentication tokens.
I'm not an SDTI employee, but I make no claim of being without bias.
As a consultant to SDTI I've done threat and market analysis for them off
and on for many years. After they asked me to write a FAQ on their tech a
year ago, I've also jumped into a lot of online conversations to quash
rumors or correct descriptions of their technology.
Hal Lockhart is an old pro in this business, so I'm sure he understands
how any widely-used computer security tech picks up (often conspiratorial)
rumors over the years. I've seen folks swear up and down the newsgroups
that each SecurID's token-specific "secret key" (which, with date/time, is
hashed to make the SecurID token code) is really the card serial number...
which is embossed on the back of many cards. Some secret!
To my mind, reports of an attacker rolling back the clock on the
authentication server to enable an attacker to reuse a sniffed
PIN/tokencode --a token-code previously used by a legit user in a legit
logon -- have a similar blatent and silly simplicity.
The ACE/SecurID system is built around a mechanism which allows the
ACE/Server to calculate the tokencode using the same version of Current
Time as the token. Time is crucial to the SecurID's mechanism. It is
this "time-synch" which gave ACE/SecurID its crucial market advantage: a
user could submit a single message to the authentication server and get a
yea or nay response. Challenge/Response systems require a message from
the server, which the user then has to type into his token, to calculate a
(Des-encrypted) response -- which then has to be typed at the keyboard and
sent to the server for a yea or nay decision.
Point is: for several years, SDTI has controlled maybe 70+ percent of
the big corporate (<1,500-token sites) market for hand-held authentication
devices with its time-synched SecurID. Doesn't it seem unlikely that
ACE/SecurID, a uniquely time-based system, wouldn't foresee this type of
straightforward attack on its server's clock and design a counter?
The first SecurIDs brought to market maybe eight years ago had all
sorts of problems -- but this was not one of them!
> Vin McLellan (who apparently is an employee of Security Dynamics) has
> written that this attack should not work, because the ACE server keeps a
> copy of every previous used authentication string. I am in no position
> to dispute this, but it seems to me that after a couple of years you
> would have a pretty big database to search.
I should be more precise: What the database actually holds is a
SecurID user-record which contains the user's logon-name, the secret key
associated with the token assigned to a specific user, the time the token
was last used, how many unsuccessful attempts have been made to use this
PIN or token-code, and a measure of any recorded "drift" in that
particular token's clock-chip (relative to the host's clock, which is
assumed to be accurate, even if it isn't.)
The ACE database doesn't really hold a list of previously used
token-codes (although I sometimes explain it that way, metaphorically) --
what it actually holds are the two pieces of information which were hashed
to make the last-used SecurID token-code.
And one of the fundamental rules that govern the way the ACE/Server
handles incoming authentication calls is: the measure of Current Time used
in a incoming request for access _must_ be subsequent to the Current Time
used in the last-recorded valid authentication call.
Incoming token-codes using the same Current Time as the last valid
SecurID authentication call -- or token-codes calculated using a Current
Time from any date/time prior to the time of the last recorded vaid access
-- are summarily rejected.
[SecurID systems also have a timely little trick to defeat race
attacks (where an eavesdropper listens to all but the last digit in a
PIN/tokencode combination and has a program set up to make one or
up-to-ten guesses on the last digit.) With a race attack, the bad guy
gets in first with his correct guess, and the good guy comes in a few
seconds later with a valid logon which get rejected -- because it uses the
same tokencode (same Current Time) as the attacker. ACE/Servers have a
protective overlap, adjustable by the ACE sysadmin, which requires them to
kick both users off the system and close down an account if two identical
calls come in within seconds of each other. The system assumes it is
under attack, closes down the user account, and whistles for help.]
I should hasten to add that none of this cleverness really matters if
your attacker can actually gain remote or physical control of the
ACE/Server's host computer -- but if that happens, your problems are
probably much bigger than any potential attack on the access control
mechanism.
Sorry this got long, but I'm too busy to write short;-)
Surete,
_Vin
--
Vin McLellan + The Privacy Guild + <vin@shore.net>
53 Nichols St., Chelsea, MA. O2150 USA Tel.(617) 884-5548
From: rocky@panix.com (R. Bernstein)
Date: 27 Mar 1997 01:10:24 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp,comp.soft-sys.dce,ibm.austin.dce
Subject: Re: Which time protocol NTP or DTS [-/+]
X-Keywords: authentication [-/+] configuration [-/+] DTS [-/+]
In response to my remark:
> > I know everyone talks about how easy it is to spoof IP addresses,
> > say on the Internet. I wonder though how many people have tried to do
> > so.
Harold Lockhart <hal@platsol.com> writes:
>
> I was using the term spoofing in the general sense of
> impersonation.
That's my point. One can hypothosize impersonation, but try it
sometime in a network that is heavily used with a server that is
heavily used as this "ACE" server would tend to be. It may not be as
easy as you imagine. Once you have done it, I'll ask you more details
about the setup you used.
> Since (standard) NTP does not use strong authentication it is possible
> for an attacker to emit messages that appear to come from an authentic
> NTP server.
Actually I believe DTS suffers from the fact that there is only *one*
time server not many. So while we are imagining spoofing many servers
(in the general sense) we can also imagine spoofing the
authentication.
Where I work, we in fact have 5 servers on the Internet with two
separate Internet providers (and each of them have multiple
backbones). Each server contacts 10 or so geographically different
sites. We also have the hardware to get time from a GPS but are
waiting a conduit to be put on the roof. I'll give you or anyone else
reading this $150 if you can spoof the IPs that my home box uses to
set its time and do it long enough for the time to be say more than 2
minutes off a 3 other stratum 1 time servers. I'll even make it easier
for you and cut the number of servers I contact down to 5 while you
"spoof"!
> Depending on the network configuration involved, this could
> be easy or hard.
Sure, it could be much easier if your network doesn't need a router
which is is probably not the market that DCE is going after. But as I
wrote above, try it in a realistic setting.
Again in response to my remark:
> > In the LAN/WAN where I work, IP spoofing of NTP peers or servers can't
> > happen for a long period.
>
Harold Lockhart <hal@platsol.com> writes:
> It is only necesary for the time to be wrong for a fraction of a second.
You seem to imagine that somehow if I can give out wrong time
information for a fraction of a second that's going to cause other
computers to get the wrong time. No, that is not how NTP works.
In the normal setup, time changes are always gradual and always
monotonically increasing. If one of the timeservers goes astray
anywhere from a millisecond to a decade, it's not going to be noticed
immediately if at all. It is only when *all* the timeservers go astray
together for a long period of time that this will be noticed. And when
would it be noticed? It is probably determinable but not something
that is easily so. And even *if* all timeservers go astray, if the
time varies widely (like 20 minutes) with respect to the computer that
has been receiving time, the information will be ignored.
> If I am able to obtain additional information about this breach, I will
> post it.
Thanks! I'd appreciate it.
> However, use of insecure time presents real risks in any serious
> security environment.
I don't see that you have demonstrated this, except perhaps in the
general sense. :) But in that case I am not sure that a proper
implimentation of NTP configured by reasonably competent people on a
real computer network would constitute "insecure time".
> Besides interferring with an authentication
> protocol, altering the time could invalidate the audit trail or
> circumvent date/time authorization checks.
Yep, not having good time is a bad thing. :)
From: vin@shore.net (Vin McLellan) [-/+]
Date: Thu, 27 Mar 1997 11:57:07 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp,comp.soft-sys.dce,ibm.austin.dce
Subject: Re: Which time protocol NTP or DTS [-/+]
X-Keywords: authentication [-/+] synchronized [-/+]
Speaking of time, the newsfeed here seems to be lagging considerably
behind the e-mail exchange among the participants in this thread. I
apologize if this make the discussion confusing to any readers. We may
also be wandering from the initial thread, but it's sometimes useful to
place such a discussion in a real-word or functional context.
It's worth considering that in the example of an ACE system -- and
perhaps others -- what counts is whether the system is dependent on an
_external_ Time signal. If it is, then I suggest the platform becomes
more stable and trustworthy if Time comes in authenticated and from
multiple sources.
Note, however, that this ACE/SecurID authentication system -- despite
the fact that it is utterly dependent upon synchronized Current Time
(identical, or at least adjusted to appear "identical," at both the
authentication server and within each of perhaps 20,000 hand-held
authenticators, SecurIDs, which might call upon a single server) the
system can manage just fine with no external Time feed.
Internal "system time" need not be dependent on GMT in order to be
stable and useful, particularly in a dedicated machine. As a closed
system, the ACE ("Access Control Encryption," btw) system can manage just
fine -- keeping its many components effectively synchronized, with no
external Time input. Many sites use this model, choosing the elegance of
simplicity.
Worth keeping in mind.
Vin <vin@shore.net> earlier wrote:
>} Point is: for several years, SDTI has controlled maybe 70+ percent of
>} the big corporate (<1,500-token sites) market for hand-held
>} authentication devices with its time-synched SecurID. Doesn't it seem
>} unlikely that ACE/SecurID, a uniquely time-based system, wouldn't
>} foresee this type of straightforward attack on its server's clock and
>} design a counter?
Nigel Metheringham <Nigel.Metheringham@theplanet.net> pulled him up short:
>I am not accusing SecurID of anything here - its a good product and I know
>it works, but I have to take issue with the previous paragraph. Having
>spent all day yesterday at a Cryptography seminar, there have been several
>examples of systems managing to survive a long time with trivially simple
>holes in them.
You are right, of course, Nigel.
My thought was slightly different. What I was thinking of was all
those curious and savvy corporate system, network, and security
administrators who may not know the innards of the ACE client/server
protocol, or the hash used to create the SecurID tokencode -- but who are
_very_ familiar with how their system obtains Time (if it obtains Time
externally,) and what if any services depend upon Time, authenticated or
not.
Marketshare is irrelevant when it comes to the security or integrity of
a product -- but when the dependencies of a product are clear and
widely-understood, the fact that many bright sysadmins have considered
them is not irrelevant. Some products are black boxes, mysterious, the
code opaque -- but at least aspects of others (like the necessity of a
stable Time signal for the time-synch ACE system) are clear and easily
analyzed by all and anyone. The widespread use or installation of some
products is analgous to open publication of the system internals for
public review.
>[...] I know that SecurID has had detailed information on their system leaked
>(so its not as closed a system as it started off), but people who are
>seriously good at the crypto stuff have not found a hole with it.... but
>the argument for its quality based on anything other than audit is not
>good for holding water....
All true. (Actually, some problems have been found -- in the
client/server protocol -- but SDTI has managed to stay ahead of the
attackers and installed fixes, generally a year or two before anyone else
discovered the potential problem.) More to the point, SDTI -- reacting to
the growing sophistication about cryptography among its potential
customers -- is about to publish the full details of the next generation
of its (RSA-based) ACE client/server protocol for public review. Public
audit, if you will;-)
<snip>
Nigel also responded when R. Bernstein <rocky@panix.com> asked for
"something more rigorous than gut feelings" on why Time services should be
authenticated.
>OK, here are a couple of good reasons....
>SecurID can be attacked - a denial of service attack, based on warping the
>time. If the time on your main ACE/Server can be seriously warped (say 5
>minutes or more), then everyone authenticating against that server is
>locked out until the server is fixed.
>
>Second: should you be attacked, working out what happened and who did it
>generally means trawling log files. This is *much* easier if the log
>files are against the same time standard, which you can trust.
Almost any network service can be subject to a denial of service
attack. Access control systems are particularly vulnerable, since most
are designed to close down a user's account ("fail safely") if they have
evidence that the account is under attack. (If you submit a valid SecurID
token-code with an invalid PIN three times, for example, an ACE/Server
will immediately close down an account, since the paranoid guy who wrote
the code worried worried about the risk of a SecurID getting stolen. Most
access control systems have similar mechanisms to void brute force
guessing of passwords or passcodes.
Suerte,
_Vin
--
Vin McLellan + The Privacy Guild + <vin@shore.net>
53 Nichols St., Chelsea, MA. O2150 USA Tel.(617) 884-5548
From: schimpf@gradient.com (Brian Schimpf) [-/+]
Date: 27 Mar 1997 18:03:45 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,comp.soft-sys.dce,ibm.austin.dce
Subject: Re: Which time protocol NTP or DTS [-/+]
X-Keywords: authentication [-/+] DTS [-/+]
In article <wih67ydoofj.fsf@panix.com>, rocky@panix.com (R. Bernstein) says:
>Actually I believe DTS suffers from the fact that there is only *one*
>time server not many. So while we are imagining spoofing many servers
>(in the general sense) we can also imagine spoofing the
>authentication.
Two things here: first, DTS does allow for multiple time servers.
In fact, I believe most people would recommend a minimum of three time
servers in an environment. I don't quite understand the second sentence,
but spoofing user or server authentication (DCE uses Kerberos.) is a lot
different than spoofing IP addresses. [Note before I get called to task, I
am *not* claiming that IP spoofing is "easy," just different.]
Brian
Brian Schimpf
Gradient Technologies Inc.
From: "Greg Schueman" <schueman@ix.netcom.com> [-/+]
Date: 27 Mar 1997 15:57:14 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP on Windows95
X-Keywords: Windows [-/+]
Thomas Herrmann <herrmann@teles.de> wrote in article
<33380D2A.1F34@teles.de>...
> I'd like to know how to find out wether I can use ntp services in my
> current environment (i.e. is ntp installed in my sub-net or so).
> Yet I have found no references to ntp implementations under Windows95.
> Do such implementations exist? Where can I get them?
There are no full NTP implementations for Windows 95, but there are some
commercial/shareware Simple NTP
protocol programs available. Look at http://www.eecis.udel.edu/~ntp
-Greg
From: kees@echelon.nl (Kees Hendrikse) [-/+]
Date: Mon, 31 Mar 1997 00:34:12 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Suggestions? [-/+]
X-Keywords: loopstats [-/+] maxpoll [-/+] minpoll [-/+] poll [-/+]
In <333ED0F5.3C23DF25@degeorge.org> David DeGeorge <dld@degeorge.org> writes:
> I am connected to the internet via an isdn and I wish to run xntpd on my
> linux machine with a
> large minpoll value, say 12 (a little over an hour). After some
> experimentation I deduced that it takes
> several polls before xntpd makes its mind up what to do. Since my clock
> seems to drift about .3 seconds every four hours I am not happy.
> Currently I run ntpdate -b ... every four hours from cron and that seems
> to work. I would be happier with xntpd but I don't want to have my isdn
> up the time that a shorter minpoll would we require. Any suggestions on
> how to start xntpd with a short poll period and then increase it or is
> this just dumb?
I do don't think ntp and ISDN go very well together. Xntp works best when
it can poll a couple of servers and can poll every 64 seconds if needed.
Obviously, this costs a lot in ISDN time. However, you might try this
approach: First, let xntpd run for about 1 or 2 days with normal minpoll
and maxpoll values, so it can estimate the frequency error and write
something sensible into the drift file. (Let xntpd write loopstats and
wait until the frequency error is stabilized.) Then, *decrease* the maxpoll
value to 8 and at the same time make xntp-traffic uninteresting to the
ISDN dialer so it won't open the line if the only traffic is ntp traffic.
What will happen is that ntp will poll the server(s) at least once per
4 minutes and at most once per minute, but packets won't get through unless
the ISDN channel is already open. Probably you will have enough ntp-traffic
to keep the clock reasonably in sync.
--
Kees Hendrikse | email: kees@echelon.nl
|
ECHELON consultancy and software development | phone: +31 (0)53 48 36 585
PO Box 545, 7500AM Enschede, The Netherlands | fax: +31 (0)53 43 37 415
From: rbthomas@lilypad.rutgers.edu (Rick Thomas) [-/+]
Date: 3 Apr 1997 19:57:21 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Suggestions? [-/+]
X-Keywords: dial [-/+] dialup [-/+] jitter [-/+] poll [-/+]
Increasing MINPOLL won't help. The problem is this: If the dialup (or
ISDN) line is inactive when a poll comes thru (no matter how
frequently this happens - i.e. whatever the value of MINPOLL), it will
have to dial to allow the packet thru. The connection will be held
long enough for the return packet from the server to arrive.
This is an asymmetric situation. It takes longer (by ntp standards,
MUCH longer) for the outgoing packet to get to the server than for the
incoming packet to get back to the client. The NTP protocol assumes
that these times are the same. This throws off the calculations for
the offset.
If NTP packets _always_ caused a dial to occur - and the dial always
took the same amount of time to complete, the asymmetry would result in
there being a consistent and predictable offset (of the same order of
magnitude as the dial time) between your clock and UTC, but you could
probably live with that. Unfortunately, that's not the way it works.
Sometimes the line is up when xntpd decides to send it's packet, and
sometimes it's down. So instead of an offset of the order of the
dial-time, you get a jitter of the same magnitude. NTP can't deal with
that and will probably declare your server to be "insane".
The best solution is to _decrease_ MAXPOLL, and train your dialer to
ignore NTP packets, as described in an earlier posting.
Enjoy!
Rick
From: phess@best.com (Patrick Hess)
Date: 2 Apr 1997 02:17:20 -0800 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Help - where to start on configuring timeserver
X-Keywords: configuration [-/+]
One liner:
file://xntp3-5.86/html/build.html
Pat
In article <334021C3.6C4C@cmgi.com>, Jayesh Kamdar <jkamdar@cmgi.com> wrote:
>Hi,
>
>I just got the tar file xntp3-5.89.tar. I untared it and trying to find
>the stuff to start configuration but I am not getting vere far. If
>anybody can give me hints for where to start I would really appreciate
>it.
>
>I would really appreciate if you can mail me privately but if can't that
>fine too, please post on this news group.Thanks a lot.
>
>Jayesh
>jkamdar@cmgi.com
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 02 Apr 1997 08:51:05 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: NTP experience with PARSE clocks
X-Keywords: DCF77 [-/+] dispersion [-/+] HP-UX [-/+] jitter [-/+] Linux [-/+] minpoll [-/+] precision [-/+] Stenn [-/+]
Hello,
I'd like to present some knowledge gained on different machines using
PARSE reference clocks (DCF77 variants).
First I want to repeat that with only a single reference clock it
seems wise to increase the default value of minpoll. For Our HP
9000/827 running HP-UX 10.10 an increase from 64s to 256s reduced the
"jitter" in the frequency noticable: The standard deviation was
reduced from 1.8 to 1.4 (several day's average, but quite stable
before and after the change).
Secondly I have made the experience that system load has ill effects
on the accuracy of the daemon; at least in Linux. Some people said
that xntpd compensates for jitter and spikes, but read on: Running the
latest version on Linux 2.0.28 synchronizing to DCF77 AM, and running
"top" and "midiplay" concurrently (as well as GNUPLOT occasionally)
the CPU was busy from 4 to 80%. xntpd just ran with high priority
(nice), but not real-time priority. As a consequence xntpd was
scheduled up to one tick late occasionally (it seems). As Linux does
not have timestamping of serial events in kernel space, the measured
event times were shifted. I immediately noticed that the dispersion
went up, while offset and frequency drifted away. When stoping the
additional system load (mainly midiplay generating a lot of interrupts
or I/O load) the dispersion, offset and frequency went back to theit
normal values.
Funny, I had never expected the frequency to be affected by system
load! This clearly indicates the advantage of using POSIX.4 real-time
scheduling where available. I had already talked to Harlan Stenn about
that, but then the opinion was "not necessary; maybe when we have
time". Agreed, it's not necessary when precision kernel timestamps for
events are available (and I'm fighting for these in the Linux kernel
list), but most commercial systems (e.g. HP-UX 10.10 on S800) don't
have it.
Maybe replace the HP-UX rtrio stuff by the posix functions. For Linux
it will ensure that xntpd is scheduled immediately when an I/O event
has occurred (otherwise it would have to wait until the time-slice of
the running process is consumed).
(As far as I remember the HP-UX supplied version of xntpd 3.5f has the
real-time stuff disabled; maybe for paranoia reason)
Ulrich
From: kees@echelon.nl (Kees Hendrikse) [-/+]
Date: Thu, 3 Apr 1997 19:01:41 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: CONRAD DCF MODUL SERI
X-Keywords: DCF [-/+] delay [-/+]
In <3343D434.6956@fantic.lnz.dec.com> Joe Watzko writes:
> Ulrich Windl wrote:
>
> Has someone got the new "DCF MODUL SERIELLE AUSGABE",
> Order# 641960 from Conrad Electronic, running on a Unix box.
> I know there is on option kit for DOS, but
> Unix would be fine.
I have one of these around, but I don't think it's any use in an xntp
environment. Basically it listens for at least a minute to the DCF signal,
reformats the info and outputs it as a BCD string. Very nice, but you
don't know *when* the output starts:
> Transmission of dates after start of the second may be delayed,
> depending on the clock's pulse width - for 5 msecs = 35-45 mesec, for
> 15 msecs = 45-75 msecs. Since the processor load may be heavier at
> certain times (e.g. for hourly transfer), the transfer of data at such
> times may be delayed up to 150 msecs.
So you'll have an unknown delay which may be as big as 150ms. It seems
this device only uses the DSF date/time info, not the much more important
start-of-second mark.
--
Kees Hendrikse | email: kees@echelon.nl
|
ECHELON consultancy and software development | phone: +31 (0)53 48 36 585
PO Box 545, 7500AM Enschede, The Netherlands | fax: +31 (0)53 43 37 415
From: thomas.g.booth@den.mmc.com (Booth, Thomas G)
Date: 4 Apr 1997 03:03:52 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Build WWVB clock from old PC? [-/+]
X-Keywords: implementation [-/+] jitter [-/+] NIST [-/+] nist [-/+] PPS [-/+] precision [-/+] resolution [-/+] WWVB [-/+]
In article <19970403011040.richw@yank.kitchener.on.ca>, richw@webcom.com
(Rich Wales) wrote:
> I was thinking of recycling an "ancient" PC/XT clone by turning it into
> a WWVB reference clock.
> The project would involve a radio receiver (fixed-tuned to WWVB), with
> the output tied into one of the modem control signal lines of a serial
> port. The PC would run a program that would synchronize itself to the
> time code pulses (hopefully to at least millisecond accuracy), decipher
> the code, and produce timestamp and PPS output in a suitable format.
> This seems like a fitting use to put an otherwise obsolete system to.
> It would also be an interesting programming project -- but before I jump
> into it, I'd like to know if anyone else out there has already done it
> (or tried to do it and concluded it won't work).
I haven't tried such a project, but here's my rambling thoughts on it.
1) An implementation based on the standard DOS system clock won't be
acceptable due to the approx. 55 ms resolution limit. A temptation would
be to just increase the system clock from the standard 18.2... ticks/sec to
1000 ticks/sec by monkeying w/ the interval timer load, but such a change
would need to be carefully evaluated for impacts to DOS/BIOS/hardware
compatibility. Also, the non-integer number of ticks/second for the
standard DOS clock makes for a rather jittery 1 PPS signal - too jittery
IMO for a precision source.
2) Accuracy & stabilty of the XT clock oscillator probably needs to be
improved. For example, if my mental math is right, a clock based on an
oscillator w/ 100 ppm frequency offset from nominal (100 ppm is not
uncommon for PC crystals) will accumulate 1 ms error in 10 seconds.
Tweaking the hardware or compensating in software to correct for frequency
offsets will help; temperature-dependent frequency variations in the
crystal will limit the improvement though. An alternative approach would
be to replace the standard clock oscillator w/ a suitable voltage
controlled crystal oscillator (VCXO) which is controlled by the 8088 via a
latch & D/A converter or similar; the CPU would be programmed to steer the
VCXO to minimize accumulated errors relative to the 1 PPS time code from
the receiver.
3) Don't forget that the WWVB time code will be delayed by propagation &
receiver effects before it reaches the PC port, and it will be necessary to
account for this. Also, it probably wouldn't hurt to ensure that the
worst-case PC I/O latency & jitter is well within the desired 1 ms
resolution.
4) FWIW NIST Special Publication 432 states an accuracy of about 0.1 ms
for the WWVB time code (see
http//www.boulder.nist.gov/timefreq/pubs/sp432/s_wwvb.htm for relevant
information). If NIST's accuracy statement isn't overly conservative, then
attempts to achieve better than millisecond level resolution may be wasted
effort.
I guess my bottom line on this project is that IMO an XT clone is not a
very optimum choice given the requirements you've established. While I
believe the 8088 processor would be adequate for the job, the XT system
design takes away some design freedom (unless you're willing to hack in
some modifications). A better approach would be to go with a more modern
uC or PIC as the basis for the project.
TGB
\\ The opinions expressed herein are my own. //
From: wiu09524@rrzc4 (Ulrich Windl) [-/+]
Date: 03 Apr 1997 08:14:52 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: xntpd dies if bad sync
You always should run ntpdate before xntpd; especially after
booting. It will save you at least five minutes waiting for sync...
--
Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
From: kees@echelon.nl (Kees Hendrikse) [-/+]
Date: Tue, 8 Apr 1997 08:36:12 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,comp.unix.sco.programmer
Subject: Taming the clock - Xntp on SCO
X-Keywords: adjustment [-/+] configuration [-/+] documentation [-/+] loopstats [-/+] maxpoll [-/+] Mills [-/+] release [-/+] resolution [-/+] SCO [-/+] Stenn [-/+]
A couple of months ago I decided to start using XNTP on two SCO systems,
one running Open Enterprise Server 5.0.0, the other SCO Unix 3.2.4.2.
Both systems had older xntp-versions installed (as supplied by SCO),
so I grabbed a recent copy from louie.udel.edu, compiled it and started
running it. After a few days it was clear xntp was not working the
way it was supposed to work. It couldn't get a good "grip" on the clocks,
and needed many resets a day.
Looking around for more info, DejaNews (www.dejanews.com) offered some
interesting articles on the subject. For example, on April 11, 1996
Tom Fitzgerald (fitz@think.com) wrote:
| Message-Id: <FITZ.96Apr11195756@rog.think.com>
| Newsgroups: comp.protocols.time.ntp
|
| (...)
| NTP and SCO don't seem to get along very well, the behavior of the
| adjtime() system call isn't what NTP wants, and NTP tends to thrash
| around trying unsuccessfully to fix things. The clock will drift
| forward and back by most of a second, screwing up the statistics.
It started to sound like a challenge. I quickly got hooked and spend a
lot of time watching 'tail -f loopstats' and continuous running ntpq's.
As it turned out, Tom was wrong and XNTP & SCO can be tweaked to like
each other well enough to get the time within about 25 ms of stable
lower stratum clocks most of the time. About the only problem left is
that xntp has a tendency to overshoot when it has to correct more than
40-50 ms but it behaves way better than before.
Xntp release 3.5.90 (April 7, 1997) includes ifdef'd code for SCO and
'configure' will add the right defines. However, that's only part of
making xntp run well, there is some tweaking to be done.
Here is a 'how to' recipe for the two versions of SCO Unix. Most probably
the OES 5.0.0 recipe can be used for OES 5.0.2 as well and the 3.2.4.2
recipe is o.k. for 3.2.4.0 and 3.2.4.1. If you are still running 3.2.2
or earlier, you're on your own.
SCO Open Enterprise Server 5.0.0
--------------------------------
1) In its default configuration, the system time is being adjusted by
the hardware clock. Change the value of 'track_rtc' to 0 in the file
/etc/conf/pack.d/kernel/space.c and relink the kernel. This will stop
this behaviour and give xntpd complete control over the clock. As an
alternative: use xntp's tickadj utility to switch off this behaviour.
(Rerun tickadj after every reboot!)
2) The kernel-variable defining the length of a tick is 'ONE_TICK_IN_US'
and has the value 10,000 us. This variable can be used by xntp, but
changing it with 'tickadj' is meaningless. The SCO kernel has no notion
of the duration of a tick; it only knows that 'hz' ticks make up one
second. So it's better to just predefine tick to be 10,000 and leave
ONE_TICK_IN_US alone. (Note: There is also a variable 'tick', which is
a remnant of earlier implementations. This variable is *not used at all*.)
Xntp 3.5.90 has tick predefined with the value 10,000 us.
3) There also is a tickadj-like variable in the kernel: 'clock_drift'.
This variable is in nano-seconds and can be used by xntp. However, it
is not working the way xntp expects it to work. Basically, xntp expects
tickadj to be the number of microseconds added to or substracted from
tick when the clock is being slewed. SCO uses clock_drift to calculate
the maximum number of ticks that should be added to or substracted from
hz (nominally 100) when an adjustment needs to be made. In other words,
time is adjusted by adding or dropping whole ticks instead of adjusting
the length of a tick.
SCO documentation suggests that any value of clock_drift is acceptable.
This is not accurate; only the integral number of 'ONE_TICK_IN_US's in
clock_drift will be used, the remainder is silently dropped and adjtime()
will be lying about the amount of adjustment that was made.
The same is true for the value of delta given to adjtime(). Although
any value will be accepted, only an integral number of ONE_TICK_IN_US's
will be adjusted. (However, the next call to adj_time() does report the
remainder.)
This limits xntpd in what it can do to adjust the system time: it
can add or substract n ticks a second, where 'n' depends solely on
the value of clock_drift. If we set 'clock_drift' to 10,000,000 ns/s,
n is 1 tick/sec, or 10,000 us/sec. In xntp-terms, this translates to
100 us/tick for exactly 'hz' ticks.
Xntpd 3.5.90 uses "clock_drift" and its value can be changed with the
tickadj utility. The value is scaled to 'us/tick'.
(100 us/tick recommended)
SCO Unix 3.2.4.2
----------------
1) In its default configuration, the system time is being adjusted by
the hardware clock. There is no user-accessible variable that controls
this behaviour. However, you can disable it by destroying the function
check_rtc() in the kernel. Write the long value 0xc3c033 into the address
of check_rtc() in /unix, which patches the function to 'xor %eax,%eax; ret;'
making it return the integer value 0 whenever it is called. Reboot the
system after applying this patch. Once you're satisfied it works and
doesn't break anything else, apply the same patch to the check_rtc()
function in clock.o, which is in /etc/conf/pack.d/kernel/os.a, so your
future kernel-builds won't reintroduce the original check_rtc() function.
**Disclaimer: Don't apply these patches unless you know what you're doing.
Backup /unix and .../kernel/os.a before patching them, document what you've
done and don't contact me if you screw up. You're on your own.**
2) The kernel-variable defining the length of a tick is 'tick' and has
the value 10,000. This variable could be used by xntp, but changing it
with 'tickadj' is as meaningless as with SCO 5.0.x. Xntp 3.5.90 has tick
predefined with the value 10.000.
3) SCO 3.2.4.x's tickadj-like variable is: 'stickadj'. This variable is
in whole 'tick's' and can be used by xntp. It is the number of ticks
that is added to or substracted from hz (nominally 100) when an adjustment
needs to be made. The default value is '1', which is the about the only
value that makes any sense; in terms of xntp it is already quite big.
This limits xntpd in what it can do to adjust the system time: it can add
or substract n ticks a second, where 'n' equals 'stickadj'.
Xntp 3.5.90 uses 'stickadj' and its value can be changed with the tickadj
utility. It is scaled to us/tick and the recommended value is 100 us/tick.
Performance
-----------
I am satisfied with the way xntp runs on my two SCO systems. Under
laboratory-like conditions (i.e. a quiet sunday morning when network
traffic is mostly xntp-traffic and system load is very low :-) loopstats
look like:
day time offset frq error const
----- --------- --------- --------- -----
50523 17542.300 -0.007926 -292.1146 9
50523 18054.160 -0.004953 -292.1542 9
50523 18566.010 -0.001108 -292.1631 9
50523 19077.870 -0.002858 -292.1859 9
50523 19589.730 -0.001098 -292.1947 9
50523 20101.590 -0.003974 -292.2265 9
50523 20613.440 -0.001926 -292.2419 9
50523 21125.300 0.000117 -292.2410 9
50523 21637.160 -0.001746 -292.2549 9
50523 22149.020 0.000795 -292.2486 9
Not bad, considering the intrinsic resolution of 10 ms. Under normal
conditions typical loopstats are like:
day time offset frq error const
----- --------- --------- --------- -----
50524 51046.130 -0.016761 -291.1288 9
50524 51557.980 -0.015408 -291.2521 9
50524 52069.840 -0.019999 -291.4121 9
50524 52581.700 -0.020481 -291.5759 9
50524 53093.550 -0.024052 -291.7683 9
50524 53605.410 -0.023958 -291.9600 9
50524 54117.270 -0.016901 -292.0952 9
50524 54629.120 -0.016059 -292.2237 9
50524 55140.980 -0.010753 -292.3097 9
50524 55652.840 -0.011551 -292.4021 9
50524 56164.700 -0.004533 -292.4384 9
50524 56676.550 -0.005615 -292.4833 9
50524 57188.410 -0.008466 -292.5510 9
50524 57700.270 -0.014977 -292.6708 9
50524 58212.120 -0.015213 -292.7925 9
Typical loop-summary for a week:
loops: 1200,
offset: -0.009986+/-0.054311, rms 0.013488
freq: -308.61+/-23.587, var 5.433
[This system is client of 3 local stratum-2 servers; each of the stratum-2
servers is client of 2 remote stratum-1 servers, 1 remote stratum-2 server
and peers with the other 2 local stratum-2 systems.]
Note:
Because of the frequency error of 300 ppm and no way to adjust 'tick',
I have to run with maxpoll=9 on this system. (Maxpoll>9 results in
offsets "swinging" from -70 ms to +70 ms whenever the loopconstant is >9.)
Thanks to Dave Mills (Mills@huey.udel.edu), Harlan Stenn
(stenn@whimsy.udel.edu) and Ulrich Windl (Ulrich.Windl@rz.uni-regensburg.de)
for helping me out with xntp issues.
Special thanks to Bela Lubkin (belal@sco.com) for digging through the SCO
Unix sources to find out what goes on inside SCO's tickadj() and related
functions.
--
Kees Hendrikse | email: kees@echelon.nl
|
ECHELON consultancy and software development | phone: +31 (0)53 48 36 585
PO Box 545, 7500AM Enschede, The Netherlands | fax: +31 (0)53 43 37 415
From: richw@webcom.com (Rich Wales) [-/+]
Date: 7 Apr 1997 10:13:34 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Build WWVB clock from old PC? [-/+]
X-Keywords: calendar [-/+] delay [-/+] implementation [-/+] PPS [-/+] precision [-/+] resolution [-/+] WWVB [-/+]
Earlier, I wrote:
I was thinking of recycling an "ancient" PC/XT clone by
turning it into a WWVB reference clock.
Thomas G. Booth <thomas.g.booth@den.mmc.com> replied:
An implementation based on the standard DOS system clock
won't be acceptable due to the approx. 55 ms resolution
limit. . . . the non-integer number of ticks/second for
the standard DOS clock makes for a rather jittery 1 PPS
signal - too jittery IMO for a precision source.
Agreed. Clearly, I'll have to do some nonstandard stuff with the system
clock in order to produce stable 1-pps output. By loading the 8253
timer with a different value -- in place of the default 0 (= 65,536) --
the system clock can be adjusted for an exact integral number of ticks
per second. For example, a counter value of 59,659 gives 20 ticks/sec.
A temptation would be to just increase the system clock
from the standard 18.2... ticks/sec to 1000 ticks/sec by
monkeying w/ the interval timer load, but such a change
would need to be carefully evaluated for impacts to DOS/
BIOS/hardware compatibility.
I, too, initially thought something like 1000 ticks/sec would be needed.
But after thinking about it some more, I don't believe this is required.
Since the reference clock only =needs= to produce accurate time info
on the second (i.e., 1-pps signals with corresponding time stamps), it
really shouldn't matter what it has to do during the course of any given
second, as long as the 1-pps signals are on time.
And if it is necessary to get an accurate fractional-second time stamp
(such as to calibrate the clock oscillator and keep it in sync with
WWVB), this info can be obtained by reading the 8253 timer info on the
fly and working with the current count value plus previous clock ticks.
I think it should be sufficient to reprogram the system clock to give
20 ticks/sec -- or even 19 ticks/sec. This would be close enough to the
nominal rate that other timer-dependent things (like the floppy drive)
won't be seriously affected. In any event, I envision this reference
clock project as a more-or-less standalone application, so even if other
things (such as floppy I/O) were disrupted once it starts up, it won't
really matter, as long as actual physical damage doesn't occur.
Accuracy and stabilty of the XT clock oscillator probably
needs to be improved. . . . Tweaking the hardware or com-
pensating in software to correct for frequency offsets will
help; temperature-dependent frequency variations in the
crystal will limit the improvement though.
True. The software should hopefully be able to correct for instability
by adjusting the system clock timer (number of crystal oscillations per
clock tick). But if the system loses the WWVB signal, the clock could
start drifting badly.
An alternative approach would be to replace the standard
clock oscillator w/ a suitable voltage controlled crystal
oscillator . . . .
Good idea. I'll look into that as a later improvement, perhaps after
first trying the standard XT clock oscillator, and seeing how reliable
the WWVB radio signal is. BTW, although I currently live near Toronto,
I'm going to be moving to the San Francisco area this summer and will be
building the project there; WWVB should be stronger there than here.
Don't forget that the WWVB time code will be delayed by
propagation & receiver effects before it reaches the PC
port, and it will be necessary to account for this.
Agreed. The delay should hopefully be known in advance, and it could be
passed to the software via a command-line argument. It should then be
possible to compute the counter value that =ought= to be present on the
system clock (8253 timer #0) at each 1-pps signal from the WWVB time
code, and adjust the system clock accordingly.
the WWVB time code contains day of year information and
last two digits of calendar year only, so it would be
necessary to ensure the software is designed to properly
handle a rollover when January 1, 2000 arrives.
Absolutely.
Rich Wales richw@webcom.com http://www.webcom.com/richw/
From: Damon at play <dhd@exnet.com> [-/+]
Date: Mon, 7 Apr 1997 20:12:28 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Solaris-2, xntpd, Java, and real-time scheduling
An interesting observation.
I have been running a non-CPU intensive Java process continuously
on a Sun SS1+ (as it happens, polling all our NTP servers via I
class or two I have written---yes, I will publish them at some point!).
While running this very gentle program, the xntpd-controlled clock
on the machine starts losing time very badly, like as much as a
second per minute! xntpd valiantly tries to cope by repeatedly
stepping the clock.
(This is all on Solaris 2.5.)
Java (JDK 1.0.2 in this version) does a lot of context switching
and system calls, even when idle, which may be affecting xntpd's
ability to be scheduled promptly on receipt of a message. The
SS1+ is quite a slow machine, and Java is quite heavy-weight,
which will exacerbate the problem if my theory holds water.
After a *small* amount of observation, it seems that making the
xntpd run real-time (with an example command from the priocntl(1)
page) has stopped the stepping behaviour:
# /usr/ucb/ps -guxww | egrep xntpd
root 240 0.0 3.2 1652 868 ? S 16:26:15 0:09
/usr/xntp/xntpd -c /etc/inet/ntp.conf
# priocntl -s -c RT -t 1 -r 10 240
# priocntl -d 240
REAL TIME PROCESSES:
PID RTPRI TQNTM
240 0 100
I shall keep watching, but since RT exists on Solaris-2, and
xntpd is an ideal candidate, it would be nice to have a
config option to use it...
Regards,
Damon
--
Damon s0dhd@exnet.com, d@hd.org
http://www2.exnet.com/ http://www.exnet.com/CV/DHDCV.html
From: Todd Aven <Todd.Aven@Bankerstrust.com> [-/+]
Date: Wed, 02 Apr 1997 10:45:52 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntp for Novell Netware 4.x? [-/+]
X-Keywords: Novell [-/+]
Christer Johansen <christer@sn.no> wrote in article
<01bc3932$31ae8440$0100a8c0@chjo2-pc.tdata.no>...
> What I would like is a xntpd for Novell Netware 4.x. That way our master
> Netware time server could synchronize to the Unix master time server and
> our whole network would be in sync. Does anyone know of such a product
> (commercial or freeware, it doesn't really matter) ?
Christer,
You should talk to Polygon (?www.polygon.com?) about their Cadence
product,
which will synch with an NTP3 server.
Regards,
Todd
From: Matthew Brookes <mtb@broadcom.ie>
Date: Fri, 04 Apr 1997 11:26:28 +0100 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Decoding Return Date/Time from Time Server
John Henry Miller wrote:
I am using "Swatch" as my time client. I was watching it get the
date
and time by trapping the WinSock API calls. I could see the Hex
value
of the Date/Time that it was returning but I could not figure out
how to
decode it. The four bytes of date/time that it returned in Hex was
"B6
EE D5 10". The date/time was 97-04-03 around 20:00. Does anybody
know
how to decode this("B6 EE D5 10")?
Thanx
Well, I don't know about "Swatch" - (I thought that was a trademark for
real wathces! :-), but RFC868 states:
The Time
The time is the number of seconds since 00:00 (midnight) 1 January 1900
GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this
base will serve until the year 2036.
For example:
the time 2,208,988,800 corresponds to 00:00 1 Jan 1970 GMT,
2,398,291,200 corresponds to 00:00 1 Jan 1976 GMT,
2,524,521,600 corresponds to 00:00 1 Jan 1980 GMT,
2,629,584,000 corresponds to 00:00 1 May 1983 GMT,
and -1,297,728,000 corresponds to 00:00 17 Nov 1858 GMT.
So, your hex number is probably just that, in hex.
As for converting it back to the real time - you'll have to ask a
programmer - which I'm not!
Matt.
From: kees@echelon.nl (Kees Hendrikse) [-/+]
Date: Fri, 11 Apr 1997 00:22:26 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Is there an overflow in the loopfilter?
X-Keywords: Cisco [-/+] VMS [-/+]
In <1997Apr10.111236.26485@roper.uwyo.edu> jimkirk@uwyo.edu (James Kirkpatrick) writes:
> [description of periodic swings in drift rate]
>
> I've noticed something similar, but am in the middle of a long-term (1 week)
> data-gathering phase and am not ready to be positive about this. But I've
> noticed an apparent 24-hour sine-wave variation in the offset values.
(..)
> Note I'm not using xntp, I'm using the NTP daemon that comes in Cisco's
> product Multinet for VMS.
Be carefull with Cisco NTP implementations as NTP tends to run with a low
priority. A couple of months ago I had a Cisco 4000 configured as client
of a number of public stratum-1 servers and as server to the rest of our
LAN. About every 30 minutes it drifted away from the other stratum 2 clocks
on our LAN. It took me a while until I realized this was caused by the
usage pattern of the router. Every 30 minutes we download newsbatches for
a couple of minutes, long enough to disrupt NTP. Make sure your 24-hour
pattern isn't linked to usage as well!
--
Kees Hendrikse | email: kees@echelon.nl
|
ECHELON consultancy and software development | phone: +31 (0)53 48 36 585
PO Box 545, 7500AM Enschede, The Netherlands | fax: +31 (0)53 43 37 415
From: jimkirk@uwyo.edu (James Kirkpatrick)
Date: 9 Apr 97 08:25:43 MDT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: clock hardware drivers?
X-Keywords: IRIG [-/+] PPS [-/+]
In article <5idqcl$9bg$1@biteme.psibercom.org>, spore! <spore@biteme.psibercom.org> writes:
|>I've begun looking into a hardware clock solution for our company. We
|>have been using public NTP servers exclusively and are ready to get our
|>own clock.
|>
|>One I'm interested in says it does IRIG-B and 1 PPS output. In terms of
|>using NTP on a box with this clock, I'm wondering what drivers from the
|>distribution would be most appropriate. I'm guessing:
|>
|>Type 6 IRIG Audio Decoder (Sun only) (IRIG)
|>
|>but I'm lost as to which one is the 'generic' 1 PPS driver. This would be
|>for a Sun box. Thanks for any info someone can provide!
We're fairly happy with a dedicated purpose-built time server. Try
http://www.datum.com
and look for their TymServ 2100. They also have boards to turn various
systems into time servers.
No affiliation, just a happy customer.
Jim
From: schimpf@gradient.com (Brian Schimpf) [-/+]
Date: 7 Apr 1997 13:05:45 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,comp.soft-sys.dce,ibm.austin.dce
Subject: Re: Which time protocol NTP or DTS (long)
X-Keywords: authentication [-/+] synchronized [-/+]
In article <wihiv217ryo.fsf@panix.com>, rocky@panix.com (R. Bernstein) says:
>
>When discussing the risks in various security critical situations
>where time drifts a bit, various folks have stressed at how critical
>it is to have events time stamped and accurate within I don't know
>what, perhaps milliseconds or so. Well, NTP doesn't really guarantee
>that you have accurate time, it just tries to *synchronize*
>clocks. (If some of the clocks have accurate time, then yes, the time
>is accurate too.)
At the risk of belaboring this discussion myself (and I agree
that we are fast approaching the point of diminishing returns here) I'll
offer one more comment. I think in the above paragraph you have
missed the fundamental point. The concern is not that clocks on
systems drift a bit. (They do and that's why time synchronization
protocols were invented, but that's not the key point under discussion.)
The point is that some elements of distributed system security rely on
system clocks being at least reasonably synchronized. If you accept
that statement as true then it means that one avenue of attack is to
perturb the system clock on a particular system in order to subvert
those protections that depend on close time synchronization. And
given that a reasonable thing to do is require that time changes ought
to happen with some level of security, i.e., authentication.
Brian
Brian Schimpf
Gradient Technologies Inc.
From: mbrett@rgs0.london.waii.com (Marc Brett) [-/+]
Date: 11 Apr 1997 09:57:03 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Cheap (GBP70) MSF (Rugby) radio clock with serial interface...
X-Keywords: antenna [-/+] Novell [-/+]
In past c.p.t.n posts, there have been warnings against cheap radio
clocks, especially MSF.
The receivers tend to be poor quality. Typical computer environments
emit too much radio-frequency noise and overwhelm the receiver, so you
may need an expensive antenna installation to get it to work at all.
Even in a noise-free environment, the cheap receivers cannot always
keep a lock on the station.
Also, the MSF transmitter is shut down regularly for maintenance, so
7/24 coverage is out of the question. How good is the backup
oscillator in a GBP70 unit?
The excellent receivers which work reliably in high-noise and
low-signal-strength environments simply cost a lot of money.
For many people, clearly the reliability is worth the extra money.
That said, it'd probably make a fun project. Writing Yet Another NTP
Driver is not that hard, and such a unit would make a great *backup*
clock for an existing NTP stratum 1 server.
Damon at play (dhd@exnet.com) wrote:
> Does anyone know anything about the ~GBP70 radio clock I've just
> heard about from a couple of suppliers, costed like this:
> * GBP70 for a time/date serial interface
> * GBP100 as above but with LCD display, alarms, etc (nice
> modern arc-shaped desk clock, also called ARC for
> ``Atomic Radio Controlled''
> * GBP260 for first (non-display) version + Novell s/w.
> Is this suitable for a very cheap backup stratum-1 source?
> Will XNTP understand its output? For GBP70 I think I'll buy
> one and see anyway. But any info gratefully received in the
> meantime. No, I can't see who the mfr is from the pictures. Bv<
> Regards,
> Damon
> --
> Damon s0dhd@exnet.com, d@hd.org
> http://www2.exnet.com/ http://www.exnet.com/CV/DHDCV.html
--
Marc Brett Western Atlas
Marc.Brett@waii.com +44 181 560 3160
From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 15 Apr 1997 15:45:51 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: syslog changes for solaris
X-Keywords: syslog [-/+]
Todd Allen (tallen@nasa.pixel.kodak.com) wrote:
: Does anyone know of the specific compile time options that I have to
: make to have ntp log using the local5 facility under 2.5 Solaris. The
: ntp faq has some information regarding this subject, but I'm still not
: getting anywhere.
: --
: ______________________________________________________________________________
: Todd Allen tallen@Kodak.COM
: ______________________________________________________________________________
Howdy,
WARNING: I'm no ntp guru. If you get other advice, it is
probably better ! I've been happy with the default LOG_DAEMON
on sparc-Solaris 2.5 on xntp 3-5.89.8.
I think you can manually add a line to configure.h to define
variable LOG_NTP to be LOG_LOCAL5
./configure
echo "#define LOG_NTP LOG_LOCAL5" >> config.h
make
I'd add a section in ntp.conf with details of what was done
so that you can do it again when you change revs. I'd also
run the entire configure, echo and make in a "script" to
save the complete details, including error messages. It
takes a long time and I always miss the parts I wanted to
see go by during a dash to the john.
As I read the code just now (version 89.8), ntpd.c checks to
see if LOG_NTP is defined, and if not, it makes it LOG_DAEMON
(which is from sys/syslog.h). If you add a define in config.h,
it will now have the text value LOG_LOCAL5, which is also in
sys/syslog.h and the openlog() will name things as you wanted.
Bruce Bartram bbartram@etl.noaa.gov just another chimehead
From: mbrett@rgs0.london.waii.com (Marc Brett) [-/+]
Date: 14 Apr 1997 18:30:40 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,sci.geo.satellite-nav
Subject: Magnavox MX4200 GPS rollover warning [-/+]
This is a notice to all NTP stratum-1 operators who use Magnavox MX4200
receivers as a time source.
At midnight August 21-22 1999, the GPS week number will roll over from
1023 to 0. Some receivers will handle this event incorrectly and
output dates starting from the GPS epoch of 6 Jan 1980.
All Magnavox MX4200 models and some MX9000-series models will cease
to output correct times after this date.
Leica, which acquired the Magnavox GPS business in 1994, is in the
process of revising the firmware for all its GPS products to account
for the GPS week and Y2K rollover events.
New PROM chips (available from Leica at $100 per set) will be needed by
every MX4200. The MX9000's can be upgraded via new firmware (diskettes
available from Leica at no cost) uploaded from a PC via the serial port.
Other Leica models may or may not be affected by the rollover event.
I have no specific information for them.
Don't contact me for help. I don't work for Leica, and don't speak
for them. I'm just passing on what they've told me. Write instead to:
Leica Global Positioning Systems
23868 Hawthorne Blvd.
Torrance, CA 90505
Tel: (310) 791-5300
Fax: (310) 791-6108
--
Marc Brett Western Atlas
Marc.Brett@waii.com +44 181 560 3160
From: jra@scfn.thpl.lib.fl.us (Jay R. Ashworth) [-/+]
Date: 15 Apr 1997 16:48:53 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,sci.geo.satellite-nav
Subject: Re: Magnavox MX4200 GPS rollover warning [-/+]
Marc Brett (mbrett@rgs0.london.waii.com) wrote:
: This is a notice to all NTP stratum-1 operators who use Magnavox MX4200
: receivers as a time source.
: At midnight August 21-22 1999, the GPS week number will roll over from
: 1023 to 0. Some receivers will handle this event incorrectly and
: output dates starting from the GPS epoch of 6 Jan 1980.
: All Magnavox MX4200 models and some MX9000-series models will cease
: to output correct times after this date.
To expand; according to a piece in the RISKS digest last week, many 9if
not all) GPS receivers, whether used as time sources or not, will have
this problem. All users of GPS systems ought to check on this with
their manufacturers.
Cheers,
-- jra
--
Jay R. Ashworth jra@scfn.thpl.lib.fl.us
Member of the Technical Staff Unsolicited Commercial Emailers Sued
The Suncoast Freenet "To really blow up an investment house requires
Tampa Bay, Florida a human being." - Mark Stalzer +1 813 790 7592
From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]
Date: 15 Apr 1997 18:17:13 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Synchronisation lost?
X-Keywords: adjtimed [-/+] delay [-/+] dispersion [-/+] HP-UX [-/+] Linux [-/+] poll [-/+] precision [-/+] reset [-/+] synchronized [-/+] syslog [-/+]
Howdy,
=?US-ASCII?Q?J=F6rgen?= Pehrson (infjope@linuxjope.seinf.abb.se) wrote:
: Hi,
: I've installed xntpd3.5f on several of our servers.
: (HP-UX, Digital UNIX, Linux) Everything seems be working fine, i.e.
: the time is synchronized between all servers and when looking at the
: output of "xntpdc -p" everything looks ok. However, once in a while,
: on all of our servers there's a "synchronisation lost" entry in
: the syslog logfile. What does that mean? Is it something to worry about?
: Thanks!
: Here's a relevant piece of /usr/adm/syslog:
: [..]
Apr 15 14:19:02 sswu01 adjtimed[22824]: started
Apr 15 14:19:02 sswu01 xntpd[22825]: xntpd version=3.5f; Fri Oct 11 15:01:58
METDST 1996 (2)
Apr 15 14:19:02 sswu01 xntpd[22825]: tickadj = 5, tick = 10000, tvu_maxslew
= 495
Apr 15 14:19:02 sswu01 xntpd[22825]: precision = 12 usec
Apr 15 14:23:19 sswu01 xntpd[22825]: synchronized to 138.227.97.32, stratum=3
Apr 15 14:22:48 sswu01 xntpd[22825]: time reset (step) -32.536485 s
Apr 15 14:22:48 sswu01 xntpd[22825]: synchronisation lost
Apr 15 14:33:27 sswu01 xntpd[22825]: synchronisation lost
Apr 15 14:41:59 sswu01 xntpd[22825]: synchronized to 138.227.97.32, stratum=3
Apr 15 14:46:15 sswu01 xntpd[22825]: time reset (step) -0.224965 s
Apr 15 14:46:15 sswu01 xntpd[22825]: synchronisation lost
Apr 15 14:51:35 sswu01 xntpd[22825]: synchronized to 138.227.97.32, stratum=3
: --
: Jorgen Pehrson, System Administrator. ABB Infosystems, Ludvika, Sweden.
: email: jorgen.pehrson@seinf.mail.abb.com
: -----------------------------------------------------------------------
: The opinions expressed in this message are my own personal views
: and do not reflect the official views of ABB Infosystems AB.
When xntpd wants to adjust the time by more than 0.128 seconds
(CLCOK_MAX_I), it "steps" the clock by jamming the what it thinks
is the correct time using the clock_settime() or some such call.
Since all the past information from its servers is now based on
a different time scale and because the exact behaviour of the
settime call are hard to predict, the daemon declares itself
unsynchronized and it clears all its filters.
After a step, some hosts might have junk in the fractions of
a second portion of the time if the set call didn't run exactly
when it was requested or if the call doesn't cleanly set the
fractions of a second part of the clock.
If the daemon losses contact with the server or decides the time
it reports is junk, it will change sync to another server. If
there is no other server, it will say sync lost. When a daemon
is unsync'ed, it won't give usable answers to clients probing
it for time.
Your syslog shows a daemon waking up, seeing that it has a
good server available ( this takes about 5 minutes usually ),
and that it is off 32 seconds (it is fast wrt the server and
needs to subtract 32 seconds from its clock). The step
message shows the request being handled and the sync lost
follows immeadiately.
After another 5 minutes, I expect that it found the same server,
but I expected another sync message and instead I find a
sync lost. Perhaps the link to the server dropped some packets
or the server was having trouble.
About 20 minutes after the first step, the sync comes back, and
the daemon decides it is still 0.22 seconds off, so it steps
again, causing the 14:46 sync lost message. 5 minutes later,
things are resynched.
If there weren't any other messages and if xntpdc -p showed
something like mine does:
remote local st poll reach delay offset disp
=======================================================================
=flatiron1.bould 140.172.37.14 2 1024 377 0.00807 0.004533 0.00121
=noc.near.net 140.172.37.14 2 1024 377 0.08081 -0.012022 0.05571
*nic-srvr-atm.bo 140.172.37.14 2 1024 377 0.00444 0.007868 0.00784
=rtr-37.etl.noaa 140.172.37.14 3 1024 377 0.00328 0.003579 0.00377
I'd say things were working OK.
The xntpdc -p fields are:
the remote server
which port the packet was on (I only have le0)
stratum of that server
number of seconds between polls
reach 8 bit octal shift
and the delay, offset and dispersion in seconds.
ntpq -p show similiar info, but the units of deley, offset and disp
are milli-seconds.
reach is an 8 bit shift register shown in octal. 001 means the
most recent probe came back. 017 shows the last four. 377
all eight. 357 shows one missing probe, but 4 good ones since.
delay is the round trip time for the packet in the network.
offset is the difference of the server's clock - daemon's clock
-0.010 would mean that the daemon is 10 ms ahead of the server.
dispersion is an estimate of the maximum expected error in the probe.
This has terms for host precision, delay and ref clock age/86400.
Hope this make the mud a bit clearer.
Bruce Bartram bbartram@etl.noaa.gov just another chimehead