RE: Acqusition of time

["Reckhard, Tobias" <tobias.reckhard () secunet com>]

Martin Peikert wrote:
> Ben Nagy wrote:
> > If a firewall can't reach an NTP server because of some 
> transient network
> > condition the clock doesn't automatically go haywire - it 
> will just start
> > drifting as per the normal accuracy of the hardware clock, no?

ntpd periodically (every hour, I believe) saves the current clock drift to a
drift file, typically /etc/ntp.drift. When the daemon starts, it initializes
the drift of its state machine using the value in this file in an effort to
speed up synchronisation (and especially it settling down). I believe it
will apply this correction to the clock even when running in an
unsynchronised state, i.e. when it can't reach any reliable peers or
servers.

You shouldn't make the typical mistake of configuring the local clock as a
reference source, however. In that case, the computer's time will skew
considerably when the other servers can't be reached. The LCL source is only
meant to be used when it is synchonised by some external means (or if you
don't want to synchronise to anything external).

> Not necessarily. You could use clockspeed, see 
> http://cr.yp.to/clockspeed.html
> ,-------------------------------------------------------------
> ----------
> | clockspeed uses a hardware tick counter to compensate for a
> | persistently fast or slow system clock. Given a few time 
> measurements
> | from a reliable source, it computes and then eliminates the clock
> | skew.

Of course this only works as long as the clock skew is constant, resulting
in linear drift if uncompensated. This is an OK assumption for quartzes
running at fixed levels of temperature, such as the clocks in always-on
servers in a thermally controlled server room. It is not OK for your typical
workstation. Reboot cycles often introduce errors of up to half a second and
temperatures vary much more. I've also observed some SGI machines to perform
20 ms jumps every now and then, completely unpredictably.

> | Typical success story: I started clockspeed on one of my Pentium
> | computers at home on 1998-05-05. I ran sntpclock (through a 28.8
> | dialup line) once on 1998-05-05 and once on 1998-05-30. On 
> 1998-08-22,
> | after no network time input for nearly three months, the clock was
> | just 0.21 seconds off.

This rating is rather subjective, of course. .21 seconds equates to 210 ms,
which is a tremendous offset by NTP standards. It's also a lot if you're
trying to sort logs from different machines, which are connected by
modertaly busy mbps, even kbps lines. Of course, the 2.3 ms per day offset
the quoted machine experiences (on average) is a lot better than the up to
half a second that uncorrected clocks can exhibit.

> So, if a firewall can't reach an NTP server a longer time, I 
> would think 
> that you really have a problem ;-) But for a sufficient 
> length of time 
> clockspeed will do the job and keep the time from drifting too far...

Could be that ntpd will, too.

I myself prefer to have a stratum 1 source in the management network that
the DMZ systems are connected to, which doesn't see any production traffic
and isn't connected to anything else. That way, worms and other crap on the
production network segments doesn't hamper NTP or any other management
traffic (until a DMZ machine is infected, of course, but that can be
mitigated further..). Of course, when faced with The Real World (TM) this
setup often remains a dream..

Cheers,
Tobias
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards