Wednesday, October 19, 2016

Network Time Protocol (NTP)

 on  with No comments 
In , ,  
A very important but sometimes overlooked technology in networking is NTP.  NTP is used for clock synchronization between hosts on a packet switched network such as the Internet. It was first designed by Dr. David L Mills of the University of Delaware in 1985.  The current protocol is NTPv4, which is described in RFC 5905.  Version 4 is backwards compatible with version 3, described in RFC 1305.  I've written about NTP before, in a post on setting up an NTP server on the NetBSD operating system.

Based on Marzullo's Algorithm, NTP is able to synchronize time to within tens of milliseconds across the Internet and to within 1 millisecond under ideal LAN conditions. The protocol typically utilizes UDP Port 123 to send and receive timestamps, however the specification also allows for broadcast and multicast communication between hosts.  The protocol calls for a warning of any impending leap second adjustments, but does not take into account any local time zone or daylight savings time information.

In addition to the standard NTP Protocol, there is a smaller and less complex protocol, SNTP that drops the storage of state over extended periods of time.  This is useful in smaller or embedded devices where highly accurate time is not required, but it is still desirable to have a reasonably accurate time.


NTP utilizes a hierarchical configuration of NTP Servers.  Each layer is called a stratum and assigned a number starting with zero. Stratum 0 hosts are highly precise devices such as atomic clocks or GPS Satellites.  Stratum zero devices are also referred to as reference clocks.  Devices that are synchronized to Stratum 0 devices are called Stratum 1, or primary time servers.  Note that the connection between Stratum 0 and Stratum 1 devices is typically a dedicated link and therefore NTP is not actually used in those synchronizations.  Devices that are synchronized to Stratum 1 devices are called Stratum 2 devices and so on. The specification of NTP has an upper limit of Stratum 15, with Stratum 16 indicating that the device's clock is unsynchronized.  The plural of stratum is strata.

The Official Reference Implementation of NTP is available at ntp.org, where is has been since its inception.  The current release is ntp-4.2.8p8 and was released on June 2, 2016.  The well being of ntp.org has been written about recently as it appears a single developer is/was primarily holding down the fort.  Is there any update to this story?

In addition to the Official Reference Implementation, ntp.org also hosts the NTP Pool Project, where publicly available NTP Servers are listed for use.  Official information about this project is at www.pool.ntp.org.  To use this pool, you simply point your devices at region specific FQDNs for pools of NTP servers. Changes to the list of available servers happens in the background, so you're never more than a DNS time out away from getting a valid IP address for an NTP server.  For example, in the US, you can use one or more of the following 4 FQDNs as your NTP Servers.

  •  0.us.pool.ntp.org
  •  1.us.pool.ntp.org
  •  2.us.pool.ntp.org
  •  3.us.pool.ntp.org

Another implementation of NTP is the OpenNTPD project, which is developed by the OpenBSD team. As with all projects under the OpenBSD umbrella, OpenNTPD is designed to be secure, easy to configure, and accurate.  The stated intent is to "[r]each a reasonable accuracy" without sacrificing "secure design for getting that last nanosecond or obscure edge case."[ It is portable, and able to be used in systems that are not OpenBSD based as well.  It does not maintain the level of accuracy of the Reference Implementation, but not clock needs to be accurate to that level.

One more common NTP implementation is the Windows Time Service, specifically that on Active Directory domain controllers.  The W32Time service was originally implemented for the purpose of keeping time accurate in the interest of Kerberos authentication, hence it's short comings.  Windows XP and earlier only implement SNTP, while Server 2003 and later (which I would assume includes XP 64-bit as it is based on the same kernel revision as Server 2003) use a fully compliant NTP protocol. However, even with Server 2003 and up, w32time cannot keep time better than a 1 to 2 second accuracy. If you require better, Microsoft says to use a different NTP implementation.

So why is accurate time so important on networks?  There are a few notable reasons.  I have 3 right now and I'm sure you can come up with a few more if you give it some thought.

1. Log synchronization across multiple devices. Consolidated syslog servers collect log messages from multiple devices. If a security professional is tracking the progression of an event on the network, it will be completely impossible to gain the complete picture if the clocks of all involved devices are not accurate. Whatever that security professional discovers may also not be admissible in court if inaccurate time raises enough doubt as to the validity of their clams.  This applies to all the devices whose logs are being sent to the central syslog server, not just "most devices are accurate."  If you care about the device enough to keep it's logs, you should care enough to have accurate timestamps so those logs are usable.

2. Single Sign on Authentication.  Active Directory users should know that the clock on your host workstation must be within 5 minutes of the clock on the domain controller that the workstation is utilizing for authentication.  This is because accurate time is one of the security checks done by the Kerberos Protocol which is at the heart of Active Directory Authentication.  Kerberos is an open protocol, and used for authentication in a number of other systems.

3. Certificate validation.  A certificate is considered valid only if the current time falls within the range specified within the certificate. A while back a coworker sent me a text showing how every website he attempted to reach gave an invalid certificate error.  The first thing I thought of was the system clock, and that ended up being the problem.  While annoying, this is still manageable on a PC where you can tell the browser to accept the seemingly invalid certificate.  But automated processes on network devices do not have such luxury and those processes will simply fail.

Configuring NTP on Cisco IOS devices

Configuring NTP on an IOS device is a straightforward operation, consisting of three steps.  First, configure the time zone.  Next, configure the NTP server.  And finally, configure optional NTP authentication.  In this example, we’ll configure NTP to synchronize to a local NTP Server.

!
! Set the time zone, and optionally the daylight savings time settings
!
clock timezone EST -5
clock summer-time  EDT recurring
!
!  Specify the ntp server(s) to use, and which one is preferred
!
ntp server 192.168.10.254 prefer
ntp server 192.168.10.253
!
! configure authentication settings
! note that multiple keys may be used as necessary
!
ntp authenticate
ntp authentication-key 1 md5 cisco123
ntp authentication-key 2 md5 cisco456
ntp server 192.168.10.254 key 1
ntp server 192.168.10.253 key 2


Configuring NTP on Cisco ASA devices


Like many features, the configuration of NTP on Cisco ASA devices is very similar to that of Cisco IOS devices. But like many features, there are a few slight differences.
!
! Set the time zone, and optionally the daylight savings time settings
!
clock timezone EST -5
clock summer-time  EDT recurring
!
! Specify the ntp server(s) to use and authentication details
!
ntp server 192.168.10.254 key 1 source inside prefer
ntp authenticate
ntp authentication-key 1 md5 cisco123
ntp trusted-key 1

Verifying NTP on Cisco IOS and ASA devices

Now we'll use a couple simple commands to verify the operation of NTP
show ntp associations [detail]
And finally, for the few of you that require greater accuracy than NTP can provide, there is the Precision Time Protocol (PTP).  PTP offers accuracy in the sub-microsecond range, which makes it suitable for measurement and control systems. It was originally described in IEEE 1588-2002 and updated to verison 2 in IEE 1588-2008. According to the specs, "IEEE 1588 is designed to fill a niche not well served by either of the two dominant protocols, NTP and GPS. IEEE 1588 is designed for local systems requiring accuracies beyond those attainable using NTP. It is also designed for applications that cannot bear the cost of a GPS receiver at each node, or for which GPS signals are inaccessible."  PTP is available in higher end Nexus switches and ASR routers, but not in the more common ISR and ISR2 series routers. Other PTP implementations can be found here.
Share:

0 comments:

Post a Comment

Discuss this post!