< draft-ietf-ntp-bcp-09.txt   draft-ietf-ntp-bcp-10.txt >
Internet Engineering Task Force D. Reilly, Ed. Internet Engineering Task Force D. Reilly, Ed.
Internet-Draft Orolia USA Internet-Draft Orolia USA
Intended status: Best Current Practice H. Stenn Intended status: Best Current Practice H. Stenn
Expires: June 15, 2019 Network Time Foundation Expires: June 16, 2019 Network Time Foundation
D. Sibold D. Sibold
PTB PTB
December 12, 2018 December 13, 2018
Network Time Protocol Best Current Practices Network Time Protocol Best Current Practices
draft-ietf-ntp-bcp-09 draft-ietf-ntp-bcp-10
Abstract Abstract
The Network Time Protocol (NTP) is one of the oldest protocols on the The Network Time Protocol (NTP) is one of the oldest protocols on the
Internet and has been widely used since its initial publication. Internet and has been widely used since its initial publication.
This document is a collection of Best Practices for general operation This document is a collection of Best Practices for general operation
of NTP servers and clients on the Internet. It includes of NTP servers and clients on the Internet. It includes
recommendations for stable, accurate and secure operation of NTP recommendations for stable, accurate and secure operation of NTP
infrastructure. This document is targeted at NTP version 4 as infrastructure. This document is targeted at NTP version 4 as
described in RFC 5905. described in RFC 5905.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 15, 2019. This Internet-Draft will expire on June 16, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
5. NTP Security Best Practices . . . . . . . . . . . . . . . . . 11 5. NTP Security Best Practices . . . . . . . . . . . . . . . . . 11
5.1. Minimizing Information Leakage . . . . . . . . . . . . . 11 5.1. Minimizing Information Leakage . . . . . . . . . . . . . 11
5.2. Avoiding Daemon Restart Attacks . . . . . . . . . . . . . 12 5.2. Avoiding Daemon Restart Attacks . . . . . . . . . . . . . 12
5.3. Detection of Attacks Through Monitoring . . . . . . . . . 13 5.3. Detection of Attacks Through Monitoring . . . . . . . . . 13
5.4. Kiss-o'-Death Packets . . . . . . . . . . . . . . . . . . 13 5.4. Kiss-o'-Death Packets . . . . . . . . . . . . . . . . . . 13
5.5. Broadcast Mode Should Only Be Used On Trusted Networks . 14 5.5. Broadcast Mode Should Only Be Used On Trusted Networks . 14
5.6. Symmetric Mode Should Only Be Used With Trusted Peers . . 14 5.6. Symmetric Mode Should Only Be Used With Trusted Peers . . 14
6. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 15 6. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 15
6.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 15 6.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 15
6.2. Server configuration . . . . . . . . . . . . . . . . . . 15 6.2. Server configuration . . . . . . . . . . . . . . . . . . 15
6.2.1. Get a vendor subdomain for pool.ntp.org . . . . . . . 16 6.2.1. NTP Pool Project Vendor Subdomains . . . . . . . . . 16
7. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 16 7. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 18
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. NTP Implementation by the Network Time Appendix A. NTP Implementation by the Network Time
Foundation . . . . . . . . . . . . . . . . . . . . . 21 Foundation . . . . . . . . . . . . . . . . . . . . . 21
A.1. Use enough time sources . . . . . . . . . . . . . . . . . 21 A.1. Use enough time sources . . . . . . . . . . . . . . . . . 21
A.2. NTP Control and Facility Messages . . . . . . . . . . . . 21 A.2. NTP Control and Facility Messages . . . . . . . . . . . . 21
A.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 22 A.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 22
A.4. Leap Second File . . . . . . . . . . . . . . . . . . . . 22 A.4. Leap Second File . . . . . . . . . . . . . . . . . . . . 22
A.5. Leap Smearing . . . . . . . . . . . . . . . . . . . . . . 23 A.5. Leap Smearing . . . . . . . . . . . . . . . . . . . . . . 23
A.6. Configuring ntpd . . . . . . . . . . . . . . . . . . . . 23 A.6. Configuring ntpd . . . . . . . . . . . . . . . . . . . . 23
A.7. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . . . 23 A.7. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . . . 23
skipping to change at page 16, line 12 skipping to change at page 16, line 12
Internet. Vendors SHOULD only synchronize to servers that they have Internet. Vendors SHOULD only synchronize to servers that they have
permission to use. permission to use.
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.
Vendors should read [RFC4085], which advises against embedding Vendors should read [RFC4085], which advises against embedding
globally-routable IP addresses in products, and offers several better globally-routable IP addresses in products, and offers several better
alternatives. alternatives.
6.2.1. Get a vendor subdomain for pool.ntp.org 6.2.1. NTP Pool Project Vendor Subdomains
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 [8] . vendors.html [8] .
7. NTP over Anycast 7. NTP over Anycast
skipping to change at page 18, line 17 skipping to change at page 18, line 17
[I-D.ietf-ntp-using-nts-for-ntp] specifies the Network Time Security [I-D.ietf-ntp-using-nts-for-ntp] specifies the Network Time Security
(NTS) mechanism and applies it to NTP. Readers are encouraged to (NTS) mechanism and applies it to NTP. Readers are encouraged to
check the status of the draft, and make use of the methods it check the status of the draft, and make use of the methods it
describes. describes.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
DOI 10.17487/RFC1305, March 1992,
<https://www.rfc-editor.org/info/rfc1305>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>. May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC4085] Plonka, D., "Embedding Globally-Routable Internet [RFC4085] Plonka, D., "Embedding Globally-Routable Internet
Addresses Considered Harmful", BCP 105, RFC 4085, Addresses Considered Harmful", BCP 105, RFC 4085,
DOI 10.17487/RFC4085, June 2005, DOI 10.17487/RFC4085, June 2005,
<https://www.rfc-editor.org/info/rfc4085>. <https://www.rfc-editor.org/info/rfc4085>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <https://www.rfc-editor.org/info/rfc4786>. December 2006, <https://www.rfc-editor.org/info/rfc4786>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
"Architectural Considerations of IP Anycast", RFC 7094,
DOI 10.17487/RFC7094, January 2014,
<https://www.rfc-editor.org/info/rfc7094>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>.
11.2. Informative References 11.2. Informative References
[BCP38INFO] [BCP38INFO]
"BCP38 Info Page", <http://www.bcp38.info>. "BCP38 Info Page", <http://www.bcp38.info>.
[CCR16] Malhotra, A. and S. Goldberg, "Attacking NTP's [CCR16] Malhotra, A. and S. Goldberg, "Attacking NTP's
Authenticated Broadcast Mode", SIGCOMM Computer Authenticated Broadcast Mode", SIGCOMM Computer
Communications Review (CCR) , 2016. Communications Review (CCR) , 2016.
[CVE-2015-8138] [CVE-2015-8138]
skipping to change at page 20, line 21 skipping to change at page 20, line 5
Mills, D., "Computer network time synchronization: the Mills, D., "Computer network time synchronization: the
Network Time Protocol", CRC Press , 2006. Network Time Protocol", CRC Press , 2006.
[NDSS14] Rossow, C., "Amplification Hell: Revisiting Network [NDSS14] Rossow, C., "Amplification Hell: Revisiting Network
Protocols for DDoS Abuse", NDSS'14, San Diego, CA. , 2014. Protocols for DDoS Abuse", NDSS'14, San Diego, CA. , 2014.
[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>.
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
DOI 10.17487/RFC1305, March 1992,
<https://www.rfc-editor.org/info/rfc1305>.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
"Architectural Considerations of IP Anycast", RFC 7094,
DOI 10.17487/RFC7094, January 2014,
<https://www.rfc-editor.org/info/rfc7094>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.3. URIs 11.3. URIs
[1] https://blog.cloudflare.com/technical-details-behind-a-400gbps- [1] https://blog.cloudflare.com/technical-details-behind-a-400gbps-
ntp-amplification-ddos-attack/ ntp-amplification-ddos-attack/
[2] http://www.pool.ntp.org/en/use.html [2] http://www.pool.ntp.org/en/use.html
skipping to change at page 20, line 50 skipping to change at page 20, line 48
bulletins.html bulletins.html
[5] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time [5] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time
[6] https://lists.ntp.org/pipermail/ntpwg/2011-August/001714.html [6] https://lists.ntp.org/pipermail/ntpwg/2011-August/001714.html
[7] https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse [7] https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse
[8] http://www.pool.ntp.org/en/vendors.html [8] http://www.pool.ntp.org/en/vendors.html
[9] http://www.ntp.org/downloads.html [9] http://bk1.ntp.org/ntp-stable/README.leapsmear?PAGE=anno
[10] http://bk1.ntp.org/ntp-stable/README.leapsmear?PAGE=anno
[11] https://support.ntp.org/bin/view/Support/ConfiguringNTP [10] https://support.ntp.org/bin/view/Support/ConfiguringNTP
Appendix A. NTP Implementation by the Network Time Foundation Appendix A. NTP Implementation by the Network Time Foundation
The Network Time Foundation (NTF) provides the reference The Network Time Foundation (NTF) provides the reference
implementation of NTP, well-known under the name "ntpd". It is implementation of NTP, well-known under the name "ntpd". It is
actively maintained and developed by NTF's NTP Project, with help actively maintained and developed by NTF's NTP Project, with help
from volunteers and NTF's supporters. This NTP software can be from volunteers and NTF's supporters. This NTP software can be
downloaded from ntp.org [9]. downloaded from <http://www.ntp.org/downloads.html>
A.1. Use enough time sources A.1. Use enough time sources
In addition to the recommendation given in Section Section 3.2 the In addition to the recommendation given in Section Section 3.2 the
ntpd implementation provides the 'pool' directive. Starting with ntpd implementation provides the 'pool' directive. Starting with
ntp-4.2.6, this directive will spin up enough associations to provide ntp-4.2.6, this directive will spin up enough associations to provide
robust time service, and will disconnect poor servers and add in new robust time service, and will disconnect poor servers and add in new
servers as-needed. If you have good reason, you may use the servers as-needed. If you have good reason, you may use the
'minclock' and 'maxclock' options of the 'tos' command to override 'minclock' and 'maxclock' options of the 'tos' command to override
the default values of how many servers are discovered through the the default values of how many servers are discovered through the
skipping to change at page 23, line 12 skipping to change at page 23, line 12
in the "early days" there was a greater chance that leap second in the "early days" there was a greater chance that leap second
information would be available from a very limited number of sources. information would be available from a very limited number of sources.
A.5. Leap Smearing A.5. Leap Smearing
Leap Smearing was introduced in ntpd versions 4.2.8.p3 and 4.3.47, in Leap Smearing was introduced in ntpd versions 4.2.8.p3 and 4.3.47, in
response to client requests. Support for leap smearing is not response to client requests. Support for leap smearing is not
configured by default and must be added at compile time. In configured by default and must be added at compile time. In
addition, no leap smearing will occur unless a leap smear interval is addition, no leap smearing will occur unless a leap smear interval is
specified in ntpd.conf . For more information, refer to specified in ntpd.conf . For more information, refer to
http://bk.ntp.org/ntp-stable/README.leapsmear?PAGE=anno [10]. http://bk.ntp.org/ntp-stable/README.leapsmear?PAGE=anno [9].
A.6. Configuring ntpd A.6. Configuring ntpd
See https://support.ntp.org/bin/view/Support/ConfiguringNTP [11] for See https://support.ntp.org/bin/view/Support/ConfiguringNTP [10] for
additional information on configuring ntpd. additional information on configuring ntpd.
A.7. Pre-Shared Keys A.7. Pre-Shared Keys
Each communication partner must add the keyid information to their Each communication partner must add the keyid information to their
key file in the form: key file in the form:
keyid label key keyid label key
An ntpd client establishes a protected association by appending the An ntpd client establishes a protected association by appending the
 End of changes. 16 change blocks. 
28 lines changed or deleted 26 lines changed or added

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