Security and standalone Stratum 1.

[Eric S. Raymond]

OK, I've been meaning to get back to this for a while. It bears on the question
of what to put in the ntp.conf file in the HOWTO.

(Heads-up, Mark.  Significant policy decision in play.)

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > Gary E. Miller <gem at rellim.com>:
> >> 5. Disallow internal system to seek NTP from other sources
> >> beyond your edge routers.
> > But now I learn that we apparently can't do that, because (according to
> > Gary) a Stratum 1 requires a minimum of three good chimers for the
> > source-selection algoritms to stay sane. 
> 
> Welcome to the real world.  It's a complicated mess.
> 
> The idea that you need to keep in mind is that clocks lie.  Not often, but 
> often enough to be interesting.  Firmware bugs are a typical source.

Are you just thinking of wrong leapsecond offsets in GPS firmware, or
are there other and more pervasive firmware sources of error?

> There are also quirks like asymmetric routing and/or packets taking a nap in 
> routers.   From here (Silicon Valley), the NIST servers on the east coast are 
> off by 30 ns.
> 
> I have many examples of NTP packets getting delayed by seconds.  Bufferbloat 
> on my DSL line often gets over 3 seconds.  I've seen 8 second round trip 
> times from SV to NIST east.  The NIST server at WWV, Ft Collins gets 
> occasional round trip times over 60 seconds.
> 
> If you are using 3 clocks, the other 2 can outvote a falseticker.  There is a 
> recurring discussion of how many clocks you need.  If you are using 3 clocks 
> but one of them stops responding, what happens if one of the remaining 2 
> lies?  ...
> 
> On top of all that, you get to consider forged packets.  They can be used for 
> DDoS activity as well as poisioning your clock.  I think the only solution to 
> that is crypto authentication.

I understand about all of this.  It's irrelevant to the case I'm trying to
think about.

Remember our mission brief, and consider the following user story. You
are - say - Dahlgren AFB, working on railguns and a top target for PLA
crackers. Doctrine says you leave as few holes in your firewall as possible,
so you close the NTP port.

You want to set up your own Stratum 1. You don't want to use any outside
network access at all. You can put GPSes on tall enough radio masts for
perfect skyview.  What do you put in your ntp.conf?

Now suppose a meddling inspector-general notices that you've spent
absurd amounts of money on four separate GPS towers and says "That's
silly.  You're not going to get different time marks from towers as
close together as you can fit on the base.  Scrap three of them.  Now.
And no putting multiple GPSes in one tower, that is only smaller-scale
pointlessness."

Now what goes in your ntp.conf?  Because this is what I want to put in ours.

Yes, I understand that in real cases the GPS will sometimes lose lock.
Ignore that.  With modern hardware I'm willing to bet that the outage
lengths to the 1% extreme won't incur enough drift to matter before the
GPS comes onstream and re-corrects.

However, if you think that assumption is inaccurate, do argue it.  Because
One of the advanced topics should be "Wgen should I be willing to sacrifice 
autonomy from the network for accuracy."

> esr at thyrsus.com said:
> > Note to self: investigate orphan mode.
> 
> That's an interesting area, but it's a different problem.  It's for keeping 
> local systems in sync with each other when the connection to outside NTP 
> servers is down and you don't have a local S1 setup.

Then orphan mode is obsolete, and both code and documentation for it should
be removed.  No, I'm not kidding.

Hanging a GPS out a window is so cheap and so accurate that retaining
code for the case where you can't have a Stratum 1 is just silly.  It
seems to me the correct answer to anyone who wants "orphan mode" is
"What the fsck are you thinking?"
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>