Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!mordor!styx!lognet2!ames!ucbcad!ucbvax!LOUIE.UDEL.EDU!Mills%udel.edu
From: Mills%udel.edu@LOUIE.UDEL.EDU
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  Ask not for whom the chimes tinkle
Message-ID: <8701090124.a018369@Huey.UDEL.EDU>
Date: Fri, 9-Jan-87 01:24:44 EST
Article-I.D.: Huey.8701090124.a018369
Posted: Fri Jan  9 01:24:44 1987
Date-Received: Fri, 9-Jan-87 06:17:39 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 20
Approved: tcp-ip@sri-nic.arpa

HW,

Unfortunately, Hans-Werner's clock can be spoofed in the same way mine was
(both us the same synchronization code). The problem is rather tricky. Every
host is told at reboot what year it is and remembers this until told
otherwise. Let's assume some j-random glitch comes along and sets the
local clock using NTP or even eyeball-and-wristwatch, which causes the
year to be changed. Then the radio clock comes up and starts ticking the
seconds but using the bogus year.

How can you protect against this? The radio clock may never come up. In
its absence the local host falls back to NTP and believes what it is told.
If it is peering with a sufficient number of other reliable clocks, then
the bog should be overcome. However, the fuzzball bog-suppressant code
does not yet do all it can in comparing multiple clocks and at the moment
of failure had only one other (presumably broken) player. Once again to
the breech, dear hearts, and reflect on the fact that nothing is quite so
public and excites so many so quickly as a timewarp. Mr. Sulu would understand.

Dave