draft-ietf-ntp-bcp-11.txt   draft-ietf-ntp-bcp-12.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: July 21, 2019 Network Time Foundation Expires: July 29, 2019 Network Time Foundation
D. Sibold D. Sibold
PTB PTB
January 17, 2019 January 25, 2019
Network Time Protocol Best Current Practices Network Time Protocol Best Current Practices
draft-ietf-ntp-bcp-11 draft-ietf-ntp-bcp-12
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 July 21, 2019. This Internet-Draft will expire on July 29, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 35 skipping to change at page 2, line 35
4. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 9 4. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 9
4.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . . . 10 4.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . . . 10
4.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Network Time Security . . . . . . . . . . . . . . . . . . 11 4.3. Network Time Security . . . . . . . . . . . . . . . . . . 11
4.4. External Security Protocols . . . . . . . . . . . . . . . 11 4.4. External Security Protocols . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . 14 5.4. Kiss-o'-Death Packets . . . . . . . . . . . . . . . . . . 14
5.5. Broadcast Mode Should Only Be Used On Trusted Networks . 14 5.5. Broadcast Mode Should Only Be Used On Trusted Networks . 15
5.6. Symmetric Mode Should Only Be Used With Trusted Peers . . 15 5.6. Symmetric Mode Should Only Be Used With Trusted Peers . . 15
6. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 15 6. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 15
6.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 15 6.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 16
6.2. Server configuration . . . . . . . . . . . . . . . . . . 16 6.2. Server configuration . . . . . . . . . . . . . . . . . . 16
7. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 16 7. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . 19
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Best Practices specific to the Network Time Appendix A. Best Practices specific to the Network Time
Foundation implementation . . . . . . . . . . . . . 21 Foundation implementation . . . . . . . . . . . . . 21
A.1. Use enough time sources . . . . . . . . . . . . . . . . . 21 A.1. Use enough time sources . . . . . . . . . . . . . . . . . 21
A.2. NTP Control and Facility Messages . . . . . . . . . . . . 22 A.2. NTP Control and Facility Messages . . . . . . . . . . . . 22
A.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 22 A.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 22
A.4. Leap Second File . . . . . . . . . . . . . . . . . . . . 23 A.4. Leap Second File . . . . . . . . . . . . . . . . . . . . 23
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 . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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
[RFC5905]. This document is a collection of best practices for the [RFC5905]. This document is a collection of best practices for the
operation of NTP clients and servers. operation of NTP clients and servers.
The recommendations in this document are intended to help operators The recommendations in this document are intended to help operators
distribute time on their networks more accurately and more securely. distribute time on their networks more accurately and more securely.
skipping to change at page 4, line 20 skipping to change at page 4, line 20
attacks. BCP 38 calls for filtering outgoing and incoming traffic to attacks. BCP 38 calls for filtering outgoing and incoming traffic to
make sure that the source and destination IP addresses are consistent make sure that the source and destination IP addresses are consistent
with the expected flow of traffic on each network interface. It is with the expected flow of traffic on each network interface. It is
RECOMMENDED that ISP's and large corporate networks implement ingress RECOMMENDED that ISP's and large corporate networks implement ingress
and egress filtering. More information is available at the BCP38 and egress filtering. More information is available at the BCP38
Info Web page [2] . Info Web page [2] .
3. NTP Configuration Best Practices 3. NTP Configuration Best Practices
This section provides Best Practices for NTP configuration and This section provides Best Practices for NTP configuration and
operation. Best Practices that are specific to the Network Time operation. Application of these best practices that are specific to
Foundation implementation are compiled in Appendix A. the Network Time Foundation implementation, including example
configuration directives valid at the time of this writing, are
compiled in Appendix A.
3.1. Keeping NTP up to date 3.1. Keeping NTP up to date
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, on many different platforms. The practices in this implementations, on many different platforms. The practices in this
document are meant to apply generally to any implementation of document are meant to apply generally to any implementation of
[RFC5905]. NTP users should select an implementation that is [RFC5905]. NTP users should select an implementation that is
actively maintained. Users should keep up to date on any known actively maintained. Users should keep up to date on any known
attacks on their selected implementation, and deploy updates attacks on their selected implementation, and deploy updates
containing security fixes as soon as practical. containing security fixes as soon as practical.
skipping to change at page 11, line 12 skipping to change at page 11, line 12
Autokey SHOULD NOT be used. Autokey SHOULD NOT be used.
4.3. Network Time Security 4.3. Network Time Security
Work is in progress on an enhanced replacement for Autokey. Refer to Work is in progress on an enhanced replacement for Autokey. Refer to
[I-D.ietf-ntp-using-nts-for-ntp] for more information. [I-D.ietf-ntp-using-nts-for-ntp] for more information.
4.4. External Security Protocols 4.4. External Security Protocols
If applicable, external security Protocols such as IPsec and MACsec If applicable, external security protocols such as IPsec and MACsec
can be applied to enhance integrity and authenticity protection of can be applied to enhance integrity and authenticity protection of
NTP time synchronization packets. Usage of such external security NTP time synchronization packets. Usage of such external security
protocols can decrease time synchronization performance [RFC7384]. protocols can decrease time synchronization performance [RFC7384].
Therefore, operators are advised to carefully evaluate if the Therefore, operators are advised to carefully evaluate if the
decreased time synchronization performance meets their specific decreased time synchronization performance meets their specific
timing requirements. timing requirements.
Note that none of the security measures described in Section 4 can
prevent packet delay manipulation attacks on NTP. Such delay attacks
can target time synchronization packets sent as clear-text or even
within an encrypted tunnel. These attacks are described further in
Section 3.2.6 of [RFC7384].
5. NTP Security Best Practices 5. NTP Security Best Practices
This section lists some general NTP security practices, but these This section lists some general NTP security practices, but these
issues may (or may not) have been mitigated in particular versions of issues may (or may not) have been mitigated in particular versions of
particular implementations. Contact the maintainers of the relevant particular implementations. Contact the maintainers of the relevant
implementation for more information. implementation for more information.
5.1. Minimizing Information Leakage 5.1. Minimizing Information Leakage
The base NTP packet leaks important information (including reference The base NTP packet leaks important information (including reference
skipping to change at page 21, line 40 skipping to change at page 21, line 44
[12] https://support.ntp.org/bin/view/Support/ConfiguringNTP [12] https://support.ntp.org/bin/view/Support/ConfiguringNTP
Appendix A. Best Practices specific to the Network Time Foundation Appendix A. Best Practices specific to the Network Time Foundation
implementation implementation
The Network Time Foundation (NTF) provides a widely used The Network Time Foundation (NTF) provides a widely used
implementation of NTP, known as ntpd [10]. It is an evolution of the implementation of NTP, known as ntpd [10]. It is an evolution of the
first NTP implementations developed by David Mills at the University first NTP implementations developed by David Mills at the University
of Delaware. This appendix contains additional recommendations of Delaware. This appendix contains additional recommendations
specific to this implementation. specific to this implementation that are valid at the time of this
writing.
A.1. Use enough time sources A.1. Use enough time sources
In addition to the recommendation given in Section 3.2 the ntpd In addition to the recommendation given in Section 3.2 the ntpd
implementation provides the 'pool' directive. Starting with ntp- implementation provides the 'pool' directive. Starting with ntp-
4.2.6, using this directive in the ntp.conf file will spin up enough 4.2.6, using this directive in the ntp.conf file will spin up enough
associations to provide robust time service, and will disconnect poor associations to provide robust time service, and will disconnect poor
servers and add in new servers as-needed. The 'minclock' and servers and add in new servers as-needed. The 'minclock' and
'maxclock' options of the 'tos' command may be used to override the 'maxclock' options of the 'tos' command may be used to override the
default values of how many servers are discovered through the 'pool' default values of how many servers are discovered through the 'pool'
 End of changes. 12 change blocks. 
12 lines changed or deleted 21 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/