Network Time Protocol

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Not to be confused with Daytime Protocol or Time Protocol.
Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

Network Time Protocol (NTP) is a networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks.

In operation since before 1985, NTP is one of the oldest Internet protocols in use. NTP was originally designed by David L. Mills of the University of Delaware, who still develops and maintains it with a team of volunteers.

Overview[edit]

The U.S. Naval Observatory Alternate Master Clock at Schriever AFB (Colorado) is a Stratum 0 source for NTP

NTP is intended to synchronize all participating computers to within a few milliseconds of Coordinated Universal Time (UTC).[1]:3 It uses a modified version of Marzullo's algorithm to select accurate time servers and is designed to mitigate the effects of variable network latency. NTP can usually maintain time to within tens of milliseconds over the public Internet, and can achieve better than one millisecond accuracy in local area networks under ideal conditions. Asymmetric routes and network congestion can cause errors of 100 ms or more.[2][3]

The protocol is usually described in terms of a client-server model, but can as easily be used in peer-to-peer relationships where both peers consider the other to be a potential time source.[1]:20 Implementations send and receive timestamps using the User Datagram Protocol (UDP) on port number 123.[4][5] They can also use broadcasting or multicasting, where clients passively listen to time updates after an initial round-trip calibrating exchange.[3] NTP supplies a warning of any impending leap second adjustment, but no information about local time zones or daylight saving time is transmitted.[2][3]

As of June 2010, the current protocol is version 4 (NTPv4), which is a proposed standard as documented in RFC 5905. It is backward compatible with version 3, specified in RFC 1305.

Clock strata[edit]

Yellow arrows indicate a direct connection; red arrows indicate a network connection.

NTP uses a hierarchical, semi-layered system of time sources. Each level of this hierarchy is termed a "stratum" and is assigned a number starting with zero at the top. The number represents the distance from the reference clock and is used to prevent cyclical dependencies in the hierarchy. Stratum is not always an indication of quality or reliability; it is common to find stratum 3 time sources that are higher quality than other stratum 2 time sources. Telecommunication systems use a different definition for clock strata.

Stratum 0
These are high-precision timekeeping devices such as atomic (cesium, rubidium) clocks, GPS clocks or other radio clocks. They generate a very accurate pulse per second signal that triggers an interrupt and timestamp on a connected computer. Stratum 0 devices are also known as reference clocks.
Stratum 1
These are computers whose system clocks are synchronized to within a few microseconds of their attached stratum 0 devices. Stratum 1 servers may peer with other stratum 1 servers for sanity checking and backup.[6] They are also referred to as primary time servers.[2][3]
Stratum 2
These are computers that are synchronized over a network to stratum 1 servers. Often a stratum 2 computer will query several stratum 1 servers. Stratum 2 computers may also peer with other stratum 2 computers to provide more stable and robust time for all devices in the peer group.
Stratum 3
These are computers that are synchronized to stratum 2 servers. They employ exactly the same algorithms for peering and data sampling as stratum 2, and can themselves act as servers for stratum 4 computers, and so on.

Only strata 0 to 15 are valid; stratum 16 is used to indicate that a device is unsynchronized. The NTP algorithms on each computer interact to construct a Bellman-Ford shortest-path spanning tree, to minimize the accumulated round-trip delay to the stratum 1 servers for all the clients.[1]:20

Timestamps[edit]

The 64-bit timestamps used by NTP consist of a 32-bit part for seconds and a 32-bit part for fractional second, giving a time scale that rolls over every 232 seconds (136 years) and a theoretical resolution of 2−32 seconds (233 picoseconds). NTP uses an epoch of January 1, 1900. The first rollover occurs in 2036,[note 1] prior to the UNIX year 2038 problem.

Future versions of NTP may extend the time representation to 128 bits: 64 bits for the second and 64 bits for the fractional-second. The current NTPv4 format has support for Era Number and Era Offset, that when used properly should aid fixing date rollover issues. According to Mills, "the 64 bit value for the fraction is enough to resolve the amount of time it takes a photon to pass an electron at the speed of light. The 64 bit second value is enough to provide unambiguous time representation until the universe goes dim."[7][note 2]

Clock synchronization algorithm[edit]

A typical NTP client will regularly poll three or more servers on diverse networks. To synchronize its clock with a remote server, the client must compute the round-trip delay time and the offset. The round-trip delay δ is computed as

\delta = (t_3 - t_0 ) - ( t_2- t_1 )

where

t0 is the client's timestamp of the request packet transmission,
t1 is the server's timestamp of the request packet reception,
t2 is the server's timestamp of the response packet transmission and
t3 is the client's timestamp of the response packet reception.

Therefore

t3 − t0 is the time elapsed on the client side between the emission of the request packet and the reception of the response packet and
t2 − t1 is the time the server waited before sending the answer.

The offset θ is given by[8]

\theta = {(t_1 - t_0) + (t_2 - t_3 ) \over 2}

The calculated δ and θ are passed through filters and subjected to statistical analysis. Outliers are discarded and an estimate of time offset is derived from the best three remaining candidates. The clock frequency is then adjusted to steadily reduce the offset, creating a feedback loop.[1]:20

The synchronization is correct when both the incoming and outgoing routes between the client and the server have symmetrical nominal delay. If the routes do not have a common nominal delay, the synchronization has a systematic bias of half the difference between the forward and backward travel times.[9]

Software implementations[edit]

Reference implementation[edit]

The NTP reference implementation, along with the protocol, has been continuously developed for over 20 years. Backwards compatibility has been maintained as new features have been added. It contains several sensitive algorithms, especially to discipline the clock, that can misbehave when synchronized to servers that use different algorithms. The software has been ported to almost every computing platform, including PCs.[1]:13 It runs as a daemon called ntpd under unix or as a service under Windows.[1]:15 Reference clocks are supported and their offsets are filtered and analysed in the same way as remote servers, although they are usually polled more frequently.[1]:19

SNTP[edit]

A less complex implementation of NTP, using the same protocol but without requiring the storage of state over extended periods of time,[10] is known as the Simple Network Time Protocol (SNTP). It is used in some embedded devices and in applications where high accuracy timing is not required.[11][12]

Windows Time service[edit]

All Microsoft Windows versions since Windows 2000 and Windows XP include the Windows Time service ("W32Time"),[13] which has the ability to sync the computer clock to an NTP server. The version in Windows 2000 and Windows XP only implements Simple NTP, and violates several aspects of the NTP version 3 standard.[14] Beginning with Windows Server 2003 and Windows Vista, a compliant implementation of full NTP is included.[15][note 3]

Leap seconds[edit]

On the day of a leap second event, ntpd receives notification from either a configuration file, an attached reference clock or a remote server. Because of the requirement that time must appear to be monotonically increasing, a leap second is inserted with the sequence 23:59:59, 23:59:60, 00:00:00. Although the clock is actually halted during the event, any processes that query the system time cause it to increase by a tiny amount, preserving the order of events. If it should ever become necessary, a leap second would be deleted by skipping 23:59:59.[18]

Security concerns[edit]

NTP servers are susceptible to man-in-the-middle attacks unless packets are cryptographically signed for authentication. The computational overhead involved can make this impractical on busy servers, particularly during denial of service attacks.[19]

Only a few security problems have been identified in the reference implementation of the NTP codebase in its 25+ year history.[20][21] The protocol has been undergoing revision and review over its entire history. As of January 2011, there are no security revisions in the NTP specification and no reports at CERT.[22] The current codebase for the reference implementation has been undergoing security audits from several sources for several years now, and there are no known high-risk vulnerabilities in the current released software.[23]

Several NTP server misuse and abuse practices exist which cause damage or degradation to a Network Time Protocol (NTP) server.

NTP has been used to facilitate DDoS attacks.[24][25] Similar to a DNS amplification attack, an attacker sends a small command to the NTP server (typically the MON_GETLIST command) with a spoofed return address. This requires that the originating network does not do egress filtering, allowing spoofing. The NTP server then responds with a much larger packet, allowing an attacker to substantially amplify the amount of data being sent to the target. This attack can be mitigated using "noquery" to disable all querying or "disable monitor" to disable just the attack vector, or by upgrading to a patched version.[26]

See also[edit]

Portal icon Time portal
  • Allan variance
  • International Atomic Time
  • NITZ (Network Identity and Time Zone) a mechanism for provisioning local time and date, as well as network provider identity information to mobile devices via a wireless network
  • OpenNTPD and Ntpdate
  • NTP pool, a collection of worldwide computers that provide a highly accurate time via the Network Time Protocol
Other time synchronization protocols

Notes[edit]

  1. ^ Implementations can determine whether rollover has occurred using a knowledge of the approximate time from other sources. Since NTP only works with the differences between timestamps and never their absolute values, the 2036 rollover is invisible as long as the timestamps are within 68 years of each other. This means that the rollover will be invisible for most running systems, since they will have the correct time to within a very small tolerance. However, systems that are starting up need to know the date within no more than 68 years. Given the large allowed error, it is not expected that this is too onerous a requirement. One suggested method is to set the clock to no earlier than the system build date. Many systems use a battery powered hardware clock to avoid this problem.
  2. ^ 2−64 seconds is about 54 zeptoseconds (light would travel 16.26 picometres, or approximately 0.31 × Bohr radius), and 264 seconds is about 585 billion years.
  3. ^ Microsoft says that the W32Time service cannot reliably maintain sync time to the range of 1 to 2 seconds.[16] If higher accuracy is desired, Microsoft recommends to use a different NTP implementation.[17] The W32Time service was originally implemented to "Make the Kerberos version 5 authentication protocol work.", which required time to be within not more than 5 minutes of the correct value.

References[edit]

  1. ^ a b c d e f g David L. Mills (12 December 2010). Computer Network Time Synchronization: The Network Time Protocol. Taylor & Francis. pp. 12–. ISBN 978-0-8493-5805-0. 
  2. ^ a b c "Executive Summary: Computer Network Time Synchronization". Retrieved 2011-11-21. 
  3. ^ a b c d "NTP FAQ". The NTP Project. Retrieved 2011-08-27. 
  4. ^ "Port Numbers". The Internet Assigned Numbers Authority (IANA). 
  5. ^ Page 16
  6. ^ "Network Time Protocol: Best Practices White Paper". Retrieved 15 October 2013. 
  7. ^ University of Delaware Digital Systems Seminar presentation by David Mills, 2006-04-26
  8. ^ Mills, David L. (2005), NTP Clock Discipline Modelling and Analysis, p. 10, retrieved 2011-07-13 
  9. ^ Gotoh, T.; Imamura, K.; Kaneko, A. (2002). "Improvement of NTP time offset under the asymmetric network with double packets method". Conference on Precision Electromagnetic Measurements. pp. 448–449. doi:10.1109/CPEM.2002.1034915. ISBN 0-7803-7242-5. 
  10. ^ "Network Time Protocol Version 4: Protocol and Algorithms Specification". June 2010. p. 54. Retrieved 2012-08-26. "Primary servers and clients complying with a subset of NTP, called the Simple Network Time Protocol (SNTPv4) [...], do not need to implement the mitigation algorithms [...] The fully developed NTPv4 implementation is intended for [...] servers with multiple upstream servers and multiple downstream servers [...] Other than these considerations, NTP and SNTP servers and clients are completely interoperable and can be intermixed [...]" 
  11. ^ RFC 4330
  12. ^ RFC 5905
  13. ^ "Windows Time Service Technical Reference". technet.microsoft.com. 2011-08-17. Retrieved 2011-09-19. 
  14. ^ "Windows Time Service page at NTP.org". Support.ntp.org. 2008-02-25. Retrieved 2011-01-12. 
  15. ^ "How the Windows Time Service Works". technet.microsoft.com. 2010-03-12. Retrieved 2011-09-19. 
  16. ^ "Support boundary to configure the Windows Time service for high accuracy environments". Microsoft Corporation. 2011-10-19. "The W32Time service is not a full-featured NTP solution [...] The W32Time service is primarily designed to [...] Make the Kerberos version 5 authentication protocol work. [And p]rovide loose sync time for client computers. [...] The W32Time service cannot reliably maintain sync time to the range of 1 to 2 seconds. It was originally implemented to "Make the Kerberos version 5 authentication protocol work." 
  17. ^ Ned Pyle (2007-10-23). "High Accuracy W32time Requirements". Microsoft Corporation. Retrieved 2012-08-26. "In some cases, customers want the time accurate down to the second. [...] the purpose of this blog is to explain [...] why we recommend using other solutions" 
  18. ^ David Mills. "The NTP Timescale and Leap Seconds". Retrieved 15 October 2013. 
  19. ^ "NTP Security Analysis". Retrieved 11 October 2013. 
  20. ^ "Security Notice". Support.ntp.org. 2009-12-10. Retrieved 2011-01-12. 
  21. ^ results returned by a search on "Network Time Protocol" at [1][original research?]
  22. ^ in RFC 778, RFC 891, RFC 956, RFC 958, RFC 1305, RFC 5905, and the NTPv4 specification
  23. ^ "Code Audit". Support.ntp.org. 2009-06-13. Retrieved 2011-01-12. 
  24. ^ Goodin, Dan (2014-01-13). "New DoS attacks taking down game sites deliver crippling 100Gbps floods". Ars Technica. Retrieved 2014-01-25. 
  25. ^ Lee, Dave (2014-02-11). "Huge hack 'ugly sign of future' for internet threats". BBC. Retrieved 2014-02-12. 
  26. ^ "DRDoS / Amplification Attack using ntpdc monlist command". support.ntp.org. 2010-04-24. Retrieved 2014-02-19. 

Relevant RFCs[edit]

Code Note Title
RFC 958 (Obsoleted by: 1059, 1119, 1305) Network Time Protocol (NTP)
RFC 1059 (Obsoleted by: 1119, 1305) Network Time Protocol (Version 1) Specification and Implementation
RFC 1119 (Obsoleted by: 1305) Network Time Protocol (Version 2) Specification and Implementation
RFC 1305 (Obsoleted by: 5905) Network Time Protocol (Version 3) Specification, Implementation and Analysis
RFC 1361 (Obsoleted by: 1769) Simple Network Time Protocol (SNTP)
RFC 1769 (Obsoleted by: 2030, 4330) Simple Network Time Protocol (SNTP)
RFC 2030 (Obsoleted by: 4330) Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
RFC 4330 (Obsoleted by: 5905) Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
RFC 5905 (Current as of 2013) Network Time Protocol Version 4: Protocol and Algorithms Specification
RFC 5906 (Current as of 2013) Network Time Protocol Version 4: Autokey Specification
RFC 5907 (Current as of 2013) Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)
RFC 5908 (Current as of 2013) Network Time Protocol (NTP) Server Option for DHCPv6

External links[edit]

Retrieved from "http://en.wikipedia.org/w/index.php?title=Network_Time_Protocol&oldid=601605831"