Re: NTP Server

[Sean Donelan <sean () donelan com>]

On Mon, 25 Oct 2010, Dobbins, Roland wrote:>
> On Oct 25, 2010, at 3:48 AM, Matthew Petach wrote:
> > NTP can potentially be used as a DoS vector by your upstream clocks, 
> if you're not running your own.
> +1
>
> Also, if you experience a network partition event for any reason (DDoS 
> attack, backhoe attack, et. al.) which disrupts communications between 
> your network and the one(s) on the Internet where the public ntp servers 
> you're using live, the accuracy of your time-hack becomes a concern just 
> at the moment when you need it the most for combinatorial analysis of 
> multiple forms of telemetry.

Modern versions of NTP have a relatively long polling interval once the
clock is stable.  Unless you are already using specialized timing 
hardware, your tolorance of the clock drift on off-the-shelf computers
and routers is not going to be an immediate issue during short-term or 
even medium-term network problems.

Any clock source can have an indeterminate outage. Generally the longer 
the hold time, the more expensive the clock hardware.


> And of course, time services for your infrastructure/services/apps 
> ought to run across your DCN, anyways, which should be kept isolated 
> from your production network (you don't want to rely upon proxies to 
> enable  something as critical as time service, IMHO).

NTP started on Fuzzball routers.  Its very light-weight on any hardware.
There are lots of reasons not to have customers accessing your 
infrastructure devices.  Lots of NTP queries can overload any device.
Although your infrastructure devices should still have synchronized 
clocks with the rest of your infrastructure. If you have an enterprise 
network dependent on firewalls, another pin-hole through the firewall for 
NTP port 123 is also an another opportunity for mischief.

There are lots of different ways to measure time.  But I've noticed
some people seem to create extreme Rube Goldberg contraptions.  Figure
out what precision and accuracy you really need.  Time is always just
an estimate.