draft-ietf-ntp-bcp-00.txt   draft-ietf-ntp-bcp-01.txt 
Internet Engineering Task Force D. Reilly Internet Engineering Task Force D. Reilly, Ed.
Internet-Draft Spectracom Corporation Internet-Draft Spectracom Corporation
Intended status: Best Current Practice H. Stenn Intended status: Best Current Practice H. Stenn
Expires: January 25, 2017 Network Time Foundation Expires: April 7, 2017 Network Time Foundation
D. Sibold D. Sibold
PTB PTB
July 24, 2016 October 4, 2016
Network Time Protocol Best Current Practices Network Time Protocol Best Current Practices
draft-ietf-ntp-bcp-00 draft-ietf-ntp-bcp-01
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 January 25, 2017. This Internet-Draft will expire on April 7, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 6
4.5. Using Pool Servers . . . . . . . . . . . . . . . . . . . 7 4.5. Using Pool Servers . . . . . . . . . . . . . . . . . . . 7
4.6. Leap Second Handling . . . . . . . . . . . . . . . . . . 7 4.6. Leap Second Handling . . . . . . . . . . . . . . . . . . 8
4.6.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 8 4.6.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 9
5. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 9 4.7. Configuring ntpd . . . . . . . . . . . . . . . . . . . . 10
5.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . . . 9 5. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 10
5.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . . . 10
6. NTP Security Best Practices . . . . . . . . . . . . . . . . . 10 5.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Minimizing Information Leakage . . . . . . . . . . . . . 10 5.3. Network Time Security . . . . . . . . . . . . . . . . . . 11
6.2. Avoiding Daemon Restart Attacks . . . . . . . . . . . . . 11 6. NTP Security Best Practices . . . . . . . . . . . . . . . . . 12
6.3. Detection of Attacks Through Monitoring . . . . . . . . . 12 6.1. Minimizing Information Leakage . . . . . . . . . . . . . 12
6.4. Broadcast Mode Should Only Be Used On Trusted Networks . 13 6.2. Avoiding Daemon Restart Attacks . . . . . . . . . . . . . 12
6.5. Symmetric Mode Should Only Be Used With Trusted Peers . . 13 6.3. Detection of Attacks Through Monitoring . . . . . . . . . 13
7. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 13 6.4. Broadcast Mode Should Only Be Used On Trusted Networks . 14
7.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 14 6.5. Symmetric Mode Should Only Be Used With Trusted Peers . . 14
7.2. KISS Packets . . . . . . . . . . . . . . . . . . . . . . 14 7. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 15
7.3. Server configuration . . . . . . . . . . . . . . . . . . 14 7.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 15
7.3.1. Get a vendor subdomain for pool.ntp.org . . . . . . . 15 7.2. KISS Packets . . . . . . . . . . . . . . . . . . . . . . 15
8. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 15 7.3. Server configuration . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 7.3.1. Get a vendor subdomain for pool.ntp.org . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 16
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 16 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . 18
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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
The best way to protect computers and networks against undefined Many network security mechanisms rely on time as part of their
behavior and security threats related to time is to keep their NTP operation. If an attacker can spoof the time, they may be able to
implementations current. bypass or neutralize other security elements. For example, incorrect
time can disrupt the ability to reconcile logfile entries on the
affected system with events on other systems. The best way to
protect computers and networks against undefined behavior and
security threats related to time is to keep their NTP implementations
current.
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 can be
considered insecure after some time. considered insecure after some time. By keeping NTP implementations
current, network operators can make sure that older behaviors are not
Many security mechanisms rely on time as part of their operation. If exploited.
an attacker can spoof the time, they may be able to bypass or
neutralize other security elements. For example, incorrect time can
disrupt the ability to reconcile logfile entries on the affected
system with events on other systems.
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 reference implementation since the first NTPv4 release in Project's ntpd since the first NTPv4 release in 1997. Each version
1997. Each version release contains at least a few bug fixes. The release contains at least a few bug fixes. The best way to stay in
best way to stay in front of these issues is to keep your NTP front of these issues is to keep your NTP implementation current.
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
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
skipping to change at page 4, line 24 skipping to change at page 4, line 27
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 this. If a machine on a network is sending out
packets claiming to be from an address that is not on that network, packets claiming to be from an address that is not on that network,
this could be the first indication that there is a machine that has this could be the first indication that there is a machine that has
been compromised, and is being used abusively. If packets are been compromised, and is being used abusively. If packets are
arriving on an external interface with a source address that should arriving on an external interface with a source address that should
only be seen on an internal network, that's a strong indication that only be seen on an internal network, that's a strong indication that
an attacker is trying to inject spoofed packets into the network. an attacker is trying to inject spoofed packets into the network.
More information is available at http://www.bcp38.info . More information is available at the BCP38 Info page [3] .
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 maintained by the Network Time Foundation, may be implementation maintained by the Network Time Foundation, 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
NTP takes the available sources of time and submits their timing data ntpd takes the available sources of time and submits their timing
to intersection and clustering algorithms, looking for the best idea data to intersection and clustering algorithms, looking for the best
of the correct time. If there is only 1 source of time, the answer idea of the correct time.
is obvious. It may not be a good source of time, but it's the only
one. If there are 2 sources of time and they agree well enough, o If there is only 1 source of time, the answer is obvious. It may
that's good. But if they don't, then ntpd has no way to know which not be a good source of time, but it's the only one.
source to believe. This gets easier if there are 3 sources of time.
But if one of those 3 sources becomes unreachable or unusable, we're o If there are 2 sources of time and they agree well enough, that's
back to only having 2 time sources. 4 sources of time is another good. But if they don't, then ntpd has no way to know which
interesting choice, assuming things go well. If one of these sources source to believe.
develops a problem there are still 3 others. Seems good. But during
the leap second we had in June of 2015, several operators implemented o If there are 3 sources of time, you can tolerate one of those
sources becoming unreachable or unusable. But at that point, we
are back down to 2 sources.
o 4 sources of time is better. If one of these sources develops a
problem there are still 3 others.
But even with 4 or more sources of time, systemic issues can happen.
During the leap second of June of 2015, several operators implemented
leap smearing while others did not, and many NTP end nodes became leap smearing while others did not, and many NTP end nodes became
very confused. See Section 4.6.1 for more information. very confused. 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. servers and add in new servers as-needed.
Monitor your ntpd instances. If your times sources do not generally Monitor your ntpd instances. If your times sources do not generally
agree, find out why and either correct the problems or stop using agree, find out why and either correct the problems or stop using
defective servers. See Section 4.4 for more information. defective servers. See Section 4.4 for more information.
skipping to change at page 5, line 25 skipping to change at page 5, line 37
Are all clocks on a network from the same vendor? They may have the Are all clocks on a network from the same vendor? They may have 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 is 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. radio-based time source unusable. If the time on your network must
be correct close to 100% of the time, then even if you are using a
satellite-based system, you must plan for those rare instances when
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. Used improperly, debugging and performance information and control. Used improperly,
these facilities can be an abuse vector. these facilities can be an abuse vector.
Mode 7 queries have been disabled by default 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 The ability to use Mode 6 beyond its basic monitoring capabilities
can be limited to authenticated sessions that provide a 'controlkey', can be limited to authenticated sessions that provide a 'controlkey',
and similarly, if Mode 7 has been explicitly enabled its use for more and similarly, if Mode 7 has been explicitly enabled its use for more
than basic monitoring can be limited to authenticated sessions that than basic monitoring can be limited to authenticated sessions that
provide a 'requestkey'. provide a 'requestkey'.
Older versions of the reference implementation of NTP could be abused Older versions of the reference implementation of NTP could be abused
skipping to change at page 6, line 26 skipping to change at page 6, line 38
restrict ... nomodify restrict ... nomodify
Users can prevent their NTP servers from participating by adding the Users can prevent their NTP servers from participating by adding the
following to their ntp.conf file: following to their 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 # nopeer is OK if you don't restrict source nomodify notrap noquery
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. The The reference implementation of NTP allows remote monitoring. The
access to this service is controlled by the restrict statement in access to this service is controlled by the restrict statement in
NTP's configuration file (ntp.conf). The syntax reads: NTP's configuration file (ntp.conf). The syntax reads:
restrict address mask address_mask nomodify restrict address mask address_mask nomodify
Monitor ntpd instances so machines that are "out of sync" can be Monitor ntpd instances so machines that are "out of sync" can be
skipping to change at page 7, line 36 skipping to change at page 7, line 47
pool, please review their instructions at http://www.pool.ntp.org/en/ pool, please review their instructions at http://www.pool.ntp.org/en/
use.html . use.html .
If you want to synchronize many computers using the pool, consider If you want to synchronize many computers using the pool, consider
running your own NTP servers, synchronizing them to the pool, and running your own NTP servers, synchronizing them to the pool, and
synchronizing your clients to your in-house NTP servers. This synchronizing your clients to your in-house NTP servers. This
reduces the load on the pool. 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 pool.ntp.org [4] . instructions at pool.ntp.org [5] .
4.6. Leap Second Handling 4.6. Leap Second Handling
The UTC timescale is kept in sync with the rotation of the earth UTC is kept in agreement with the astronomical time UT1 [6] to witin
through the use of leap seconds. NTP time is based on the UTC +0.9 second (in absolute value) by the insertion of leap seconds.
timescale, and the protocol has the capability to broadcast leap UTC is an atomic time scale whereas UT1 is based on the rotational
second information. Some GNSS systems (like GPS) broadcast leap rate of the earth. Leap seconds are not introduced at a fixed rate.
second information, so if you have a Stratum-1 server synced to GNSS They are announced when necessary to keep UTC and UT1 aligned by the
(or you are synced to a lower stratum server that is ultimately IERS (International Earth rotation and Reference systems Service) in
synced to GNSS), you will get advance notification of impending leap its Bulletin C [7].
seconds automatically.
NTP time is based on the UTC timescale, and the protocol has the
capability to broadcast leap second information. Some GNSS systems
(like GPS) or radio transmitters (like DCF77) broadcast leap second
information, so if you have a Stratum-1 server synced to GNSS (or you
are synced to a lower stratum server that is ultimately synced to
GNSS), you will get advance notification of impending leap seconds
automatically.
Since the length of the UT1 day is slowly increasing [8], all leap
seconds that have been introduced since the practice started in 1972
have been "positive" leap seconds, where a second is added to UTC.
NTP also supports a "negative" leap second, where a second is removed
from UTC, should that ever become necessary.
While earlier versions of NTP contained some ambiguity regarding when While earlier versions of NTP contained some ambiguity regarding when
leap seconds could occur, RFC 5905 is clear that leap seconds are leap seconds could occur, RFC 5905 is clear that leap seconds are
processed at the end of a month. If an upstream server is processed at the end of a month. If an upstream server is
broadcasting that a leap second is pending, RFC5905-compliant servers broadcasting that a leap second is pending, RFC5905-compliant servers
should apply it at the end of the last minute of the last day of the should apply it at the end of the last minute of the last day of the
month. month.
The IETF maintains a leap second list The IETF maintains a leap second list [9] for NTP users who are not
(https://www.ietf.org/timezones/data/leap-seconds.list) for NTP users receiving leap second information through an automatic source. The
who are not receiving leap second information through an automatic use of leap second files requires ntpd 4.2.6 or later. After
source. The use of leap second files requires ntpd 4.2.6 or later. fetching the leap seconds file onto the server, add this line to
After fetching the leap seconds file onto the server, add this line ntpd.conf to apply the file:
to ntpd.conf to apply the file:
leapfile "/path/to your/leap-file" leapfile "/path/to your/leap-file"
You will need to restart to apply the changes. You will need to restart to apply the changes.
Files are 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/leap- US Navy (maintains GPS Time): ftp://tycho.usno.navy.mil/pub/ntp/leap-
skipping to change at page 8, line 24 skipping to change at page 9, line 4
leapfile "/path/to your/leap-file" leapfile "/path/to your/leap-file"
You will need to restart to apply the changes. You will need to restart to apply the changes.
Files are 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/leap- US Navy (maintains GPS Time): ftp://tycho.usno.navy.mil/pub/ntp/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
Servers with a manually configured leap second file will ignore leap ntpd servers with a manually configured leap second file will ignore
second information broadcast from upstream NTP servers until the leap leap second information broadcast from upstream NTP servers until the
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
always accepted by ntpd.
If no valid leap second file is available, a leap second notification
may be accepted from upstream NTP servers. As of ntpd 4.2.6, a
majority of servers must provide the notification before it is
accepted. Before 4.2.6, a leap second notification would be accepted
if only a single upstream server of a group of configured servers
provided a leap second notification. This would lead to misbehavior
if single NTP servers sent an invalid leap second warning, e.g. due
to a faulty GPS receiver in one server.
4.6.1. Leap Smearing 4.6.1. Leap Smearing
Some NTP installations may instead make use of a technique called Some NTP installations may instead make use of a technique called
"Leap Smearing". With this method, instead of introducing an extra "Leap Smearing". With this method, instead of introducing an extra
second (or eliminating a second), NTP time will be slewed in small second (or eliminating a second), NTP time will be slewed in small
increments over a comparably large window of time around the leap increments over a comparably large window of time (called the smear
second event. The amount of the slew should be small enough that interval) around the leap second event. The smear interval should be
clients will follow the smeared time without objecting. During the large enough to make the rate that the time is slewed small, so that
adjustment window, the NTP server's time may be offset from UTC by as clients will follow the smeared time without objecting. (86400s,
much as .5 seconds. This is done to enable software that doesn't which is 1 day, has been used sucessfully.) During the adjustment
deal with minutes that have more or less than 60 seconds to function window, all the NTP clients' times may be offset from UTC by as much
correctly, at the expense of fidelity to UTC during the smear window. as a full second, depending on the implementation. But at least all
clients will agree on what time they think it is!
The purpose of Leap Smearing is to enable software that doesn't deal
with the leap second event properly to function correctly, at the
expense of fidelity to UTC during the smear window. During a
standard leap second event, that minute will have 61 (or possibly 59)
seconds in it, and some applications (and even some OS's) are known
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.
Support is not configured by default and must be added at compile Support is not configured by default and must be added at compile
time. In addition, no leap smearing will occur unless a leap smear time. In addition, no leap smearing will occur unless a leap smear
interval is specified in ntpd.conf . For more information, refer to interval is specified in ntpd.conf . For more information, refer to
http://bk1.ntp.org/ntp-stable/README.leapsmear?PAGE=anno . http://bk1.ntp.org/ntp-stable/README.leapsmear?PAGE=anno .
Clients that are connected to leap smearing servers must never apply
the "standard" NTP leap second handling. So if they are using ntpd,
these clients must never have a leap second file loaded, and the
smearing servers must never advertise 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 may be configured this way anyway in spite of this guidance. servers may be configured this way anyway in spite of this 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 never be they are using deal with them. Individual clients must never be
configured to use a mixture of smeared and non-smeared servers. configured to use a mixture of smeared and non-smeared servers.
4.7. Configuring ntpd
See https://support.ntp.org/bin/view/Support/ConfiguringNTP for
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
skipping to change at page 10, line 26 skipping to change at page 11, line 35
trusted keys by the "trustedkey" statement in the NTP configuration trusted keys by 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. By 2011, security researchers had identified authenticate servers. By 2011, security researchers had identified
computational areas in the Autokey protocol that, while secure at the computational areas in the Autokey protocol that, while secure at the
time of its original design, were no longer secure. Work was begun time of its original design, were no longer secure.
on an enhanced replacement for Autokey, which was called Network Time
Security (NTS) [6]. NTS was published in the summer of 2013. As of
February 2016, this effort was at draft #13, and about to begin
'final call'. The first unicast implementation of NTS was started in
the summer of 2015 and is expected to be released in the summer of
2016.
We recommend that Autokey NOT BE USED. Know that as of the fall of We recommend that Autokey NOT BE USED. Know that as of the fall of
2011, a common(?) laptop computer could crack the security cookie 2011, a common(?) laptop computer could crack the security cookie
used in the Autokey protocol in 30 minutes' time. If you must use used in the Autokey protocol in 30 minutes' time. If you must use
Autokey, know that your session keys should be set to expire in under Autokey, know that your session keys should be set to expire in under
30 minutes' time. 30 minutes' time.
5.3. Network Time Security
Work has begun on an enhanced replacement for Autokey, which is
called Network Time Security (NTS) [NTS]. NTS was published in the
summer of 2013. As of October 2016, this effort was at draft #15,
and about to begin 'final call'. The first unicast implementation of
NTS was started in the summer of 2015 and is expected to be released
in 2016.
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 can 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,
skipping to change at page 14, line 12 skipping to change at page 15, line 20
for network computing. And as computing becomes more ubiquitous, for network computing. And as computing becomes more ubiquitous,
there will be many small "Internet of Things" devices that require there will be many small "Internet of Things" devices that require
accurate time. These embedded devices may not have a traditional accurate time. These embedded devices may not have a traditional
user interface, but if they connect to the Internet they will be user interface, but if they connect to the Internet they will be
subject to the same security threats as traditional deployments. subject to the same security threats as traditional 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, attention to the current state of NTP bugs and security issues,
because their customers usually don't have the ability to update because their customers don't have the ability to update their NTP
their NTP implementation on their own. Those devices may have a implementation on their own. Those devices may have a single
single firmware upgrade, provided by the manufacturer, that updates firmware upgrade, provided by the manufacturer, that updates all
all capabilities at once. This means that the vendor assumes the capabilities at once. This means that the vendor assumes 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 the NTP server This should also include the ability to update the NTP server
address. address.
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 [7]. and Abuse [12].
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.
skipping to change at page 17, line 30 skipping to change at page 18, line 41
"Architectural Considerations of IP Anycast", RFC 7094, "Architectural Considerations of IP Anycast", RFC 7094,
DOI 10.17487/RFC7094, January 2014, DOI 10.17487/RFC7094, January 2014,
<http://www.rfc-editor.org/info/rfc7094>. <http://www.rfc-editor.org/info/rfc7094>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <http://www.rfc-editor.org/info/rfc7384>. October 2014, <http://www.rfc-editor.org/info/rfc7384>.
12.2. Informative References 12.2. Informative References
[CCR16] Malhotra, and Goldberg, "Attacking NTP's Authenticated [CCR16] Malhotra, A. and S. Goldberg, "Attacking NTP's
Broadcast Mode", 2016. Authenticated Broadcast Mode", SIGCOMM Computer
Communications Review (CCR) , 2016.
[CVE-2015-8138] [CVE-2015-8138]
Van Gundy, and Gardner, "NETWORK TIME PROTOCOL ORIGIN Van Gundy, M. and J. Gardner, "NETWORK TIME PROTOCOL
TIMESTAMP CHECK IMPERSONATION VULNERABILITY", 2016, ORIGIN TIMESTAMP CHECK IMPERSONATION VULNERABILITY", 2016,
<http://www.talosintel.com/reports/TALOS-2016-0077>. <http://www.talosintel.com/reports/TALOS-2016-0077>.
[CVE-2015-8139] [CVE-2015-8139]
Van Gundy, , "NETWORK TIME PROTOCOL NTPQ AND NTPDC ORIGIN Van Gundy, M., "NETWORK TIME PROTOCOL NTPQ AND NTPDC
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, and Lichvar, "Xleave Pivot: NTP Basic Mode to Gardner, J. and M. Lichvar, "Xleave Pivot: NTP Basic Mode
Interleaved", 2016, <http://blog.talosintel.com/2016/04/ to Interleaved", 2016,
<http://blog.talosintel.com/2016/04/
vulnerability-spotlight-further-ntpd_27.html>. vulnerability-spotlight-further-ntpd_27.html>.
[NDSS16] Malhotra, , Cohen, , Brakke, , and Goldberg, "Attacking [NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg,
the Network Time Protocol", 2016, "Attacking the Network Time Protocol", NDSS'16, San Diego,
<https://eprint.iacr.org/2015/1020.pdf>. CA. , 2016, <https://eprint.iacr.org/2015/1020.pdf>.
[NTS] "Network Time Security", [NTS] Sibold, D., Roettger, S., and K. Teichel, "Network Time
<https://datatracker.ietf.org/doc/draft-ietf-ntp-network- Security", draft-ietf-ntp-network-time-security-15 (work
time-security/>. in progress), September 2016.
[NTSFORNTP] [NTSFORNTP]
"Using the Network Time Security Specification to Secure Sibold, D., Roettger, S., and K. Teichel, "Using the
the Network Time Protocol", Network Time Security Specification to Secure the Network
<https://datatracker.ietf.org/doc/draft-ietf-ntp-using- Time Protocol", draft-ietf-ntp-using-nts-for-ntp-06 (work
nts-for-ntp/>. 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] https://github.com/ntp-project/ntp
[4] http://www.pool.ntp.org/en/join.html [3] http://www.bcp38.info
[6] https://tools.ietf.org/html/draft-ietf-ntp-network-time- [5] http://www.pool.ntp.org/en/join.html
security-00
[7] https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse [6] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time
[7] https://www.iers.org/IERS/EN/Publications/Bulletins/
bulletins.html
[8] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time
[9] https://www.ietf.org/timezones/data/leap-seconds.list
[12] https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse
Authors' Addresses Authors' Addresses
Denis Reilly Denis Reilly (editor)
Spectracom Corporation Spectracom Corporation
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
Harlan Stenn Harlan Stenn
Network Time Foundation Network Time Foundation
P.O. Box 918 P.O. Box 918
 End of changes. 38 change blocks. 
123 lines changed or deleted 189 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/