draft-ietf-ntp-bcp-02.txt   draft-ietf-ntp-bcp-03.txt 
Internet Engineering Task Force D. Reilly, Ed. Internet Engineering Task Force D. Reilly, Ed.
Internet-Draft Spectracom Corporation Internet-Draft Spectracom
Intended status: Best Current Practice H. Stenn Intended status: Best Current Practice H. Stenn
Expires: May 4, 2017 Network Time Foundation Expires: October 15, 2017 Network Time Foundation
D. Sibold D. Sibold
PTB PTB
October 31, 2016 April 13, 2017
Network Time Protocol Best Current Practices Network Time Protocol Best Current Practices
draft-ietf-ntp-bcp-02 draft-ietf-ntp-bcp-03
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 May 4, 2017. This Internet-Draft will expire on October 15, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
5. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 10 5. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 10
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 . 14
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 . . . . . . . . . . . . . . . . . . . 16 7. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 15
7.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 16 7.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 16
7.2. KISS Packets . . . . . . . . . . . . . . . . . . . . . . 16 7.2. KISS Packets . . . . . . . . . . . . . . . . . . . . . . 16
7.3. Server configuration . . . . . . . . . . . . . . . . . . 17 7.3. Server configuration . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . 19
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20
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
skipping to change at page 12, line 10 skipping to change at page 12, line 10
Note that the NTP process has to trust the applied key. An NTP Note that the NTP process has to trust the applied key. An NTP
process explicitly has to add each key it want to trust to a list of process explicitly has to add each key it want to trust to a list of
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. However, by 2011, security researchers had
computational areas in the Autokey protocol that, while secure at the identified grave vulnerabilities leading to a complete breach of the
time of its original design, were no longer secure. protocol in real time on commodity hardware, which renders it
"completely useless". [12])
It is recommended that Autokey not be used. Know that as of the fall
of 2011, a common(?) laptop computer could crack the security cookie
used in the Autokey protocol in 30 minutes' time. If you want to use
Autokey, know that your session keys should be set to expire in under
30 minutes' time.
If you have reason to believe your autokey-protected associations It is strongly recommended that Autokey not be used.
will be attacked, you should read https://lists.ntp.org/pipermail/
ntpwg/2011-August/001714.html and decide what resources your
attackers might be using, and adjust the session key expiration time
accordingly.
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 first published as
an Internet-Draft in the summer of 2013. As of October 2016, this an Internet-Draft in the summer of 2013. As of October 2016, this
effort was at draft #15, and about to begin 'final call'. The first 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 unicast implementation of NTS was started in the summer of 2015 and
is expected to be released in early 2017. is expected to be released in early 2017.
skipping to change at page 16, line 31 skipping to change at page 16, line 21
have a single firmware upgrade, provided by the manufacturer, that have a single firmware upgrade, provided by the manufacturer, that
updates all capabilities at once. This means that the vendor assumes updates all capabilities at once. This means that the vendor assumes
the responsibility of making sure their devices have the latest NTP the 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 [12]. and Abuse [13].
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 50 skipping to change at page 17, line 39
after server is taken down (and before packets are directed to a new after server is taken down (and before packets are directed to a new
server), these additions are transparent to the clients. server), these additions are transparent to the clients.
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 are allowed to arbitrarily enter and leave the
network or as the routing behavior changes, the server a particular network or as the routing behavior changes, the server a particular
client is connected to could change. This can cause a shift in the client is connected to could change. This can cause a shift in the
delay and symmetry between the client and the server. delay and symmetry between the client and the server.
NOTE WELL: Using anycast for NTP is likely to be a bad idea, because NOTE WELL: Using a single anycast address for NTP should be done with
it means there is likely to be an apparent single time server source care. It means there is likely to be an apparent single time server
for the client population. A key element of a robust NTP deployment source for the client population. A key element of a robust NTP
is multiple sources of time. With multiple time servers a client can deployment is multiple sources of time. With multiple time servers a
analyze the various time sources, selecting good ones, and client can analyze the various time sources, selecting good ones, and
disregarding poor ones. In an Anycast scenario, this analysis is disregarding poor ones. Users that want this benefit should not rely
likely impossible. on a single Anycast address for NTP.
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 are allowed to arbitrarily enter and leave the
network, the server any given client is connected to could change. network, the server any given client is connected to could change.
It is recommended that anycast be deployed in environments where It is recommended that anycast be deployed in environments where
these small shifts can be tolerated. 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 anycast server, even if that
skipping to change at page 18, line 45 skipping to change at page 18, line 34
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, and Miroslav Lichvar. Goldberg, Martin Burnicki, Miroslav Lichvar, and Daniel Fox Franke.
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.
skipping to change at page 21, line 14 skipping to change at page 20, line 47
[6] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time [6] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time
[7] https://www.iers.org/IERS/EN/Publications/Bulletins/ [7] https://www.iers.org/IERS/EN/Publications/Bulletins/
bulletins.html bulletins.html
[8] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time [8] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time
[9] https://www.ietf.org/timezones/data/leap-seconds.list [9] https://www.ietf.org/timezones/data/leap-seconds.list
[12] https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse [12] https://lists.ntp.org/pipermail/ntpwg/2011-August/001714.html
[13] https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse
Authors' Addresses Authors' Addresses
Denis Reilly (editor) Denis Reilly (editor)
Spectracom Corporation 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
Harlan Stenn Harlan Stenn
Network Time Foundation Network Time Foundation
P.O. Box 918 P.O. Box 918
Talent, OR 97540 Talent, OR 97540
 End of changes. 17 change blocks. 
35 lines changed or deleted 28 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/