Internet Engineering Task Force (IETF) D. Reilly, Ed.
Request for Comments: 8633 Orolia USA
BCP: 223 H. Stenn
Category: Best Current Practice Network Time Foundation
ISSN: 2070-1721 D. Sibold
PTB
July 2019
Internet Engineering Task Force (IETF) D. Reilly, Ed.
Request for Comments: 8633 Orolia USA
BCP: 223 H. Stenn
Category: Best Current Practice Network Time Foundation
ISSN: 2070-1721 D. Sibold
PTB
July 2019
Network Time Protocol Best Current Practices
网络时间协议最佳当前实践
Abstract
摘要
The Network Time Protocol (NTP) is one of the oldest protocols on the Internet and has been widely used since its initial publication. This document is a collection of best practices for the general operation of NTP servers and clients on the Internet. It includes recommendations for the stable, accurate, and secure operation of NTP infrastructure. This document is targeted at NTP version 4 as described in RFC 5905.
网络时间协议（networktimeprotocol，NTP）是Internet上最古老的协议之一，自其最初发布以来就得到了广泛的应用。本文档是Internet上NTP服务器和客户端一般操作的最佳实践的集合。它包括关于NTP基础设施稳定、准确和安全运行的建议。本文件针对RFC 5905中所述的NTP版本4。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8633.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8633.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. General Network Security Best Practices . . . . . . . . . . . 4
2.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. NTP Configuration Best Practices . . . . . . . . . . . . . . 5
3.1. Keeping NTP Up to Date . . . . . . . . . . . . . . . . . 5
3.2. Using Enough Time Sources . . . . . . . . . . . . . . . . 5
3.3. Using a Diversity of Reference Clocks . . . . . . . . . . 6
3.4. Control Messages . . . . . . . . . . . . . . . . . . . . 7
3.5. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. Using Pool Servers . . . . . . . . . . . . . . . . . . . 8
3.7. Leap-Second Handling . . . . . . . . . . . . . . . . . . 8
3.7.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 9
4. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 10
4.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . . . 11
4.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Network Time Security . . . . . . . . . . . . . . . . . . 11
4.4. External Security Protocols . . . . . . . . . . . . . . . 12
5. NTP Security Best Practices . . . . . . . . . . . . . . . . . 12
5.1. Minimizing Information Leakage . . . . . . . . . . . . . 12
5.2. Avoiding Daemon Restart Attacks . . . . . . . . . . . . . 13
5.3. Detection of Attacks through Monitoring . . . . . . . . . 14
5.4. Kiss-o'-Death Packets . . . . . . . . . . . . . . . . . . 15
5.5. Broadcast Mode Only on Trusted Networks . . . . . . . . . 15
5.6. Symmetric Mode Only with Trusted Peers . . . . . . . . . 16
6. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 16
6.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 16
6.2. Server Configuration . . . . . . . . . . . . . . . . . . 17
7. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Best Practices Specific to the Network Time
Foundation Implementation . . . . . . . . . . . . . 23
A.1. Use Enough Time Sources . . . . . . . . . . . . . . . . . 23
A.2. NTP Control and Facility Messages . . . . . . . . . . . . 23
A.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 24
A.4. Leap-Second File . . . . . . . . . . . . . . . . . . . . 24
A.5. Leap Smearing . . . . . . . . . . . . . . . . . . . . . . 25
A.6. Configuring ntpd . . . . . . . . . . . . . . . . . . . . 25
A.7. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . . . 25
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. General Network Security Best Practices . . . . . . . . . . . 4
2.1. BCP 38 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. NTP Configuration Best Practices . . . . . . . . . . . . . . 5
3.1. Keeping NTP Up to Date . . . . . . . . . . . . . . . . . 5
3.2. Using Enough Time Sources . . . . . . . . . . . . . . . . 5
3.3. Using a Diversity of Reference Clocks . . . . . . . . . . 6
3.4. Control Messages . . . . . . . . . . . . . . . . . . . . 7
3.5. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. Using Pool Servers . . . . . . . . . . . . . . . . . . . 8
3.7. Leap-Second Handling . . . . . . . . . . . . . . . . . . 8
3.7.1. Leap Smearing . . . . . . . . . . . . . . . . . . . . 9
4. NTP Security Mechanisms . . . . . . . . . . . . . . . . . . . 10
4.1. Pre-Shared Key Approach . . . . . . . . . . . . . . . . . 11
4.2. Autokey . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Network Time Security . . . . . . . . . . . . . . . . . . 11
4.4. External Security Protocols . . . . . . . . . . . . . . . 12
5. NTP Security Best Practices . . . . . . . . . . . . . . . . . 12
5.1. Minimizing Information Leakage . . . . . . . . . . . . . 12
5.2. Avoiding Daemon Restart Attacks . . . . . . . . . . . . . 13
5.3. Detection of Attacks through Monitoring . . . . . . . . . 14
5.4. Kiss-o'-Death Packets . . . . . . . . . . . . . . . . . . 15
5.5. Broadcast Mode Only on Trusted Networks . . . . . . . . . 15
5.6. Symmetric Mode Only with Trusted Peers . . . . . . . . . 16
6. NTP in Embedded Devices . . . . . . . . . . . . . . . . . . . 16
6.1. Updating Embedded Devices . . . . . . . . . . . . . . . . 16
6.2. Server Configuration . . . . . . . . . . . . . . . . . . 17
7. NTP over Anycast . . . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Best Practices Specific to the Network Time
Foundation Implementation . . . . . . . . . . . . . 23
A.1. Use Enough Time Sources . . . . . . . . . . . . . . . . . 23
A.2. NTP Control and Facility Messages . . . . . . . . . . . . 23
A.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 24
A.4. Leap-Second File . . . . . . . . . . . . . . . . . . . . 24
A.5. Leap Smearing . . . . . . . . . . . . . . . . . . . . . . 25
A.6. Configuring ntpd . . . . . . . . . . . . . . . . . . . . 25
A.7. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . . . 25
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
NTP version 4 (NTPv4) has been widely used since its publication as [RFC5905]. This document is a collection of best practices for the operation of NTP clients and servers.
NTP版本4（NTPv4）自其作为[RFC5905]出版以来已被广泛使用。本文档是NTP客户端和服务器操作的最佳实践的集合。
The recommendations in this document are intended to help operators distribute time on their networks more accurately and securely. They are intended to apply generally to a broad range of networks. Some specific networks may have higher accuracy requirements that call for additional techniques beyond what is documented here.
本文档中的建议旨在帮助运营商更准确、更安全地在其网络上分配时间。它们一般适用于广泛的网络。一些特定的网络可能具有更高的精度要求，这要求使用本文所述之外的其他技术。
Among the best practices covered are recommendations for general network security, time protocol-specific security, and NTP server and client configuration. NTP operation in embedded devices is also covered.
所涵盖的最佳实践包括针对一般网络安全性、特定于时间协议的安全性以及NTP服务器和客户端配置的建议。还包括嵌入式设备中的NTP操作。
This document also contains information for protocol implementors who want to develop their own implementations compliant with RFC 5905.
本文档还包含协议实施者的信息，他们希望开发符合RFC 5905的自己的实现。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Many network attacks rely on modifying the IP source address of a packet to point to a different IP address than the computer from which it originated. UDP-based protocols, such as NTP, are generally more susceptible to spoofing attacks than connection-oriented protocols. NTP control messages can generate a lot of data in response to a small query, which makes it attractive as a vector for distributed denial-of-service attacks (NTP Control messages are discussed further in Section 3.4). One documented instance of such an attack can be found in [DDOS], with further discussion in [IMC14] and [NDSS14].
许多网络攻击依赖于修改数据包的IP源地址，使其指向与其源计算机不同的IP地址。基于UDP的协议（如NTP）通常比面向连接的协议更容易受到欺骗攻击。NTP控制消息可以生成大量数据来响应一个小查询，这使得它成为分布式拒绝服务攻击的一个载体（NTP控制消息将在第3.4节中进一步讨论）。此类攻击的一个记录实例可在[DDOS]中找到，并在[IMC14]和[NDSS14]中进行进一步讨论。
BCP 38 [RFC2827] was published in 2000 to provide some level of remediation against address-spoofing attacks. BCP 38 calls for filtering outgoing and incoming traffic to make sure that the source and destination IP addresses are consistent with the expected flow of traffic on each network interface. It is RECOMMENDED that ISPs and
BCP 38[RFC2827]于2000年发布，旨在针对地址欺骗攻击提供某种程度的补救措施。BCP 38调用筛选传出和传入流量，以确保源和目标IP地址与每个网络接口上的预期流量一致。建议ISP和
large corporate networks implement ingress and egress filtering. More information is available at [BCP38WIKI].
大型公司网络实施入口和出口过滤。有关更多信息，请访问[BCP38WIKI]。
This section provides best practices for NTP configuration and operation. Application of these best practices that are specific to the Network Time Foundation implementation, including example configuration directives valid at the time of this writing, are compiled in Appendix A.
本节提供NTP配置和操作的最佳实践。适用于网络时间基础实现的这些最佳实践的应用，包括在撰写本文时有效的示例配置指令，在附录A中进行了编译。
There are multiple versions and implementations of the NTP protocol in use on many different platforms. The practices in this document are meant to apply generally to any implementation of [RFC5905]. NTP users should select an implementation that is actively maintained. Users should keep up to date on any known attacks on their selected implementation and deploy updates containing security fixes as soon as it is practical.
NTP协议在许多不同的平台上都有多个版本和实现。本文件中的实践一般适用于[RFC5905]的任何实施。NTP用户应选择积极维护的实现。用户应及时了解对其选定实现的任何已知攻击，并在可行的情况下尽快部署包含安全修复的更新。
An NTP implementation that is compliant with [RFC5905] takes the available sources of time and submits this timing data to sophisticated intersection, clustering, and combining algorithms to get the best estimate of the correct time. The description of these algorithms is beyond the scope of this document. Interested readers should read [RFC5905] or the detailed description of NTP in [MILLS2006].
符合[RFC5905]的NTP实施采用可用的时间源，并将该计时数据提交给复杂的交叉口、群集和组合算法，以获得正确时间的最佳估计。这些算法的描述超出了本文档的范围。感兴趣的读者应阅读[RFC5905]或[MILLS2006]中NTP的详细说明。
o If there is only one source of time, the answer is obvious. It may not be a good source of time, but it's the only source that can be considered. Any issue with the time at the source will be passed on to the client.
o 如果时间只有一个来源，答案是显而易见的。这可能不是一个好的时间来源，但它是唯一可以考虑的来源。源位置的任何时间问题都将传递给客户端。
o If there are two sources of time and they align well enough, then the best time can be calculated easily. But if one source fails, then the solution degrades to the single-source solution outlined above. And if the two sources don't agree, it will be difficult to know which one is correct without making use of information from outside of the protocol.
o 如果有两个时间来源，并且它们足够一致，那么可以很容易地计算出最佳时间。但是，如果一个源出现故障，那么该解决方案将退化为上述的单源解决方案。如果两个消息来源不一致，如果不利用协议之外的信息，就很难知道哪一个是正确的。
o If there are three sources of time, there is more data available to converge on the best calculated time, and this time is more likely to be accurate. And the loss of one of the sources (by becoming unreachable or unusable) can be tolerated. But at that point, the solution degrades to the two-source solution.
o 如果有三个时间来源，则有更多数据可用于收敛到最佳计算时间，并且该时间更可能准确。而其中一个来源的丢失（变得无法访问或无法使用）是可以容忍的。但在这一点上，溶液退化为双源溶液。
o Having four or more sources of time is better as long as the sources are diverse (Section 3.3). If one of these sources develops a problem, there are still at least three other time sources.
o 有四个或四个以上的时间来源更好，只要来源不同（第3.3节）。如果其中一个时间源出现问题，则至少还有三个其他时间源。
This analysis assumes that a majority of the servers used in the solution are honest, even if some may be inaccurate. Operators should be aware of the possibility that if an attacker is in control of the network, the time coming from all servers could be compromised.
此分析假设解决方案中使用的大多数服务器都是诚实的，即使有些服务器可能不准确。运营商应意识到，如果攻击者控制网络，所有服务器的时间可能会受到影响。
Operators who are concerned with maintaining accurate time SHOULD use at least four independent, diverse sources of time. Four sources will provide sufficient backup in case one source goes down. If four sources are not available, operators MAY use fewer sources, which is subject to the risks outlined above.
关注保持准确时间的操作员应使用至少四个独立、不同的时间来源。四个震源将提供足够的备份，以防一个震源发生故障。如果四个来源不可用，运营商可能会使用较少的来源，这取决于上述风险。
But even with four or more sources of time, systemic problems can happen. One example involves the leap-smearing concept detailed in Section 3.7.1. For several hours before and after the June 2015 leap second, several operators configured their NTP servers with leap smearing while others did not. Many NTP end nodes could not determine an accurate time source because two of their four sources of time gave them consistent UTC/POSIX time, while the other two gave them consistent leap-smeared time. This is just one of many potential causes of disagreement among time sources.
但即使有四个或更多的时间来源，系统性问题也可能发生。一个例子涉及第3.7.1节详述的leap涂抹概念。在2015年6月闰秒前后的几个小时内，一些运营商将其NTP服务器配置为leap涂抹，而其他运营商则没有。许多NTP终端节点无法确定准确的时间源，因为它们的四个时间源中有两个给了它们一致的UTC/POSIX时间，而另外两个给了它们一致的跳跃时间。这只是造成时间来源不一致的许多潜在原因之一。
Operators are advised to monitor all time sources that are in use. If time sources do not generally align, operators are encouraged to investigate the cause and either correct the problems or stop using defective servers. See Section 3.5 for more information.
建议操作员监控所有正在使用的时间源。如果时间来源通常不一致，建议操作员调查原因，纠正问题或停止使用有缺陷的服务器。详见第3.5节。
When using servers with attached hardware reference clocks, it is suggested that different types of reference clocks be used. Having a diversity of sources with independent implementations means that any one issue is less likely to cause a service interruption.
当使用带有附加硬件参考时钟的服务器时，建议使用不同类型的参考时钟。拥有具有独立实现的多种来源意味着任何一个问题都不太可能导致服务中断。
Are all clocks on a network from the same vendor? They may have the same bugs. Even devices from different vendors may not be truly independent if they share common elements. Are they using the same base chipset? Are they all running the same version of firmware? Chipset and firmware bugs can happen, but they can be more difficult to diagnose than application software bugs. When having the correct time is of critical importance, it's ultimately up to operators to ensure that their sources are sufficiently independent, even if they are not under the operator's control.
网络上的所有时钟是否来自同一供应商？它们可能有相同的bug。即使是来自不同供应商的设备，如果它们共享相同的元素，也可能不是真正独立的。他们使用相同的基本芯片组吗？它们是否都运行相同版本的固件？芯片组和固件错误可能会发生，但它们比应用软件错误更难诊断。当拥有正确的时间至关重要时，操作员最终要确保其来源足够独立，即使它们不在操作员的控制之下。
A systemic problem with time from any satellite navigation service is possible and has happened. Sunspot activity can render a satellite or radio-based time source unusable. Depending on the application requirements, operators may need to consider backup scenarios in the rare circumstance when the satellite system is faulty or unavailable.
任何卫星导航服务都可能出现系统性的时间问题，而且已经发生。太阳黑子活动会使基于卫星或无线电的时间源无法使用。根据应用需求，在卫星系统出现故障或不可用时，操作员可能需要考虑罕见情况下的备份方案。
Some implementations of NTPv4 provide the NTP control messages (also known as Mode 6 messages). These messages were originally specified in Appendix B of [RFC1305], which defined NTPv3. These messages do not appear in the NTPv4 specification [RFC5905], which obsoletes the NTPv3 specification [RFC1305], but they are still used. At the time of this writing, work is being done to formally document the structure of these control messages for use with NTPv4 in [CTRLMSG].
NTPv4的一些实现提供NTP控制消息（也称为模式6消息）。这些消息最初在[RFC1305]的附录B中指定，该附录定义了NTPv3。这些消息没有出现在NTPv4规范[RFC5905]中，该规范淘汰了NTPv3规范[RFC1305]，但仍在使用。在撰写本文时，正在进行工作，以正式记录这些控制消息的结构，以便在[CTRLMSG]中与NTPv4一起使用。
NTP control messages are designed to permit monitoring and optionally authenticated control of NTP and its configuration. Used properly, these facilities provide vital debugging and performance information and control. But these facilities can be a vector for amplification attacks when abused. For this reason, it is RECOMMENDED that public-facing NTP servers block NTP control message queries from outside their organization.
NTP控制消息旨在允许对NTP及其配置进行监视和可选的身份验证控制。如果使用得当，这些设施将提供重要的调试和性能信息以及控制。但这些设施在被滥用时可能成为放大攻击的载体。因此，建议面向公众的NTP服务器阻止来自其组织外部的NTP控制消息查询。
The ability to use NTP control messages beyond their basic monitoring capabilities SHOULD be limited to authenticated sessions that provide a 'controlkey'. It can also be limited through mechanisms outside of the NTP specification, such as Access Control Lists, that only allow access from approved IP addresses.
除了基本监控功能之外，使用NTP控制消息的能力应限于提供“控制密钥”的经过身份验证的会话。它还可以通过NTP规范之外的机制进行限制，例如访问控制列表，该列表只允许从批准的IP地址进行访问。
The NTP control message responses are much larger than the corresponding queries. Thus, they can be abused in high-bandwidth DDoS attacks. Section 2.1 gives more information on how to provide protection for this abuse by implementing BCP 38.
NTP控制消息响应比相应的查询大得多。因此，它们可能在高带宽DDoS攻击中被滥用。第2.1节提供了有关如何通过实施BCP 38为这种滥用提供保护的更多信息。
Operators SHOULD use their NTP implementation's remote monitoring capabilities to quickly identify servers that are out of sync and ensure correct functioning of the service. Operators SHOULD also monitor system logs for messages so that problems and abuse attempts can be quickly identified.
运营商应使用其NTP实施的远程监控功能快速识别不同步的服务器，并确保服务正常运行。操作员还应监控系统日志中的消息，以便快速识别问题和滥用尝试。
If a system starts to receive NTP Reply packets from a remote time server that do not correspond to any requests sent by the system, that can be an indication that an attacker is forging that system's IP address in requests to the remote time server. The goal of this attack is to adversely impact the availability of time to the
如果系统开始从远程时间服务器接收与系统发送的任何请求不对应的NTP回复数据包，则这可能表示攻击者正在向远程时间服务器发送的请求中伪造该系统的IP地址。此攻击的目标是对服务器的可用时间产生不利影响
targeted system whose address is being forged. Based on these forged packets, the remote time server might decide to throttle or rate-limit packets or even stop sending packets to the targeted system.
地址被伪造的目标系统。基于这些伪造的数据包，远程时间服务器可能决定对数据包进行节流或速率限制，甚至停止向目标系统发送数据包。
If a system is a broadcast client and its system log shows that it is receiving early time messages from its server, that is an indication that somebody may be forging packets from a broadcast server (broadcast client and server modes are defined in Section 3 of [RFC5905]).
如果系统是广播客户端，且其系统日志显示其正在从其服务器接收早期消息，则表示有人可能伪造来自广播服务器的数据包（广播客户端和服务器模式在[RFC5905]第3节中定义）。
If a server's system log shows messages that indicate it is receiving NTP timestamps that are much earlier than the current system time, then either the system clock is unusually fast or somebody is trying to launch a replay attack against that server.
如果服务器的系统日志显示消息，表明它正在接收比当前系统时间早得多的NTP时间戳，则系统时钟异常快，或者有人试图对该服务器发起重播攻击。
It only takes a small amount of bandwidth and system resources to synchronize one NTP client, but NTP servers that can service tens of thousands of clients take more resources to run. Network operators and advanced users who want to synchronize their computers MUST only synchronize to servers that they have permission to use.
同步一个NTP客户端只需要少量带宽和系统资源，但可以为成千上万个客户端提供服务的NTP服务器需要更多的资源才能运行。要同步其计算机的网络运营商和高级用户必须只同步到他们有权使用的服务器。
The NTP Pool Project is a group of volunteers who have donated their computing and bandwidth resources to freely distribute time from primary time sources to others on the Internet. The time is generally of good quality but comes with no guarantee whatsoever. If you are interested in using this pool, please review their instructions at [POOLUSE].
NTP Pool项目是一群志愿者，他们捐赠了自己的计算和带宽资源，在互联网上自由地将时间从主要时间来源分配给其他人。时间通常质量很好，但没有任何保证。如果您有兴趣使用此池，请在[POOLUSE]查看他们的说明。
Vendors can obtain their own subdomain that is part of the NTP Pool Project. This offers vendors the ability to safely make use of the time distributed by the pool for their devices. Details are available at [POOLVENDOR].
供应商可以获得属于NTP池项目的自己的子域。这使供应商能够安全地利用池为其设备分配的时间。有关详细信息，请访问[POOLVENDOR]。
If there is a need to synchronize many computers, an operator may want to run local NTP servers that are synchronized to the NTP Pool Project. NTP users on that operator's networks can then be synchronized to local NTP servers.
如果需要同步多台计算机，操作员可能希望运行与NTP池项目同步的本地NTP服务器。然后，该运营商网络上的NTP用户可以同步到本地NTP服务器。
UTC is kept in agreement with the Universal Time UT1 [SOLAR] to within +/- 0.9 seconds by the insertion (or possibly deletion) of a leap second. UTC is an atomic time scale, whereas UT1 is based on the rotational rate of the earth. Leap seconds are not introduced at
通过插入（或可能删除）闰秒，UTC与世界时UT1[SOLAR]保持一致，在+/-0.9秒内。UTC是原子时标，而UT1是基于地球的旋转速率。闰秒不会在任何时候引入
a fixed rate. They are announced by the International Earth Rotation and Reference Systems Service (IERS) in its Bulletin C [IERS] when necessary to keep UTC and UT1 aligned.
固定利率。国际地球自转和参考系统服务（IERS）在其公告C[IERS]中宣布了这些标准，以使UTC和UT1保持一致。
NTP time is based on the UTC timescale, and the protocol has the capability to broadcast leap-second information. Some global navigation satellite systems (like GPS) or radio transmitters (like DCF77) broadcast leap-second information. If an NTP client is synced to an NTP server that provides leap-second notification, the client will get advance notification of impending leap seconds automatically.
NTP时间基于UTC时间刻度，协议具有广播闰秒信息的能力。一些全球导航卫星系统（如GPS）或无线电发射机（如DCF77）广播闰秒信息。如果NTP客户端与提供闰秒通知的NTP服务器同步，则客户端将自动获得即将到来的闰秒的提前通知。
Since the length of the UT1 day generally slowly increases [SOLAR], 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 if it ever becomes necessary.
由于UT1天的长度通常缓慢增加[太阳]，自1972年开始实践以来引入的所有闰秒均为正闰秒，其中秒添加到UTC。NTP还支持负闰秒，如果有必要，将从UTC中删除一秒。
While earlier versions of NTP contained some ambiguity regarding when a leap second broadcast by a server should be applied by a client, RFC 5905 is clear that leap seconds are only applied on the last day of a month. However, because some older clients may apply it at the end of the current day, it is RECOMMENDED that NTP servers wait until the last day of the month before broadcasting leap seconds. Doing this will prevent older clients from applying a leap second at the wrong time. When implementing this recommendation, operators should ensure that clients are not configured to use polling intervals greater than 24 hours so the leap-second notification is not missed.
虽然早期版本的NTP对客户端何时应用服务器的闰秒广播存在一些模糊性，但RFC 5905清楚地表明，闰秒仅在一个月的最后一天应用。但是，由于一些较旧的客户端可能会在当天结束时应用它，因此建议NTP服务器等到当月最后一天再广播闰秒。这样做可以防止老客户在错误的时间应用闰秒。执行此建议时，操作员应确保客户端未配置为使用大于24小时的轮询间隔，以便不会错过闰秒通知。
In circumstances where an NTP server is not receiving leap-second information from an automated source, certain organizations maintain files that are updated every time a new leap second is announced:
在NTP服务器未从自动源接收闰秒信息的情况下，某些组织维护的文件在每次宣布新的闰秒时都会更新：
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-seconds.list>
US Navy (maintains GPS Time):
<ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.list>
IERS (announces leap seconds):
<https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list>
IERS (announces leap seconds):
<https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list>
Some NTP installations make use of a technique called leap smearing. With this method, instead of introducing an extra second (or eliminating a second) in a leap-second event, NTP time is adjusted in small increments over a comparably large window of time (called the smear interval) around the leap-second event. The smear interval
一些NTP装置使用一种称为leap涂抹的技术。使用这种方法，在闰秒事件中不引入额外的秒（或消除秒），而是在闰秒事件周围相对较大的时间窗口（称为涂抹间隔）内以小增量调整NTP时间。涂抹间隔
should be large enough for the time to be adjusted at a low rate, so that clients will follow the smeared time without objecting. Periods ranging from two to twenty-four hours have been used successfully. During the adjustment window, all the NTP clients' times may be offset from UTC by as much as a full second, depending on the implementation. However, all clients will generally agree on what time they think it is.
应足够大，以便以较低的速率调整时间，以便客户能够在不反对的情况下遵循涂抹的时间。已经成功地使用了从两小时到二十四小时不等的时段。在调整窗口期间，根据实施情况，所有NTP客户端的时间可能会与UTC相差整整一秒。然而，所有客户通常都会同意他们认为是什么时间。
The purpose of leap smearing is to enable systems that don't deal with the leap-second event properly to function consistently, at the expense of fidelity to UTC during the smear window. During a standard leap-second event, a minute will have 61 (or possibly 59) seconds, and some applications (and even some OSs) are known to have problems with that.
leap涂抹的目的是使未正确处理闰秒事件的系统能够一致地运行，而牺牲涂抹窗口期间对UTC的逼真度。在标准的闰秒事件中，一分钟将有61秒（或者可能是59秒），而一些应用程序（甚至一些操作系统）已知在这方面存在问题。
Operators who have legal obligations or other strong requirements to be synchronized with UTC or civil time SHOULD NOT use leap smearing because the distributed time cannot be guaranteed to be traceable to UTC during the smear interval.
具有与UTC或civil time同步的法律义务或其他强烈要求的操作员不应使用leap涂抹，因为无法保证在涂抹间隔期间，分布的时间可追溯到UTC。
Clients that are connected to leap-smearing servers MUST NOT apply the standard NTP leap-second handling. These clients must never have a leap-second file loaded, and the smearing servers must never advertise to clients for which a leap second is pending.
连接到leap涂抹服务器的客户端不得应用标准NTP闰秒处理。这些客户端决不能加载闰秒文件，涂抹服务器决不能向挂起闰秒的客户端播发。
Any use of leap-smearing servers should be limited to within a single, well-controlled environment. 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 leap smear interval, and there is no standardized way for a client to detect that a server is using leap smearing. However, be aware that some public-facing servers may be configured this way in spite of this guidance.
任何leap涂抹服务器的使用都应该限制在一个单一的、控制良好的环境中。Leap涂抹不得用于面向公众的NTP服务器，因为在Leap涂抹间隔期间，它们将与非涂抹服务器（以及UTC）不一致，并且客户端没有标准方法检测服务器是否正在使用Leap涂抹。但是，请注意，尽管有此指导，一些面向公众的服务器可能会以这种方式配置。
System administrators are advised to be aware of impending leap seconds and how the servers (inside and outside their organization) they are using deal with them. Individual clients MUST NOT be configured to use a mixture of smeared and non-smeared servers. If a client uses smeared servers, the servers it uses must all have the same leap smear configuration.
建议系统管理员注意即将到来的闰秒，以及他们使用的服务器（组织内部和外部）如何处理闰秒。不得将单个客户端配置为混合使用涂抹服务器和非涂抹服务器。如果客户端使用涂抹服务器，则它使用的服务器必须全部具有相同的leap涂抹配置。
In the standard configuration, NTP packets are exchanged unprotected 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 content of the NTP packet, which leads to degradation of the time synchronization or transmission of false time information. A threat analysis for time-synchronization protocols is given in [RFC7384].
在标准配置中，NTP数据包在客户端和服务器之间不受保护地交换。因此，能够成为中间人的对手能够删除、重放或修改NTP分组的内容，这导致时间同步或假时间信息的传输的劣化。[RFC7384]中给出了时间同步协议的威胁分析。
NTP provides two internal security mechanisms to protect the authenticity and integrity of the NTP packets. Both measures protect the NTP packet by means of a Message Authentication Code (MAC). Neither of them encrypts the NTP's payload because this payload information is not considered to be confidential.
NTP提供两种内部安全机制来保护NTP数据包的真实性和完整性。这两种措施都通过消息认证码（MAC）来保护NTP数据包。它们都不会加密NTP的有效载荷，因为该有效载荷信息不被视为机密信息。
This approach applies a symmetric key for the calculation of the MAC, which protects the authenticity and integrity of the exchanged packets for an association. NTP does not provide a mechanism for the exchange of keys between the associated nodes. Therefore, for each association, keys MUST be exchanged securely by external means, and they MUST be protected from disclosure. It is RECOMMENDED that each association be protected by its own unique key. It is RECOMMENDED that participants agree to refresh keys periodically. However, NTP does not provide a mechanism to assist in doing so. Each communication partner will need to keep track of its keys in its own local key storage.
这种方法将对称密钥应用于MAC的计算，从而保护关联交换数据包的真实性和完整性。NTP不提供在相关节点之间交换密钥的机制。因此，对于每个关联，必须通过外部手段安全地交换密钥，并且必须保护密钥不被泄露。建议每个关联由其自己的唯一密钥保护。建议参与者同意定期刷新密钥。然而，NTP并没有提供一种机制来协助这样做。每个通信伙伴都需要在其本地密钥存储中跟踪其密钥。
[RFC5905] specifies using the MD5 hash algorithm for calculation of the MAC, but other algorithms may be supported as well. The MD5 hash is now considered to be too weak and unsuitable for cryptographic usage. [RFC6151] has more information on the algorithm's weaknesses. Implementations will soon be available based on AES-128-CMAC [RFC8573], and users SHOULD use that when it is available.
[RFC5905]指定使用MD5哈希算法计算MAC，但也可能支持其他算法。MD5散列现在被认为太弱，不适合加密使用。[RFC6151]提供了有关该算法弱点的更多信息。基于AES-128-CMAC[RFC8573]的实现很快将可用，用户应在可用时使用。
Some implementations store the key in clear text. Therefore, it MUST only be readable by the NTP process.
有些实现以明文形式存储密钥。因此，它必须只能由NTP进程读取。
An NTP client has to be able to link a key to a particular server in order to establish a protected association. This linkage is implementation specific. Once applied, a key will be trusted until the link is removed.
NTP客户端必须能够将密钥链接到特定服务器，以便建立受保护的关联。这种联系是特定于实现的。一旦应用，密钥将被信任，直到链接被删除。
[RFC5906] specifies the Autokey protocol. It was published in 2010 to provide automated key management and authentication of NTP servers. However, security researchers have identified vulnerabilities [AUTOKEY] in the Autokey protocol.
[RFC5906]指定自动密钥协议。它于2010年发布，旨在为NTP服务器提供自动密钥管理和身份验证。然而，安全研究人员已经确定了自动密钥协议中的漏洞[自动密钥]。
Autokey SHOULD NOT be used.
不应使用自动键。
Work is in progress on an enhanced replacement for Autokey. Refer to [NTSFORNTP] for more information.
增强型Autokey替代品的工作正在进行中。有关更多信息，请参阅[NTSFORNTP]。
If applicable, external security protocols such as IPsec and MACsec can be applied to enhance the integrity and authenticity protection of NTP time-synchronization packets. Usage of such external security protocols can decrease time-synchronization performance [RFC7384]. Therefore, operators are advised to carefully evaluate whether the decreased time-synchronization performance meets their specific timing requirements.
如果适用，可以应用IPsec和MACsec等外部安全协议来增强NTP时间同步数据包的完整性和真实性保护。使用这种外部安全协议会降低时间同步性能[RFC7384]。因此，建议运营商仔细评估降低的时间同步性能是否满足其特定的定时要求。
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].
请注意，第4节中描述的任何安全措施都不能防止NTP上的数据包延迟操纵攻击。这种延迟攻击的目标可能是以明文形式发送的时间同步数据包，甚至是在加密隧道中发送的时间同步数据包。[RFC7384]第3.2.6节进一步描述了这些攻击。
This section lists some general NTP security practices, but these issues may (or may not) have been mitigated in particular versions of particular implementations. Contact the maintainers of the relevant implementation for more information.
本节列出了一些通用NTP安全实践，但这些问题可能（也可能没有）在特定实现的特定版本中得到缓解。有关更多信息，请联系相关实现的维护人员。
The base NTP packet leaks important information (including reference ID and reference time) that may be used in attacks [NDSS16] [CVE-2015-8138] [CVE-2016-1548]. A remote attacker can learn this information by sending mode 3 queries to a target system and inspecting the fields in the mode 4 response packet. NTP control queries also leak important information (including reference ID, expected origin timestamp, etc.) that may be used in attacks [CVE-2015-8139]. A remote attacker can learn this information by sending control queries to a target system and inspecting the leaked information in the response.
基本NTP数据包泄漏可能用于攻击的重要信息（包括参考ID和参考时间）[NDSS16][CVE-2015-8138][CVE-2016-1548]。远程攻击者可以通过向目标系统发送模式3查询并检查模式4响应数据包中的字段来了解此信息。NTP控制查询还泄漏可能用于攻击的重要信息（包括参考ID、预期来源时间戳等）[CVE-2015-8139]。远程攻击者可以通过向目标系统发送控制查询并检查响应中泄漏的信息来了解此信息。
As such, mechanisms outside of the NTP protocol, such as Access Control Lists, SHOULD be used to limit the exposure of this information to allowed IP addresses and keep it from remote attackers not on the list. Hosts SHOULD only respond to NTP control queries from authorized parties.
因此，应使用NTP协议之外的机制（如访问控制列表）将此信息的公开限制在允许的IP地址内，并防止列表外的远程攻击者攻击。主机应仅响应来自授权方的NTP控制查询。
An NTP client that does not provide time on the network can additionally log and drop incoming mode 3 timing queries from unexpected sources. Note well that the easiest way to monitor the status of an NTP instance is to send it a mode 3 query, so it may not be desirable to drop all mode 3 queries. As an alternative, operators SHOULD either filter mode 3 queries from outside their
不提供网络时间的NTP客户端还可以记录和删除来自意外来源的传入模式3计时查询。请注意，监视NTP实例状态的最简单方法是向其发送模式3查询，因此可能不希望删除所有模式3查询。另一种选择是，操作员应该从外部过滤模式3查询
networks or make sure mode 3 queries are allowed only from trusted systems or networks.
网络或确保仅允许来自受信任系统或网络的模式3查询。
A "leaf-node host" is a host that uses NTP solely for the purpose of adjusting its own system time. Such a host is not expected to provide time to other hosts and relies exclusively on NTP's basic mode to take time from a set of servers (that is, the host sends mode 3 queries to its servers and receives mode 4 responses from these servers containing timing information.) To minimize information leakage, leaf-node hosts SHOULD drop all incoming NTP packets except mode 4 response packets that come from known sources. An exception to this can be made if a leaf-node host is being actively monitored, in which case incoming packets from the monitoring server can be allowed.
“叶节点主机”是仅为调整自身系统时间而使用NTP的主机。这样的主机不会向其他主机提供时间，并且完全依赖NTP的基本模式从一组服务器（即，主机向其服务器发送模式3查询，并从这些服务器接收模式4响应，其中包含定时信息）获取时间，以尽可能减少信息泄漏，叶节点主机应丢弃所有传入的NTP数据包，来自已知来源的模式4响应数据包除外。如果叶节点主机正在被主动监视，则可以对此进行例外，在这种情况下，可以允许来自监视服务器的传入数据包。
Please refer to [DATAMIN] for more information.
有关更多信息，请参阅[DATAMIN]。
[RFC5905] says NTP clients should not accept time shifts greater than the panic threshold. Specifically, RFC 5905 says "PANIC means the offset is greater than the panic threshold PANICT (1000 s) and SHOULD cause the program to exit with a diagnostic message to the system log."
[RFC5905]表示NTP客户端不应接受大于恐慌阈值的时间偏移。具体地说，RFC 5905表示“恐慌意味着偏移量大于恐慌阈值恐慌（1000秒），应导致程序退出，并向系统日志发送诊断消息。”
However, this behavior can be exploited by attackers as described in [NDSS16] when the following two conditions hold:
但是，在以下两种情况下，[NDSS16]中描述的攻击者可以利用此行为：
1. The operating system automatically restarts the NTP client when it quits. Modern UNIX and UNIX-like operating systems are replacing traditional init systems with process supervisors, such as systemd, which can be configured to automatically restart any daemons that quit. This behavior is the default in CoreOS and Arch Linux. As of the time of this writing, it appears likely to become the default behavior in other systems as they migrate legacy init scripts to process supervisors such as systemd.
1. 当NTP客户端退出时，操作系统会自动重新启动它。现代UNIX和类UNIX操作系统正在用进程监视器（如systemd）取代传统的init系统，systemd可以配置为自动重新启动退出的任何守护进程。这种行为是CoreOS和Arch Linux中的默认行为。在撰写本文时，当其他系统将遗留init脚本迁移到诸如systemd之类的进程管理器时，它可能成为默认行为。
2. The NTP client is configured to ignore the panic threshold on all restarts.
2. NTP客户端配置为在所有重新启动时忽略紧急阈值。
In such cases, if the attacker can send the target an offset that exceeds the panic threshold, the client will quit. Then, when it restarts, it ignores the panic threshold and accepts the attacker's large offset.
在这种情况下，如果攻击者可以向目标发送超过紧急阈值的偏移量，则客户端将退出。然后，当它重新启动时，它会忽略恐慌阈值并接受攻击者的大偏移量。
Operators need to be aware that when operating with the above two conditions, the panic threshold offers no protection from attacks. The natural solution is not to run hosts with these conditions.
操作员需要意识到，在上述两种情况下操作时，恐慌阈值无法提供攻击防护。自然的解决方案是不在这些条件下运行主机。
Specifically, operators SHOULD NOT ignore the panic threshold in all cold-start situations unless sufficient oversight and checking is in place to make sure that this type of attack cannot happen.
具体而言，除非有足够的监督和检查确保此类攻击不会发生，否则操作员不应忽略所有冷启动情况下的恐慌阈值。
As an alternative, the following steps MAY be taken by operators to mitigate the risk of attack:
作为替代方案，运营商可采取以下步骤来降低攻击风险：
o Monitor the NTP system log to detect when the NTP daemon quit due to a panic event, as this could be a sign of an attack.
o 监视NTP系统日志，以检测NTP守护程序何时因紧急事件退出，因为这可能是攻击的迹象。
o Request manual intervention when a timestep larger than the panic threshold is detected.
o 当检测到时间步长大于紧急阈值时，请求手动干预。
o Configure the ntp client to only ignore the panic threshold in a cold-start situation.
o 将ntp客户端配置为在冷启动情况下仅忽略紧急阈值。
o Increase the minimum number of servers required before the NTP client adjusts the system clock. This will make the NTP client wait until enough trusted sources of time agree before declaring the time to be correct.
o 在NTP客户端调整系统时钟之前，增加所需的最小服务器数。这将使NTP客户端在声明正确的时间之前等待足够多的可信时间源。
In addition, the following steps SHOULD be taken by those who implement the NTP protocol:
此外，实施NTP协议的人应采取以下步骤：
o Prevent the NTP daemon from taking time steps that set the clock to a time earlier than the compile date of the NTP daemon.
o 防止NTP守护进程采取将时钟设置为早于NTP守护进程编译日期的时间步。
o Prevent the NTP daemon from putting 'INIT' in the reference ID of its NTP packets upon initializing. This will make it more difficult for attackers to know when the daemon reboots.
o 防止NTP守护进程在初始化时将“INIT”放入其NTP数据包的引用ID中。这将使攻击者更难知道守护进程何时重新启动。
Operators SHOULD monitor their NTP instances to detect attacks. Many known attacks on NTP have particular signatures. Common attack signatures include:
操作员应监控其NTP实例以检测攻击。许多已知的NTP攻击都有特定的特征。常见的攻击特征包括：
1. Bogus packets - A packet whose origin timestamp does not match the value that is expected by the client.
1. 伪数据包-其原始时间戳与客户端预期值不匹配的数据包。
2. Zero origin packet - A packet with an origin timestamp set to zero [CVE-2015-8138].
2. 零起始数据包-起始时间戳设置为零的数据包[CVE-2015-8138]。
3. A packet with an invalid cryptographic MAC.
3. 具有无效加密MAC的数据包。
The observation of many such packets could indicate that the client is under attack.
对许多这样的数据包的观察可能表明客户端受到攻击。
The "Kiss-o'-Death" (KoD) packet includes a rate-management mechanism where a server can tell a misbehaving client to reduce its query rate. KoD packets in general (and the RATE packet in particular) are defined in Section 7.4 of [RFC5905]. It is RECOMMENDED that all NTP devices respect these packets and back off when asked to do so by a server. This is even more important for an embedded device, which may not have an exposed control interface for NTP.
“Kiss-o'-Death”（KoD）数据包包括一种速率管理机制，在该机制中，服务器可以告诉行为不端的客户端降低其查询速率。[RFC5905]第7.4节对一般KoD数据包（尤其是速率数据包）进行了定义。建议所有NTP设备尊重这些数据包，并在服务器要求时退出。这对于嵌入式设备更为重要，因为它可能没有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) to a reasonable maximum. This maximum can vary by implementation but should not exceed a poll interval value of 13 (two hours). The mechanism to determine how much to increase the poll interval value is undefined in [RFC5905]. If the client uses the poll interval value sent by the server in the RATE packet, it MUST NOT simply accept any value. Using large interval values may create a vector for a denial-of-service attack that causes the client to stop querying its server [NDSS16].
也就是说，客户机必须只接受具有有效原始时间戳的KoD数据包。一旦速率数据包被接受，客户端应将其轮询间隔值（从而降低其轮询速率）增加到合理的最大值。此最大值可能因实现而异，但不应超过轮询间隔值13（两小时）。[RFC5905]中未定义确定轮询间隔值增加多少的机制。如果客户端在速率数据包中使用服务器发送的轮询间隔值，则它不能简单地接受任何值。使用大间隔值可能会创建拒绝服务攻击的向量，导致客户端停止查询其服务器[NDSS16]。
The KoD rate-management mechanism relies on clients behaving properly in order to be effective. Some clients ignore the RATE packet entirely, and other poorly implemented clients might unintentionally increase their poll rate and simulate a denial-of-service attack. Server administrators are advised to be prepared for this and take measures outside of the NTP protocol to drop packets from misbehaving clients when these clients are detected.
KoD费率管理机制依赖于客户的正常行为，以确保有效。一些客户端完全忽略速率数据包，而其他实现较差的客户端可能会无意中增加其轮询速率并模拟拒绝服务攻击。建议服务器管理员对此做好准备，并在检测到行为异常的客户端时，在NTP协议之外采取措施从这些客户端丢弃数据包。
Kiss-o'-Death (KoD) packets can be used in denial-of-service attacks. Thus, the observation of even just one RATE packet with a high poll value could be sign that the client is under attack. And KoD packets are commonly accepted even when not cryptographically authenticated, which increases the risk of denial-of-service attacks.
Kiss-o'-Death（KoD）数据包可用于拒绝服务攻击。因此，即使只观察到一个具有高轮询值的速率数据包，也可能表明客户端受到攻击。即使未经加密验证，KoD数据包也被普遍接受，这增加了拒绝服务攻击的风险。
Per [RFC5905], NTP's broadcast mode is authenticated using symmetric key cryptography. The broadcast server and all its broadcast clients share a symmetric cryptographic key, and the broadcast server uses this key to append a MAC to the broadcast packets it sends.
根据[RFC5905]，NTP的广播模式使用对称密钥加密进行验证。广播服务器及其所有广播客户端共享对称加密密钥，广播服务器使用该密钥将MAC附加到其发送的广播数据包中。
Importantly, all broadcast clients that listen to this server have to know the cryptographic key. This means that any client can use this key to send valid broadcast messages that look like they come from the broadcast server. Thus, a rogue broadcast client can use its knowledge of this key to attack the other broadcast clients.
重要的是，所有收听此服务器的广播客户端都必须知道加密密钥。这意味着任何客户端都可以使用此密钥发送看起来像来自广播服务器的有效广播消息。因此，流氓广播客户端可以利用其对该密钥的了解来攻击其他广播客户端。
For this reason, an NTP broadcast server and all its clients have to trust each other. Broadcast mode SHOULD only be run from within a trusted network.
因此，NTP广播服务器及其所有客户端必须相互信任。广播模式只能在受信任的网络中运行。
In symmetric mode, two peers, Alice and Bob, can both push and pull synchronization to and from each other using either ephemeral symmetric passive (mode 2) or persistent symmetric active (NTP mode 1) packets. The persistent association is preconfigured and initiated at the active peer but is not preconfigured at the passive peer (Bob). Upon receipt of a mode 1 NTP packet from Alice, Bob mobilizes a new ephemeral association if he does not have one 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 symmetric passive peer.
在对称模式下，两个对等方Alice和Bob都可以使用短暂对称被动（模式2）或持久对称主动（NTP模式1）数据包相互推拉同步。持久关联在主动对等点预配置并启动，但在被动对等点（Bob）未预配置。在收到Alice发送的模式1 NTP数据包后，如果Bob还没有一个临时关联，他将启动一个新的临时关联。这对Bob来说是一个安全风险，因为任意攻击者可以通过要求Bob成为其对称被动对等方来改变Bob的时间。
For this reason, a host SHOULD only allow symmetric passive associations to be established with trusted peers. Specifically, a host SHOULD require each of its symmetric passive associations to be cryptographically authenticated. Each symmetric passive association SHOULD be authenticated under a different cryptographic key.
因此，主机应只允许与受信任的对等方建立对称被动关联。具体来说，主机应该要求其每个对称被动关联都经过加密身份验证。每个对称被动关联都应该使用不同的加密密钥进行身份验证。
As computing becomes more ubiquitous, there will be many small embedded devices that require accurate time. These devices may not have a persistent battery-backed clock, so using NTP to set the correct time on power-up may be critical for proper operation. These devices may not have a traditional user interface, but if they connect to the Internet, they will be subject to the same security threats as traditional deployments.
随着计算变得越来越普遍，将有许多小型嵌入式设备需要精确的时间。这些设备可能没有持久的电池备份时钟，因此使用NTP设置正确的通电时间对于正确操作可能至关重要。这些设备可能没有传统的用户界面，但如果它们连接到Internet，它们将受到与传统部署相同的安全威胁。
Vendors of embedded devices are advised to pay attention to the current state of protocol security issues and bugs in their chosen implementation because their customers don't have the ability to update their NTP implementation on their own. Those devices may have a single firmware upgrade, provided by the manufacturer, that updates all capabilities at once. This means that the vendor assumes the responsibility of making sure their devices have an up-to-date and secure NTP implementation.
建议嵌入式设备供应商注意所选实现中的协议安全问题和错误的当前状态，因为他们的客户无法自行更新NTP实现。这些设备可能有一个由制造商提供的固件升级，一次更新所有功能。这意味着供应商有责任确保其设备具有最新且安全的NTP实施。
Vendors of embedded devices SHOULD include the ability to update the list of NTP servers used by the device.
嵌入式设备供应商应具备更新设备使用的NTP服务器列表的能力。
There is a catalog of NTP server abuse incidents, some of which involve embedded devices, on the Wikipedia page for NTP Server Misuse and Abuse [MISUSE].
维基百科页面上有一个NTP服务器滥用事件目录，其中一些涉及嵌入式设备，用于NTP服务器滥用和滥用[滥用]。
Vendors of embedded devices with preconfigured NTP servers need to carefully consider which servers to use. There are several public-facing NTP servers available, but they may not be prepared to service requests from thousands of new devices on the Internet. Vendors MUST only preconfigure NTP servers that they have permission to use.
具有预先配置的NTP服务器的嵌入式设备供应商需要仔细考虑使用哪些服务器。有几种面向公众的NTP服务器可用，但它们可能不准备为来自互联网上数千台新设备的请求提供服务。供应商只能预先配置他们有权使用的NTP服务器。
Vendors are encouraged to invest resources into providing their own time servers for their devices to connect to. This may be done through the NTP Pool Project, as documented in Section 3.6.
鼓励供应商投入资源，为其设备提供自己的时间服务器，以供连接。如第3.6节所述，这可以通过NTP池项目完成。
Vendors should read [RFC4085], which advises against embedding globally routable IP addresses in products and offers several better alternatives.
供应商应阅读[RFC4085]，其中建议不要在产品中嵌入全局可路由IP地址，并提供了几种更好的替代方案。
Anycast is described in BCP 126 [RFC4786] (see also [RFC7094]). With anycast, a single IP address is assigned to multiple servers, and routers direct packets to the closest active server.
BCP 126[RFC4786]中描述了选播（另请参见[RFC7094]）。使用anycast，一个IP地址分配给多个服务器，路由器将数据包定向到最近的活动服务器。
Anycast is often used for Internet services at known IP addresses, such as DNS. Anycast can also be used in large organizations to simplify the configuration of many NTP clients. Each client can be configured with the same NTP server IP address, and a pool of anycast servers can be deployed to service those requests. New servers can be added to or taken from the pool, and other than a temporary loss of service while a server is taken down, these additions can be transparent to the clients.
Anycast通常用于已知IP地址（如DNS）的Internet服务。Anycast还可以在大型组织中使用，以简化许多NTP客户端的配置。每个客户端都可以配置相同的NTP服务器IP地址，并且可以部署一个选播服务器池来服务这些请求。新服务器可以添加到池中或从池中取出，除了在服务器关闭时暂时失去服务外，这些添加对客户端是透明的。
Note well that using a single anycast address for NTP presents its own potential issues. It means each client will likely use a single time server source. A key element of a robust NTP deployment is each client using multiple sources of time. With multiple time sources, a client will analyze the various time sources, select good ones, and disregard poor ones. If a single anycast address is used, this analysis will not happen. This can be mitigated by creating multiple, separate anycast pools so clients can have multiple sources of time while still gaining the configuration benefits of the anycast pools.
请注意，为NTP使用单个选播地址会带来其自身的潜在问题。这意味着每个客户机都可能使用单个时间服务器源。健壮的NTP部署的一个关键要素是每个客户端使用多个时间源。对于多个时间源，客户机将分析各种时间源，选择好的时间源，而忽略差的时间源。如果使用单个选播地址，则不会进行此分析。这可以通过创建多个独立的选播池来缓解，这样客户端就可以拥有多个时间源，同时仍然可以获得选播池的配置优势。
If clients are connected to an NTP server via anycast, the client does not know which particular server they are connected to. As anycast servers enter and leave the network or the network topology changes, the server to which a particular client is connected may change. This may cause a small shift in time from the perspective of the client when the server to which it is connected changes. Extreme cases where the network topology changes rapidly could cause the server seen by a client to rapidly change as well, which can lead to larger time inaccuracies. It is RECOMMENDED that network operators only deploy anycast NTP in environments where operators know these small shifts can be tolerated by the applications running on the clients being synchronized in this manner.
如果客户端通过anycast连接到NTP服务器，则客户端不知道它们连接到哪个特定服务器。随着选播服务器进入和离开网络，或者网络拓扑发生变化，特定客户端连接到的服务器可能会发生变化。当连接到的服务器发生变化时，从客户端的角度来看，这可能会导致时间上的微小变化。网络拓扑快速变化的极端情况也可能导致客户端看到的服务器快速变化，这可能导致更大的时间不准确。建议网络运营商仅在运营商知道以这种方式同步的客户机上运行的应用程序可以容忍这些微小变化的环境中部署anycast NTP。
Configuration of an anycast interface is independent of NTP. Clients will always connect to the closest server, even if that server is having NTP issues. It is RECOMMENDED that anycast NTP implementations have an independent method of monitoring the performance of NTP on a server. If the server is not performing to specification, it should remove itself from the anycast network. It is also RECOMMENDED that each anycast NTP server have an alternative method of access, such as an alternate unicast IP address, so its performance can be checked independently of the anycast routing scheme.
选播接口的配置独立于NTP。客户端将始终连接到最近的服务器，即使该服务器存在NTP问题。建议anycast NTP实现具有独立的方法来监控服务器上NTP的性能。如果服务器未按照规范执行，则应将其自身从选播网络中删除。还建议每个选播NTP服务器具有备用访问方法，例如备用单播IP地址，以便可以独立于选播路由方案检查其性能。
One useful application in large networks is to use a hybrid unicast/ anycast approach. Stratum 1 NTP servers can be deployed with unicast interfaces at several sites. Each site may have several Stratum 2 servers with two Ethernet interfaces or a single interface that can support multiple addresses. One interface has a unique unicast IP address. The second has an anycast IP interface (with a shared IP address per location). The unicast interfaces can be used to obtain time from the Stratum 1 servers globally (and perhaps peer with the other Stratum 2 servers at their site). Clients at each site can be configured to use the shared anycast address for their site, simplifying their configuration. Keeping the anycast routing restricted on a per-site basis will minimize the disruption at the client if its closest anycast server changes. Each Stratum 2 server can be uniquely identified on their unicast interface to make monitoring easier.
在大型网络中，一个有用的应用是使用混合单播/选播方法。第1层NTP服务器可以在多个站点部署单播接口。每个站点可能有几个具有两个以太网接口的第2层服务器，或一个可支持多个地址的接口。一个接口具有唯一的单播IP地址。第二个有一个选播IP接口（每个位置有一个共享IP地址）。单播接口可用于从第1层服务器全局获取时间（可能在其站点与其他第2层服务器对等）。每个站点的客户端都可以配置为使用其站点的共享选播地址，从而简化其配置。如果最近的选播服务器发生变化，则在每个站点上限制选播路由将最大限度地减少客户端的中断。每个第2层服务器都可以在其单播接口上唯一标识，以便于监控。
This document has no IANA actions.
本文档没有IANA操作。
Time is a fundamental component of security on the Internet. The absence of a reliable source of current time subverts many common web authentication schemes, e.g., by allowing the use of expired credentials or allowing the replay of messages only intended to be processed once.
时间是互联网安全的基本组成部分。缺少可靠的当前时间源会破坏许多常见的web身份验证方案，例如，通过允许使用过期的凭据或允许重播只打算处理一次的消息。
Much of this document directly addresses how to secure NTP servers. In particular, see Section 2, Section 4, and Section 5.
本文档的大部分内容直接介绍了如何保护NTP服务器。具体见第2节、第4节和第5节。
There are several general threats to time-synchronization protocols, which are discussed in [RFC7384].
[RFC7384]中讨论了对时间同步协议的几种常见威胁。
[NTSFORNTP] specifies the Network Time Security (NTS) mechanism and applies it to NTP. Readers are encouraged to check the status of the document and make use of the methods it describes.
[NTSFORNTP]指定网络时间安全（NTS）机制并将其应用于NTP。鼓励读者检查文档的状态，并使用文档描述的方法。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，DOI 10.17487/RFC2827，2000年5月<https://www.rfc-editor.org/info/rfc2827>.
[RFC4085] Plonka, D., "Embedding Globally-Routable Internet Addresses Considered Harmful", BCP 105, RFC 4085, DOI 10.17487/RFC4085, June 2005, <https://www.rfc-editor.org/info/rfc4085>.
[RFC4085]Plonka，D.，“嵌入被认为有害的全球可路由互联网地址”，BCP 105，RFC 4085，DOI 10.17487/RFC4085，2005年6月<https://www.rfc-editor.org/info/rfc4085>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <https://www.rfc-editor.org/info/rfc4786>.
[RFC4786]Abley，J.和K.Lindqvist，“任意广播服务的运营”，BCP 126，RFC 4786，DOI 10.17487/RFC4786，2006年12月<https://www.rfc-editor.org/info/rfc4786>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 5905，DOI 10.17487/RFC59052010年6月<https://www.rfc-editor.org/info/rfc5905>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[AUTOKEY] Roettger, S., "Autokey-Protocol Analysis", August 2011, <https://lists.ntp.org/pipermail/ ntpwg/2011-August/001714.html>.
[自动密钥]Roettger，S.，“自动密钥协议分析”，2011年8月<https://lists.ntp.org/pipermail/ ntpwg/2011年8月/001714.html>。
[BCP38WIKI] "BCP38.info Wiki", October 2016, <http://www.bcp38.info>.
[BCP38WIKI]“BCP38.info Wiki”，2016年10月<http://www.bcp38.info>.
[CCR16] Malhotra, A. and S. Goldberg, "Attacking NTP's Authenticated Broadcast Mode", SIGCOMM Computer Communications Review (CCR) Volume 46, Issue 2, DOI 10.1145/2935634.2935637, April 2016.
[CCR16]Malhotra，A.和S.Goldberg，“攻击NTP的认证广播模式”，SIGCOMM计算机通信评论（CCR）第46卷，第2期，DOI 10.1145/2935634.2935637，2016年4月。
[CONFIGNTP] Network Time Foundation, "Configuring NTP", November 2018, <https://support.ntp.org/bin/view/Support/ConfiguringNTP>.
[网络时代基金会]，“配置NTP”，2018年11月，<https://support.ntp.org/bin/view/Support/ConfiguringNTP>.
[CTRLMSG] Haberman, B., Ed., "Control Messages Protocol for Use with Network Time Protocol Version 4", Work in Progress, draft-ietf-ntp-mode-6-cmds-06, September 2018.
[CTRLMSG]Haberman，B.，Ed.“与网络时间协议版本4一起使用的控制消息协议”，正在进行的工作，草稿-ietf-ntp-mode-6-cmds-062018年9月。
[CVE-2015-8138] Van Gundy, M. and J. Gardner, "Network Time Protocol Origin Timestamp Check Impersonation Vulnerability", January 2016, <https://www.talosintel.com/reports/TALOS-2016-0077>.
[CVE-2015-8138]Van Gundy，M.和J.Gardner，“网络时间协议源时间戳检查模拟漏洞”，2016年1月<https://www.talosintel.com/reports/TALOS-2016-0077>.
[CVE-2015-8139] Van Gundy, M., "Network Time Protocol ntpq and ntpdc Origin Timestamp Disclosure Vulnerability", January 2016, <https://www.talosintel.com/reports/TALOS-2016-0078>.
[CVE-2015-8139]Van Gundy，M.，“网络时间协议ntpq和ntpdc源时间戳泄露漏洞”，2016年1月<https://www.talosintel.com/reports/TALOS-2016-0078>.
[CVE-2016-1548] Gardner, J. and M. Lichvar, "Xleave Pivot: NTP Basic Mode to Interleaved", April 2016, <https://blog.talosintel.com/2016/04/ vulnerability-spotlight-further-ntpd_27.html>.
[CVE-2016-1548]Gardner，J.和M.Lichvar，“Xleave Pivot:NTP基本模式到交错”，2016年4月<https://blog.talosintel.com/2016/04/ 漏洞-spotlight-further-ntpd_27.html>。
[DATAMIN] Franke, D. and A. Malhotra, "NTP Client Data Minimization", Work in Progress, draft-ietf-ntp-data-minimization-04, March 2019.
[DATAMIN]Franke，D.和A.Malhotra，“NTP客户数据最小化”，正在进行的工作，草案-ietf-NTP-Data-Minimization-042019年3月。
[DDOS] Prince, M., "Technical Details Behind a 400Gbps NTP Amplification DDoS Attack", February 2014, <https://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack>.
[DDOS]Prince，M.，“400Gbps NTP放大DDOS攻击背后的技术细节”，2014年2月<https://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack>.
[IERS] IERS, "IERS Bulletins", <https://www.iers.org/IERS/EN/Publications/Bulletins/ bulletins.html>.
[IERS]IERS，“IERS公告”<https://www.iers.org/IERS/EN/Publications/Bulletins/ bulletins.html>。
[IMC14] Czyz, J., Kallitsis, M., Gharaibeh, M., Papadopoulos, C., Bailey, M., and M. Karir, "Taming the 800 Pound Gorilla: The Rise and Decline of NTP DDoS Attacks", Proceedings of the 2014 Internet Measurement Conference, DOI 10.1145/2663716.2663717, November 2014.
[IMC14]Czyz，J.，Kallitsis，M.，Gharaibeh，M.，Papadopoulos，C.，Bailey，M.，和M.Karir，“驯服800磅大猩猩：NTP DDoS攻击的兴起和衰落”，《2014年互联网测量会议录》，DOI 10.1145/2663716.2663717，2014年11月。
[LEAPSEC] Burnicki, M., "Leap Second Smearing", <http://bk1.ntp.org/ ntp-stable/README.leapsmear?PAGE=anno>.
[LEAPSEC]Burnicki，M.，“闰秒涂抹”<http://bk1.ntp.org/ ntp稳定/README.leapstroude？PAGE=anno>。
[MILLS2006] Mills, D., "Computer network time synchronization: the Network Time Protocol", CRC Press, 2006.
[MILLS2006]Mills，D.，“计算机网络时间同步：网络时间协议”，CRC出版社，2006年。
[MISUSE] Wikipedia, "NTP Server Misuse and Abuse", May 2019, <https://en.wikipedia.org/w/index.php? title=NTP_server_misuse_and_abuse&oldid=899024751>.
[滥用]维基百科，“NTP服务器滥用和滥用”，2019年5月<https://en.wikipedia.org/w/index.php? title=NTP\u服务器\u滥用\u和\u滥用&oldid=899024751>。
[NDSS14] Rossow, C., "Amplification Hell: Revisiting Network Protocols for DDoS Abuse", Network and Distributed System Security (NDSS) Symposium 2014, DOI 10.14722/ndss.2014.23233, February 2014, <https://www.ndss-symposium.org/ndss2014/programme/ amplification-hell-revisiting-network-protocols-ddos-abuse/>.
[NDSS14]Rossow，C.，“放大地狱：重新审视DDoS滥用的网络协议”，2014年网络和分布式系统安全（NDSS）研讨会，DOI 10.14722/NDSS.2014.23233，2014年2月<https://www.ndss-symposium.org/ndss2014/programme/ 重温网络协议ddos滥用/>。
[NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, "Attacking the Network Time Protocol", Network and Distributed System Security (NDSS) Symposium 2016, DOI 10.14722/ndss.2016.23090, February 2016, <https://eprint.iacr.org/2015/1020.pdf>.
[NDSS16]Malhotra，A.，Cohen，I.，Brakke，E.，和S.Goldberg，“攻击网络时间协议”，2016年网络和分布式系统安全（NDSS）研讨会，DOI 10.14722/NDSS.2016.230902016年2月<https://eprint.iacr.org/2015/1020.pdf>.
[NTPDOWN] Network Time Foundation, "NTP Software Downloads", <http://www.ntp.org/downloads.html>.
网络时间基础，“NTP软件下载”，<http://www.ntp.org/downloads.html>.
[NTSFORNTP] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. Sundblad, "Network Time Security for the Network Time Protocol", Work in Progress, draft-ietf-ntp-using-nts-for-ntp-20, July 2019.
[NTSFORNTP]Franke，D.，Sibold，D.，Teichel，K.，Dansarie，M.，和R.Sundblad，“网络时间协议的网络时间安全”，正在进行的工作，草案-ietf-ntp-using-nts-for-ntp-202019年7月。
[POOLUSE] NTP Pool Project, "Use the Pool", <https://www.pool.ntp.org/en/use.html>.
[POOLUSE]NTP池项目，“使用池”<https://www.pool.ntp.org/en/use.html>.
[POOLVENDOR] NTP Pool Project, "The NTP Pool for Vendors", <https://www.pool.ntp.org/en/vendors.html>.
[POOLVENDOR]NTP池项目，“供应商的NTP池”<https://www.pool.ntp.org/en/vendors.html>.
[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>.
[RFC1305]Mills，D.，“网络时间协议（版本3）规范、实施和分析”，RFC 1305，DOI 10.17487/RFC1305，1992年3月<https://www.rfc-editor.org/info/rfc1305>.
[RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol Version 4: Autokey Specification", RFC 5906, DOI 10.17487/RFC5906, June 2010, <https://www.rfc-editor.org/info/rfc5906>.
[RFC5906]Haberman，B.，Ed.和D.Mills，“网络时间协议第4版：自动密钥规范”，RFC 5906，DOI 10.17487/RFC5906，2010年6月<https://www.rfc-editor.org/info/rfc5906>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, <https://www.rfc-editor.org/info/rfc6151>.
[RFC6151]Turner，S.和L.Chen，“MD5消息摘要和HMAC-MD5算法的更新安全注意事项”，RFC 6151，DOI 10.17487/RFC6151，2011年3月<https://www.rfc-editor.org/info/rfc6151>.
[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>.
[RFC7094]McPherson，D.，Oran，D.，Thaler，D.，和E.Osterweil，“IP选播的架构考虑”，RFC 7094，DOI 10.17487/RFC7094，2014年1月<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>.
[RFC7384]Mizrahi，T.，“分组交换网络中时间协议的安全要求”，RFC 7384，DOI 10.17487/RFC7384，2014年10月<https://www.rfc-editor.org/info/rfc7384>.
[RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code for the Network Time Protocol", RFC 8573, DOI 10.17487/RFC8573, June 2019, <https://www.rfc-editor.org/info/rfc8573>.
[RFC8573]Malhotra，A.和S.Goldberg，“网络时间协议的消息认证码”，RFC 8573，DOI 10.17487/RFC8573，2019年6月<https://www.rfc-editor.org/info/rfc8573>.
[SOLAR] Wikipedia, "Solar Time", May 2019, <https://en.wikipedia.org/w/index.php? title=Solar_time&oldid=896601472#Mean_solar_time>.
[太阳能]维基百科，“太阳时间”，2019年5月<https://en.wikipedia.org/w/index.php? title=Solar_time&oldid=896601472#Mean_Solar_time>。
Appendix A. Best Practices Specific to the Network Time Foundation Implementation
附录A.网络时代基金会具体实施的最佳实践
The Network Time Foundation (NTF) provides a widely used implementation of NTP, known as ntpd [NTPDOWN]. It is an evolution of the first NTP implementations developed by David Mills at the University of Delaware. This appendix contains additional recommendations specific to this implementation that are valid at the time of this writing.
网络时间基金会（NTF）提供了广泛使用的NTP实现，称为NTPD[NTPUD]。这是David Mills在德拉瓦大学开发的第一个NTP实现的演变。本附录包含在撰写本文时有效的针对本实施的其他建议。
In addition to the recommendation given in Section 3.2, the ntpd implementation provides the 'pool' directive. Starting with ntp-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 servers and add in new servers as needed. The 'minclock' and 'maxclock' options of the 'tos' command may be used to override the default values of how many servers are discovered through the 'pool' directive.
除了第3.2节中给出的建议外，ntpd实施还提供了“池”指令。从ntp-4.2.6开始，在ntp.conf文件中使用此指令将启动足够多的关联，以提供强健的时间服务，并将断开较差的服务器，并根据需要添加新服务器。“tos”命令的“minclock”和“maxclock”选项可用于覆盖通过“pool”指令发现的服务器数量的默认值。
In addition to NTP control messages, the ntpd implementation also offers the Mode 7 commands for monitoring and configuration.
除了NTP控制消息外，ntpd实现还提供用于监视和配置的模式7命令。
If Mode 7 has been explicitly enabled to be used for more than basic monitoring, it should be limited to authenticated sessions that provide a 'requestkey'.
如果模式7已显式启用以用于基本监视以外的用途，则应将其限制为提供“requestkey”的经过身份验证的会话。
As mentioned above, there are two general ways to use Mode 6 and Mode 7 requests. One way is to query ntpd for information, and this mode can be disabled with:
如上所述，使用模式6和模式7请求有两种通用方法。一种方法是查询ntpd以获取信息，可通过以下方式禁用此模式：
restrict ... noquery
限制无疑问
The second way to use Mode 6 and Mode 7 requests is to modify ntpd's behavior. Modification of ntpd's configuration requires an authenticated session by default. If no authentication keys have been specified, no modifications can be made. For additional protection, the ability to perform these modifications can be controlled with:
使用模式6和模式7请求的第二种方法是修改ntpd的行为。默认情况下，修改ntpd的配置需要经过身份验证的会话。如果未指定身份验证密钥，则无法进行任何修改。为获得额外保护，可通过以下方式控制执行这些修改的能力：
restrict ... nomodify
限制nomodify
Users can prevent their NTP servers from considering query/ configuration traffic by default by adding the following to their ntp.conf file:
默认情况下，用户可以通过向NTP.conf文件中添加以下内容来防止其NTP服务器考虑查询/配置流量：
restrict default -4 nomodify notrap nopeer noquery
限制默认值-4 nomodify notrap nopeer noquery
restrict default -6 nomodify notrap nopeer noquery
限制默认值-6 nomodify notrap nopeer noquery
restrict source nomodify notrap noquery
限制源nomodify notrap noquery
The ntpd implementation allows remote monitoring. Access to this service is generally controlled by the "noquery" directive in NTP's configuration file (ntp.conf) via a "restrict" statement. The syntax reads:
ntpd实现允许远程监控。对该服务的访问通常由NTP配置文件（NTP.conf）中的“noquery”指令通过“restrict”语句控制。语法如下：
restrict address mask address_mask noquery
限制地址掩码地址\u掩码noquery
If a system is using broadcast mode and is running ntp-4.2.8p6 or later, use the fourth field of the ntp.keys file to specify the IPs of machines that are allowed to serve time to the group.
如果系统使用广播模式并运行ntp-4.2.8p6或更高版本，请使用ntp.keys文件的第四个字段指定允许为组服务时间的机器的IP。
The use of leap-second files requires ntpd 4.2.6 or later. After fetching the leap-second file onto the server, add this line to ntpd.conf to apply and use the file, substituting the proper path:
使用闰秒文件需要ntpd 4.2.6或更高版本。将闰秒文件提取到服务器上后，将此行添加到ntpd.conf以应用和使用该文件，并替换正确的路径：
leapfile "/path/to/leap-file"
leapfile "/path/to/leap-file"
There may be a need to restart ntpd to apply this change.
可能需要重新启动ntpd以应用此更改。
ntpd servers with a manually configured leap-second file will ignore a leap-second information broadcast from upstream NTP servers until the 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.
具有手动配置的闰秒文件的ntpd服务器将忽略从上游NTP服务器广播的闰秒信息，直到闰秒文件过期。如果没有有效的闰秒文件可用，则ntpd始终接受来自附加参考时钟的闰秒通知。
If no valid leap-second file is available, a leap-second notification may be accepted from upstream NTP servers. As of ntp-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 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, but this behavior was once chosen because in the "early days", there was a greater chance that leap-
如果没有有效的闰秒文件可用，则可以接受来自上游NTP服务器的闰秒通知。从ntp-4.2.6开始，大多数服务器必须在接受通知之前提供通知。在4.2.6之前，如果一组已配置服务器的单个上游服务器提供闰秒通知，则可接受闰秒通知。如果单个NTP服务器发送无效的闰秒警告（例如，由于一台服务器中的GPS接收器出现故障），这将导致不当行为，但这种行为曾经被选择，因为在“早期”，发生这种闰秒的可能性更大-
second information would be available from a very limited number of sources.
第二个信息来源非常有限。
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 configured by default and must be added at compile time. In addition, no leap smearing will occur unless a leap smear interval is specified in ntpd.conf. For more information, refer to [LEAPSEC].
为响应客户请求，ntpd版本4.2.8.p3和4.3.47中引入了Leap涂抹。默认情况下不配置对leap涂抹的支持，必须在编译时添加。此外，除非在ntpd.conf中指定了跳跃涂抹间隔，否则不会发生跳跃涂抹。有关更多信息，请参阅[LEAPSEC]。
See [CONFIGNTP] for additional information on configuring ntpd.
有关配置ntpd的更多信息，请参阅[CONFIGNTP]。
Each communication partner must add the key information to their key file in the form:
每个通信合作伙伴必须以以下形式将密钥信息添加到其密钥文件中：
keyid type key
密钥ID类型密钥
where "keyid" is a number between 1 and 65534, inclusive; "type" is an ASCII character that defines the key format; and "key" is the key itself.
其中，“keyid”是一个介于1和65534之间的数字（包括1和65534）；“类型”是定义键格式的ASCII字符；而“钥匙”就是钥匙本身。
An ntpd client establishes a protected association by appending the option "key keyid" to the server statement in ntp.conf,
ntpd客户端通过在ntp.conf中的server语句中附加选项“key keyid”来建立受保护的关联，
server address key keyid
服务器地址密钥密钥ID
substituting the server address in the "address" field and the numerical keyid to use with that server in the "keyid" field.
在“地址”字段中替换服务器地址，在“密钥ID”字段中替换要与该服务器一起使用的数字密钥ID。
A key is deemed trusted when its keyid is added to the list of trusted keys by the "trustedkey" statement in ntp.conf.
当密钥的keyid通过ntp.conf中的“trustedkey”语句添加到受信任密钥列表中时，该密钥被视为受信任密钥。
trustedkey keyid_1 keyid_2 ... keyid_n
信任密钥密钥ID\u 1密钥ID\u 2。。。钥匙
Starting with ntp-4.2.8p7, the ntp.keys file accepts an optional fourth column, a comma-separated list of IPs that are allowed to serve time. 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].
从ntp-4.2.8p7开始，ntp.keys文件接受一个可选的第四列，这是一个逗号分隔的IP列表，允许服务时间。使用此功能。但是，请注意，知道对称广播密钥的敌对客户端仍然可以很容易地将其源IP欺骗到允许服务时间的IP。这很容易做到，因为客户端没有验证广播模式数据包上的源时间戳。相比之下，客户机/服务器和对称模式确实需要原始时间戳验证，这使得欺骗数据包更加困难[CCR16]。
Acknowledgments
致谢
The authors wish to acknowledge the contributions of Sue Graves, Samuel Weiler, Lisa Perdue, Karen O'Donoghue, David Malone, Sharon Goldberg, Martin Burnicki, Miroslav Lichvar, Daniel Fox Franke, Robert Nagy, and Brian Haberman.
作者希望感谢Sue Graves、Samuel Weiler、Lisa Perdue、Karen O'Donoghue、David Malone、Sharon Goldberg、Martin Burnicki、Miroslav Lichvar、Daniel Fox Franke、Robert Nagy和Brian Haberman的贡献。
Authors' Addresses
作者地址
Denis Reilly (editor) Orolia USA 1565 Jefferson Road, Suite 460 Rochester, NY 14623 United States of America
Denis Reilly（编辑）Orolia USA美国纽约州罗切斯特杰斐逊路1565号460室14623
Email: denis.reilly@orolia.com
Email: denis.reilly@orolia.com
Harlan Stenn Network Time Foundation P.O. Box 918 Talent, OR 97540 United States of America
HalLANSTN网络时间基金会信箱918人才，或97540美利坚合众国
Email: stenn@nwtime.org
Email: stenn@nwtime.org
Dieter Sibold Physikalisch-Technische Bundesanstalt Bundesallee 100 Braunschweig D-38116 Germany
德国布伦瑞克D-38116德国联邦卫生技术学院
Phone: +49-(0)531-592-8420
Fax: +49-531-592-698420
Email: dieter.sibold@ptb.de
Phone: +49-(0)531-592-8420
Fax: +49-531-592-698420
Email: dieter.sibold@ptb.de