[ednog] Building a cheap NTP stratum-2 network with retired Cisco gear

Shumon Huque shuque at isc.upenn.edu
Wed Jun 22 20:27:00 EDT 2005


On Wed, Jun 22, 2005 at 05:06:15PM -0500, John Kristoff wrote:

Nice write up John. Thanks! I have a few comments:

> Note, ideally the clients will get time from at least three of our
> stratum 2's, but most clients tend to just use one.  To help balance
> the load in the latter case we will have use DNS round robin with a
> name such as time.northwestern.edu.  Anycast NTP could also be used,
> but not with 3524's unless they ran routing code (which we won't be
> doing).  Even then I don't expect this to really buy us a whole lot
> and the little bit of added complexity (and potential for NTP breakage,
> however unlikely - 4 packets are used in NTP) just doesn't seem like
> it is worth it today.

If there are NTP implementations that repeatedly resolve the
DNS name of the peer/server, then round robin DNS probably
causes a problem because it will result in miscalculated jitter,
delay and error estimates. I'm guessing most NTP implementations
resolve the DNS name only once on startup though.

Also, what do you do if one of the routers in the round robin
set is down? Doesn't that result in unreachability of the NTP
service for a subset of your clients? I think it's best to train
users to specify multiple time servers if they want reliability.

> Internally peered stratum-2's will use MD5 auth.  MD5 will not be
> available for general clients, since it cannot be securely nor easily
> managed for large numbers of clients.  A shared MD5 hash passphrase
> can be used for centrally controlled devices that support it, such
> as other switches, routers and servers.  The use of MD5 may not buy
> buy us a whole lot, but anything that can raise the bar without
> too much trouble is probably a good idea in my opinion.  Note however,
> that I know of only two stratum-1's that will support MD5 to stratum-2
> downstreams and I've asked a quite a far amount of operators.

To properly secure the time information, I believe we need to 
authenticate the entire NTP synchronization path all the way to
the stratum 0 time sources. I don't think this is readily 
achievable today because the GPS, CDMA, radio signals and ACTS
dialup are not authenticated. If you find a stratum-1 that is
synchronized via a physically secured path to an atomic clock,
let me know :-)

Peering with a diverse set of peers over diverse paths probably
mitigates most potential threats from an active attacker. We also
do something like you: MD5 authenticated time between our campus
peer group and to other important servers (Kerberos servers etc).

For distributing authenticated time to clients who want it, we
are planning to set up public key authentication and distribute 
the NTP server public keys widely around campus. Pubkey auth is
supported only in the latest implementations (NTP 4 from UDel).

--Shumon.


More information about the ednog mailing list