draft-ietf-ntp-bcp-03.txt   draft-ietf-ntp-bcp-04.txt 
Internet Engineering Task Force D. Reilly, Ed. Internet Engineering Task Force D. Reilly, Ed.
Internet-Draft Spectracom Internet-Draft Spectracom
Intended status: Best Current Practice H. Stenn Intended status: Best Current Practice H. Stenn
Expires: October 15, 2017 Network Time Foundation Expires: November 22, 2017 Network Time Foundation
D. Sibold D. Sibold
PTB PTB
April 13, 2017 May 21, 2017
Network Time Protocol Best Current Practices Network Time Protocol Best Current Practices
draft-ietf-ntp-bcp-03 draft-ietf-ntp-bcp-04
Abstract Abstract
NTP Version 4 (NTPv4) has been widely used since its publication as NTP Version 4 (NTPv4) has been widely used since its publication as
RFC 5905 [RFC5905]. This documentation is a collection of Best RFC 5905 [RFC5905]. This documentation is a collection of Best
Practices from across the NTP community. Practices from across the NTP community.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 October 15, 2017. This Internet-Draft will expire on November 22, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Keeping NTP up to date . . . . . . . . . . . . . . . . . . . 3 2. Keeping NTP up to date . . . . . . . . . . . . . . . . . . . 3
3. General Network Security Best Practices . . . . . . . . . . . 4 3. General Network Security Best Practices . . . . . . . . . . . 4
3.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. NTP Configuration Best Practices . . . . . . . . . . . . . . 4 4. NTP Configuration Best Practices . . . . . . . . . . . . . . 4
4.1. Use enough time sources . . . . . . . . . . . . . . . . . 4 4.1. Use enough time sources . . . . . . . . . . . . . . . . . 4
4.2. Use a diversity of Reference Clocks . . . . . . . . . . . 5 4.2. Use a diversity of Reference Clocks . . . . . . . . . . . 5
4.3. Mode 6 and 7 . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Mode 6 and 7 . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 7
4.5. Using Pool Servers . . . . . . . . . . . . . . . . . . . 7 4.5. Using Pool Servers . . . . . . . . . . . . . . . . . . . 8
4.6. Leap Second Handling . . . . . . . . . . . . . . . . . . 8 4.6. Leap Second Handling . . . . . . . . . . . . . . . . . . 8
4.6.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 9 4.6.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 10
4.7. Configuring ntpd . . . . . . . . . . . . . . . . . . . . 10 4.7. Configuring ntpd . . . . . . . . . . . . . . . . . . . . 11
5. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 10 5. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 11
5.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . . . 11 5.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . . . 11
5.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Network Time Security . . . . . . . . . . . . . . . . . . 12 5.3. Network Time Security . . . . . . . . . . . . . . . . . . 12
6. NTP Security Best Practices . . . . . . . . . . . . . . . . . 12 6. NTP Security Best Practices . . . . . . . . . . . . . . . . . 12
6.1. Minimizing Information Leakage . . . . . . . . . . . . . 12 6.1. Minimizing Information Leakage . . . . . . . . . . . . . 12
6.2. Avoiding Daemon Restart Attacks . . . . . . . . . . . . . 13 6.2. Avoiding Daemon Restart Attacks . . . . . . . . . . . . . 13
6.3. Detection of Attacks Through Monitoring . . . . . . . . . 14 6.3. Detection of Attacks Through Monitoring . . . . . . . . . 14
6.4. Broadcast Mode Should Only Be Used On Trusted Networks . 14 6.4. Broadcast Mode Should Only Be Used On Trusted Networks . 15
6.5. Symmetric Mode Should Only Be Used With Trusted Peers . . 15 6.5. Symmetric Mode Should Only Be Used With Trusted Peers . . 15
7. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 15 7. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 16
7.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 16 7.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 16
7.2. KISS Packets . . . . . . . . . . . . . . . . . . . . . . 16 7.2. KISS Packets . . . . . . . . . . . . . . . . . . . . . . 17
7.3. Server configuration . . . . . . . . . . . . . . . . . . 16 7.3. Server configuration . . . . . . . . . . . . . . . . . . 17
7.3.1. Get a vendor subdomain for pool.ntp.org . . . . . . . 17 7.3.1. Get a vendor subdomain for pool.ntp.org . . . . . . . 17
8. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 17 8. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 20
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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
RFC 5905 [RFC5905]. This documentation is a collection of Best RFC 5905 [RFC5905]. This documentation is a collection of Best
Practices from across the NTP community. Practices from across the NTP community.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Keeping NTP up to date 2. Keeping NTP up to date
Many network security mechanisms rely on time as part of their Many network security mechanisms rely on time as part of their
operation. If an attacker can spoof the time, they may be able to operation. If an attacker can spoof the time, they may be able to
bypass or neutralize other security elements. For example, incorrect bypass or neutralize other security elements. For example, incorrect
time can disrupt the ability to reconcile logfile entries on the time can disrupt the ability to reconcile logfile entries on the
affected system with events on other systems. The best way to affected system with events on other systems. The best way to detect
protect computers and networks against undefined behavior and and protect computers and networks against undefined behavior and
security threats related to time is to keep their NTP implementations security threats related to time is to keep their NTP implementations
current. current, use an appropriate number of trustworthy time sources, and
properly monitor their time infrastructure.
There are always new ideas about security on the Internet, and an There are always new ideas about security on the Internet, and an
application which is secure today could be insecure tomorrow once an application which is secure today could be insecure tomorrow once an
unknown bug (or a known behavior) is exploited in the right way. unknown bug (or a known behavior) is exploited in the right way.
Even our definition of what is secure has evolved over the years, so Even our definition of what is secure has evolved over the years, so
code which was considered secure when it was written can be code which was considered secure when it was written may turn out to
considered insecure after some time. By keeping NTP implementations be insecure after some time. By keeping NTP implementations current,
current, network operators can make sure that older behaviors are not having "enough" trustworthy time sources, and properly monitoring
exploited. their time infrastructure, network operators can make sure that their
time infrastructure is operating correctly and within specification,
and is not being attacked or misused.
Thousands of individual bugs have been found and fixed in the NTP Thousands of individual bugs have been found and fixed in the NTP
Project's ntpd since the first NTPv4 release in 1997. Each version Project's ntpd since the first NTPv4 release in 1997. Each version
release contains at least a few bug fixes. The best way to stay in release contains at least a few bug fixes. The best way to stay in
front of these issues is to keep your NTP implementation current. front of these issues is to keep your NTP implementation current.
There are multiple versions of the NTP protocol in use, and multiple There are multiple versions of the NTP protocol in use, and multiple
implementations in use, on many different platforms. It is implementations in use, on many different platforms. It is
recommended that NTP users actively monitor wherever they get their recommended that NTP users actively monitor wherever they get their
software to find out if their versions are vulnerable to any known software to find out if their versions are vulnerable to any known
skipping to change at page 4, line 4 skipping to change at page 4, line 8
There are multiple versions of the NTP protocol in use, and multiple There are multiple versions of the NTP protocol in use, and multiple
implementations in use, on many different platforms. It is implementations in use, on many different platforms. It is
recommended that NTP users actively monitor wherever they get their recommended that NTP users actively monitor wherever they get their
software to find out if their versions are vulnerable to any known software to find out if their versions are vulnerable to any known
attacks, and deploy updates containing security fixes as soon as attacks, and deploy updates containing security fixes as soon as
practical. practical.
The reference implementation of NTP Version 4 from Network Time The reference implementation of NTP Version 4 from Network Time
Foundation (NTF) continues to be actively maintained and developed by Foundation (NTF) continues to be actively maintained and developed by
NTF's NTP Project, with help from volunteers and NTF's supporters. NTF's NTP Project, with help from volunteers and NTF's supporters.
This NTP software can be downloaded from ntp.org [1] and also from This NTP software can be downloaded from ntp.org [1] and also from
NTF's github page [2]. NTF's NTP Project's BitKeeper repository [2] or github page [3].
3. General Network Security Best Practices 3. General Network Security Best Practices
3.1. BCP 38 3.1. BCP 38
Many network attacks rely on modifying the IP source address of a Many network attacks rely on modifying the IP source address of a
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. This modification/abuse vector has been known for originated it. This modification/abuse vector has been known for
quite some time, and BCP 38 [RFC2827] was approved in 2000 to address quite some time, and BCP 38 [RFC2827] was approved in 2000 to address
this. BCP 38 [RFC2827] calls for filtering outgoing and incoming this. BCP 38 [RFC2827] calls for filtering outgoing and incoming
traffic to make sure that the source and destination IP addresses are traffic to make sure that the source and destination IP addresses are
consistent with the expected flow of traffic on each network consistent with the expected flow of traffic on each network
interface. It is recommended that all networks (and ISP's of any interface. It is recommended that all networks (and ISP's of any
size) implement this. If a machine on a network is sending out size) implement ingress and egress filtering. If a machine on a
packets claiming to be from an address that is not on that network, network is sending out packets claiming to be from an address that is
this could be the first indication that there is a machine that has not on that network, this could be the first indication that there is
been compromised, and is being used abusively. If packets are a machine that has been compromised, and is being used abusively. If
arriving on an external interface with a source address that is packets are arriving on an external interface with a source address
normally only seen on an internal network, that's a strong indication that should only be seen on an internal network, that's a strong
that an attacker is trying to inject spoofed packets into the indication that an attacker is trying to inject spoofed packets into
network. More information is available at the BCP38 Info page [3] . the network. More information is available at the BCP38 Info page
[4] .
4. NTP Configuration Best Practices 4. NTP Configuration Best Practices
These Best Practices, while based on the ntpd reference These Best Practices, while based on the ntpd reference
implementation developed and maintained by Network Time Foundation, implementation maintained by Network Time Foundation, may be
may be applicable to other implementations as well. applicable to other implementations as well.
4.1. Use enough time sources 4.1. Use enough time sources
ntpd takes the available sources of time and submits their timing An NTP implementation (as opposed to an SNTP implementation) takes
data to intersection and clustering algorithms, looking for the best the available sources of time and submits this timing data to
idea of the correct time. sophisticated intersection, clustering, and combing 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 RFC 5905 [RFC5905] or the detailed description of NTP in
MILLS 2006 [MILLS2006]
o If there is only 1 source of time, the answer is obvious. It o If there is only 1 source of time, the answer is obvious. It may
might not be a good source of time, but it's the only one. 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
will be passed on to the client.
o If there are 2 sources of time and they agree well enough, that's o If there are 2 sources of time and they agree well enough, then
good. But if they don't, then ntpd has no way to know which the best "time" can be calculated easily. But if one source
source to believe. fails, then your solution degrades to the single-source solution
outlined above. And if the two sources don't agree, then it's
impossible to know which one is correct by simply looking at the
time.
o If there are 3 sources of time, you can tolerate one of those o If there are 3 sources of time, there is more data available to
sources becoming unreachable or unusable. But at that point, we converge on a "best" time, and this time is more likely to be
are back down to 2 sources. accurate. And you can tolerate one of the sources becoming
unreachable or unusable. But at that point, you are back down to
2 sources.
o 4 sources of time is better. If one of these sources develops a o 4 or more sources of time is better. If one of these sources
problem there are still 3 others. develops a problem there are still at least 3 other time sources.
But even with 4 or more sources of time, systemic issues can happen. But even with 4 or more sources of time, systemic problems can
During the leap second of June of 2015, several operators implemented happen. During the leap second of June of 2015, several operators
leap smearing while others did not, and some NTP clients follwed 2 implemented leap smearing while others did not, and many NTP end
servers that offered UTC time (with leap second announcements) and 2 nodes could not determine an accurate time source because 2 of their
servers that offered leap smeared time (with no leap second 4 sources of time gave them consistent UTC/POSIX time, while the
announcements). See Section 4.6.1 for more information. other 2 gave them consistent leap-smeared time. See Section 4.6.1
for more information.
Starting with ntp-4.2.6, the 'pool' directive will spin up "enough" Starting with ntp-4.2.6, the 'pool' directive will spin up "enough"
associations to provide robust time service, and will disconnect poor associations to provide robust time service, and will disconnect poor
servers and add in new servers as-needed. The default values built servers and add in new servers as-needed. If you have good reason,
in to ntpd should be correct. If you have good reasons, you may use you may use the 'minclock' and 'maxclock' options of the 'tos'
the 'minclock' and 'maxclock' options of the 'tos' command to command to override the default values of how many servers are
override the default values of how many servers are discovered and discovered through the 'pool' directive.
used through the 'pool' directive.
Properly monitor your NTP instances. If your time sources do not Monitor your ntpd instances. If your time sources do not generally
generally agree, find out why and either correct the problems or stop agree, find out why and either correct the problems or stop using
using defective servers. See Section 4.4 for more information. defective servers. See Section 4.4 for more information.
4.2. Use a diversity of Reference Clocks 4.2. Use a diversity of Reference Clocks
When using servers with attached hardware reference clocks, it is When using servers with attached hardware reference clocks, it is
recommended that several different types of reference clocks be used. recommended that several different types of reference clocks be used.
Having a diversity of sources means that any one issue is less likely Having a diversity of sources means that any one issue is less likely
to cause a service interruption. to cause a service interruption.
Are all clocks on a network from the same vendor? They might have Are all clocks on a network from the same vendor? They may have the
the same bugs. Are they using the same base chipset, regardless of same bugs. Are they using the same base chipset, regardless of
whether or not the finished products are from different vendors? Are whether or not the finished products are from different vendors? Are
they all running the same version of firmware? Chipset and firmware they all running the same version of firmware? Chipset and firmware
bugs can happen, but are often more difficult to diagnose than a bugs can happen, but is often more difficult to diagnose than a
standard software bug. standard software bug.
A systemic problem with time from any satellite navigation service is A systemic problem with time from any satellite navigation service is
possible and has happened. Sunspot activity can render satellite or possible and has happened. Sunspot activity can render satellite or
radio-based time source unusable. If the time on your network needs radio-based time source unusable. If the time on your network must
to be correct close to 100% of the time, then even if you are using a be correct close to 100% of the time, then even if you are using a
satellite-based time source you must plan for those rare instances satellite-based system, you must plan for those rare instances when
when the time source is unavailable or wrong. the system is unavailable (or wrong!).
4.3. Mode 6 and 7 4.3. Mode 6 and 7
NTP Mode 6 (ntpq) and Mode 7 (ntpdc) packets are designed to permit NTP Mode 6 (ntpq) and Mode 7 (ntpdc) packets are designed to permit
monitoring and optional authenticated control of ntpd and its monitoring and optional authenticated control of ntpd and its
configuration. Used properly, these facilities provide vital configuration. Used properly, these facilities provide vital
debugging and performance information, and control facilities. Used debugging and performance information and control. Used improperly,
improperly, these facilities can be an abuse vector. these facilities can be an abuse vector.
Mode 7 queries have been disabled by default in ntpd since 4.2.7p230, Mode 7 queries have been disabled by default in ntpd since 4.2.7p230,
released on 2011/11/01. Do not enable Mode 7 unless there is a released on 2011/11/01. Do not enable Mode 7 unless there is a
compelling reason to do so. compelling reason to do so.
The ability to use Mode 6 beyond its basic monitoring capabilities is The ability to use Mode 6 beyond its basic monitoring capabilities
limited by default to authenticated sessions that provide and use a can be limited to authenticated sessions that provide a 'controlkey'.
'controlkey'. Similarly, if Mode 7 has been explicitly enabled its Similarly, if Mode 7 has been explicitly enabled its use for more
use for more than basic monitoring is limited by default to than basic monitoring can be limited to authenticated sessions that
authenticated sessions that provide and use a 'requestkey'. provide a 'requestkey'.
Older versions of the reference implementation of NTP likely do not Older versions of the reference implementation of NTP could be abused
have the protections listed above and could be abused to participate to participate in high-bandwidth DDoS attacks, if the above
in high-bandwidth DDoS attacks, if the above restrictions are not restrictions are not applied. Starting with ntp-4.2.7p26, released
applied. Starting with ntp-4.2.7p26, released in April of 2010, ntpd in April of 2010, ntpd requires the use of a nonce before replying
requires the use of a nonce before replying with potentially large with potentially large response packets.
response packets.
As mentioned above, there are two general ways to use Mode 6 and Mode 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 7 requests. One way is to query ntpd for information, and this mode
can be disabled with: can be disabled with:
restrict ... noquery restrict ... noquery
The second way to use Mode 6 and Mode 7 requests is to modify ntpd's The second way to use Mode 6 and Mode 7 requests is to modify ntpd's
behavior. Modification of ntpd ordinarily requires an authenticated behavior. Modification of ntpd's configuration requires an
session. By default, if no authentication keys have been specified authenticated session BY default. If no authentication keys have
no modifications can be made. For additional protection, the ability been specified no modifications can be made. For additional
to perform these modifications can be controlled with: protection, the ability to perform these modifications can be
controlled with:
restrict ... nomodify
Adminitstrators can prevent their NTP servers from responding to restrict ... nomodify
these directive in the general case by adding the following to their Users can prevent their NTP servers from considering query/
configuration traffic by default by adding the following to their
ntp.conf file: ntp.conf file:
restrict default -4 nomodify notrap nopeer noquery restrict default -4 nomodify notrap nopeer noquery
restrict default -6 nomodify notrap nopeer noquery restrict default -6 nomodify notrap nopeer noquery
restrict source nomodify notrap noquery restrict source nomodify notrap noquery
# nopeer is OK if you don't use the 'pool' directive # nopeer is OK if you don't use the 'pool' directive
4.4. Monitoring 4.4. Monitoring
The reference implementation of NTP allows remote monitoring. Access The reference implementation of NTP allows remote monitoring. Access
to this service is controlled by the restrict statement in ntpd's to this service is generally controlled by the "noquery" directive in
configuration file (ntp.conf). The syntax is: NTP's configuration file (ntp.conf) via a "restrict" statement. The
syntax reads:
restrict address mask address_mask nomodify restrict address mask address_mask noquery
Monitor ntpd instances so machines that are "out of sync" can be Monitor ntpd instances so machines that are "out of sync" can be
quickly identified. Monitor system logs for messages from ntpd so quickly identified. Monitor system logs for messages from ntpd so
abuse attempts can be quickly identified. problems and abuse attempts can be quickly identified.
If a system starts getting unexpected time replies from its time If a system starts getting unexpected time replies from its time
servers, that is a likely indication that an abuser is forging your servers, that can be an indication that the IP address of the system
server's IP in time requests to your time server in an attempt to is being forged in requests to its time server, and these abusers are
convince your time servers to stop serving time to your system. trying to convince that time server to stop serving time to that
system.
If a system is a broadcast client and its syslog shows that it is If a system is a broadcast client and its syslog shows that it is
receiving "early" time messages from its server, that is an receiving "early" time messages from its server, that is an
indication that somebody might be forging packets from a broadcast indication that somebody may be forging packets from a broadcast
server. Broadcast time should only be used in trusted networks. server.
If a server's syslog shows messages that indicates it is receiving If a server's syslog shows messages that indicates it is receiving
timestamps that are earlier than the current system time, then either timestamps that are earlier than the current system time, then either
the system clock is unusually fast or somebody is trying to launch a the system clock is unusually fast or somebody is trying to launch a
replay attack against that server. replay attack against that server.
If a system is using broadcast mode and is running ntp-4.2.8p6 or If a system is using broadcast mode and is running ntp-4.2.8p6 or
later, use the 4th field of the ntp.keys file to specify the IPs of later, use the 4th field of the ntp.keys file to specify the IPs of
machines that are allowed to serve time to the group. machines that are allowed to serve time to the group.
4.5. Using Pool Servers 4.5. Using Pool Servers
It only takes a small amount of bandwidth and system resources to It only takes a small amount of bandwidth and system resources to
synchronize one NTP client, but NTP servers that can service tens of synchronize one NTP client, but NTP servers that can service tens of
thousands of clients take more resources to run. Users who want to thousands of clients take more resources to run. Users who want to
synchronize their computers should only synchronize to servers that synchronize their computers should only synchronize to servers that
they have permission to use. they have permission to use.
The NTP pool project is a collection of volunteers who have donated The NTP pool project is a group of volunteers who have donated their
their computing and bandwidth resources to provide time on the computing and bandwidth resources to freely distribute time from
Internet for free. The time is generally of good quality, but comes primary time sources to others on the Internet. The time is
with no guarantee whatsoever. If you are interested in using the generally of good quality, but comes with no guarantee whatsoever.
pool, please review their instructions at http://www.pool.ntp.org/en/ If you are interested in using the pool, please review their
use.html . instructions at http://www.pool.ntp.org/en/use.html .
If you want to synchronize many computers using the pool, consider If you are a vendor who wishes to provide time service to your
running your own NTP servers, synchronizing them to the pool, and customers or clients, consider joining the pool and providing a
synchronizing your clients to your in-house NTP servers. This "vendor zone" thru the pool project.
reduces the load on the pool.
If you want to synchronize many computers, consider running your own
NTP servers that are synchronized by the pool, and synchronizing your
clients to your in-house NTP servers. This reduces the load on the
pool.
If you would like to contribute a server with a static IP address and If you would like to contribute a server with a static IP address and
a permanent Internet conenction to the pool, please consult the a permanent Internet conenction to the pool, please consult the
instructions at http://www.pool.ntp.org/en/join.html . instructions at http://www.pool.ntp.org/en/join.html .
4.6. Leap Second Handling 4.6. Leap Second Handling
UTC is kept in agreement with the astronomical time UT1 [6] to within UTC is kept in agreement with the astronomical time UT1 [7] to within
+/- 0.9 seconds by the insertion or deletion of a leap second. UTC +/- 0.9 seconds by the insertion (or possibly a deletion) of a leap
is an atomic time scale whereas UT1 is based on the rotational rate second. UTC is an atomic time scale whereas UT1 is based on the
of the earth. Leap seconds are not introduced at a fixed rate. They rotational rate of the earth. Leap seconds are not introduced at a
are announced by the IERS (International Earth rotation and Reference fixed rate. They are announced by the IERS (International Earth
systems Service) in its Bulletin C [7] when necessary to keep UTC and rotation and Reference systems Service) in its Bulletin C [8] when
UT1 aligned. necessary to keep UTC and UT1 aligned.
NTP time is based on the UTC timescale, and the protocol has the NTP time is based on the UTC timescale, and the protocol has the
capability to broadcast leap second information. Some GNSS systems capability to broadcast leap second information. Some GNSS systems
(like GPS) or radio transmitters (like DCF77) broadcast leap second (like GPS) or radio transmitters (like DCF77) broadcast leap second
information, so if you have a Stratum-1 server synced to GNSS or you information, so if you are synced to an ntp server that is ultimately
are synced to a lower stratum server that is ultimately synced to synced to a source that provides leap second notification you will
GNSS, you will get advance notification of impending leap seconds get advance notification of impending leap seconds automatically.
automatically.
Since the length of the UT1 day is generally slowly increasing [8], Since the length of the UT1 day is generally slowly increasing [9],
all leap seconds that have been introduced since the practice started all leap seconds that have been introduced since the practice started
in 1972 have been "positive" leap seconds, where a second is added to 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 UTC. NTP also supports a "negative" leap second, where a second is
removed from UTC, in the event that the IERS announces one. removed from UTC, should that ever become necessary (or useful).
While earlier versions of NTP contained some ambiguity regarding when While earlier versions of NTP contained some ambiguity regarding when
a leap second that is broadcast by a server is applied by a client, a leap second that is broadcast by a server should be applied by a
RFC 5905 is clear that leap seconds are only applied on the last day client, RFC 5905 is clear that leap seconds are only applied on the
of a month. However, because some older clients might apply it at last day of a month. However, because some older clients may apply
the end of the current day, it is recommended that NTP servers wait it at the end of the current day, it is recommended that NTP servers
until the last day of the month before broadcasting leap seconds. wait until the last day of the month before broadcasting leap
Doing this will prevent older clients from applying a leap second at seconds. Doing this will prevent older clients from applying a leap
the wrong time. Note well that in NTPv4 the maximum allowed poll second at the wrong time. Note well that NTPv4 allows a maximum poll
interval is 17, or about 1.5 days' time. In this situation, it's interval of 17, or 131,072 seconds, which is longer than a day.
possible that a client will miss the leap second announcement.
The IETF maintains a leap second list [9]. The use of a leap second The IETF maintains a leap second list [10] for NTP users who are not
list requires ntpd 4.2.6 or later. After fetching the leap seconds receiving leap second information through an automatic source. The
file onto the server, add this line to ntpd.conf to apply the file: use of leap second files requires ntpd 4.2.6 or later. After
fetching the leap seconds file onto the server, add this line to
ntpd.conf to apply and use the file:
leapfile "/path/to your/leap-file" leapfile "/path/to your/leap-file"
You may need to restart ntpd to apply this change. You may need to restart ntpd to apply this change.
The leap second list file is also available from other sources: Files are also available from other sources:
NIST: ftp://time.nist.gov/pub/leap-seconds.list NIST: ftp://time.nist.gov/pub/leap-seconds.list
US Navy (maintains GPS Time): ftp://tycho.usno.navy.mil/pub/ntp/ US Navy (maintains GPS Time): ftp://tycho.usno.navy.mil/pub/ntp/leap-
leap-seconds.list seconds.list
IERS (announces leap seconds): IERS (announces leap seconds):
https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list
ntpd servers with a manually configured leap second file will ignore ntpd servers with a manually configured leap second file will ignore
leap second information broadcast from upstream NTP servers until the leap second information broadcast from upstream NTP servers until the
leap second file expires. leap second file expires. If no valid leap second file is available
then a leap second notification from an attached reference clock is
If no valid leap second file is available then a leap second always accepted by ntpd.
notification from an attached reference clock is always accepted by
ntpd.
If no valid leap second file is available, a leap second notification If no valid leap second file is available, a leap second notification
may be accepted from upstream NTP servers. As of ntpd 4.2.6, a may be accepted from upstream NTP servers. As of ntp-4.2.6, a
majority of servers must provide the notification before it is majority of servers must provide the notification before it is
accepted. Before 4.2.6, a leap second notification would be accepted accepted. Before 4.2.6, a leap second notification would be accepted
if only a single upstream server of a group of configured servers if a single upstream server of a group of configured servers provided
provided a leap second notification. While this was useful behavior a leap second notification. This would lead to misbehavior if single
in the past, when information about pending leap seconds was less NTP servers sent an invalid leap second warning, e.g. due to a faulty
available. Now, we have the combination of 1) easy availablilty of GPS receiver in one server, but this behavior was once chosen because
the leap second file and software to use it, and 2) a greater in the "early days" there was a greater chance that leap second
awareness of the potential for hostile behavior. In this new light, information would be available from a very limited number of sources.
we have shifted from "believe a single warning" to "follow the best
authoritative source". The best authoritative source is the leap
seconds list file, The next best source would be an attached refclock
that can provide notification of leap second adjustments, and the
next best source would be the majority consensus from upstream
servers. There is still a risk of misbehavior if a "master" NTP
server gets an invalid leap second warning, e.g. due to an incorrect
leap second list file, or a faulty GPS receiver.
4.6.1. Leap Smearing 4.6.1. Leap Smearing
Some NTP installations may make use of a technique called "Leap Some NTP installations may instead make use of a technique called
Smearing" to propagate a leap second correction. With this method, "Leap Smearing". With this method, instead of introducing an extra
instead of introducing an extra second (or eliminating a second), NTP second (or eliminating a second), NTP time will be slewed in small
time will be slewed in small increments over a comparably large increments over a comparably large window of time (called the smear
window of time (called the smear interval) around the leap second interval) around the leap second event. The smear interval should be
event. The smear interval should be large enough to make the rate large enough to make the rate that the time is slewed small, so that
that the time is slewed small, so that clients will follow the clients will follow the smeared time without objecting. Periods
smeared time without objecting. A smear interval of 86400 seconds, ranging from 2 to 24 hours have been used sucessfully. During the
which is 1 day, has been used sucessfully. During the adjustment adjustment window, all the NTP clients' times may be offset from UTC
window, all the NTP clients' times could be offset from UTC by as by as much as a full second, depending on the implementation. But at
much as a full second, depending on the implementation. But at least least all clients will generally agree on what time they think it is!
all clients will agree on what time they think it is!
NOTE WELL that using a leap-smear can cause your reported time to be
"legally indefensible" and/or be a breach of compliance regulations.
The purpose of Leap Smearing is to enable systems that don't deal The purpose of Leap Smearing is to enable systems that don't deal
with the leap second event properly to function smoothly, at the with the leap second event properly to function consistently, at the
expense of fidelity to UTC during the smear window. During a expense of fidelity to UTC during the smear window. During a
standard leap second event, that minute will have 61 (or possibly 59) standard leap second event, that minute will have 61 (or possibly 59)
seconds in it, and some applications (and even some OSes) are known seconds in it, and some applications (and even some OS's) are known
to have problems with that. to have problems with that.
Leap Smearing was introduced in ntpd versions 4.2.8.p3 and 4.3.47. Leap Smearing was introduced in ntpd versions 4.2.8.p3 and 4.3.47, in
Support is not availabled by default and has to be specifically added response to CLIENT requests. Support for leap smearing is not
at compile time. In addition, no leap smearing will occur unless a configured by default and must be added at compile time. In
leap smear interval is specified in ntpd.conf . For more addition, no leap smearing will occur unless a leap smear interval is
information, refer to http://bk1.ntp.org/ntp-stable/ specified in ntpd.conf . For more information, refer to
README.leapsmear?PAGE=anno . http://bk.ntp.org/ntp-stable/README.leapsmear?PAGE=anno [11].
Clients that are connected to leap smearing servers must not apply Clients that are connected to leap smearing servers MUST NOT apply
the "standard" NTP leap second handling. So if they are using ntpd, the "standard" NTP leap second handling. So if they are using ntpd,
these clients must not have a leap second file loaded, and the these clients must never have a leap second file loaded, and the
smearing servers must not advertise that a leap second is pending. smearing servers must never advertise to clients that a leap second
is pending.
Leap Smearing must not be used for public-facing NTP servers, as they 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 will disagree with non-smearing servers (as well as UTC) during the
leap smear interval. However, be aware that some public-facing leap smear interval. However, be aware that some public-facing
servers might be configured this way anyway in spite of this servers may be configured this way anyway in spite of this guidance.
guidance.
System Administrators are advised to be aware of impending leap System Administrators are advised to be aware of impending leap
seconds and how the servers (inside and outside their organization) seconds and how the servers (inside and outside their organization)
they are using deal with them. Individual clients must not be they are using deal with them. Individual clients must never be
configured to use a mixture of smeared and non-smeared servers. If a 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 client uses smeared servers, the servers it uses must all have the
same leap smear configuration. same leap smear configuration.
4.7. Configuring ntpd 4.7. Configuring ntpd
Configuration access to ntpd is controlled by the "modify" status in
NTP's configuration file (ntp.conf), which is controlled by a
"restrict" statement. The syntax is:
restrict address mask address_mask nomodify
See https://support.ntp.org/bin/view/Support/ConfiguringNTP for See https://support.ntp.org/bin/view/Support/ConfiguringNTP for
additional information on configuring ntpd. additional information on configuring ntpd.
5. NTP Security Mechanisms 5. NTP Security Mechanisms
In the standard configuration NTP packets are exchanged unprotected In the standard configuration NTP packets are exchanged unprotected
between client and server. An adversary that is able to become a 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 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 content of the NTP packet, which leads to degradation of the time
synchronization or the transmission of false time information. A synchronization or the transmission of false time information. A
profound threat analysis for time synchronization protocols are given profound threat analysis for time synchronization protocols are given
in RFC 7384 [RFC7384]. NTP provides two internal security mechanisms in RFC 7384 [RFC7384]. NTP provides two internal security mechanisms
to protect authenticity and integrity of the NTP packets. Both to protect authenticity and integrity of the NTP packets. Both
measures protect the NTP packet by means of a Message Authentication measures protect the NTP packet by means of a Message Authentication
Code (MAC). Neither of them encrypts the NTP's payload, because it Code (MAC). Neither of them encrypts the NTP's payload, because this
is not considered to be confidential. payload information is not considered to be confidential.
5.1. Pre-Shared Key Approach 5.1. Pre-Shared Key Approach
This approach applies a symmetric key for the calculation of the MAC, This approach applies a symmetric key for the calculation of the MAC,
which protects authenticity and integrity of the exchanged packets which protects authenticity and integrity of the exchanged packets
for a association. NTP does not provide a mechanism for the exchange for a association. NTP does not provide a mechanism for the exchange
of the keys between the associated nodes. Therefore, for each of the keys between the associated nodes. Therefore, for each
association, keys have to be exchanged securely by external means. association, keys have to be exchanged securely by external means.
It is recommended that each association be protected by its own It is recommended that each association be protected by its own
unique key. NTP does not provide a mechanism to automatically unique key. NTP does not provide a mechanism to automatically
refresh the applied keys. It is therefore recommended that the refresh the applied keys. It is therefore recommended that the
participants periodically agree on a fresh key. The calculation of participants periodically agree on a fresh key. The calculation of
the MAC may always be based on an MD5 hash. If the NTP daemon is the MAC may always be based on an MD5 hash, and an AES-128-CMAC hash
built against an OpenSSL library, NTP can also base the calculation is expected to soon be allowed as well. If the NTP daemon is built
of the MAC upon the SHA-1 or any other digest algorithm supported by against an OpenSSL library, NTP can also base the calculation of the
each side's OpenSSL library. MAC upon any other digest algorithm supported by each side's OpenSSL
library.
To use this approach the communication partners have to exchange the To use this approach the communication partners have to exchange the
key, which consists of a keyid with a value between 1 and 65534, key, which consists of a keyid with a value between 1 and 65534,
inclusive, and a label which indicates the chosen digest algorithm. inclusive, and a label which indicates the chosen digest algorithm.
Each communication partner adds this information to their key file in Each communication partner adds this information to their key file in
the form: the form:
keyid label key keyid label key
The key file contains the key in clear text. Therefore it should The key file contains the key in clear text. Therefore it should
only be readable by the NTP process. Different keys are added line only be readable by the NTP process. Different keys are added line
by line to the key file. by line to the key file.
A NTP client establishes a protected association by appending the A NTP client establishes a protected association by appending the
option "key keyid" to the server statement in the NTP configuration option "key keyid" to the server statement in the NTP configuration
file: file:
server address key keyid server address key keyid
Note that the NTP process has to trust the applied key. An NTP Note that the NTP process has to trust the applied key. A key is
process explicitly has to add each key it want to trust to a list of deemed trusted when its keyid is added to the list of trusted keys by
trusted keys by the "trustedkey" statement in the NTP configuration the "trustedkey" statement in the NTP configuration file.
file.
trustedkey keyid_1 keyid_2 ... keyid_n trustedkey keyid_1 keyid_2 ... keyid_n
5.2. Autokey 5.2. Autokey
Autokey was designed in 2003 to provide a means for clients to Autokey was designed in 2003 to provide a means for clients to
authenticate servers. However, by 2011, security researchers had authenticate servers. However, security researchers have identified
identified grave vulnerabilities leading to a complete breach of the vulnerabilities in the Autokey protocol, which make the protocol
protocol in real time on commodity hardware, which renders it "useless". [13]
"completely useless". [12])
It is strongly recommended that Autokey not be used. Autokey SHOULD NOT BE USED.
5.3. Network Time Security 5.3. Network Time Security
Work has begun on an enhanced replacement for Autokey, which is Work has begun on an enhanced replacement for Autokey, which is
called Network Time Security (NTS) [NTS]. NTS was first published as called Network Time Security (NTS) [NTS]. NTS was published in the
an Internet-Draft in the summer of 2013. As of October 2016, this summer of 2013. As of October 2016, this effort was at draft #15,
effort was at draft #15, and about to begin 'final call'. The first and about to begin 'final call'. The first unicast implementation of
unicast implementation of NTS was started in the summer of 2015 and NTS was started in the summer of 2015 and is expected to be released
is expected to be released in early 2017. in early 2017.
6. NTP Security Best Practices 6. NTP Security Best Practices
6.1. Minimizing Information Leakage 6.1. Minimizing Information Leakage
The base NTP packet leaks important information (including reference The base NTP packet leaks important information (including reference
ID and reference time) that can be used in attacks [NDSS16], ID and reference time) that may be used in attacks [NDSS16],
[CVE-2015-8138], [CVE-2016-1548]. A remote attacker can learn this [CVE-2015-8138], [CVE-2016-1548]. A remote attacker can learn this
information by sending mode 3 queries to a target system and information by sending mode 3 queries to a target system and
inspecting the fields in the mode 4 response packet. NTP control inspecting the fields in the mode 4 response packet. NTP control
queries also leak important information (including reference ID, queries also leak important information (including reference ID,
expected origin timestamp, etc.) that can be used in attacks expected origin timestamp, etc.) that may be used in attacks
[CVE-2015-8139]. A remote attacker can learn this information by [CVE-2015-8139]. A remote attacker can learn this information by
sending control queries to a target system and inspecting the sending control queries to a target system and inspecting the
response. response.
As such, access control should be used to prevent the exposure of As such, access control should be used to limit the exposure of this
this information to inappropriate third parties. information to inappropriate third parties.
Hosts should only respond to NTP control queries from authorized Hosts should only respond to NTP control queries from authorized
parties. One way to do this is to only allow control queries from parties. One way to do this is to only allow control queries from
authorized IP addresses. authenticated sources via authorized IP addresses.
A host that is not supposed to act as an NTP server that provides A host that is not supposed to act as an NTP server that provides
timing information to other hosts should additionally drop incoming timing information to other hosts may additionally log and drop
mode 3 timing queries. incoming mode 3 timing queries from unexpected sources. Note well
that the easiest way to monitor ntpd's status is to send it a mode 3
query. A much better appropach might be to filter mode 3 queries at
the edge, or make sure mode 3 queries are allowed from trusted
systems or networks.
A "leaf client" is a host that is using NTP solely for the purpose of An "leaf-node host" is host that is using NTP solely for the purpose
adjusting its own time. A leaf client should not be a time server to of adjusting its own system time. Such a host is not expected to
other hosts. That is, a leaf client sends mode 3 queries to its provide time to other hosts, and relies exclusively on NTP's basic
servers and receives mode 4 responses from these servers containing mode to take time from a set of servers. (That is, the host sends
timing information. To minimize information leakage, leaf clients mode 3 queries to its servers and receives mode 4 responses from
should drop all incoming NTP packets except for packets coming from these servers containing timing information.) To minimize
trusted monitoring systems and mode 4 response packets that come from information leakage, leaf-node hosts should drop all incoming NTP
its configured time sources. packets except mode 4 response packets that come from unknown
sources. Note well that proper monitoring of an ntpd instance
includes checking the time of that ntpd instance.
6.2. Avoiding Daemon Restart Attacks 6.2. Avoiding Daemon Restart Attacks
[RFC5905] says NTP clients should not accept time shifts greater than RFC 5905 [RFC5905] says NTP clients should not accept time shifts
the panic threshold. Specifically, RFC5905 says "PANIC means the greater than the panic threshold. Specifically, RFC 5905 says "PANIC
offset is greater than the panic threshold PANICT (1000 s) and should means the offset is greater than the panic threshold PANICT (1000 s)
cause the program to exit with a diagnostic message to the system and SHOULD cause the program to exit with a diagnostic message to the
log." system log."
However, this behavior is designed to be used only in cold-start However, this behavior can be exploited by attackers [NDSS16], when
situations. If it is used in more general situations it can be the following two conditions hold:
exploited by attackers [NDSS16] when ntpd is restarted with a
disabled panic gate check.
If your operating system has init scripts, these scripts should not 1. The operating system automatically restarts the NTP daemon when
disable panic gate checking on restarts. it quits. (Modern *NIX 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. It is likely to become the default behavior in other
systems as they migrate legacy init scripts to process
supervisors such as systemd.)
A growing number of operating systems use process supervisors such as 2. If, against long-standing recommendation, ntpd is always started
systemd to automatically restart any daemons that quit. This with the -g option, it will ignore the panic threshold when it is
behavior is the default in CoreOS and Arch Linux. It is likely to restarted. The -g option SHOULD only be provided in cold-start
become the default behavior in other Linux-based systems as they situations.
migrate legacy init scripts to systemd. These scripts should not
disable panic gate checking on restarts.
If, against long-standing recommendations, a system disables panic In such cases, if the attacker can send the target an offset that
gate checking on all restarts, an attacker can send the target an exceeds the panic threshold, the client will quit. Then, when the
offset that exceeds the panic threshold, causing the client to quit. client restarts, it ignores the panic threshold and accepts the
Then, when the client restarts, it ignores the panic threshold and attacker's large offset.
accepts the attacker's large offset.
Hosts running with the above two conditions should be aware that the Hosts running with the above two conditions should be aware that the
panic threshold does not protect them from attacks. A natural panic threshold does not protect them from attacks. The recommended
solution is not to run hosts with these conditions. and natural solution is not to run hosts with these conditions.
Specifically, only use the -g flag in cold-start situations, or when
sufficient oversight and checking is in place to make sure that the
use of -g is appropriate.
As an alternative, the following steps could be taken to mitigate the As an alternative, the following steps could be taken to mitigate the
risk of attack. risk of attack.
o Monitor NTP system log to detect when the NTP daemon has quit due o Monitor NTP system log to detect when the NTP daemon has quit due
to a panic event, as this could be a sign of an attack. to a panic event, as this could be a sign of an attack.
o Request manual intervention when a timestep larger than the panic o Request manual intervention when a timestep larger than the panic
threshold is detected. threshold is detected.
o Prevent the NTP daemon from taking time steps that set the clock 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. to a time earlier than the compile date of the NTP daemon.
o Modify the NTP daemon so that it "hangs" (ie does not quit, but o Add "minsane" and "minclock" parameters to the ntp.conf file so
just waits for a better timing samples but does not modify the ntpd waits until "enough" trusted sources of time agree on the
local clock) when it receives a large offset. correct time.
6.3. Detection of Attacks Through Monitoring 6.3. Detection of Attacks Through Monitoring
Users should monitor their NTP instances to detect attacks. Many Users should monitor their NTP instances to detect attacks. Many
known attacks on NTP have particular signatures. Common attack known attacks on NTP have particular signatures. Common attack
signatures include: signatures include:
1. "Bogus packets" - A packet whose origin timestamp does not match 1. "Bogus packets" - A packet whose origin timestamp does not match
the value that expected by the client. the value that expected by the client.
skipping to change at page 14, line 39 skipping to change at page 15, line 20
The observation of many such packets could indicate that the client The observation of many such packets could indicate that the client
is under attack. is under attack.
Also, Kiss-o'-Death (KoD) packets can be used in denial of service Also, Kiss-o'-Death (KoD) packets can be used in denial of service
attacks. Thus, the observation of even just one KoD packet with a attacks. Thus, the observation of even just one KoD packet with a
high poll value (e.g. poll>10) could be sign that the client is under high poll value (e.g. poll>10) could be sign that the client is under
attack. attack.
6.4. Broadcast Mode Should Only Be Used On Trusted Networks 6.4. Broadcast Mode Should Only Be Used On Trusted Networks
Per [RFC5905], NTP's broadcast mode is authenticated using symmetric Per RFC 5905 [RFC5905], NTP's broadcast mode is authenticated using
key cryptography. The broadcast server and all of its broadcast symmetric key cryptography. The broadcast server and all of its
clients share a symmetric cryptographic key, and this key is used by broadcast clients share a symmetric cryptographic key, and the
the broadcast server to build and by the broadcast clients to broadcast server uses this key to append a message authentication
authenticate the Message Authentication Code (MAC) that protects NTP code (MAC) to the broadcast packets it sends.
broadcast packets.
Put another way, all broadcast clients that listen to broadcast Importantly, all broadcast clients that listen to this server must
servers know and share the same cryptographic key. This mean that know the cryptographic key. This mean that any client can use this
any client can use this key to send valid broadcast messages that key to send valid broadcast messages that look like they come from
look like they come from the broadcast server. Thus, a rogue with the broadcast server. Thus, a rogue broadcast client can use its
knowledge of this key cab attack broadcast clients. knowledge of this key to attack the other broadcast clients.
For this reason, all NTP broadcast servers and clients need to trust For this reason, an NTP broadcast server and all its client must
each other. Broadcast mode should only be run from within a trusted trust each other. Broadcast mode should only be run from within a
network. trusted network.
Starting with ntp-4.2.8p7 the ntp.keys file accepts an optional 4th Starting with ntp-4.2.8p7 the ntp.keys file accepts an optional 4th
column, a comma-separated list of IPs that are allowed to serve time. column, a comma-separated list of IPs that are allowed to serve time.
Use this feature. Use this feature.
Updated NTP broadcast clients are protected against and detect these
attacks by reporting unexpected or inconsistent broadcast packets,
and by ignoring broadcast packets that arrive "too early". Monitor
your NTP log files.
6.5. Symmetric Mode Should Only Be Used With Trusted Peers 6.5. Symmetric Mode Should Only Be Used With Trusted Peers
In symmetric mode, two peers Alice and Bob can both push and pull In symmetric mode, two peers Alice and Bob can both push and pull
synchronization to and from each other using either ephemeral synchronization to and from each other using either ephemeral
symmetric passive (mode 2) or persistent symmetric active (NTP mode symmetric passive (mode 2) or persistent symmetric active (NTP mode
1) packets. The persistent association is preconfigured and 1) packets. The persistent association is preconfigured and
initiated at the active peer but not preconfigured at the passive initiated at the active peer but not preconfigured at the passive
peer (Bob). Upon receipt of a mode 1 NTP packet from Alice, Bob peer (Bob). Upon receipt of a mode 1 NTP packet from Alice, Bob
mobilizes a new ephemeral association if he does not have one mobilizes a new ephemeral association if he does not have one
already. This is a security risk for Bob because an arbitrary 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 attacker can attempt to change Bob's time by asking Bob to become its
symmetric passive peer. symmetric passive peer.
For this reason, a host (Bob) should only allow symmetric passive For this reason, a host (Bob) should only allow symmetric passive
associations to be established with trusted peers. Specifically, Bob associations to be established with trusted peers. Specifically, Bob
should require each of its symmetric passive association to be should require each of its symmetric passive association to be
cryptographically authenticated. Each symmetric passive association cryptographically authenticated. Each symmetric passive association
should be authenticated under a different cryptographic key. should be authenticated under a different cryptographic key.
The use of a different cryptographic key for each peer association The use of a different cryptographic key per peer prevents a Sybil
prevents a Sybil attack, where a single malicious peer uses the same attack, where a single malicious peer uses the same cryptographic key
cryptographic key to set up multiple symmetric associations a target, to set up multiple symmetric associations a target, and thus bias the
and thus bias the results of the target's Byzantine fault tolerant results of the target's Byzantine fault tolerant peer selection
peer selection algorithms. algorithms.
Starting with ntp-4.2.8p7 the ntp.keys file accepts an optional 4th
column, a comma-separated list of IPs that are allowed to serve time.
Use this feature.
7. NTP in Embedded Devices 7. NTP in Embedded Devices
Readers of this BCP likely already understand how important accurate Readers of this BCP likely already understand how important accurate
time is for network computing. And as computing becomes more time is for network computing. And as computing becomes more
ubiquitous, there will be many "Internet of Things" devices that ubiquitous, there will be many small "Internet of Things" devices
require accurate time. These embedded devices might not have a that require accurate time. These embedded devices may not have a
traditional user interface, but if they connect to the Internet they traditional user interface, but if they connect to the Internet they
will be subject to the same security threats as traditional will be subject to the same security threats as traditional
deployments. deployments.
7.1. Updating Embedded Devices 7.1. Updating Embedded Devices
Vendors of embedded devices have a special responsibility to pay Vendors of embedded devices have a special responsibility to pay
attention to the current state of NTP bugs and security issues and attention to the current state of NTP bugs and security issues,
fix them quickly, because their customers don't have the ability to because their customers don't have the ability to update their NTP
update their NTP implementation on their own. Those devices might implementation on their own. Those devices may have a single
have a single firmware upgrade, provided by the manufacturer, that firmware upgrade, provided by the manufacturer, that updates all
updates all capabilities at once. This means that the vendor assumes capabilities at once. This means that the vendor assumes the
the responsibility of making sure their devices have the latest NTP responsibility of making sure their devices have the latest NTP
updates applied. updates applied.
This should also include the ability to update any NTP server This should also include the ability to update any NTP server
addresses on these devices. addresses on these devices.
There is a catalog of NTP server abuse incidents, some of which There is a catalog of NTP server abuse incidents, some of which
involve embedded devices, on the Wikipedia page for NTP Server Misuse involve embedded devices, on the Wikipedia page for NTP Server Misuse
and Abuse [13]. and Abuse [14].
7.2. KISS Packets 7.2. KISS Packets
The "Kiss-o'-Death" (KoD) packet is a rate limiting mechanism where a The "Kiss-o'-Death" (KoD) packet is a rate limiting mechanism where a
server can tell a misbehaving client to "back off" its query rate. server can tell a misbehaving client to "back off" its query rate.
It is important for all NTP devices to respect these packets and back It is important for all NTP devices to respect these packets and back
off when asked to do so by a server. It is even more important for off when asked to do so by a server. It is even more important for
an embedded device, which may not have exposed a control interface an embedded device, which may not have exposed a control interface
for NTP. for NTP.
The KoD mechanism relies on clients behaving properly in order to be The KoD mechanism relies on clients behaving properly in order to be
effective. Some clients ignore the KoD packet entirely, and other effective. Some clients ignore the KoD packet entirely, and other
poorly-implemented clients erroneously and destructively increase poorly-implemented clients might unintentionally increase their poll
their poll rate and create a low-level denial of service attack. rate and simulate a denial of service attack. Server administrators
Server administrators should be prepared for this and take measures should be prepared for this and take measures outside of the NTP
outside of the NTP protocol to drop packets from misbehaving clients. protocol to drop packets from misbehaving clients.
7.3. Server configuration 7.3. Server configuration
Vendors of embedded devices that need time synchronization should Vendors of embedded devices that need time synchronization should
also carefully consider where they get their time from. There are also carefully consider where they get their time from. There are
several public-facing NTP servers available, but they might not be several public-facing NTP servers available, but they may not be
prepared to service requests from thousands of new devices on the prepared to service requests from thousands of new devices on the
Internet. Internet.
Vendors are encouraged to invest resources into providing their own Vendors are encouraged to invest resources into providing their own
time servers for their devices to connect to. time servers for their devices to connect to.
7.3.1. Get a vendor subdomain for pool.ntp.org 7.3.1. Get a vendor subdomain for pool.ntp.org
The NTP Pool Project offers a program where vendors can obtain their The NTP Pool Project offers a program where vendors can obtain their
own subdomain that is part of the NTP Pool. This offers vendors the own subdomain that is part of the NTP Pool. This offers vendors the
ability to safely make use of the time distributed by the Pool for ability to safely make use of the time distributed by the Pool for
their devices. Vendors are encouraged to support the pool if they their devices. Vendors are encouraged to support the pool if they
participate. For more information, visit http://www.pool.ntp.org/en/ participate. For more information, visit http://www.pool.ntp.org/en/
vendors.html . vendors.html .
8. NTP over Anycast 8. NTP over Anycast
Anycast is described in BCP 126 [RFC4786], with additional Anycast is described in BCP 126 [RFC4786]. (Also see RFC 7094
information at RFC 7094 [RFC7094]. With anycast, single IP address [RFC7094]). With anycast, a single IP address is assigned to
is assigned to multiple interfaces, and routers direct packets to the multiple interfaces, and routers direct packets to the closest active
closest active interface. interface.
Anycast is often used for Internet services at known IP addresses, Anycast is often used for Internet services at known IP addresses,
such as DNS. Anycast could be used in large organizations to such as DNS. Anycast can also be used in large organizations to
simplify configuration of a large number of NTP clients, but note simplify configuration of a large number of NTP clients. Each client
well this simplification comes at the cost of degraded NTP behavior can be configured with the same NTP server IP address, and a pool of
and performance. Each client can be configured with the same NTP anycast servers can be deployed to service those requests. New
server IP address, and a pool of anycast servers can be deployed to servers can be added to or taken from the pool, and other than a
service those requests. New servers can be added to or taken from temporary loss of service while a server is taken down, these
the pool, and other than a possible brief loss of service immediately additions can be transparent to the clients.
after server is taken down (and before packets are directed to a new
server), these additions are transparent to the clients.
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 are allowed to arbitrarily enter and leave the
network or as the routing behavior changes, the server a particular
client is connected to could change. This can cause a shift in the
delay and symmetry between the client and the server.
NOTE WELL: Using a single anycast address for NTP should be done with NOTE WELL: Using a single anycast address for NTP should be done with
care. It means there is likely to be an apparent single time server care. It means each client will likely use a single time server
source for the client population. A key element of a robust NTP source. A key element of a robust NTP deployment is each client
deployment is multiple sources of time. With multiple time servers a using multiple sources of time. With multiple time sources, a client
client can analyze the various time sources, selecting good ones, and will analyze the various time sources, selecting good ones, and
disregarding poor ones. Users that want this benefit should not rely disregarding poor ones. If a single Anycast address is used, this
on a single Anycast address for NTP. analysis will not happen.
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 are allowed to arbitrarily enter and leave the anycast servers may arbitrarily enter and leave the network, the
network, the server any given client is connected to could change. server a particular client is connected to may change. This may
It is recommended that anycast be deployed in environments where cause a small shift in time from the perspective of the client when
these small shifts can be tolerated. the server it is connected to changes. It is recommended that
anycast only be deployed in environments where these small shifts can
be tolerated.
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 anycast server, even if that will always connect to the closest server, even if that server is
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 all servers and clients. If a server is not performance of NTP on a server. If the server is not performing to
performing to specification, it should remove itself from the Anycast specification, it should remove itself from the Anycast network. It
network. It is also recommended that each Anycast NTP server have at is also recommended that each Anycast NTP server have at least one
least one Unicast interface so its performance can be checked Unicast interface, so its performance can be checked independently of
independently of the anycast routing scheme. the anycast routing scheme.
One useful application in large networks is to use a hybrid unicast/ One useful application in large networks is to use a hybrid unicast/
anycast approach. Stratum 1 NTP servers can be deployed with unicast anycast approach. Stratum 1 NTP servers can be deployed with unicast
interfaces at several sites. Each site could have several Stratum 2 interfaces at several sites. Each site may have several Stratum 2
servers with two ethernet interfaces. One interface has a unique servers with two ethernet interfaces. One interface has a unique
unicast IP address. The second has an anycast IP interface (with a unicast IP address. The second has an anycast IP interface (with a
shared IP address per location). The unicast interfaces can be used shared IP address per location). The unicast interfaces can be used
to obtain time from the Stratum 1 servers globally (and perhaps peer to obtain time from the Stratum 1 servers globally (and perhaps peer
with the other Stratum 2 servers at their site). Clients at each 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 can be configured to use the shared anycast address for their
site, simplifying their configuration. Keeping the anycast routing site, simplifying their configuration. Keeping the anycast routing
restricted on a per-site basis will minimize the disruption at the restricted on a per-site basis will minimize the disruption at the
client if its closest anycast server changes. Each Stratum 2 server client if its closest anycast server changes. Each Stratum 2 server
can be uniquely identified on their unicast interface, to make can be uniquely identified on their unicast interface, to make
monitoring easier. monitoring easier.
9. Acknowledgements 9. Acknowledgements
The authors wish to acknowledge the contributions of Sue Graves, The authors wish to acknowledge the contributions of Sue Graves,
Samuel Weiler, Lisa Perdue, Karen O'Donoghue, David Malone, Sharon Samuel Weiler, Lisa Perdue, Karen O'Donoghue, David Malone, Sharon
Goldberg, Martin Burnicki, Miroslav Lichvar, and Daniel Fox Franke. Goldberg, Martin Burnicki, Miroslav Lichvar, Daniel Fox Franke, and
Robert Nagy.
10. IANA Considerations 10. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
11. Security Considerations 11. Security Considerations
Time is a fundamental component of security on the internet. Time is a fundamental component of security on the internet.
Credentials and certificates can expire. Logins and other forms of Credentials and certificates can expire. Logins and other forms of
access can be revoked after a period of time, or at a scheduled time. access can be revoked after a period of time, or at a scheduled time.
And some applications might assume that system time cannot be changed And some applications may assume that system time cannot be changed
and is always monotonic, and vulnerabilites could be exposed if a and is always monotonic, and vulnerabilites may be exposed if a time
time in the past is forced into a system. Therefore, any system in the past is forced into a system. Therefore, any system
adminstrator concerned with security should be concerned with how the adminstrator concerned with security should be concerned with how the
current time gets into their system. current time gets into their system.
[NTS] is an Internet-Draft of a collection of methods to secure time [NTS] is an Internet-Draft of a collection of methods to secure time
transfer over networks. [NTSFORNTP] is an Internet-Draft that transfer over networks. [NTSFORNTP] is an Internet-Draft that
applies the methods in [NTS] specifically to NTP. At the time of applies the methods in [NTS] specifically to NTP. At the time of
this writing, these are still drafts. Readers are encouraged to this writing, these are still drafts. Readers are encourages to
check the status of these drafts, and make use of the methods they check the status of these drafts, and make use of the methods they
describe. describe.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 20, line 16 skipping to change at page 20, line 41
Van Gundy, M., "NETWORK TIME PROTOCOL NTPQ AND NTPDC Van Gundy, M., "NETWORK TIME PROTOCOL NTPQ AND NTPDC
ORIGIN TIMESTAMP DISCLOSURE VULNERABILITY", 2016, ORIGIN TIMESTAMP DISCLOSURE VULNERABILITY", 2016,
<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>.
[MILLS2006]
Mills, D., "Computer network time synchronization: the
Network Time Protocol", CRC Press , 2006.
[NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, [NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg,
"Attacking the Network Time Protocol", NDSS'16, San Diego, "Attacking the Network Time Protocol", NDSS'16, San Diego,
CA. , 2016, <https://eprint.iacr.org/2015/1020.pdf>. CA. , 2016, <https://eprint.iacr.org/2015/1020.pdf>.
[NTS] Sibold, D., Roettger, S., and K. Teichel, "Network Time [NTS] Sibold, D., Roettger, S., and K. Teichel, "Network Time
Security", draft-ietf-ntp-network-time-security-15 (work Security", draft-ietf-ntp-network-time-security-15 (work
in progress), September 2016. in progress), September 2016.
[NTSFORNTP] [NTSFORNTP]
Sibold, D., Roettger, S., and K. Teichel, "Using the Sibold, D., Roettger, S., and K. Teichel, "Using the
Network Time Security Specification to Secure the Network Network Time Security Specification to Secure the Network
Time Protocol", draft-ietf-ntp-using-nts-for-ntp-06 (work Time Protocol", draft-ietf-ntp-using-nts-for-ntp-06 (work
in progress), September 2016. in progress), September 2016.
12.3. URIs 12.3. URIs
[1] http://www.ntp.org/downloads.html [1] http://www.ntp.org/downloads.html
[2] https://github.com/ntp-project/ntp [2] http://bk.ntp.org/
[3] http://www.bcp38.info [3] https://github.com/ntp-project/ntp
[6] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time [4] http://www.bcp38.info
[7] https://www.iers.org/IERS/EN/Publications/Bulletins/ [7] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time
[8] https://www.iers.org/IERS/EN/Publications/Bulletins/
bulletins.html bulletins.html
[8] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time [9] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time
[9] https://www.ietf.org/timezones/data/leap-seconds.list [10] https://www.ietf.org/timezones/data/leap-seconds.list
[12] https://lists.ntp.org/pipermail/ntpwg/2011-August/001714.html [11] http://bk1.ntp.org/ntp-stable/README.leapsmear?PAGE=anno
[13] https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse [13] https://lists.ntp.org/pipermail/ntpwg/2011-August/001714.html
[14] https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse
Authors' Addresses Authors' Addresses
Denis Reilly (editor) Denis Reilly (editor)
Spectracom Spectracom
1565 Jefferson Road, Suite 460 1565 Jefferson Road, Suite 460
Rochester, NY 14623 Rochester, NY 14623
US US
Email: denis.reilly@spectracom.orolia.com Email: denis.reilly@spectracom.orolia.com
 End of changes. 118 change blocks. 
346 lines changed or deleted 372 lines changed or added

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