Menu
Home Explore People Places Arts History Plants & Animals Science Life & Culture Technology
On this page
Network Time Protocol
Networking protocol for clock synchronization

The Network Time Protocol (NTP) is a longstanding protocol used for clock synchronization across computer systems over packet-switched networks with variable latency. Designed by David L. Mills at the University of Delaware, NTP synchronizes devices within milliseconds of Coordinated Universal Time. The protocol uses the intersection algorithm to select accurate time servers and reduce errors caused by network delays. Typically operating under a client–server model, NTP also supports peer-to-peer modes and exchanges timestamps via the UDP protocol on port 123. The current version, NTPv4, remains backward compatible with earlier versions.

Related Image Collections Add Image
Profiles
1 Image
We don't have any YouTube videos related to Network Time Protocol yet.
We don't have any PDF documents related to Network Time Protocol yet.
We don't have any Books related to Network Time Protocol yet.
We don't have any archived web articles related to Network Time Protocol yet.

Clock synchronization algorithm

A typical NTP client regularly polls one or more NTP servers. The client must compute its time offset and round-trip delay. Time offset θ is the positive or negative (client time > server time) difference in absolute time between the two clocks. It is defined by

θ = ( t 1 − t 0 ) + ( t 2 − t 3 ) 2 , {\displaystyle \theta ={\frac {(t_{1}-t_{0})+(t_{2}-t_{3})}{2}},} and the round-trip delay δ by δ = ( t 3 − t 0 ) − ( t 2 − t 1 ) , {\displaystyle \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.12: 19 

To derive the expression for the offset, note that for the request packet, t 0 + θ + δ / 2 = t 1 {\displaystyle t_{0}+\theta +\delta /2=t_{1}} and for the response packet, t 3 + θ − δ / 2 = t 2 {\displaystyle t_{3}+\theta -\delta /2=t_{2}} Solving for θ yields the definition of the time offset.

The values for θ and δ are passed through filters and subjected to statistical analysis ("mitigation"). Outliers are discarded and an estimate of time offset is derived from the best three remaining candidates. The clock frequency is then adjusted to reduce the offset gradually ("discipline"), creating a feedback loop.13: 20 

Accurate synchronization is achieved 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, a systematic bias exists of half the difference between the forward and backward travel times. A number of approaches have been proposed to measure asymmetry,14 but among practical implementations only chrony seems to have one included.1516

History

In 1979, network time synchronization technology was used in what was possibly the first public demonstration of Internet services running over a trans-Atlantic satellite network, at the National Computer Conference in New York. The technology was later described in the 1981 Internet Engineering Note (IEN) 17317 and a public protocol was developed from it that was documented in RFC 778. The technology was first deployed in a local area network as part of the Hello routing protocol and implemented in the Fuzzball router, an experimental operating system used in network prototyping, where it ran for many years.

Other related network tools were available both then and now. They include the Daytime and Time protocols for recording the time of events, as well as the ICMP Timestamp messages and IP Timestamp option (RFC 781). More complete synchronization systems, although lacking NTP's data analysis and clock disciplining algorithms, include the Unix daemon timed, which uses an election algorithm to appoint a server for all the clients;18 and the Digital Time Synchronization Service (DTSS), which uses a hierarchy of servers similar to the NTP stratum model.

In 1985, NTP version 0 (NTPv0) was implemented in both Fuzzball and Unix, and the NTP packet header and round-trip delay and offset calculations, which have persisted into NTPv4, were documented in RFC 958. Despite the relatively slow computers and networks available at the time, accuracy of better than 100 milliseconds was usually obtained on Atlantic spanning links, with accuracy of tens of milliseconds on Ethernet networks.

In 1988, a much more complete specification of the NTPv1 protocol, with associated algorithms, was published in RFC 1059. It drew on the experimental results and clock filter algorithm documented in RFC 956 and was the first version to describe the client–server and peer-to-peer modes. In 1991, the NTPv1 architecture, protocol and algorithms were brought to the attention of a wider engineering community with the publication of an article by David L. Mills in the IEEE Transactions on Communications.19

In 1989, RFC 1119 was published defining NTPv2 by means of a state machine, with pseudocode to describe its operation. It introduced a management protocol and cryptographic authentication scheme which have both survived into NTPv4, along with the bulk of the algorithm. However the design of NTPv2 was criticized for lacking formal correctness by the DTSS community, and the clock selection procedure was modified to incorporate Marzullo's algorithm for NTPv3 onwards.20

In 1992, RFC 1305 defined NTPv3. The RFC included an analysis of all sources of error, from the reference clock down to the final client, which enabled the calculation of a metric that helps choose the best server where several candidates appear to disagree. Broadcast mode was introduced.

In subsequent years, as new features were added and algorithm improvements were made, it became apparent that a new protocol version was required.21 In 2010, RFC 5905 was published containing a proposed specification for NTPv4.22 Following the retirement of Mills from the University of Delaware, the reference implementation is currently maintained as an open source project led by Harlan Stenn.2324 On the IANA side, a ntp (network time protocols) work group is in charge of reviewing proposed drafts.25

The protocol has significantly progressed since NTPv4.26 As of 2022, three RFC documents describing updates to the protocol have been published,272829 not counting the numerous peripheral standards30 such as Network Time Security.31 Mills had mentioned plans for a "NTPv5" on his page, but one was never published.32 An unrelated draft termed "NTPv5" by M. Lichvar of chrony was initiated in 2020 and includes security, accuracy, and scaling changes.33

SNTP

As NTP replaced the use of the old Time Protocol, some use cases nevertheless found the full protocol too complicated. In 1992, Simple Network Time Protocol (SNTP) was defined to fill this niche. The SNTPv3 standard describes a way to use NTPv3, such that no storage of state over an extended period is needed. The topology becomes essentially the same as with the Time Protocol, as only one server is used.34 In 1996, SNTP was updated to SNTPv435 with some features of the then-in-development NTPv4. The current version of SNTPv4 was merged into the main NTPv4 standard in 2010.36 SNTP is fully interoperable with NTP since it does not define a new protocol.37: §14  However, the simple algorithms provide times of reduced accuracy and thus it is inadvisable to sync time from an SNTP source.38

Clock strata

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 for the reference clock at the top. A server synchronized to a stratum n server runs at stratum n + 1. 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.39 A brief description of strata 0, 1, 2 and 3 is provided below.

Stratum 0 These are high-precision timekeeping devices such as atomic clocks, GNSS (including GPS) or other radio clocks, or a PTP-synchronized clock.40 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. NTP servers cannot advertise themselves as stratum 0. A stratum field set to 0 in NTP packet indicates an unspecified stratum.41: 21  Stratum 1 These are computers whose system time is synchronized to within a few microseconds of their attached stratum 0 devices. Stratum 1 servers may peer with other stratum 1 servers for sanity check and backup.42 They are also referred to as primary time servers.4344 Stratum 2 These are computers that are synchronized over a network to stratum 1 servers. Often a stratum 2 computer queries 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 the same algorithms for peering and data sampling as stratum 2, and can themselves act as servers for stratum 4 computers, and so on.

The upper limit for stratum is 15; 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.45: 20 

In addition to stratum, the protocol is able to identify the synchronization source for each server in terms of a reference identifier (refid).

Common time reference identifiers (refid) codes
Refid46Clock Source
GOESGeostationary Operational Environmental Satellite (described as “Geosynchronous Orbit Environment Satellite” in RFC 5905)
GPSGlobal Positioning System
GALGalileo Positioning System
PPSGeneric pulse-per-second
IRIGInter-Range Instrumentation Group
WWVBLF Radio WWVB Fort Collins, Colorado 60 kHz
DCF/PZF47LF Radio DCF77 Mainflingen, DE 77.5 kHz
HBGLF Radio HBG Prangins, HB 75 kHz (ceased operation)
MSFLF Radio MSF Anthorn, UK 60 kHz
JJYLF Radio JJY Fukushima, JP 40 kHz, Saga, JP 60 kHz
LORCMF Radio Loran-C station, 100 kHz
TDFMF Radio Allouis, FR 162 kHz
CHUHF Radio CHU Ottawa, Ontario
WWVHF Radio WWV Fort Collins, Colorado
WWVHHF Radio WWVH Kauai, Hawaii
NISTNIST telephone modem
ACTSNIST telephone modem
USNOUSNO telephone modem
PTBGerman PTB time standard telephone modem
MRS(Informal) Multi Reference Sources
GOOG(Unofficial) Google Refid used by Google NTP servers as time4.google.com

For servers on stratum 2 and below, the refid is an encoded form of the upstream time server's IP address. For IPv4, this is simply the 32-bit address; for IPv6, it would be the first 32 bits of the MD5 hash of the source address. Refids serve to detect and prevent timing loops to the first degree.48

The refid field is filled with status words in the case of kiss-o'-death (KoD) packets, which tell the client to stop sending requests so that the server can rest.49 Some examples are INIT (initialization), STEP (step time change), and RATE (client requesting too fast).50 The program output may additionally use codes not transmitted in the packet to indicate error, such as XFAC to indicate a network disconnection.51

The IANA maintains a registry for refid source names and KoD codes. Informal assignments can still appear.52

Software implementations

Further information: ntpd § Implementations

Reference implementation

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 personal computers. It runs as a daemon called ntpd under Unix or as a service under Windows. 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.53: 15–19  This implementation was audited in 2017, finding 14 potential security issues.54

Windows Time

All Microsoft Windows versions since Windows 2000 include the Windows Time service (W32Time),55 which has the ability to synchronize the computer clock to an NTP server.

W32Time was originally implemented for the purpose of the Kerberos version 5 authentication protocol, which required time to be within 5 minutes of the correct value to prevent replay attacks. The network time server in Windows 2000 Server (and Windows XP) does not implement NTP disciplined synchronization, only locally disciplined synchronization with NTP/SNTP correction.56

Beginning with Windows Server 2003 and Windows Vista, the NTP provider for W32Time became compatible with a significant subset of NTPv3.57 Microsoft states that W32Time cannot reliably maintain time synchronization with one second accuracy.58 If higher accuracy is desired, Microsoft recommends using a newer version of Windows or different NTP implementation.59

Beginning with Windows 10 version 1607 and Windows Server 2016, W32Time can be configured to reach time accuracy of 1 s, 50 ms or 1 ms under certain specified operating conditions.606162

OpenNTPD

In 2004, Henning Brauer of OpenBSD presented OpenNTPD, an NTPv3/SNTPv463 implementation with a focus on security and encompassing a privilege separated design. Whilst it is aimed more closely at the simpler generic needs of OpenBSD users, it also includes some protocol security improvements while still being compatible with existing NTP servers. The simpler code base sacrifices accuracy, deemed unnecessary in this use case.64 A portable version is available in Linux package repositories.

NTPsec

NTPsec is a fork of the reference implementation that has been systematically security-hardened. The fork point was in June 2015 and was in response to a series of compromises in 2014.65 The first production release shipped in October 2017.66 Between removal of unsafe features, removal of support for obsolete hardware, and removal of support for obsolete Unix variants, NTPsec has been able to pare away 75% of the original codebase, making the remainder easier to audit.67 A 2017 audit of the code showed eight security issues, including two that were not present in the original reference implementation, but NTPsec did not suffer from eight other issues that remained in the reference implementation.68

chrony

Main article: chrony

chrony is an independent NTP implementation mainly sponsored by Red Hat, who uses it as the default time program in their distributions.69 Being written from scratch, chrony has a simpler codebase allowing for better security70 and lower resource consumption.71 It does not however compromise on accuracy, instead syncing faster and better than the reference ntpd in many circumstances. It is versatile enough for ordinary computers, which are unstable, go into sleep mode or have intermittent connection to the Internet. It is also designed for virtual machines, a more unstable environment.72

chrony has been evaluated as "trustworthy", with only a few incidents.73 It is able to achieve improved precision on LAN connections, using hardware timestamping on the network adapter.74 Support for Network Time Security (NTS) was added on version 4.0.75 chrony is available under GNU General Public License version 2, was created by Richard Curnow in 1997 and is currently maintained by Miroslav Lichvar.76

ntpd-rs

ntpd-rs is a security-focused implementation of the NTP protocol, founded by the Internet Security Research Group as part of their Prossimo initiative for the creation of memory safe Internet infrastructure. ntpd-rs is implemented in Rust programming language which offers memory safety guarantees in addition to the Real-time computing capabilities which are required for an NTP implementation. ntpd-rs is used in security-sensitive environments such as the Let's Encrypt non-profit Certificate Authority.77 Support for NTS is available.78 ntpd-rs is part of the "Pendulum" project which also includes a Precision Time Protocol implementation "statime". Both projects are available under Apache and MIT software licenses.

Others

Leap seconds

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

An alternative implementation, called leap smearing, consists in introducing the leap second incrementally during a period of 24 hours, from noon to noon in UTC time. This implementation is used by Google (both internally and on their public NTP servers), Amazon AWS,83 and Facebook.84 chrony supports leap smear in smoothtime and leapsecmode configurations, but such use is not to be mixed with a public NTP pool as leap smear is non-standard and will throw off client calculation in a mix.85

Security concerns

See also: NTP server misuse and abuse

Because adjusting system time is generally a privileged operation, part or all of NTP code has to be run with some privileges in order to support its core functionality. Only a few other security problems have been identified in the reference implementation of the NTP codebase, but those that appeared in 2009[which?] were cause for significant concern.8687 The protocol has been undergoing revision and review throughout its history. The codebase for the reference implementation has undergone security audits from several sources for several years.88

A stack buffer overflow exploit was discovered and patched in 2014.89 Apple was concerned enough about this vulnerability that it used its auto-update capability for the first time.90 On systems using the reference implementation, which is running with root user's credential, this could allow unlimited access. Some other implementations, such as OpenNTPD, have smaller code base and adopted other mitigation measures like privilege separation, are not subject to this flaw.91

A 2017 security audit of three NTP implementations, conducted on behalf of the Linux Foundation's Core Infrastructure Initiative, suggested that both NTP9293 and NTPsec94 were more problematic than chrony95 from a security standpoint.96

NTP servers can be susceptible to man-in-the-middle attacks unless packets are cryptographically signed for authentication.97 The computational overhead involved can make this impractical on busy servers, particularly during denial of service attacks.98 NTP message spoofing from a man-in-the-middle attack can be used to alter clocks on client computers and allow a number of attacks based on bypassing of cryptographic key expiration.99 Some of the services affected by fake NTP messages identified are TLS, DNSSEC, various caching schemes (such as DNS cache), Border Gateway Protocol (BGP), Bitcoin and a number of persistent login schemes.100101

NTP has been used in distributed denial of service attacks.102103 A small query is sent to an NTP server with the return IP address spoofed to be the target address. Similar to the DNS amplification attack, the server responds with a much larger reply that allows an attacker to substantially increase the amount of data being sent to the target. To avoid participating in an attack, NTP server software can be upgraded or servers can be configured to ignore external queries.104

Secure extensions

NTP itself includes support for authenticating servers to clients. NTPv3 supports a symmetric key mode, which is not useful against MITM. The public key system known as "autokey" in NTPv4 adapted from IPSec offers useful authentication,105 but is not practical for a busy server.106 Autokey was also later found to suffer from several design flaws,107 with no correction published, save for a change in the message authentication code.108 Autokey should no longer be used.109

Network Time Security (NTS) is a secure version of NTPv4 with TLS and AEAD.110 The main improvement over previous attempts is that a separate "key establishment" server handles the heavy asymmetric cryptography, which needs to be done only once. If the server goes down, previous users would still be able to fetch time without fear of MITM.111 NTS is supported by several NTP servers including Cloudflare and Netnod.112113 It can be enabled on chrony, NTPsec, and ntpd-rs.114

Microsoft also has an approach to authenticate NTPv3/SNTPv4 packets using a Windows domain identity, known as MS-SNTP.115 This system is implemented in the reference ntpd and chrony, using samba for the domain connection.116

NTP packet header format

NTP packet header format117: §7.3 
OffsetOctet0123
OctetBit012345678910111213141516171819202122232425262728293031
00LIVNModeStratumPollPrecision
432Root Delay
864Root Dispersion
1296Reference ID
16128Reference Timestamp (64-bits)
20160
24192Origin Timestamp (64-bits)
28224
32256Receive Timestamp (64-bits)
36288
40320Transmit Timestamp (64-bits)
44352
48384Optional: Extension Field(s) (n * 32 bits)
52416Optional: Key Identifier (If a MAC is present)
56448Optional: Message Digest (dgst) (If a MAC is present)
60480
64512
68544
LI (Leap Indicator): 2 bits Warning of leap second insertion or deletion:
  • 0 = no warning
  • 1 = last minute has 61 seconds
  • 2 = last minute has 59 seconds
  • 3 = unknown (clock unsynchronized)
VN (Version Number): 3 bits NTP version number, typically 4. Mode: 3 bits Association mode:
  • 0 = reserved
  • 1 = symmetric active
  • 2 = symmetric passive
  • 3 = client
  • 4 = server
  • 5 = broadcast
  • 6 = control
  • 7 = private
Stratum: 8 bits Indicates the distance from the reference clock.
  • 0 = invalid
  • 1 = primary server
  • 2–15 = secondary
  • 16 = unsynchronized
Poll: 8 bits Maximum interval between successive messages, in log₂(seconds). Typical range is 6 to 10. Precision: 8 bits Signed log₂(seconds) of system clock precision (e.g., –18 ≈ 1 microsecond). Root Delay: 32 bits Total round-trip delay to the reference clock, in NTP short format. Root Dispersion: 32 bits Total dispersion to the reference clock, in NTP short format. Reference ID: 32 bits Identifies the specific server or reference clock; interpretation depends on Stratum. Reference Timestamp: 64 bits Time when the system clock was last set or corrected, in NTP timestamp format. Origin Timestamp (org): 64 bits Time at the client when the request departed, in NTP timestamp format. Receive Timestamp (rec): 64 bits Time at the server when the request arrived, in NTP timestamp format. Transmit Timestamp (xmt): 64 bits Time at the server when the response left, in NTP timestamp format. Extension Field: variable Optional field(s) for NTP extensions (see 118, Section 7.5). Key Identifier: 32 bits Unsigned integer designating an MD5 key shared by the client and server. Message Digest (MD5): 128 bits MD5 hash covering the packet header and extension fields, used for authentication.

Timestamps

The 64-bit binary fixed-point 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. Therefore, the first rollover occurs on February 7, 2036.119120

NTPv4 introduces a 128-bit date format: 64 bits for the second and 64 bits for the fractional-second. The most-significant 32 bits of this format is the Era Number which resolves rollover ambiguity in most cases.121 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."122123

See also

Notes

Further reading

References

  1. David L. Mills (12 December 2010). Computer Network Time Synchronization: The Network Time Protocol. Taylor & Francis. pp. 12–. ISBN 978-0-8493-5805-0. Archived from the original on 18 July 2014. Retrieved 16 October 2016. 978-0-8493-5805-0 ↩

  2. "Executive Summary: Computer Network Time Synchronization". Archived from the original on 2 November 2011. Retrieved 21 November 2011. http://www.eecis.udel.edu/~mills/exec.html ↩

  3. "NTP FAQ". The NTP Project. Archived from the original on 6 September 2011. Retrieved 27 August 2011. http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-ACCURATE-CLOCK ↩

  4. David L. Mills (12 December 2010). Computer Network Time Synchronization: The Network Time Protocol. Taylor & Francis. pp. 12–. ISBN 978-0-8493-5805-0. Archived from the original on 18 July 2014. Retrieved 16 October 2016. 978-0-8493-5805-0 ↩

  5. "Port Numbers". The Internet Assigned Numbers Authority (IANA). Archived from the original on 4 June 2001. Retrieved 19 January 2011. https://www.iana.org/assignments/port-numbers ↩

  6. D. Mills; J. Burbank; W. Kasch (August 2010). J. Martin (ed.). Network Time Protocol Version 4: Protocol and Algorithms Specification. Internet Engineering Task Force. doi:10.17487/RFC5905. ISSN 2070-1721. RFC 5905. Proposed Standard. Obsoletes RFC 1305, 4330. Updated by RFC 7822, 8573 and 9109. /wiki/David_L._Mills ↩

  7. "NTP FAQ". The NTP Project. Archived from the original on 6 September 2011. Retrieved 27 August 2011. http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-ACCURATE-CLOCK ↩

  8. "Executive Summary: Computer Network Time Synchronization". Archived from the original on 2 November 2011. Retrieved 21 November 2011. http://www.eecis.udel.edu/~mills/exec.html ↩

  9. "NTP FAQ". The NTP Project. Archived from the original on 6 September 2011. Retrieved 27 August 2011. http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-ACCURATE-CLOCK ↩

  10. D. Mills; J. Burbank; W. Kasch (August 2010). J. Martin (ed.). Network Time Protocol Version 4: Protocol and Algorithms Specification. Internet Engineering Task Force. doi:10.17487/RFC5905. ISSN 2070-1721. RFC 5905. Proposed Standard. Obsoletes RFC 1305, 4330. Updated by RFC 7822, 8573 and 9109. /wiki/David_L._Mills ↩

  11. David L. Mills (March 1992). Network Time Protocol (Version 3) - Specification, Implementation and Analysis. Network Working Group. doi:10.17487/RFC1305. RFC 1305. Obsolete. Obsoleted by RFC 5905. Obsoletes RFC 958, 1059 and 1119. /wiki/David_L._Mills ↩

  12. David L. Mills (12 December 2010). Computer Network Time Synchronization: The Network Time Protocol. Taylor & Francis. pp. 12–. ISBN 978-0-8493-5805-0. Archived from the original on 18 July 2014. Retrieved 16 October 2016. 978-0-8493-5805-0 ↩

  13. David L. Mills (12 December 2010). Computer Network Time Synchronization: The Network Time Protocol. Taylor & Francis. pp. 12–. ISBN 978-0-8493-5805-0. Archived from the original on 18 July 2014. Retrieved 16 October 2016. 978-0-8493-5805-0 ↩

  14. Gotoh, T.; Imamura, K.; Kaneko, A. (2002). "Improvement of NTP time offset under the asymmetric network with double packets method". Conference Digest Conference on Precision Electromagnetic Measurements. Conference on Precision Electromagnetic Measurements. pp. 448–449. doi:10.1109/CPEM.2002.1034915. ISBN 0-7803-7242-5. 0-7803-7242-5 ↩

  15. Lichvar, Miroslav (18 September 2018). "chrony – chrony.conf(5)". Chrony project. Retrieved 2 August 2020. This directive enables hardware timestamping of NTP packets sent to and received from the specified network interface. https://chrony.tuxfamily.org/doc/4.3/chrony.conf.html#hwtimestamp ↩

  16. "sourcestats.c, function estimate_asymmetry()". git.tuxfamily.org (chrony). https://git.tuxfamily.org/chrony/chrony.git/tree/sourcestats.c?h=4.3 ↩

  17. D.L. Mills (25 February 1981), Time Synchronization in DCNET Hosts, archived from the original on 30 December 1996 https://web.archive.org/web/19961230073104/http://www.cis.ohio-state.edu/htbin/ien/ien173.html ↩

  18. "TIMED(8)", UNIX System Manager's Manual, archived from the original on 22 July 2011, retrieved 12 September 2017 http://www.skrenta.com/rt/man/timed.8.html ↩

  19. David L. Mills (October 1991). "Internet Time Synchronization: The Network Time Protocol" (PDF). IEEE Transactions on Communications. 39 (10): 1482–1493. Bibcode:1991ITCom..39.1482M. doi:10.1109/26.103043. Archived (PDF) from the original on 10 June 2016. Retrieved 6 November 2017. http://www3.cs.stonybrook.edu/~jgao/CSE590-spring11/91-ntp.pdf ↩

  20. David L. Mills (March 1992). Network Time Protocol (Version 3) - Specification, Implementation and Analysis. Network Working Group. doi:10.17487/RFC1305. RFC 1305. Obsolete. The clock-selection procedure was modified to remove the first of the two sorting/discarding steps and replace with an algorithm first proposed by Marzullo and later incorporated in the Digital Time Service. These changes do not significantly affect the ordinary operation of or compatibility with various versions of NTP, but they do provide the basis for formal statements of correctness. /wiki/David_L._Mills ↩

  21. David L. Mills (15 November 2010). Computer Network Time Synchronization: The Network Time Protocol on Earth and in Space, Second Edition. CRC Press. p. 377. ISBN 978-1-4398-1464-2. 978-1-4398-1464-2 ↩

  22. "Future Plans", Network Time Synchronization Research Project, archived from the original on 23 December 2014, retrieved 24 December 2014 https://www.eecis.udel.edu/~mills/ntp.html ↩

  23. "NTP Needs Money: Is A Foundation The Answer?". InformationWeek. 23 March 2015. Archived from the original on 10 April 2015. Retrieved 4 April 2015. http://www.informationweek.com/cloud/infrastructure-as-a-service/ntp-needs-money-is-a-foundation-the-answer/d/d-id/1319557 ↩

  24. "NTP's Fate Hinges On 'Father Time'". InformationWeek. 11 March 2015. Archived from the original on 10 April 2015. Retrieved 4 April 2015. http://www.informationweek.com/it-life/ntps-fate-hinges-on-father-time/d/d-id/1319432?cmp=em-prog-na-na-newsltr_20150313_control&imm_mid=0ce65e&page_number=2 ↩

  25. "Network Time Protocols (ntp): Documents". datatracker.ietf.org. Retrieved 27 December 2022. https://datatracker.ietf.org/wg/ntp/documents/ ↩

  26. "Future Plans", Network Time Synchronization Research Project, archived from the original on 23 December 2014, retrieved 24 December 2014 https://www.eecis.udel.edu/~mills/ntp.html ↩

  27. T. Mizrahi; D. Mayer (March 2016). Network Time Protocol Version 4 (NTPv4) Extension Fields. Internet Engineering Task Force. doi:10.17487/RFC7822. ISSN 2070-1721. RFC 7822. Informational. Updates RFC 5905. https://datatracker.ietf.org/doc/html/rfc7822 ↩

  28. A. Malhotra; S. Goldberg (June 2019). Message Authentication Code for the Network Time Protocol. Internet Engineering Task Force. doi:10.17487/RFC8573. ISSN 2070-1721. RFC 8573. Proposed Standard. Updates RFC 5905. https://datatracker.ietf.org/doc/html/rfc8573 ↩

  29. F. Gont; G. Gont; M. Lichvar (August 2021). Network Time Protocol Version 4: Port Randomization. Internet Engineering Task Force. doi:10.17487/RFC9109. ISSN 2070-1721. RFC 9109. Proposed Standard. Updates RFC 5905. https://datatracker.ietf.org/doc/html/rfc9109 ↩

  30. "Network Time Protocols (ntp): Documents". datatracker.ietf.org. Retrieved 27 December 2022. https://datatracker.ietf.org/wg/ntp/documents/ ↩

  31. D. Franke; D. Sibold; K. Teichel; M. Dansarie; R. Sundblad (September 2020). Network Time Security for the Network Time Protocol. Internet Engineering Task Force. doi:10.17487/RFC8915. ISSN 2070-1721. RFC 8915. Proposed Standard. https://datatracker.ietf.org/doc/html/rfc8915 ↩

  32. "Future Plans", Network Time Synchronization Research Project, archived from the original on 23 December 2014, retrieved 24 December 2014 https://www.eecis.udel.edu/~mills/ntp.html ↩

  33. Lichvar, Miroslav (6 December 2022). "Network Time Protocol Version 5". www.ietf.org. https://www.ietf.org/archive/id/draft-mlichvar-ntp-ntpv5-06.html ↩

  34. D. Mills (August 1992). Type of Service in the Internet Protocol Suite. Network Working Group. doi:10.17487/RFC1361. RFC 1361. Obsolete. Obsoleted by RFC 1769. /wiki/David_L._Mills ↩

  35. D. Mills (October 1996). Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. Network Working Group. doi:10.17487/RFC2030. RFC 2030. Obsolete. Obsoleted by RFC 4330. Obsoletes RFC 1769. /wiki/David_L._Mills ↩

  36. D. Mills; J. Burbank; W. Kasch (August 2010). J. Martin (ed.). Network Time Protocol Version 4: Protocol and Algorithms Specification. Internet Engineering Task Force. doi:10.17487/RFC5905. ISSN 2070-1721. RFC 5905. Proposed Standard. Obsoletes RFC 1305, 4330. Updated by RFC 7822, 8573 and 9109. /wiki/David_L._Mills ↩

  37. D. Mills; J. Burbank; W. Kasch (August 2010). J. Martin (ed.). Network Time Protocol Version 4: Protocol and Algorithms Specification. Internet Engineering Task Force. doi:10.17487/RFC5905. ISSN 2070-1721. RFC 5905. Proposed Standard. 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 [...] /wiki/David_L._Mills ↩

  38. D. Mills (January 2006). Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. Network Working Group. doi:10.17487/RFC4330. RFC 4330. Obsolete. Obsoletes RFC 2030 and 1769. Obsoleted by RFC 5905. /wiki/David_L._Mills ↩

  39. Telecommunication systems use a different definition for clock strata. /wiki/Synchronization_in_telecommunications ↩

  40. "Combining PTP with NTP to Get the Best of Both Worlds". www.redhat.com. Programs from the linuxptp package can be used in a combination with an NTP daemon. A PTP clock on a NIC is synchronized by ptp4l and is used as a reference clock by chronyd or ntpd for synchronization of the system clock. https://www.redhat.com/en/blog/combining-ptp-ntp-get-best-both-worlds ↩

  41. D. Mills; J. Burbank; W. Kasch (August 2010). J. Martin (ed.). Network Time Protocol Version 4: Protocol and Algorithms Specification. Internet Engineering Task Force. doi:10.17487/RFC5905. ISSN 2070-1721. RFC 5905. Proposed Standard. Obsoletes RFC 1305, 4330. Updated by RFC 7822, 8573 and 9109. /wiki/David_L._Mills ↩

  42. "Network Time Protocol: Best Practices White Paper". Archived from the original on 1 October 2013. Retrieved 15 October 2013. http://www.cisco.com/en/US/tech/tk869/tk769/technologies_white_paper09186a0080117070.shtml ↩

  43. "Executive Summary: Computer Network Time Synchronization". Archived from the original on 2 November 2011. Retrieved 21 November 2011. http://www.eecis.udel.edu/~mills/exec.html ↩

  44. "NTP FAQ". The NTP Project. Archived from the original on 6 September 2011. Retrieved 27 August 2011. http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-ACCURATE-CLOCK ↩

  45. David L. Mills (12 December 2010). Computer Network Time Synchronization: The Network Time Protocol. Taylor & Francis. pp. 12–. ISBN 978-0-8493-5805-0. Archived from the original on 18 July 2014. Retrieved 16 October 2016. 978-0-8493-5805-0 ↩

  46. "'ntpq -p' output". NLUG.ML1.co.uk. Archived from the original on 12 November 2018. Retrieved 12 November 2018. https://nlug.ml1.co.uk/2012/01/ntpq-p-output/831 ↩

  47. "IMS-PZF: PZF (DCF77) Correlation Receiver (Eurocard)". Meinberg Funkuhren GmbH & Co KG. Retrieved 19 June 2025. https://www.meinbergglobal.com/english/products/ims-pzf-receiver.htm ↩

  48. D. Mills; J. Burbank; W. Kasch (August 2010). J. Martin (ed.). Network Time Protocol Version 4: Protocol and Algorithms Specification. Internet Engineering Task Force. doi:10.17487/RFC5905. ISSN 2070-1721. RFC 5905. Proposed Standard. Obsoletes RFC 1305, 4330. Updated by RFC 7822, 8573 and 9109. /wiki/David_L._Mills ↩

  49. D. Mills; J. Burbank; W. Kasch (August 2010). J. Martin (ed.). Network Time Protocol Version 4: Protocol and Algorithms Specification. Internet Engineering Task Force. doi:10.17487/RFC5905. ISSN 2070-1721. RFC 5905. Proposed Standard. Obsoletes RFC 1305, 4330. Updated by RFC 7822, 8573 and 9109. /wiki/David_L._Mills ↩

  50. "Event Messages and Status Words". docs.ntpsec.org. Refid codes are used in kiss-o'-death (KoD) packets, the reference identifier field in ntpq and ntpmon billboard displays and log messages. https://docs.ntpsec.org/latest/decode.html#kiss ↩

  51. "'ntpq -p' output". NLUG.ML1.co.uk. Archived from the original on 12 November 2018. Retrieved 12 November 2018. https://nlug.ml1.co.uk/2012/01/ntpq-p-output/831 ↩

  52. "Network Time Protocol (NTP) Parameters". www.iana.org. https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml ↩

  53. David L. Mills (12 December 2010). Computer Network Time Synchronization: The Network Time Protocol. Taylor & Francis. pp. 12–. ISBN 978-0-8493-5805-0. Archived from the original on 18 July 2014. Retrieved 16 October 2016. 978-0-8493-5805-0 ↩

  54. "Pentest-Report NTP 01.2017" (PDF). Cure53. 2017. Archived (PDF) from the original on 1 December 2018. Retrieved 3 July 2019. https://wiki.mozilla.org/images/e/ea/Ntp-report.pdf ↩

  55. "Windows Time Service Technical Reference". technet.microsoft.com. 17 August 2011. Archived from the original on 6 September 2011. Retrieved 19 September 2011. https://technet.microsoft.com/en-us/library/cc773061%28WS.10%29.aspx ↩

  56. "Windows Time Service page at NTP.org". Support.NTP.org. 25 February 2008. Archived from the original on 14 May 2017. Retrieved 1 May 2017. https://support.ntp.org/bin/view/Support/WindowsTimeService ↩

  57. "How the Windows Time Service Works". technet.microsoft.com. 12 March 2010. Archived from the original on 24 September 2011. Retrieved 19 September 2011. https://technet.microsoft.com/en-us/library/cc773013%28WS.10%29.aspx ↩

  58. "Support boundary to configure the Windows Time service for high accuracy environments". Microsoft. 19 October 2011. Archived from the original on 12 January 2009. Retrieved 10 December 2008. http://support.microsoft.com/kb/939322 ↩

  59. Ned Pyle (23 October 2007). "High Accuracy W32time Requirements". Microsoft. Archived from the original on 17 October 2012. Retrieved 26 August 2012. https://docs.microsoft.com/en-us/archive/blogs/askds/high-accuracy-w32time-requirements ↩

  60. "Windows Server 2016 Accurate Time". technet.microsoft.com. Archived from the original on 2 December 2016. Retrieved 7 December 2016. https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-ds/get-started/windows-time-service/windows-2016-accurate-time ↩

  61. "Support boundary to configure the Windows Time service for high accuracy environments". Microsoft. 19 October 2011. Archived from the original on 12 January 2009. Retrieved 10 December 2008. http://support.microsoft.com/kb/939322 ↩

  62. dahavey. "Support boundary for high-accuracy time". docs.microsoft.com. Archived from the original on 2 May 2021. Retrieved 24 July 2021. https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/support-boundary ↩

  63. "ntpd(8) - OpenBSD manual pages". man.openbsd.org. It implements the Simple Network Time Protocol version 4, as described in RFC 5905, and the Network Time Protocol version 3, as described in RFC 1305. https://man.openbsd.org/ntpd ↩

  64. The OpenBSD Project (21 August 2006). "FAQ 6.12.1: 'But OpenNTPD isn't as accurate as the ntp.org daemon!'". The OpenBSD Project. Archived from the original on 5 February 2016. Retrieved 14 May 2020. https://web.archive.org/web/20160205120110/http://www.openbsd.org/faq/faq6.html#OpenNTPDaccurate ↩

  65. Raymond, Eric S. (30 March 2017). "NTPsec: a Secure, Hardened NTP Implementation | Linux Journal". Linux Journal. Archived from the original on 26 January 2024. Retrieved 26 January 2024. https://www.linuxjournal.com/content/ntpsec-secure-hardened-ntp-implementation ↩

  66. "The Secure Network Time Protocol (NTPsec) Distribution". Archived from the original on 13 January 2019. Retrieved 12 January 2019. https://ntpsec.org ↩

  67. Liska, Allan (10 December 2016). NTP Security: A Quick-Start Guide. Apress. pp. 80–. ISBN 978-1-4842-2412-0. 978-1-4842-2412-0 ↩

  68. "Pentest-Report NTPsec 01.2017" (PDF). Cure53. 2017. Archived (PDF) from the original on 4 July 2019. Retrieved 3 July 2019. https://wiki.mozilla.org/images/1/10/Ntpsec-report.pdf ↩

  69. Lichvar, Miroslav (20 July 2016). "Combining PTP with NTP to Get the Best of Both Worlds". Red Hat Enterprise Linux Blog. Red Hat. Archived from the original on 30 July 2016. Retrieved 19 November 2017. Starting with Red Hat Enterprise Linux 7.0 (and now in Red Hat Enterprise Linux 6.8) a more versatile NTP implementation is also provided via the chrony package https://web.archive.org/web/20160730091110/http://rhelblog.redhat.com/2016/07/20/combining-ptp-with-ntp-to-get-the-best-of-both-worlds/ ↩

  70. "Securing Network Time". Core Infrastructure Initiative, a Linux Foundation Collaborative Project. Core Infrastructure Initiative. 27 September 2017. Archived from the original on 28 October 2017. Retrieved 19 November 2017. In sum, the Chrony NTP software stands solid and can be seen as trustworthy https://web.archive.org/web/20171028123642/https://www.coreinfrastructure.org/news/blogs/2017/09/securing-network-time ↩

  71. "chrony introduction". TuxFamily, a non-profit organization. chrony. Archived from the original on 9 December 2009. Retrieved 19 November 2017. The software is supported on Linux, FreeBSD, NetBSD, macOS, and Solaris. https://web.archive.org/web/20091209115945/https://chrony.tuxfamily.org/ ↩

  72. Both, David. "Manage NTP with Chrony". Opensource.com. Archived from the original on 29 June 2019. Retrieved 29 June 2019. https://opensource.com/article/18/12/manage-ntp-chrony ↩

  73. Heiderich, Mario (August 2017). "Pentest-Report Chrony 08.2017" (PDF). Cure53.de Team. wiki.mozilla.org, AKA MozillaWiki or WikiMO. Archived from the original (PDF) on 5 October 2017. Retrieved 19 November 2017. Withstanding eleven full days of on-remote testing in August of 2017 means that Chrony is robust, strong, and developed with security in mind. https://web.archive.org/web/20171005123643/https://wiki.mozilla.org/images/e/e4/Chrony-report.pdf ↩

  74. Lichvar, Miroslav (18 September 2018). "chrony – chrony.conf(5)". Chrony project. Retrieved 2 August 2020. This directive enables hardware timestamping of NTP packets sent to and received from the specified network interface. https://chrony.tuxfamily.org/doc/4.3/chrony.conf.html#hwtimestamp ↩

  75. "chrony/chrony.git - Official Git repository for the Chrony project". git.tuxfamily.org. Retrieved 31 July 2021. https://git.tuxfamily.org/chrony/chrony.git/tree/NEWS?id=4.0#n6 ↩

  76. "chrony introduction". TuxFamily, a non-profit organization. chrony. Archived from the original on 9 December 2009. Retrieved 19 November 2017. The software is supported on Linux, FreeBSD, NetBSD, macOS, and Solaris. https://web.archive.org/web/20091209115945/https://chrony.tuxfamily.org/ ↩

  77. Aas, Josh. "More Memory Safety for Let's Encrypt: Deploying ntpd-rs". Let's Encrypt. Let's Encrypt. Retrieved 18 December 2024. https://letsencrypt.org/2024/06/24/ntpd-rs-deployment/ ↩

  78. "Network Time Security - ntpd-rs documentation". docs.ntpd-rs.pendulum-project.org. Retrieved 13 January 2025. https://docs.ntpd-rs.pendulum-project.org/guide/nts/ ↩

  79. Poul-Henning, Kamp. "20140926 – Playing with time again". PHK's Bikeshed. Archived from the original on 20 December 2019. Retrieved 4 June 2015. http://phk.freebsd.dk/time/20140926 ↩

  80. Poul-Henning, Kamp. "Network time synchronization software, NTPD replacement". ntimed git repository README file. Github. Archived from the original on 2 August 2015. Retrieved 4 June 2015. https://github.com/bsdphk/Ntimed ↩

  81. "Switching from OpenNTPd to Chrony - anarcat". anarc.at. So in effect, systemd-timesyncd became the default NTP daemon in Debian in bookworm, which I find somewhat surprising. https://anarc.at/blog/2022-01-23-chrony/ ↩

  82. David Mills. "The NTP Timescale and Leap Seconds". Archived from the original on 7 September 2013. Retrieved 15 October 2013. http://www.eecis.udel.edu/~mills/leap.html ↩

  83. "Google Developers Leap Smear". Archived from the original on 4 April 2019. Retrieved 4 April 2019. https://developers.google.com/time/smear ↩

  84. Obleukhov, Oleg (18 March 2020). "Building a more accurate time service at Facebook scale". Engineering at Meta. https://engineering.fb.com/2020/03/18/production-engineering/ntp-service/ ↩

  85. "chrony – Frequently Asked Questions". chrony.tuxfamily.org. https://chrony.tuxfamily.org/faq.html#_should_be_a_leap_smear_enabled_on_ntp_server ↩

  86. "Security Notice". Support.NTP.org. 10 December 2009. Retrieved 12 January 2011.[permanent dead link] http://support.ntp.org/security ↩

  87. "Cisco IOS Software Network Time Protocol Packet Vulnerability". Cisco Systems. 23 September 2009. Archived from the original on 11 June 2020. Retrieved 11 June 2020. https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20090923-ntp ↩

  88. "Code Audit". Support.NTP.org. 13 June 2009. Retrieved 12 January 2011. http://support.ntp.org/Main/CodeAudit ↩

  89. "Network Time Protocol Vulnerabilities (Update C) | ICS-CERT". Ics-cert.us-cert.gov. Archived from the original on 20 December 2014. Retrieved 15 April 2015. https://ics-cert.us-cert.gov/advisories/ICSA-14-353-01 ↩

  90. Cunningham, Andrew (23 December 2014). "Apple automatically patches Macs to fix severe NTP security flaw". arstechnica. Archived from the original on 15 April 2015. Retrieved 29 April 2015. https://arstechnica.com/apple/2014/12/apple-automatically-patches-macs-to-fix-severe-ntp-security-flaw/ ↩

  91. Fairhead, Harry (23 December 2014). "NTP The Latest Open Source Security Problem". I Programmer. Archived from the original on 24 December 2014. Retrieved 24 December 2014. https://web.archive.org/web/20141224071634/http://www.i-programmer.info/news/149-security/8120-ntp-the-latest-open-source-security-problem.html ↩

  92. NTP SecurityNotice Page Archived 2014-02-19 at the Wayback Machine http://support.ntp.org/bin/view/Main/SecurityNotice ↩

  93. NVD NIST Product Search NTP https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&cpe_vendor=cpe%3A%2F%3Antp&cpe_product=cpe%3A%2F%3A%3Antp ↩

  94. NVD NIST Product Search NTPsec Archived 2020-06-26 at the Wayback Machine https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&cpe_vendor=cpe%3A%2F%3Antpsec&cpe_product=cpe%3A%2F%3A%3Antpsec ↩

  95. NVD NIST Product Search Chrony Archived 2020-06-26 at the Wayback Machine https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&cpe_vendor=cpe%3A%2F%3Atuxfamily&cpe_product=cpe%3A%2F%3A%3Achrony ↩

  96. "CII Audit Identifies Most Secure NTP Implementation". The Linux Foundation. 28 September 2017. Archived from the original on 3 February 2018. Retrieved 3 July 2019. https://web.archive.org/web/20180203195701/https://www.linuxfoundation.org/blog/cii-audit-identifies-secure-ntp-implementation/ ↩

  97. Network Time Protocol Version 4: Autokey Specification. IETF. June 2010. doi:10.17487/RFC5906. RFC 5906. https://datatracker.ietf.org/doc/html/rfc5906 ↩

  98. "NTP Security Analysis". Archived from the original on 7 September 2013. Retrieved 11 October 2013. https://web.archive.org/web/20130907040625/http://www.eecis.udel.edu/%7emills/security.html ↩

  99. Jose Selvi (16 October 2014). "Bypassing HTTP Strict Transport Security" (PDF). Archived from the original (PDF) on 18 October 2014. Retrieved 16 October 2014. https://web.archive.org/web/20141018053055/https://www.blackhat.com/docs/eu-14/materials/eu-14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf ↩

  100. Aanchal Malhotra; Isaac E. Cohen; Erik Brakke & Sharon Goldberg (20 October 2015). "Attacking the Network Time Protocol" (PDF). NDSS. Archived from the original (PDF) on 22 October 2015. Retrieved 27 October 2015. https://web.archive.org/web/20151022140151/http://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf ↩

  101. "Attacking the Network Time Protocol". www.cs.bu.edu. Archived from the original on 24 October 2015. Retrieved 27 October 2015. https://web.archive.org/web/20151024172618/http://www.cs.bu.edu/~goldbe/NTPattack.html ↩

  102. Goodin, Dan (13 January 2014). "New DoS attacks taking down game sites deliver crippling 100Gbps floods". Ars Technica. Archived from the original on 24 January 2014. Retrieved 25 January 2014. https://arstechnica.com/security/2014/01/new-dos-attacks-taking-down-game-sites-deliver-crippling-100-gbps-floods/ ↩

  103. Lee, Dave (11 February 2014). "Huge Hack 'Ugly Sign of Future' for Internet Threats". BBC. Archived from the original on 11 February 2014. Retrieved 12 February 2014. https://www.bbc.co.uk/news/technology-26136774 ↩

  104. "DRDoS / Amplification Attack using ntpdc monlist command". support.NTP.org. 24 April 2010. Archived from the original on 30 March 2014. Retrieved 13 April 2014. http://support.ntp.org/bin/view/Main/SecurityNotice#April_2010_DRDoS_Amplification_A ↩

  105. Network Time Protocol Version 4: Autokey Specification. IETF. June 2010. doi:10.17487/RFC5906. RFC 5906. https://datatracker.ietf.org/doc/html/rfc5906 ↩

  106. "NTP Security Analysis". Archived from the original on 7 September 2013. Retrieved 11 October 2013. https://web.archive.org/web/20130907040625/http://www.eecis.udel.edu/%7emills/security.html ↩

  107. Dieter Sibold; Stephen Röttger (2012). Analysis of NTP's Autokey Protocol (PDF). IETF 83. https://www.ietf.org/proceedings/83/slides/slides-83-tictoc-1.pdf ↩

  108. A. Malhotra; S. Goldberg (June 2019). Message Authentication Code for the Network Time Protocol. Internet Engineering Task Force. doi:10.17487/RFC8573. ISSN 2070-1721. RFC 8573. Proposed Standard. Updates RFC 5905. https://datatracker.ietf.org/doc/html/rfc8573 ↩

  109. H. Stenn; D. Sibold (July 2019). D. Reilly (ed.). Network Time Protocol Best Current Practices. Internet Engineering Task Force. doi:10.17487/RFC8633. ISSN 2070-1721. BCP 223. RFC 8633. Best Current Practice 223Best Current Practice. sec. 4.2. https://datatracker.ietf.org/doc/html/rfc8633 ↩

  110. "nts.time.nl homepage". nts.time.nl. Retrieved 19 August 2021. https://nts.time.nl/ ↩

  111. D. Franke; D. Sibold; K. Teichel; M. Dansarie; R. Sundblad (September 2020). Network Time Security for the Network Time Protocol. Internet Engineering Task Force. doi:10.17487/RFC8915. ISSN 2070-1721. RFC 8915. Proposed Standard. https://datatracker.ietf.org/doc/html/rfc8915 ↩

  112. Langer, Martin (5 December 2019). "Setting up NTS-Secured NTP with NTPsec". Weberblog.net. Retrieved 19 August 2021. https://weberblog.net/setting-up-nts-secured-ntp-with-ntpsec/ ↩

  113. "How to use NTS | Netnod". Netnod. Retrieved 19 August 2021. https://www.netnod.se/time-and-frequency/how-to-use-nts ↩

  114. "Network Time Security · Cloudflare Time Services docs". developers.cloudflare.com. 13 August 2024. Retrieved 12 January 2025. https://developers.cloudflare.com/time-services/nts/ ↩

  115. "[MS-SNTP]: Network Time Protocol (NTP) Authentication Extensions". 24 June 2021. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sntp/8106cb73-ab3a-4542-8bc8-784dd32031cc ↩

  116. "Comparison of NTP implementations". chrony.tuxfamily.org. Retrieved 8 October 2019. https://chrony.tuxfamily.org/comparison.html ↩

  117. D. Mills; J. Burbank; W. Kasch (August 2010). J. Martin (ed.). Network Time Protocol Version 4: Protocol and Algorithms Specification. Internet Engineering Task Force. doi:10.17487/RFC5905. ISSN 2070-1721. RFC 5905. Proposed Standard. Obsoletes RFC 1305, 4330. Updated by RFC 7822, 8573 and 9109. /wiki/David_L._Mills ↩

  118. D. Mills; J. Burbank; W. Kasch (August 2010). J. Martin (ed.). Network Time Protocol Version 4: Protocol and Algorithms Specification. Internet Engineering Task Force. doi:10.17487/RFC5905. ISSN 2070-1721. RFC 5905. Proposed Standard. Obsoletes RFC 1305, 4330. Updated by RFC 7822, 8573 and 9109. /wiki/David_L._Mills ↩

  119. David L. Mills (12 May 2012). "The NTP Era and Era Numbering". Archived from the original on 26 October 2016. Retrieved 24 September 2016. https://www.eecis.udel.edu/~mills/y2k.html ↩

  120. W. Richard Stevens; Bill Fenner; Andrew M. Rudoff (2004). UNIX Network Programming. Addison-Wesley Professional. pp. 582–. ISBN 978-0-13-141155-5. Archived from the original on 30 March 2019. Retrieved 16 October 2016. 978-0-13-141155-5 ↩

  121. "A look at the Year 2036/2038 problems and time proofness in various systems". 14 March 2017. Archived from the original on 21 July 2018. Retrieved 20 July 2018. http://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/ ↩

  122. University of Delaware Digital Systems Seminar presentation by David Mills, 2006-04-26 /wiki/University_of_Delaware ↩

  123. 2−64 seconds is about 54 zeptoseconds (light would travel 16.26 picometers, or approximately 0.31 × Bohr radius), and 264 seconds is about 585 billion years. /wiki/1_E-21_s ↩