The Network Time Protocol (NTP) is widely used to synchronize
computer clocks in the Internet. This document describes NTP version
4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3),
described in RFC 1305, as well as previous versions of the protocol.
NTPv4 includes a modified protocol header to accommodate the Internet
Protocol version 6 address family. NTPv4 includes fundamental
improvements in the mitigation and discipline algorithms that extend
the potential accuracy to the tens of microseconds with modern
workstations and fast LANs. It includes a dynamic server discovery
scheme, so that in many cases, specific server configuration is not
required. It corrects certain errors in the NTPv3 design and
implementation and includes an optional extension mechanism.
NTP, or network time protocol is a necessity for a management network. This is not only for accuracy in time from the user perspective, but also for event correlation and authentication mechanisms. Certain authentication mechanisms, such as Kerberos, rely heavily on time synchronization. It is also difficult to correlate events, operational or security related, without time synchronization across the enterprise. NTP V4 is the most recent implementation of the protocol and integrates with IPV6 and also provides some fixes based on issues with NTP V3.
Network time is critical on an enterprise network to ensure the integrity of the network. Many facets of the integrity of the network are affected when time is not properly synchronized. For example, audit logs become unreliable and there is no way to properly account for actions taken on the network. This could cause a loss to a organization with no way to determine who or what caused the loss and thereby make it impossible to take the appropriate administrative actions to prevent a future occurrence. The NTP protocol can be used in this case to ensure that an accurate time stamp is placed in the logging system to point to the user and change that made caused the issue.
Implementation of NTP within a management network is relatively simple. There are hardware clocks available on the market that will sync with GPS (global positions system) and provide reliable time for the network. NTP servers are also included in most Linux distributions for organizations who are willing to include open source options in their management network. For commercial use, this might simply require the purchase of an enterprise license for Linux. In some cases, a purchase might not be necessary at all, outside of the normal hardware procurement for a server.
In many cases, such as it is with Kerberos, security is based around time. Whether it be the need to place a small window on the validity of a ticket or the need to control access based on time of day, it is important for your systems to be on a synchronized time source. It is also crucial, in the case of a logging infrastructure, to ensure that your systems are in the same time zone. Time zone conversion can be done on a receiving system, but it is preferable not to manipulate the original logs received as this can bring into question the integrity of the logs themselves. Having worked in a military environment for over 10 years, I have found that one of the best ways to manage time is to use GMT/UTC and synchronize all systems in the network with one or more stratum 1 time clocks.
For the purposes of NTP, a primary NTP server is considered stratum 1. A server who gets its time from a stratum 1 server is considered stratum 2. As stratums increase, there is naturally a drift in time that occurs. While NTP clients on operating systems are configured to allow for a small amount of drift, I would recommend two best practices. First all systems within the enterprise should be receiving time from the same stratum level. Second, I would suggest that the primary (stratum 1) time server in your environment be a hardware clock and not sync with an outside time source as this would actually make it a stratum 2 time source.
If you have additional comments related to time service on a management network or other advice you would like to share with our readers, please do so in the comments below. As always, I appreciate your constructive criticism as I intend to use this blog to provide my personal experience and also as a means to gain more experience from our readers.