draft-ietf-ntp-bcp-12.txt   draft-ietf-ntp-bcp-13.txt 
Internet Engineering Task Force D. Reilly, Ed. Internet Engineering Task Force D. Reilly, Ed.
Internet-Draft Orolia USA Internet-Draft Orolia USA
Intended status: Best Current Practice H. Stenn Intended status: Best Current Practice H. Stenn
Expires: July 29, 2019 Network Time Foundation Expires: September 27, 2019 Network Time Foundation
D. Sibold D. Sibold
PTB PTB
January 25, 2019 March 26, 2019
Network Time Protocol Best Current Practices Network Time Protocol Best Current Practices
draft-ietf-ntp-bcp-12 draft-ietf-ntp-bcp-13
Abstract Abstract
The Network Time Protocol (NTP) is one of the oldest protocols on the The Network Time Protocol (NTP) is one of the oldest protocols on the
Internet and has been widely used since its initial publication. Internet and has been widely used since its initial publication.
This document is a collection of Best Practices for general operation This document is a collection of Best Practices for general operation
of NTP servers and clients on the Internet. It includes of NTP servers and clients on the Internet. It includes
recommendations for stable, accurate and secure operation of NTP recommendations for stable, accurate and secure operation of NTP
infrastructure. This document is targeted at NTP version 4 as infrastructure. This document is targeted at NTP version 4 as
described in RFC 5905. described in RFC 5905.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 29, 2019. This Internet-Draft will expire on September 27, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. General Network Security Best Practices . . . . . . . . . . . 3 2. General Network Security Best Practices . . . . . . . . . . . 3
2.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. NTP Configuration Best Practices . . . . . . . . . . . . . . 4 3. NTP Configuration Best Practices . . . . . . . . . . . . . . 4
3.1. Keeping NTP up to date . . . . . . . . . . . . . . . . . 4 3.1. Keeping NTP up to date . . . . . . . . . . . . . . . . . 4
3.2. Use enough time sources . . . . . . . . . . . . . . . . . 4 3.2. Use enough time sources . . . . . . . . . . . . . . . . . 4
3.3. Use a diversity of Reference Clocks . . . . . . . . . . . 5 3.3. Use a diversity of Reference Clocks . . . . . . . . . . . 5
3.4. Control Messages . . . . . . . . . . . . . . . . . . . . 6 3.4. Control Messages . . . . . . . . . . . . . . . . . . . . 6
3.5. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 6 3.5. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. Using Pool Servers . . . . . . . . . . . . . . . . . . . 7 3.6. Using Pool Servers . . . . . . . . . . . . . . . . . . . 7
3.7. Leap Second Handling . . . . . . . . . . . . . . . . . . 7 3.7. Leap Second Handling . . . . . . . . . . . . . . . . . . 8
3.7.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 8 3.7.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 9
4. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 9 4. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 10
4.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . . . 10 4.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . . . 10
4.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Network Time Security . . . . . . . . . . . . . . . . . . 11 4.3. Network Time Security . . . . . . . . . . . . . . . . . . 11
4.4. External Security Protocols . . . . . . . . . . . . . . . 11 4.4. External Security Protocols . . . . . . . . . . . . . . . 11
5. NTP Security Best Practices . . . . . . . . . . . . . . . . . 11 5. NTP Security Best Practices . . . . . . . . . . . . . . . . . 11
5.1. Minimizing Information Leakage . . . . . . . . . . . . . 11 5.1. Minimizing Information Leakage . . . . . . . . . . . . . 11
5.2. Avoiding Daemon Restart Attacks . . . . . . . . . . . . . 12 5.2. Avoiding Daemon Restart Attacks . . . . . . . . . . . . . 12
5.3. Detection of Attacks Through Monitoring . . . . . . . . . 13 5.3. Detection of Attacks Through Monitoring . . . . . . . . . 14
5.4. Kiss-o'-Death Packets . . . . . . . . . . . . . . . . . . 14 5.4. Kiss-o'-Death Packets . . . . . . . . . . . . . . . . . . 14
5.5. Broadcast Mode Should Only Be Used On Trusted Networks . 15 5.5. Broadcast Mode Should Only Be Used On Trusted Networks . 15
5.6. Symmetric Mode Should Only Be Used With Trusted Peers . . 15 5.6. Symmetric Mode Should Only Be Used With Trusted Peers . . 15
6. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 15 6. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 15
6.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 16 6.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 16
6.2. Server configuration . . . . . . . . . . . . . . . . . . 16 6.2. Server configuration . . . . . . . . . . . . . . . . . . 16
7. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 16 7. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 19
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Best Practices specific to the Network Time Appendix A. Best Practices specific to the Network Time
Foundation implementation . . . . . . . . . . . . . 21 Foundation implementation . . . . . . . . . . . . . 21
A.1. Use enough time sources . . . . . . . . . . . . . . . . . 21 A.1. Use enough time sources . . . . . . . . . . . . . . . . . 22
A.2. NTP Control and Facility Messages . . . . . . . . . . . . 22 A.2. NTP Control and Facility Messages . . . . . . . . . . . . 22
A.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 22 A.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 23
A.4. Leap Second File . . . . . . . . . . . . . . . . . . . . 23 A.4. Leap Second File . . . . . . . . . . . . . . . . . . . . 23
A.5. Leap Smearing . . . . . . . . . . . . . . . . . . . . . . 23 A.5. Leap Smearing . . . . . . . . . . . . . . . . . . . . . . 23
A.6. Configuring ntpd . . . . . . . . . . . . . . . . . . . . 23 A.6. Configuring ntpd . . . . . . . . . . . . . . . . . . . . 24
A.7. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . . . 24 A.7. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
NTP version 4 (NTPv4) has been widely used since its publication as NTP version 4 (NTPv4) has been widely used since its publication as
[RFC5905]. This document is a collection of best practices for the [RFC5905]. This document is a collection of best practices for the
operation of NTP clients and servers. operation of NTP clients and servers.
The recommendations in this document are intended to help operators The recommendations in this document are intended to help operators
skipping to change at page 4, line 7 skipping to change at page 4, line 7
packet to point to a different IP address than the computer which packet to point to a different IP address than the computer which
originated it. UDP-based protocols such as NTP are generally more originated it. UDP-based protocols such as NTP are generally more
susceptible to spoofing attacks than connection-oriented protocols. susceptible to spoofing attacks than connection-oriented protocols.
NTP control messages can generate a lot of data in response to a NTP control messages can generate a lot of data in response to a
small query, which makes it attractive as a vector for distributed small query, which makes it attractive as a vector for distributed
denial-of-service attacks. (NTP Control messages are discussed denial-of-service attacks. (NTP Control messages are discussed
further in Section 3.4). One documented instance of such an attack further in Section 3.4). One documented instance of such an attack
can be found here [1], and further discussion in [IMC14] and can be found here [1], and further discussion in [IMC14] and
[NDSS14]. [NDSS14].
Mitigating source address spoofing attacks should be a priority of BCP 38 [RFC2827] was published in 2000 to to provide some level of
anyone administering NTP. BCP 38 [RFC2827] was published in 2000 to remediation against address-spoofing attacks. BCP 38 calls for
to provide some level of remediation against address-spoofing filtering outgoing and incoming traffic to make sure that the source
attacks. BCP 38 calls for filtering outgoing and incoming traffic to and destination IP addresses are consistent with the expected flow of
make sure that the source and destination IP addresses are consistent traffic on each network interface. It is RECOMMENDED that ISP's and
with the expected flow of traffic on each network interface. It is large corporate networks implement ingress and egress filtering.
RECOMMENDED that ISP's and large corporate networks implement ingress More information is available at the BCP38 Info Web page [2] .
and egress filtering. More information is available at the BCP38
Info Web page [2] .
3. NTP Configuration Best Practices 3. NTP Configuration Best Practices
This section provides Best Practices for NTP configuration and This section provides Best Practices for NTP configuration and
operation. Application of these best practices that are specific to operation. Application of these best practices that are specific to
the Network Time Foundation implementation, including example the Network Time Foundation implementation, including example
configuration directives valid at the time of this writing, are configuration directives valid at the time of this writing, are
compiled in Appendix A. compiled in Appendix A.
3.1. Keeping NTP up to date 3.1. Keeping NTP up to date
skipping to change at page 5, line 5 skipping to change at page 4, line 51
[MILLS2006]. [MILLS2006].
o If there is only 1 source of time, the answer is obvious. It may o If there is only 1 source of time, the answer is obvious. It may
not be a good source of time, but it's the only source of time not be a good source of time, but it's the only source of time
that can be considered. Any issue with the time at the source that can be considered. Any issue with the time at the source
will be passed on to the client. will be passed on to the client.
o If there are 2 sources of time and they agree well enough, then o If there are 2 sources of time and they agree well enough, then
the best time can be calculated easily. But if one source fails, the best time can be calculated easily. But if one source fails,
then the solution degrades to the single-source solution outlined then the solution degrades to the single-source solution outlined
above. And if the two sources don't agree, then it's impossible above. And if the two sources don't agree, it will be difficult
to know which one is correct by simply looking at the time. to know which one is correct without making use of information
from outside of the protocol.
o If there are 3 sources of time, there is more data available to o If there are 3 sources of time, there is more data available to
converge on the best calculated time, and this time is more likely 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 to be accurate. And the loss of one of the sources (by becoming
unreachable or unusable) can be tolerated. But at that point, the unreachable or unusable) can be tolerated. But at that point, the
solution degrades to the 2 source solution. solution degrades to the 2 source solution.
o 4 or more sources of time is better, as long as the sources are o 4 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 diverse (Section 3.3). If one of these sources develops a problem
there are still at least 3 other time sources. there are still at least 3 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 Operators who are concerned with maintaining accurate time SHOULD use
at least 4 independent, diverse sources of time. Four sources will at least 4 independent, diverse sources of time. Four sources will
provide sufficient backup in case one source goes down. If four provide sufficient backup in case one source goes down. If four
sources are not available, operators MAY use fewer sources, subject sources are not available, operators MAY use fewer sources, subject
to the risks outlined above. to the risks outlined above.
But even with 4 or more sources of time, systemic problems can But even with 4 or more sources of time, systemic problems can
happen. One example involves the leap smearing concept detailed in happen. One example involves the leap smearing concept detailed in
Section 3.7.1. For several hours before and after the June 2015 leap Section 3.7.1. For several hours before and after the June 2015 leap
second, several operators configured their NTP servers with leap second, several operators configured their NTP servers with leap
skipping to change at page 6, line 50 skipping to change at page 7, line 13
protection for this abuse by implementing BCP 38. protection for this abuse by implementing BCP 38.
3.5. Monitoring 3.5. Monitoring
Operators SHOULD use their NTP implementation's remote monitoring Operators SHOULD use their NTP implementation's remote monitoring
capabilities to quickly identify servers which are out of sync, and capabilities to quickly identify servers which are out of sync, and
ensure correctness of the service. Operators SHOULD also monitor ensure correctness of the service. Operators SHOULD also monitor
system logs for messages so problems and abuse attempts can be system logs for messages so problems and abuse attempts can be
quickly identified. quickly identified.
If a system starts to receive NTP Reply packets from a time server If a system starts to receive NTP Reply packets from a remote time
that do not correspond to any requests sent by the system, that can server that do not correspond to any requests sent by the system,
be an indication that an attacker is forging that system's IP address that can be an indication that an attacker is forging that system's
in requests to the remote time server. The goal of this attack would IP address in requests to the remote time server. The goal of this
be to convince the time server to stop serving time to the system attack is to adversely impact the availability of time to the
whose address is being forged. 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 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 receiving early time messages from its server, that is an indication
that somebody may be forging packets from a broadcast server. that somebody may be forging packets from a broadcast server.
(Broadcast client and server modes are defined in Section 3 of (Broadcast client and server modes are defined in Section 3 of
[RFC5905]) [RFC5905])
If a server's system log shows messages that indicates it is If a server's system log shows messages that indicates it is
receiving NTP timestamps that are much earlier than the current receiving NTP timestamps that are much earlier than the current
system time, then either the system clock is unusually fast or system time, then either the system clock is unusually fast or
skipping to change at page 17, line 24 skipping to change at page 17, line 29
pools. pools.
If clients are connected to an NTP server via anycast, the client If clients are connected to an NTP server via anycast, the client
does not know which particular server they are connected to. As does not know which particular server they are connected to. As
anycast servers enter and leave the network, or the network topology anycast servers enter and leave the network, or the network topology
changes, the server a particular client is connected to may change. changes, the server a particular client is connected to may change.
This may cause a small shift in time from the perspective of the This may cause a small shift in time from the perspective of the
client when the server it is connected to changes. In extreme cases client when the server it is connected to changes. In extreme cases
where the network topology is changing rapidly, this could cause the where the network topology is changing rapidly, this could cause the
server seen by a client to rapidly change as well, which can lead to server seen by a client to rapidly change as well, which can lead to
larger time inaccuracies. It is RECOMMENDED that anycast only be larger time inaccuracies. It is RECOMMENDED that network operators
deployed in environments where this behavior can be tolerated 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 Configuration of an anycast interface is independent of NTP. Clients
will always connect to the closest server, even if that server is will always connect to the closest server, even if that server is
having NTP issues. It is RECOMMENDED that anycast NTP having NTP issues. It is RECOMMENDED that anycast NTP
implementations have an independent method of monitoring the implementations have an independent method of monitoring the
performance of NTP on a server. If the server is not performing to performance of NTP on a server. If the server is not performing to
specification, it should remove itself from the Anycast network. It specification, it should remove itself from the Anycast network. It
is also RECOMMENDED that each Anycast NTP server have an alternative is also RECOMMENDED that each Anycast NTP server have an alternative
method of access, such as an alternate Unicast IP address, so its method of access, such as an alternate Unicast IP address, so its
performance can be checked independently of the anycast routing performance can be checked independently of the anycast routing
skipping to change at page 19, line 42 skipping to change at page 20, line 7
<http://www.talosintel.com/reports/TALOS-2016-0078>. <http://www.talosintel.com/reports/TALOS-2016-0078>.
[CVE-2016-1548] [CVE-2016-1548]
Gardner, J. and M. Lichvar, "Xleave Pivot: NTP Basic Mode Gardner, J. and M. Lichvar, "Xleave Pivot: NTP Basic Mode
to Interleaved", 2016, to Interleaved", 2016,
<http://blog.talosintel.com/2016/04/ <http://blog.talosintel.com/2016/04/
vulnerability-spotlight-further-ntpd_27.html>. vulnerability-spotlight-further-ntpd_27.html>.
[I-D.ietf-ntp-data-minimization] [I-D.ietf-ntp-data-minimization]
Franke, D. and A. Malhotra, "NTP Client Data Franke, D. and A. Malhotra, "NTP Client Data
Minimization", draft-ietf-ntp-data-minimization-03 (work Minimization", draft-ietf-ntp-data-minimization-04 (work
in progress), September 2018. in progress), March 2019.
[I-D.ietf-ntp-mac] [I-D.ietf-ntp-mac]
Malhotra, A. and S. Goldberg, "Message Authentication Code Malhotra, A. and S. Goldberg, "Message Authentication Code
for the Network Time Protocol", draft-ietf-ntp-mac-06 for the Network Time Protocol", draft-ietf-ntp-mac-06
(work in progress), January 2019. (work in progress), January 2019.
[I-D.ietf-ntp-mode-6-cmds] [I-D.ietf-ntp-mode-6-cmds]
Haberman, B., "Control Messages Protocol for Use with Haberman, B., "Control Messages Protocol for Use with
Network Time Protocol Version 4", draft-ietf-ntp-mode- Network Time Protocol Version 4", draft-ietf-ntp-mode-
6-cmds-06 (work in progress), September 2018. 6-cmds-06 (work in progress), September 2018.
[I-D.ietf-ntp-using-nts-for-ntp] [I-D.ietf-ntp-using-nts-for-ntp]
Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time Sundblad, "Network Time Security for the Network Time
Protocol", draft-ietf-ntp-using-nts-for-ntp-15 (work in Protocol", draft-ietf-ntp-using-nts-for-ntp-17 (work in
progress), December 2018. progress), February 2019.
[IMC14] Czyz, J., Kallitsis, M., Gharaibeh, M., Papadopoulos, C., [IMC14] Czyz, J., Kallitsis, M., Gharaibeh, M., Papadopoulos, C.,
Bailey, M., and M. Karir, "Taming the 800 Pound Gorilla: Bailey, M., and M. Karir, "Taming the 800 Pound Gorilla:
The Rise and Decline of NTP DDoS Attacks", Internet The Rise and Decline of NTP DDoS Attacks", Internet
Measurement Conference , 2014. Measurement Conference , 2014.
[MILLS2006] [MILLS2006]
Mills, D., "Computer network time synchronization: the Mills, D., "Computer network time synchronization: the
Network Time Protocol", CRC Press , 2006. Network Time Protocol", CRC Press , 2006.
 End of changes. 18 change blocks. 
36 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/