draft-ietf-ntp-bcp-04.txt   draft-ietf-ntp-bcp-05.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: November 22, 2017 Network Time Foundation Expires: December 15, 2017 Network Time Foundation
D. Sibold D. Sibold
PTB PTB
May 21, 2017 June 13, 2017
Network Time Protocol Best Current Practices Network Time Protocol Best Current Practices
draft-ietf-ntp-bcp-04 draft-ietf-ntp-bcp-05
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 November 22, 2017. This Internet-Draft will expire on December 15, 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 31 skipping to change at page 2, line 31
4.6.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 10 4.6.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 10
4.7. Configuring ntpd . . . . . . . . . . . . . . . . . . . . 11 4.7. Configuring ntpd . . . . . . . . . . . . . . . . . . . . 11
5. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 11 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 . 15 6.4. KISS Packets . . . . . . . . . . . . . . . . . . . . . . 15
6.5. Symmetric Mode Should Only Be Used With Trusted Peers . . 15 6.5. Broadcast Mode Should Only Be Used On Trusted Networks . 15
7. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 16 6.6. Symmetric Mode Should Only Be Used With Trusted Peers . . 16
7.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 16 7. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 17
7.2. KISS Packets . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 17
7.3. Server configuration . . . . . . . . . . . . . . . . . . 17 7.2. Server configuration . . . . . . . . . . . . . . . . . . 17
7.3.1. Get a vendor subdomain for pool.ntp.org . . . . . . . 17 7.2.1. Get a vendor subdomain for pool.ntp.org . . . . . . . 17
8. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 17 8. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 20
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
skipping to change at page 8, line 18 skipping to change at page 8, line 18
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 group of volunteers who have donated their The NTP pool project is a group of volunteers who have donated their
computing and bandwidth resources to freely distribute time from computing and bandwidth resources to freely distribute time from
primary time sources to others on the Internet. The time is primary time sources to others on the Internet. The time is
generally of good quality, but comes with no guarantee whatsoever. generally of good quality, but comes with no guarantee whatsoever.
If you are interested in using the pool, please review their If you are interested in using the pool, please review their
instructions at http://www.pool.ntp.org/en/use.html . instructions at http://www.pool.ntp.org/en/use.html.
If you are a vendor who wishes to provide time service to your If you are a vendor who wishes to provide time service to your
customers or clients, consider joining the pool and providing a customers or clients, consider joining the pool and providing a
"vendor zone" thru the pool project. "vendor zone" thru the pool project.
If you want to synchronize many computers, consider running your own If you want to synchronize many computers, consider running your own
NTP servers that are synchronized by the pool, and synchronizing your NTP servers that are synchronized by the pool, and synchronizing your
clients to your in-house NTP servers. This reduces the load on the clients to your in-house NTP servers. This reduces the load on the
pool. pool.
skipping to change at page 15, line 15 skipping to change at page 15, line 15
2. "Zero origin packet" - A packet with a origin timestamp set to 2. "Zero origin packet" - A packet with a origin timestamp set to
zero [CVE-2015-8138]. zero [CVE-2015-8138].
3. A packet with an invalid cryptographic MAC [CCR16]. 3. A packet with an invalid cryptographic MAC [CCR16].
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 could be sign that the client is under attack. See
attack. Section 6.4 for more information.
6.4. Broadcast Mode Should Only Be Used On Trusted Networks 6.4. KISS Packets
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.
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
an embedded device, which may not have exposed a control interface
for NTP.
That said, a client must only accept a KoD packet if it has a valid
origin timestamp. Once a RATE packet is accepted, the client should
increase its poll interval value (thus decreasing its polling rate)
up to a reasonable maximum. This maximum can vary by implementation
but should not exceed a poll interval value of 13 (2 hours). The
mechanism to determine how much to increase the poll interval value
is undefined in RFC 5905 [RFC5905]. If the client uses the poll
interval value sent by the server in the KoD packet, it must not
simply accept any value. Using large interval values may open a
vector for a denial-of-service attack that causes the client to stop
querying its server [NDSS16].
The KoD mechanism relies on clients behaving properly in order to be
effective. Some clients ignore the KoD packet entirely, and other
poorly-implemented clients might unintentionally increase their poll
rate and simulate a denial of service attack. Server administrators
should be prepared for this and take measures outside of the NTP
protocol to drop packets from misbehaving clients.
6.5. Broadcast Mode Should Only Be Used On Trusted Networks
Per RFC 5905 [RFC5905], NTP's broadcast mode is authenticated using Per RFC 5905 [RFC5905], NTP's broadcast mode is authenticated using
symmetric key cryptography. The broadcast server and all of its symmetric key cryptography. The broadcast server and all of its
broadcast clients share a symmetric cryptographic key, and the broadcast clients share a symmetric cryptographic key, and the
broadcast server uses this key to append a message authentication broadcast server uses this key to append a message authentication
code (MAC) to the broadcast packets it sends. code (MAC) to the broadcast packets it sends.
Importantly, all broadcast clients that listen to this server must Importantly, all broadcast clients that listen to this server must
know the cryptographic key. This mean that any client can use this know the cryptographic key. This mean that any client can use this
key to send valid broadcast messages that look like they come from key to send valid broadcast messages that look like they come from
the broadcast server. Thus, a rogue broadcast client can use its the broadcast server. Thus, a rogue broadcast client can use its
knowledge of this key to attack the other broadcast clients. knowledge of this key to attack the other broadcast clients.
For this reason, an NTP broadcast server and all its client must For this reason, an NTP broadcast server and all its client must
trust each other. Broadcast mode should only be run from within a trust each other. Broadcast mode should only be run from within a
trusted 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. Note, however, that an adversarial client that
knows the symmetric broadcast key could still easily spoof its source
IP to an IP that is allowed to serve time. (This is easy to do
because the origin timestamp on broadcast mode packets is not
validated by the client. By contrast, client/server and symmetric
modes do require origin timestamp validation, making it more
difficult to spoof packets [CCR16].
6.5. Symmetric Mode Should Only Be Used With Trusted Peers 6.6. 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
skipping to change at page 17, line 5 skipping to change at page 17, line 33
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 [14]. and Abuse [14].
7.2. KISS Packets 7.2. Server configuration
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.
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
an embedded device, which may not have exposed a control interface
for NTP.
The KoD mechanism relies on clients behaving properly in order to be
effective. Some clients ignore the KoD packet entirely, and other
poorly-implemented clients might unintentionally increase their poll
rate and simulate a denial of service attack. Server administrators
should be prepared for this and take measures outside of the NTP
protocol to drop packets from misbehaving clients.
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 may 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.2.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
 End of changes. 12 change blocks. 
36 lines changed or deleted 54 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/