NTP server(s)

Gary Gapinski Gapinski at nasa.gov
Thu Oct 25 19:06:30 UTC 2012


On 10/25/2012 02:28 PM, Jeffrey Blank wrote:
> We will certainly have rules available to that end.
>
> The question is whether you want it encoded as part a compliance
> enforcement regime for a wide variety of use cases.  Previous consensus
> discussion indicated that a single NTP server in an enclave was common
> practice, but that that system (acting as an NTP server) commonly used
> multiple sources for time.
>
> What would you want to enforce on all systems, as that is our constraint?
>

Anyone who wishes to _ensure_ time synchronization will use three or 
more NTP servers. This is normally a requirement levied for logging and 
audit purposes, but interesting things can happen to, e.g., license 
servers and clients thereof when clocks drift. Kerberos and AD are also 
sensitive to clock drift, as are software authenticators, etc. A 
one-second negative clock slew will cause an RSA Authentication Manager 
RADIUS service to decide life is no longer worth living (ask me how I know).

Anyone who needs not ensure time synchronization can use less than 
three, with an increased expectation of interesting failure modes.

When one server is used, the local system will track it for better or 
worse, until it becomes unavailable, at which point the local clock skew 
takes over until the server becomes available again, at which point a 
fast slew will occur.

With a quorum, there is far more assurance of accuracy as well as 
avoidance of fast slews.

Multiple lower stratum NTP servers are cheap as chips to provide, even 
in "enclaves". Most commercial network gear can provide NTP.



More information about the scap-security-guide mailing list