[ntp:questions] Re: Estimate of the number of people using the pool system

David L. Mills mills at udel.edu
Wed Oct 22 18:10:37 UTC 2003


Adrian,

Historically, this discussion has been going on since before Kerberos
was born a dog. A couple of years back the DNS root servers folks were
so concerned about time hijack that the White House called a meeting. I
got grilled about the vulnerability of NTP to various kinds of attack,
including replay, spoof, clog and middleman, not to mention the dozen
sanity checks in the code now. The results are at
http://www.eecis.udel.edu/~mills/database/reports/stime/stime.pdf, with
further information at the NTP project page and in the NTP
documentation.

It is highly likely that most pool server operators won't care a lot
about security; however, the very ubiquitous nature of the pool concept
represents a masquerade vulnerability that a terrorist might exploit.
This is not to say you guys are derelict in any way, just that the
question will come up about how secure is the pool service and what can
be done to harden it.

I take a very serious line about the vulnerability of mobilizing an
association from unauthentcates sources; in particular, the default NTP
behavior is to mobilize associations only with cryptographically
verified sources. This behavior was motiviated by past experience when
the MBONE flourished and my unprotected multicast client popped up with
hordes of unclean servers of dubious reputation scattered all over the
world.

There are several schemes now implemented, documented and tested in NTP,
among which the IFF identity scheme may be the most useful. The scheme
requires the server and clients to generate certificates and the server
to generate an identity key. The public value of the identity key is
returned in an automatic response to a mail message. Send a message to
crypto.ntp.org with your chosen password in the subject line.

We run IFF here for access to our private server pogo.udel.edu and USNO
is running it for test. If interested, see the Authentication Options
and ntp_keygen pages in the NTP documentation. In the classic
dreary-overdocumenting-excess style I am famous for, those pages are a
mouthful and I should write a simple script for ordinary mortals.

Dave

P.S. I no longer cling to sanity; I abandoned it years ago.

Adrian 'Dagurashibanipal' von Bidder wrote:
> 
> Clinging to sanity, David L. Mills mumbled in his beard:
> 
> > Adrian,
> >
> > The NTP clock discipline increases the poll interval until reaching
> > maxpoll when incidental jitter and wander, justify. However, there is no
> > reliable correlation between poll interval and nominal accuracy. In
> > other words, you can't pick a maxpoll out of the air and expect the
> > incidental jitter and wander to prevail less than any particular value.
> 
> Ok. That tells me that if I recommend an increased maxpoll value, I
> basically recommend a higher target jitter/wander of the client using the
> pool. This is fine with me so far.
> 
> > In fact, if the incidental jitter and wander of the pool population is
> > truly in the tens of milliseconds, the poll interval will probably not
> > ramp up beyond the default anyway.
> 
> I've not seen this happen. All servers either properly go up to maxpoll, or
> they are discarded as falsetickers (but still are at maxpoll after some
> time).
> 
> ntpq -pn on one of the monitoring servers tells me:
>  - the big majority is within +/-10ms offset
>  - of the 93 servers, 11 servers are outside of +/-50ms
>    and of these, 10 are detected as falsetickers or have been unreachable
>    until recently.
> 
> This is with network delays of 50 to more than 100ms, and with jitter values
> varying widely between 0.someting up to around 50.
> 
> So I guess the conclusion is that ntp really does what it should do even on
> a bad network with big delay and jitter.
> 
> > New subject to swim the pool: What do you want to do about
> > authentication in case a terrorist hijacks one or more servers? I offer
> > the (optional) Autokey public-key scheme as candidate, which is now in
> > use here and in evaluation elsewhere. I'm not sure the servers and
> 
> I'm not sure who would here be authenticating with whom.
> 
> If our terrorist hijacks the database/nameserver, all is lost anyway.
> If our terrorist hijacks one of the timeservers in the pool, doesn't he
> automatically get the secret key of that timeserver, too?
> 
> And if we detect the hijacking, we just throw that timeserver out of the
> pool - no new clients will be syncing with that timeserver.
> 
> Disclaimer: So far, I never studied how the autokey authentication works, so
> I am probably just not seeing 'it'.
> 
> cheers
> -- vbi
> 
> >> Clinging to sanity, David L. Mills mumbled in his beard:
> >>
> > [While my cling to sanity certainly is tenuous, our fascist news server
> > won't let me include your message.]
> 
> :-)
> 
> --
> Lack of money is the root of all evil.
>                 -- George Bernard Shaw



More information about the questions mailing list