summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8633.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8633.txt')
-rw-r--r--doc/rfc/rfc8633.txt1459
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc8633.txt b/doc/rfc/rfc8633.txt
new file mode 100644
index 0000000..7e67c79
--- /dev/null
+++ b/doc/rfc/rfc8633.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) D. Reilly, Ed.
+Request for Comments: 8633 Orolia USA
+BCP: 223 H. Stenn
+Category: Best Current Practice Network Time Foundation
+ISSN: 2070-1721 D. Sibold
+ PTB
+ July 2019
+
+
+ Network Time Protocol Best Current Practices
+
+Abstract
+
+ The Network Time Protocol (NTP) is one of the oldest protocols on the
+ Internet and has been widely used since its initial publication.
+ This document is a collection of best practices for the general
+ operation of NTP servers and clients on the Internet. It includes
+ recommendations for the stable, accurate, and secure operation of NTP
+ infrastructure. This document is targeted at NTP version 4 as
+ described in RFC 5905.
+
+Status of This Memo
+
+ This memo documents an Internet Best Current Practice.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ BCPs is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8633.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reilly, et al. Best Current Practice [Page 1]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+Copyright Notice
+
+ Copyright (c) 2019 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reilly, et al. Best Current Practice [Page 2]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
+ 2. General Network Security Best Practices . . . . . . . . . . . 4
+ 2.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. NTP Configuration Best Practices . . . . . . . . . . . . . . 5
+ 3.1. Keeping NTP Up to Date . . . . . . . . . . . . . . . . . 5
+ 3.2. Using Enough Time Sources . . . . . . . . . . . . . . . . 5
+ 3.3. Using a Diversity of Reference Clocks . . . . . . . . . . 6
+ 3.4. Control Messages . . . . . . . . . . . . . . . . . . . . 7
+ 3.5. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.6. Using Pool Servers . . . . . . . . . . . . . . . . . . . 8
+ 3.7. Leap-Second Handling . . . . . . . . . . . . . . . . . . 8
+ 3.7.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 9
+ 4. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 10
+ 4.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . . . 11
+ 4.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 4.3. Network Time Security . . . . . . . . . . . . . . . . . . 11
+ 4.4. External Security Protocols . . . . . . . . . . . . . . . 12
+ 5. NTP Security Best Practices . . . . . . . . . . . . . . . . . 12
+ 5.1. Minimizing Information Leakage . . . . . . . . . . . . . 12
+ 5.2. Avoiding Daemon Restart Attacks . . . . . . . . . . . . . 13
+ 5.3. Detection of Attacks through Monitoring . . . . . . . . . 14
+ 5.4. Kiss-o'-Death Packets . . . . . . . . . . . . . . . . . . 15
+ 5.5. Broadcast Mode Only on Trusted Networks . . . . . . . . . 15
+ 5.6. Symmetric Mode Only with Trusted Peers . . . . . . . . . 16
+ 6. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 16
+ 6.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 16
+ 6.2. Server Configuration . . . . . . . . . . . . . . . . . . 17
+ 7. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 17
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
+ 10.2. Informative References . . . . . . . . . . . . . . . . . 20
+ Appendix A. Best Practices Specific to the Network Time
+ Foundation Implementation . . . . . . . . . . . . . 23
+ A.1. Use Enough Time Sources . . . . . . . . . . . . . . . . . 23
+ A.2. NTP Control and Facility Messages . . . . . . . . . . . . 23
+ A.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 24
+ A.4. Leap-Second File . . . . . . . . . . . . . . . . . . . . 24
+ A.5. Leap Smearing . . . . . . . . . . . . . . . . . . . . . . 25
+ A.6. Configuring ntpd . . . . . . . . . . . . . . . . . . . . 25
+ A.7. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . . . 25
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
+
+
+
+
+Reilly, et al. Best Current Practice [Page 3]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+1. Introduction
+
+ NTP version 4 (NTPv4) has been widely used since its publication as
+ [RFC5905]. This document is a collection of best practices for the
+ operation of NTP clients and servers.
+
+ The recommendations in this document are intended to help operators
+ distribute time on their networks more accurately and securely. They
+ are intended to apply generally to a broad range of networks. Some
+ specific networks may have higher accuracy requirements that call for
+ additional techniques beyond what is documented here.
+
+ Among the best practices covered are recommendations for general
+ network security, time protocol-specific security, and NTP server and
+ client configuration. NTP operation in embedded devices is also
+ covered.
+
+ This document also contains information for protocol implementors who
+ want to develop their own implementations compliant with RFC 5905.
+
+1.1. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+2. General Network Security Best Practices
+
+2.1. BCP 38
+
+ Many network attacks rely on modifying the IP source address of a
+ packet to point to a different IP address than the computer from
+ which it originated. UDP-based protocols, such as NTP, are generally
+ more susceptible to spoofing attacks than connection-oriented
+ protocols. NTP control messages can generate a lot of data in
+ response to a small query, which makes it attractive as a vector for
+ distributed denial-of-service attacks (NTP Control messages are
+ discussed further in Section 3.4). One documented instance of such
+ an attack can be found in [DDOS], with further discussion in [IMC14]
+ and [NDSS14].
+
+ BCP 38 [RFC2827] was published in 2000 to provide some level of
+ remediation against address-spoofing attacks. BCP 38 calls for
+ filtering outgoing and incoming traffic to make sure that the source
+ and destination IP addresses are consistent with the expected flow of
+ traffic on each network interface. It is RECOMMENDED that ISPs and
+
+
+
+Reilly, et al. Best Current Practice [Page 4]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+ large corporate networks implement ingress and egress filtering.
+ More information is available at [BCP38WIKI].
+
+3. NTP Configuration Best Practices
+
+ This section provides best practices for NTP configuration and
+ operation. Application of these best practices that are specific to
+ the Network Time Foundation implementation, including example
+ configuration directives valid at the time of this writing, are
+ compiled in Appendix A.
+
+3.1. Keeping NTP Up to Date
+
+ There are multiple versions and implementations of the NTP protocol
+ in use on many different platforms. The practices in this document
+ are meant to apply generally to any implementation of [RFC5905]. NTP
+ users should select an implementation that is actively maintained.
+ Users should keep up to date on any known attacks on their selected
+ implementation and deploy updates containing security fixes as soon
+ as it is practical.
+
+3.2. Using Enough Time Sources
+
+ An NTP implementation that is compliant with [RFC5905] takes the
+ available sources of time and submits this timing data to
+ sophisticated intersection, clustering, and combining algorithms to
+ get the best estimate of the correct time. The description of these
+ algorithms is beyond the scope of this document. Interested readers
+ should read [RFC5905] or the detailed description of NTP in
+ [MILLS2006].
+
+ o If there is only one source of time, the answer is obvious. It
+ may not be a good source of time, but it's the only source that
+ can be considered. Any issue with the time at the source will be
+ passed on to the client.
+
+ o If there are two sources of time and they align well enough, then
+ the best time can be calculated easily. But if one source fails,
+ then the solution degrades to the single-source solution outlined
+ above. And if the two sources don't agree, it will be difficult
+ to know which one is correct without making use of information
+ from outside of the protocol.
+
+ o If there are three sources of time, there is more data available
+ to converge on the best calculated time, and this time is more
+ likely to be accurate. And the loss of one of the sources (by
+ becoming unreachable or unusable) can be tolerated. But at that
+ point, the solution degrades to the two-source solution.
+
+
+
+Reilly, et al. Best Current Practice [Page 5]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+ o Having four or more sources of time is better as long as the
+ sources are diverse (Section 3.3). If one of these sources
+ develops a problem, there are still at least three other time
+ sources.
+
+ This analysis assumes that a majority of the servers used in the
+ solution are honest, even if some may be inaccurate. Operators
+ should be aware of the possibility that if an attacker is in control
+ of the network, the time coming from all servers could be
+ compromised.
+
+ Operators who are concerned with maintaining accurate time SHOULD use
+ at least four independent, diverse sources of time. Four sources
+ will provide sufficient backup in case one source goes down. If four
+ sources are not available, operators MAY use fewer sources, which is
+ subject to the risks outlined above.
+
+ But even with four or more sources of time, systemic problems can
+ happen. One example involves the leap-smearing concept detailed in
+ Section 3.7.1. For several hours before and after the June 2015 leap
+ second, several operators configured their NTP servers with leap
+ smearing while others did not. Many NTP end nodes could not
+ determine an accurate time source because two of their four sources
+ of time gave them consistent UTC/POSIX time, while the other two gave
+ them consistent leap-smeared time. This is just one of many
+ potential causes of disagreement among time sources.
+
+ Operators are advised to monitor all time sources that are in use.
+ If time sources do not generally align, operators are encouraged to
+ investigate the cause and either correct the problems or stop using
+ defective servers. See Section 3.5 for more information.
+
+3.3. Using a Diversity of Reference Clocks
+
+ When using servers with attached hardware reference clocks, it is
+ suggested that different types of reference clocks be used. Having a
+ diversity of sources with independent implementations means that any
+ one issue is less likely to cause a service interruption.
+
+ Are all clocks on a network from the same vendor? They may have the
+ same bugs. Even devices from different vendors may not be truly
+ independent if they share common elements. Are they using the same
+ base chipset? Are they all running the same version of firmware?
+ Chipset and firmware bugs can happen, but they can be more difficult
+ to diagnose than application software bugs. When having the correct
+ time is of critical importance, it's ultimately up to operators to
+ ensure that their sources are sufficiently independent, even if they
+ are not under the operator's control.
+
+
+
+Reilly, et al. Best Current Practice [Page 6]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+ A systemic problem with time from any satellite navigation service is
+ possible and has happened. Sunspot activity can render a satellite
+ or radio-based time source unusable. Depending on the application
+ requirements, operators may need to consider backup scenarios in the
+ rare circumstance when the satellite system is faulty or unavailable.
+
+3.4. Control Messages
+
+ Some implementations of NTPv4 provide the NTP control messages (also
+ known as Mode 6 messages). These messages were originally specified
+ in Appendix B of [RFC1305], which defined NTPv3. These messages do
+ not appear in the NTPv4 specification [RFC5905], which obsoletes the
+ NTPv3 specification [RFC1305], but they are still used. At the time
+ of this writing, work is being done to formally document the
+ structure of these control messages for use with NTPv4 in [CTRLMSG].
+
+ NTP control messages are designed to permit monitoring and optionally
+ authenticated control of NTP and its configuration. Used properly,
+ these facilities provide vital debugging and performance information
+ and control. But these facilities can be a vector for amplification
+ attacks when abused. For this reason, it is RECOMMENDED that public-
+ facing NTP servers block NTP control message queries from outside
+ their organization.
+
+ The ability to use NTP control messages beyond their basic monitoring
+ capabilities SHOULD be limited to authenticated sessions that provide
+ a 'controlkey'. It can also be limited through mechanisms outside of
+ the NTP specification, such as Access Control Lists, that only allow
+ access from approved IP addresses.
+
+ The NTP control message responses are much larger than the
+ corresponding queries. Thus, they can be abused in high-bandwidth
+ DDoS attacks. Section 2.1 gives more information on how to provide
+ protection for this abuse by implementing BCP 38.
+
+3.5. Monitoring
+
+ Operators SHOULD use their NTP implementation's remote monitoring
+ capabilities to quickly identify servers that are out of sync and
+ ensure correct functioning of the service. Operators SHOULD also
+ monitor system logs for messages so that problems and abuse attempts
+ can be quickly identified.
+
+ If a system starts to receive NTP Reply packets from a remote time
+ server that do not correspond to any requests sent by the system,
+ that can be an indication that an attacker is forging that system's
+ IP address in requests to the remote time server. The goal of this
+ attack is to adversely impact the availability of time to the
+
+
+
+Reilly, et al. Best Current Practice [Page 7]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+ targeted system whose address is being forged. Based on these forged
+ packets, the remote time server might decide to throttle or rate-
+ limit packets or even stop sending packets to the targeted system.
+
+ If a system is a broadcast client and its system log shows that it is
+ receiving early time messages from its server, that is an indication
+ that somebody may be forging packets from a broadcast server
+ (broadcast client and server modes are defined in Section 3 of
+ [RFC5905]).
+
+ If a server's system log shows messages that indicate it is receiving
+ NTP timestamps that are much earlier than the current system time,
+ then either the system clock is unusually fast or somebody is trying
+ to launch a replay attack against that server.
+
+3.6. Using Pool Servers
+
+ It only takes a small amount of bandwidth and system resources to
+ synchronize one NTP client, but NTP servers that can service tens of
+ thousands of clients take more resources to run. Network operators
+ and advanced users who want to synchronize their computers MUST only
+ synchronize to servers that they have permission to use.
+
+ The NTP Pool Project is a group of volunteers who have donated their
+ computing and bandwidth resources to freely distribute time from
+ primary time sources to others on the Internet. The time is
+ generally of good quality but comes with no guarantee whatsoever. If
+ you are interested in using this pool, please review their
+ instructions at [POOLUSE].
+
+ Vendors can obtain their own subdomain that is part of the NTP Pool
+ Project. This offers vendors the ability to safely make use of the
+ time distributed by the pool for their devices. Details are
+ available at [POOLVENDOR].
+
+ If there is a need to synchronize many computers, an operator may
+ want to run local NTP servers that are synchronized to the NTP Pool
+ Project. NTP users on that operator's networks can then be
+ synchronized to local NTP servers.
+
+3.7. Leap-Second Handling
+
+ UTC is kept in agreement with the Universal Time UT1 [SOLAR] to
+ within +/- 0.9 seconds by the insertion (or possibly deletion) of a
+ leap second. UTC is an atomic time scale, whereas UT1 is based on
+ the rotational rate of the earth. Leap seconds are not introduced at
+
+
+
+
+
+Reilly, et al. Best Current Practice [Page 8]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+ a fixed rate. They are announced by the International Earth Rotation
+ and Reference Systems Service (IERS) in its Bulletin C [IERS] when
+ necessary to keep UTC and UT1 aligned.
+
+ NTP time is based on the UTC timescale, and the protocol has the
+ capability to broadcast leap-second information. Some global
+ navigation satellite systems (like GPS) or radio transmitters (like
+ DCF77) broadcast leap-second information. If an NTP client is synced
+ to an NTP server that provides leap-second notification, the client
+ will get advance notification of impending leap seconds
+ automatically.
+
+ Since the length of the UT1 day generally slowly increases [SOLAR],
+ all leap seconds that have been introduced since the practice started
+ in 1972 have been positive leap seconds, where a second is added to
+ UTC. NTP also supports a negative leap second, where a second is
+ removed from UTC if it ever becomes necessary.
+
+ While earlier versions of NTP contained some ambiguity regarding when
+ a leap second broadcast by a server should be applied by a client,
+ RFC 5905 is clear that leap seconds are only applied on the last day
+ of a month. However, because some older clients may apply it at the
+ end of the current day, it is RECOMMENDED that NTP servers wait until
+ the last day of the month before broadcasting leap seconds. Doing
+ this will prevent older clients from applying a leap second at the
+ wrong time. When implementing this recommendation, operators should
+ ensure that clients are not configured to use polling intervals
+ greater than 24 hours so the leap-second notification is not missed.
+
+ In circumstances where an NTP server is not receiving leap-second
+ information from an automated source, certain organizations maintain
+ files that are updated every time a new leap second is announced:
+
+ NIST: <ftp://time.nist.gov/pub/leap-seconds.list>
+
+ US Navy (maintains GPS Time):
+ <ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.list>
+
+ IERS (announces leap seconds):
+ <https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list>
+
+3.7.1. Leap Smearing
+
+ Some NTP installations make use of a technique called leap smearing.
+ With this method, instead of introducing an extra second (or
+ eliminating a second) in a leap-second event, NTP time is adjusted in
+ small increments over a comparably large window of time (called the
+ smear interval) around the leap-second event. The smear interval
+
+
+
+Reilly, et al. Best Current Practice [Page 9]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+ should be large enough for the time to be adjusted at a low rate, so
+ that clients will follow the smeared time without objecting. Periods
+ ranging from two to twenty-four hours have been used successfully.
+ During the adjustment window, all the NTP clients' times may be
+ offset from UTC by as much as a full second, depending on the
+ implementation. However, all clients will generally agree on what
+ time they think it is.
+
+ The purpose of leap smearing is to enable systems that don't deal
+ with the leap-second event properly to function consistently, at the
+ expense of fidelity to UTC during the smear window. During a
+ standard leap-second event, a minute will have 61 (or possibly 59)
+ seconds, and some applications (and even some OSs) are known to have
+ problems with that.
+
+ Operators who have legal obligations or other strong requirements to
+ be synchronized with UTC or civil time SHOULD NOT use leap smearing
+ because the distributed time cannot be guaranteed to be traceable to
+ UTC during the smear interval.
+
+ Clients that are connected to leap-smearing servers MUST NOT apply
+ the standard NTP leap-second handling. These clients must never have
+ a leap-second file loaded, and the smearing servers must never
+ advertise to clients for which a leap second is pending.
+
+ Any use of leap-smearing servers should be limited to within a
+ single, well-controlled environment. Leap smearing MUST NOT be used
+ for public-facing NTP servers, as they will disagree with non-
+ smearing servers (as well as UTC) during the leap smear interval, and
+ there is no standardized way for a client to detect that a server is
+ using leap smearing. However, be aware that some public-facing
+ servers may be configured this way in spite of this guidance.
+
+ System administrators are advised to be aware of impending leap
+ seconds and how the servers (inside and outside their organization)
+ they are using deal with them. Individual clients MUST NOT be
+ configured to use a mixture of smeared and non-smeared servers. If a
+ client uses smeared servers, the servers it uses must all have the
+ same leap smear configuration.
+
+4. NTP Security Mechanisms
+
+ In the standard configuration, NTP packets are exchanged unprotected
+ between client and server. An adversary that is able to become a man
+ in the middle is therefore able to drop, replay, or modify the
+ content of the NTP packet, which leads to degradation of the time
+ synchronization or transmission of false time information. A threat
+ analysis for time-synchronization protocols is given in [RFC7384].
+
+
+
+Reilly, et al. Best Current Practice [Page 10]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+ NTP provides two internal security mechanisms to protect the
+ authenticity and integrity of the NTP packets. Both measures protect
+ the NTP packet by means of a Message Authentication Code (MAC).
+ Neither of them encrypts the NTP's payload because this payload
+ information is not considered to be confidential.
+
+4.1. Pre-Shared Key Approach
+
+ This approach applies a symmetric key for the calculation of the MAC,
+ which protects the authenticity and integrity of the exchanged
+ packets for an association. NTP does not provide a mechanism for the
+ exchange of keys between the associated nodes. Therefore, for each
+ association, keys MUST be exchanged securely by external means, and
+ they MUST be protected from disclosure. It is RECOMMENDED that each
+ association be protected by its own unique key. It is RECOMMENDED
+ that participants agree to refresh keys periodically. However, NTP
+ does not provide a mechanism to assist in doing so. Each
+ communication partner will need to keep track of its keys in its own
+ local key storage.
+
+ [RFC5905] specifies using the MD5 hash algorithm for calculation of
+ the MAC, but other algorithms may be supported as well. The MD5 hash
+ is now considered to be too weak and unsuitable for cryptographic
+ usage. [RFC6151] has more information on the algorithm's weaknesses.
+ Implementations will soon be available based on AES-128-CMAC
+ [RFC8573], and users SHOULD use that when it is available.
+
+ Some implementations store the key in clear text. Therefore, it MUST
+ only be readable by the NTP process.
+
+ An NTP client has to be able to link a key to a particular server in
+ order to establish a protected association. This linkage is
+ implementation specific. Once applied, a key will be trusted until
+ the link is removed.
+
+4.2. Autokey
+
+ [RFC5906] specifies the Autokey protocol. It was published in 2010
+ to provide automated key management and authentication of NTP
+ servers. However, security researchers have identified
+ vulnerabilities [AUTOKEY] in the Autokey protocol.
+
+ Autokey SHOULD NOT be used.
+
+4.3. Network Time Security
+
+ Work is in progress on an enhanced replacement for Autokey. Refer to
+ [NTSFORNTP] for more information.
+
+
+
+Reilly, et al. Best Current Practice [Page 11]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+4.4. External Security Protocols
+
+ If applicable, external security protocols such as IPsec and MACsec
+ can be applied to enhance the integrity and authenticity protection
+ of NTP time-synchronization packets. Usage of such external security
+ protocols can decrease time-synchronization performance [RFC7384].
+ Therefore, operators are advised to carefully evaluate whether the
+ decreased time-synchronization performance meets their specific
+ timing requirements.
+
+ Note that none of the security measures described in Section 4 can
+ prevent packet delay manipulation attacks on NTP. Such delay attacks
+ can target time-synchronization packets sent as clear text or even
+ within an encrypted tunnel. These attacks are described further in
+ Section 3.2.6 of [RFC7384].
+
+5. NTP Security Best Practices
+
+ This section lists some general NTP security practices, but these
+ issues may (or may not) have been mitigated in particular versions of
+ particular implementations. Contact the maintainers of the relevant
+ implementation for more information.
+
+5.1. Minimizing Information Leakage
+
+ The base NTP packet leaks important information (including reference
+ ID and reference time) that may be used in attacks [NDSS16]
+ [CVE-2015-8138] [CVE-2016-1548]. A remote attacker can learn this
+ information by sending mode 3 queries to a target system and
+ inspecting the fields in the mode 4 response packet. NTP control
+ queries also leak important information (including reference ID,
+ expected origin timestamp, etc.) that may be used in attacks
+ [CVE-2015-8139]. A remote attacker can learn this information by
+ sending control queries to a target system and inspecting the leaked
+ information in the response.
+
+ As such, mechanisms outside of the NTP protocol, such as Access
+ Control Lists, SHOULD be used to limit the exposure of this
+ information to allowed IP addresses and keep it from remote attackers
+ not on the list. Hosts SHOULD only respond to NTP control queries
+ from authorized parties.
+
+ An NTP client that does not provide time on the network can
+ additionally log and drop incoming mode 3 timing queries from
+ unexpected sources. Note well that the easiest way to monitor the
+ status of an NTP instance is to send it a mode 3 query, so it may not
+ be desirable to drop all mode 3 queries. As an alternative,
+ operators SHOULD either filter mode 3 queries from outside their
+
+
+
+Reilly, et al. Best Current Practice [Page 12]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+ networks or make sure mode 3 queries are allowed only from trusted
+ systems or networks.
+
+ A "leaf-node host" is a host that uses NTP solely for the purpose of
+ adjusting its own system time. Such a host is not expected to
+ provide time to other hosts and relies exclusively on NTP's basic
+ mode to take time from a set of servers (that is, the host sends mode
+ 3 queries to its servers and receives mode 4 responses from these
+ servers containing timing information.) To minimize information
+ leakage, leaf-node hosts SHOULD drop all incoming NTP packets except
+ mode 4 response packets that come from known sources. An exception
+ to this can be made if a leaf-node host is being actively monitored,
+ in which case incoming packets from the monitoring server can be
+ allowed.
+
+ Please refer to [DATAMIN] for more information.
+
+5.2. Avoiding Daemon Restart Attacks
+
+ [RFC5905] says NTP clients should not accept time shifts greater than
+ the panic threshold. Specifically, RFC 5905 says "PANIC means the
+ offset is greater than the panic threshold PANICT (1000 s) and SHOULD
+ cause the program to exit with a diagnostic message to the system
+ log."
+
+ However, this behavior can be exploited by attackers as described in
+ [NDSS16] when the following two conditions hold:
+
+ 1. The operating system automatically restarts the NTP client when
+ it quits. Modern UNIX and UNIX-like operating systems are
+ replacing traditional init systems with process supervisors, such
+ as systemd, which can be configured to automatically restart any
+ daemons that quit. This behavior is the default in CoreOS and
+ Arch Linux. As of the time of this writing, it appears likely to
+ become the default behavior in other systems as they migrate
+ legacy init scripts to process supervisors such as systemd.
+
+ 2. The NTP client is configured to ignore the panic threshold on all
+ restarts.
+
+ In such cases, if the attacker can send the target an offset that
+ exceeds the panic threshold, the client will quit. Then, when it
+ restarts, it ignores the panic threshold and accepts the attacker's
+ large offset.
+
+ Operators need to be aware that when operating with the above two
+ conditions, the panic threshold offers no protection from attacks.
+ The natural solution is not to run hosts with these conditions.
+
+
+
+Reilly, et al. Best Current Practice [Page 13]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+ Specifically, operators SHOULD NOT ignore the panic threshold in all
+ cold-start situations unless sufficient oversight and checking is in
+ place to make sure that this type of attack cannot happen.
+
+ As an alternative, the following steps MAY be taken by operators to
+ mitigate the risk of attack:
+
+ o Monitor the NTP system log to detect when the NTP daemon quit due
+ to a panic event, as this could be a sign of an attack.
+
+ o Request manual intervention when a timestep larger than the panic
+ threshold is detected.
+
+ o Configure the ntp client to only ignore the panic threshold in a
+ cold-start situation.
+
+ o Increase the minimum number of servers required before the NTP
+ client adjusts the system clock. This will make the NTP client
+ wait until enough trusted sources of time agree before declaring
+ the time to be correct.
+
+ In addition, the following steps SHOULD be taken by those who
+ implement the NTP protocol:
+
+ o Prevent the NTP daemon from taking time steps that set the clock
+ to a time earlier than the compile date of the NTP daemon.
+
+ o Prevent the NTP daemon from putting 'INIT' in the reference ID of
+ its NTP packets upon initializing. This will make it more
+ difficult for attackers to know when the daemon reboots.
+
+5.3. Detection of Attacks through Monitoring
+
+ Operators SHOULD monitor their NTP instances to detect attacks. Many
+ known attacks on NTP have particular signatures. Common attack
+ signatures include:
+
+ 1. Bogus packets - A packet whose origin timestamp does not match
+ the value that is expected by the client.
+
+ 2. Zero origin packet - A packet with an origin timestamp set to
+ zero [CVE-2015-8138].
+
+ 3. A packet with an invalid cryptographic MAC.
+
+ The observation of many such packets could indicate that the client
+ is under attack.
+
+
+
+
+Reilly, et al. Best Current Practice [Page 14]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+5.4. Kiss-o'-Death Packets
+
+ The "Kiss-o'-Death" (KoD) packet includes a rate-management mechanism
+ where a server can tell a misbehaving client to reduce its query
+ rate. KoD packets in general (and the RATE packet in particular) are
+ defined in Section 7.4 of [RFC5905]. It is RECOMMENDED that all NTP
+ devices respect these packets and back off when asked to do so by a
+ server. This is even more important for an embedded device, which
+ may not have an exposed control interface for NTP.
+
+ That said, a client MUST only accept a KoD packet if it has a valid
+ origin timestamp. Once a RATE packet is accepted, the client should
+ increase its poll interval value (thus decreasing its polling rate)
+ to a reasonable maximum. This maximum can vary by implementation but
+ should not exceed a poll interval value of 13 (two hours). The
+ mechanism to determine how much to increase the poll interval value
+ is undefined in [RFC5905]. If the client uses the poll interval
+ value sent by the server in the RATE packet, it MUST NOT simply
+ accept any value. Using large interval values may create a vector
+ for a denial-of-service attack that causes the client to stop
+ querying its server [NDSS16].
+
+ The KoD rate-management mechanism relies on clients behaving properly
+ in order to be effective. Some clients ignore the RATE packet
+ entirely, and other poorly implemented clients might unintentionally
+ increase their poll rate and simulate a denial-of-service attack.
+ Server administrators are advised to be prepared for this and take
+ measures outside of the NTP protocol to drop packets from misbehaving
+ clients when these clients are detected.
+
+ Kiss-o'-Death (KoD) packets can be used in denial-of-service attacks.
+ Thus, the observation of even just one RATE packet with a high poll
+ value could be sign that the client is under attack. And KoD packets
+ are commonly accepted even when not cryptographically authenticated,
+ which increases the risk of denial-of-service attacks.
+
+5.5. Broadcast Mode Only on Trusted Networks
+
+ Per [RFC5905], NTP's broadcast mode is authenticated using symmetric
+ key cryptography. The broadcast server and all its broadcast clients
+ share a symmetric cryptographic key, and the broadcast server uses
+ this key to append a MAC to the broadcast packets it sends.
+
+ Importantly, all broadcast clients that listen to this server have to
+ know the cryptographic key. This means that any client can use this
+ key to send valid broadcast messages that look like they come from
+ the broadcast server. Thus, a rogue broadcast client can use its
+ knowledge of this key to attack the other broadcast clients.
+
+
+
+Reilly, et al. Best Current Practice [Page 15]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+ For this reason, an NTP broadcast server and all its clients have to
+ trust each other. Broadcast mode SHOULD only be run from within a
+ trusted network.
+
+5.6. Symmetric Mode Only with Trusted Peers
+
+ In symmetric mode, two peers, Alice and Bob, can both push and pull
+ synchronization to and from each other using either ephemeral
+ symmetric passive (mode 2) or persistent symmetric active (NTP mode
+ 1) packets. The persistent association is preconfigured and
+ initiated at the active peer but is not preconfigured at the passive
+ peer (Bob). Upon receipt of a mode 1 NTP packet from Alice, Bob
+ mobilizes a new ephemeral association if he does not have one
+ already. This is a security risk for Bob because an arbitrary
+ attacker can attempt to change Bob's time by asking Bob to become its
+ symmetric passive peer.
+
+ For this reason, a host SHOULD only allow symmetric passive
+ associations to be established with trusted peers. Specifically, a
+ host SHOULD require each of its symmetric passive associations to be
+ cryptographically authenticated. Each symmetric passive association
+ SHOULD be authenticated under a different cryptographic key.
+
+6. NTP in Embedded Devices
+
+ As computing becomes more ubiquitous, there will be many small
+ embedded devices that require accurate time. These devices may not
+ have a persistent battery-backed clock, so using NTP to set the
+ correct time on power-up may be critical for proper operation. These
+ devices may not have a traditional user interface, but if they
+ connect to the Internet, they will be subject to the same security
+ threats as traditional deployments.
+
+6.1. Updating Embedded Devices
+
+ Vendors of embedded devices are advised to pay attention to the
+ current state of protocol security issues and bugs in their chosen
+ implementation because their customers don't have the ability to
+ update their NTP implementation on their own. Those devices may have
+ a single firmware upgrade, provided by the manufacturer, that updates
+ all capabilities at once. This means that the vendor assumes the
+ responsibility of making sure their devices have an up-to-date and
+ secure NTP implementation.
+
+ Vendors of embedded devices SHOULD include the ability to update the
+ list of NTP servers used by the device.
+
+
+
+
+
+Reilly, et al. Best Current Practice [Page 16]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+ There is a catalog of NTP server abuse incidents, some of which
+ involve embedded devices, on the Wikipedia page for NTP Server Misuse
+ and Abuse [MISUSE].
+
+6.2. Server Configuration
+
+ Vendors of embedded devices with preconfigured NTP servers need to
+ carefully consider which servers to use. There are several public-
+ facing NTP servers available, but they may not be prepared to service
+ requests from thousands of new devices on the Internet. Vendors MUST
+ only preconfigure NTP servers that they have permission to use.
+
+ Vendors are encouraged to invest resources into providing their own
+ time servers for their devices to connect to. This may be done
+ through the NTP Pool Project, as documented in Section 3.6.
+
+ Vendors should read [RFC4085], which advises against embedding
+ globally routable IP addresses in products and offers several better
+ alternatives.
+
+7. NTP over Anycast
+
+ Anycast is described in BCP 126 [RFC4786] (see also [RFC7094]). With
+ anycast, a single IP address is assigned to multiple servers, and
+ routers direct packets to the closest active server.
+
+ Anycast is often used for Internet services at known IP addresses,
+ such as DNS. Anycast can also be used in large organizations to
+ simplify the configuration of many NTP clients. Each client can be
+ configured with the same NTP server IP address, and a pool of anycast
+ servers can be deployed to service those requests. New servers can
+ be added to or taken from the pool, and other than a temporary loss
+ of service while a server is taken down, these additions can be
+ transparent to the clients.
+
+ Note well that using a single anycast address for NTP presents its
+ own potential issues. It means each client will likely use a single
+ time server source. A key element of a robust NTP deployment is each
+ client using multiple sources of time. With multiple time sources, a
+ client will analyze the various time sources, select good ones, and
+ disregard poor ones. If a single anycast address is used, this
+ analysis will not happen. This can be mitigated by creating
+ multiple, separate anycast pools so clients can have multiple sources
+ of time while still gaining the configuration benefits of the anycast
+ pools.
+
+
+
+
+
+
+Reilly, et al. Best Current Practice [Page 17]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+ If clients are connected to an NTP server via anycast, the client
+ does not know which particular server they are connected to. As
+ anycast servers enter and leave the network or the network topology
+ changes, the server to which a particular client is connected may
+ change. This may cause a small shift in time from the perspective of
+ the client when the server to which it is connected changes. Extreme
+ cases where the network topology changes rapidly could cause the
+ server seen by a client to rapidly change as well, which can lead to
+ larger time inaccuracies. It is RECOMMENDED that network operators
+ only deploy anycast NTP in environments where operators know these
+ small shifts can be tolerated by the applications running on the
+ clients being synchronized in this manner.
+
+ Configuration of an anycast interface is independent of NTP. Clients
+ will always connect to the closest server, even if that server is
+ having NTP issues. It is RECOMMENDED that anycast NTP
+ implementations have an independent method of monitoring the
+ performance of NTP on a server. If the server is not performing to
+ specification, it should remove itself from the anycast network. It
+ is also RECOMMENDED that each anycast NTP server have an alternative
+ method of access, such as an alternate unicast IP address, so its
+ performance can be checked independently of the anycast routing
+ scheme.
+
+ One useful application in large networks is to use a hybrid unicast/
+ anycast approach. Stratum 1 NTP servers can be deployed with unicast
+ interfaces at several sites. Each site may have several Stratum 2
+ servers with two Ethernet interfaces or a single interface that can
+ support multiple addresses. One interface has a unique unicast IP
+ address. The second has an anycast IP interface (with a shared IP
+ address per location). The unicast interfaces can be used to obtain
+ time from the Stratum 1 servers globally (and perhaps peer with the
+ other Stratum 2 servers at their site). Clients at each site can be
+ configured to use the shared anycast address for their site,
+ simplifying their configuration. Keeping the anycast routing
+ restricted on a per-site basis will minimize the disruption at the
+ client if its closest anycast server changes. Each Stratum 2 server
+ can be uniquely identified on their unicast interface to make
+ monitoring easier.
+
+8. IANA Considerations
+
+ This document has no IANA actions.
+
+
+
+
+
+
+
+
+Reilly, et al. Best Current Practice [Page 18]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+9. Security Considerations
+
+ Time is a fundamental component of security on the Internet. The
+ absence of a reliable source of current time subverts many common web
+ authentication schemes, e.g., by allowing the use of expired
+ credentials or allowing the replay of messages only intended to be
+ processed once.
+
+ Much of this document directly addresses how to secure NTP servers.
+ In particular, see Section 2, Section 4, and Section 5.
+
+ There are several general threats to time-synchronization protocols,
+ which are discussed in [RFC7384].
+
+ [NTSFORNTP] specifies the Network Time Security (NTS) mechanism and
+ applies it to NTP. Readers are encouraged to check the status of the
+ document and make use of the methods it describes.
+
+10. References
+
+10.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
+ Defeating Denial of Service Attacks which employ IP Source
+ Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
+ May 2000, <https://www.rfc-editor.org/info/rfc2827>.
+
+ [RFC4085] Plonka, D., "Embedding Globally-Routable Internet
+ Addresses Considered Harmful", BCP 105, RFC 4085,
+ DOI 10.17487/RFC4085, June 2005,
+ <https://www.rfc-editor.org/info/rfc4085>.
+
+ [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
+ Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
+ December 2006, <https://www.rfc-editor.org/info/rfc4786>.
+
+ [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
+ "Network Time Protocol Version 4: Protocol and Algorithms
+ Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
+ <https://www.rfc-editor.org/info/rfc5905>.
+
+
+
+
+
+
+Reilly, et al. Best Current Practice [Page 19]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+10.2. Informative References
+
+ [AUTOKEY] Roettger, S., "Autokey-Protocol Analysis", August 2011,
+ <https://lists.ntp.org/pipermail/
+ ntpwg/2011-August/001714.html>.
+
+ [BCP38WIKI]
+ "BCP38.info Wiki", October 2016, <http://www.bcp38.info>.
+
+ [CCR16] Malhotra, A. and S. Goldberg, "Attacking NTP's
+ Authenticated Broadcast Mode", SIGCOMM Computer
+ Communications Review (CCR) Volume 46, Issue 2,
+ DOI 10.1145/2935634.2935637, April 2016.
+
+ [CONFIGNTP]
+ Network Time Foundation, "Configuring NTP", November 2018,
+ <https://support.ntp.org/bin/view/Support/ConfiguringNTP>.
+
+ [CTRLMSG] Haberman, B., Ed., "Control Messages Protocol for Use with
+ Network Time Protocol Version 4", Work in Progress,
+ draft-ietf-ntp-mode-6-cmds-06, September 2018.
+
+ [CVE-2015-8138]
+ Van Gundy, M. and J. Gardner, "Network Time Protocol
+ Origin Timestamp Check Impersonation Vulnerability",
+ January 2016,
+ <https://www.talosintel.com/reports/TALOS-2016-0077>.
+
+ [CVE-2015-8139]
+ Van Gundy, M., "Network Time Protocol ntpq and ntpdc
+ Origin Timestamp Disclosure Vulnerability", January 2016,
+ <https://www.talosintel.com/reports/TALOS-2016-0078>.
+
+ [CVE-2016-1548]
+ Gardner, J. and M. Lichvar, "Xleave Pivot: NTP Basic Mode
+ to Interleaved", April 2016,
+ <https://blog.talosintel.com/2016/04/
+ vulnerability-spotlight-further-ntpd_27.html>.
+
+ [DATAMIN] Franke, D. and A. Malhotra, "NTP Client Data
+ Minimization", Work in Progress, draft-ietf-ntp-data-
+ minimization-04, March 2019.
+
+
+
+
+
+Reilly, et al. Best Current Practice [Page 20]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+ [DDOS] Prince, M., "Technical Details Behind a 400Gbps NTP
+ Amplification DDoS Attack", February 2014,
+ <https://blog.cloudflare.com/technical-details-behind-a-
+ 400gbps-ntp-amplification-ddos-attack>.
+
+ [IERS] IERS, "IERS Bulletins",
+ <https://www.iers.org/IERS/EN/Publications/Bulletins/
+ bulletins.html>.
+
+ [IMC14] Czyz, J., Kallitsis, M., Gharaibeh, M., Papadopoulos, C.,
+ Bailey, M., and M. Karir, "Taming the 800 Pound Gorilla:
+ The Rise and Decline of NTP DDoS Attacks", Proceedings of
+ the 2014 Internet Measurement Conference,
+ DOI 10.1145/2663716.2663717, November 2014.
+
+ [LEAPSEC] Burnicki, M., "Leap Second Smearing", <http://bk1.ntp.org/
+ ntp-stable/README.leapsmear?PAGE=anno>.
+
+ [MILLS2006]
+ Mills, D., "Computer network time synchronization: the
+ Network Time Protocol", CRC Press, 2006.
+
+ [MISUSE] Wikipedia, "NTP Server Misuse and Abuse", May 2019,
+ <https://en.wikipedia.org/w/index.php?
+ title=NTP_server_misuse_and_abuse&oldid=899024751>.
+
+ [NDSS14] Rossow, C., "Amplification Hell: Revisiting Network
+ Protocols for DDoS Abuse", Network and Distributed System
+ Security (NDSS) Symposium 2014,
+ DOI 10.14722/ndss.2014.23233, February 2014,
+ <https://www.ndss-symposium.org/ndss2014/programme/
+ amplification-hell-revisiting-network-protocols-ddos-
+ abuse/>.
+
+ [NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg,
+ "Attacking the Network Time Protocol", Network and
+ Distributed System Security (NDSS) Symposium 2016,
+ DOI 10.14722/ndss.2016.23090, February 2016,
+ <https://eprint.iacr.org/2015/1020.pdf>.
+
+ [NTPDOWN] Network Time Foundation, "NTP Software Downloads",
+ <http://www.ntp.org/downloads.html>.
+
+ [NTSFORNTP]
+ Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
+ Sundblad, "Network Time Security for the Network Time
+ Protocol", Work in Progress, draft-ietf-ntp-using-nts-for-
+ ntp-20, July 2019.
+
+
+
+Reilly, et al. Best Current Practice [Page 21]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+ [POOLUSE] NTP Pool Project, "Use the Pool",
+ <https://www.pool.ntp.org/en/use.html>.
+
+ [POOLVENDOR]
+ NTP Pool Project, "The NTP Pool for Vendors",
+ <https://www.pool.ntp.org/en/vendors.html>.
+
+ [RFC1305] Mills, D., "Network Time Protocol (Version 3)
+ Specification, Implementation and Analysis", RFC 1305,
+ DOI 10.17487/RFC1305, March 1992,
+ <https://www.rfc-editor.org/info/rfc1305>.
+
+ [RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol
+ Version 4: Autokey Specification", RFC 5906,
+ DOI 10.17487/RFC5906, June 2010,
+ <https://www.rfc-editor.org/info/rfc5906>.
+
+ [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
+ for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
+ RFC 6151, DOI 10.17487/RFC6151, March 2011,
+ <https://www.rfc-editor.org/info/rfc6151>.
+
+ [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
+ "Architectural Considerations of IP Anycast", RFC 7094,
+ DOI 10.17487/RFC7094, January 2014,
+ <https://www.rfc-editor.org/info/rfc7094>.
+
+ [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
+ Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
+ October 2014, <https://www.rfc-editor.org/info/rfc7384>.
+
+ [RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code
+ for the Network Time Protocol", RFC 8573,
+ DOI 10.17487/RFC8573, June 2019,
+ <https://www.rfc-editor.org/info/rfc8573>.
+
+ [SOLAR] Wikipedia, "Solar Time", May 2019,
+ <https://en.wikipedia.org/w/index.php?
+ title=Solar_time&oldid=896601472#Mean_solar_time>.
+
+
+
+
+
+
+
+
+
+
+
+
+Reilly, et al. Best Current Practice [Page 22]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+Appendix A. Best Practices Specific to the Network Time Foundation
+ Implementation
+
+ The Network Time Foundation (NTF) provides a widely used
+ implementation of NTP, known as ntpd [NTPDOWN]. It is an evolution
+ of the first NTP implementations developed by David Mills at the
+ University of Delaware. This appendix contains additional
+ recommendations specific to this implementation that are valid at the
+ time of this writing.
+
+A.1. Use Enough Time Sources
+
+ In addition to the recommendation given in Section 3.2, the ntpd
+ implementation provides the 'pool' directive. Starting with ntp-
+ 4.2.6, using this directive in the ntp.conf file will spin up enough
+ associations to provide robust time service and will disconnect poor
+ servers and add in new servers as needed. The 'minclock' and
+ 'maxclock' options of the 'tos' command may be used to override the
+ default values of how many servers are discovered through the 'pool'
+ directive.
+
+A.2. NTP Control and Facility Messages
+
+ In addition to NTP control messages, the ntpd implementation also
+ offers the Mode 7 commands for monitoring and configuration.
+
+ If Mode 7 has been explicitly enabled to be used for more than basic
+ monitoring, it should be limited to authenticated sessions that
+ provide a 'requestkey'.
+
+ As mentioned above, there are two general ways to use Mode 6 and Mode
+ 7 requests. One way is to query ntpd for information, and this mode
+ can be disabled with:
+
+ restrict ... noquery
+
+ The second way to use Mode 6 and Mode 7 requests is to modify ntpd's
+ behavior. Modification of ntpd's configuration requires an
+ authenticated session by default. If no authentication keys have
+ been specified, no modifications can be made. For additional
+ protection, the ability to perform these modifications can be
+ controlled with:
+
+ restrict ... nomodify
+
+
+
+
+
+
+
+Reilly, et al. Best Current Practice [Page 23]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+ Users can prevent their NTP servers from considering query/
+ configuration traffic by default by adding the following to their
+ ntp.conf file:
+
+ restrict default -4 nomodify notrap nopeer noquery
+
+ restrict default -6 nomodify notrap nopeer noquery
+
+ restrict source nomodify notrap noquery
+
+A.3. Monitoring
+
+ The ntpd implementation allows remote monitoring. Access to this
+ service is generally controlled by the "noquery" directive in NTP's
+ configuration file (ntp.conf) via a "restrict" statement. The syntax
+ reads:
+
+ restrict address mask address_mask noquery
+
+ If a system is using broadcast mode and is running ntp-4.2.8p6 or
+ later, use the fourth field of the ntp.keys file to specify the IPs
+ of machines that are allowed to serve time to the group.
+
+A.4. Leap-Second File
+
+ The use of leap-second files requires ntpd 4.2.6 or later. After
+ fetching the leap-second file onto the server, add this line to
+ ntpd.conf to apply and use the file, substituting the proper path:
+
+ leapfile "/path/to/leap-file"
+
+ There may be a need to restart ntpd to apply this change.
+
+ ntpd servers with a manually configured leap-second file will ignore
+ a leap-second information broadcast from upstream NTP servers until
+ the leap-second file expires. If no valid leap-second file is
+ available, then a leap-second notification from an attached reference
+ clock is always accepted by ntpd.
+
+ If no valid leap-second file is available, a leap-second notification
+ may be accepted from upstream NTP servers. As of ntp-4.2.6, a
+ majority of servers must provide the notification before it is
+ accepted. Before 4.2.6, a leap-second notification would be accepted
+ if a single upstream server of a group of configured servers provided
+ a leap-second notification. This would lead to misbehavior if single
+ NTP servers sent an invalid leap second warning, e.g., due to a
+ faulty GPS receiver in one server, but this behavior was once chosen
+ because in the "early days", there was a greater chance that leap-
+
+
+
+Reilly, et al. Best Current Practice [Page 24]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+ second information would be available from a very limited number of
+ sources.
+
+A.5. Leap Smearing
+
+ Leap smearing was introduced in ntpd versions 4.2.8.p3 and 4.3.47 in
+ response to client requests. Support for leap smearing is not
+ configured by default and must be added at compile time. In
+ addition, no leap smearing will occur unless a leap smear interval is
+ specified in ntpd.conf. For more information, refer to [LEAPSEC].
+
+A.6. Configuring ntpd
+
+ See [CONFIGNTP] for additional information on configuring ntpd.
+
+A.7. Pre-Shared Keys
+
+ Each communication partner must add the key information to their key
+ file in the form:
+
+ keyid type key
+
+ where "keyid" is a number between 1 and 65534, inclusive; "type" is
+ an ASCII character that defines the key format; and "key" is the key
+ itself.
+
+ An ntpd client establishes a protected association by appending the
+ option "key keyid" to the server statement in ntp.conf,
+
+ server address key keyid
+
+ substituting the server address in the "address" field and the
+ numerical keyid to use with that server in the "keyid" field.
+
+ A key is deemed trusted when its keyid is added to the list of
+ trusted keys by the "trustedkey" statement in ntp.conf.
+
+ trustedkey keyid_1 keyid_2 ... keyid_n
+
+ Starting with ntp-4.2.8p7, the ntp.keys file accepts an optional
+ fourth column, a comma-separated list of IPs that are allowed to
+ serve time. Use this feature. Note, however, that an adversarial
+ client that knows the symmetric broadcast key could still easily
+ spoof its source IP to an IP that is allowed to serve time. This is
+ easy to do because the origin timestamp on broadcast mode packets is
+ not validated by the client. By contrast, client/server and
+ symmetric modes do require origin timestamp validation, making it
+ more difficult to spoof packets [CCR16].
+
+
+
+Reilly, et al. Best Current Practice [Page 25]
+
+RFC 8633 Network Time Protocol BCP July 2019
+
+
+Acknowledgments
+
+ The authors wish to acknowledge the contributions of Sue Graves,
+ Samuel Weiler, Lisa Perdue, Karen O'Donoghue, David Malone, Sharon
+ Goldberg, Martin Burnicki, Miroslav Lichvar, Daniel Fox Franke,
+ Robert Nagy, and Brian Haberman.
+
+Authors' Addresses
+
+ Denis Reilly (editor)
+ Orolia USA
+ 1565 Jefferson Road, Suite 460
+ Rochester, NY 14623
+ United States of America
+
+ Email: denis.reilly@orolia.com
+
+
+ Harlan Stenn
+ Network Time Foundation
+ P.O. Box 918
+ Talent, OR 97540
+ United States of America
+
+ Email: stenn@nwtime.org
+
+
+ Dieter Sibold
+ Physikalisch-Technische Bundesanstalt
+ Bundesallee 100
+ Braunschweig D-38116
+ Germany
+
+ Phone: +49-(0)531-592-8420
+ Fax: +49-531-592-698420
+ Email: dieter.sibold@ptb.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reilly, et al. Best Current Practice [Page 26]
+