Internet Engineering Task Force (IETF) T. Mizrahi
Request for Comments: 7384 Marvell
Category: Informational October 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) T. Mizrahi
Request for Comments: 7384 Marvell
Category: Informational October 2014
ISSN: 2070-1721
Security Requirements of Time Protocols in Packet Switched Networks
分组交换网络中时间协议的安全要求
Abstract
摘要
As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization.
随着时间和频率分布协议变得越来越普遍和广泛部署，人们越来越担心它们面临各种安全威胁。本文件定义了一组时间协议的安全要求，重点是精确时间协议（PTP）和网络时间协议（NTP）。本文档还讨论了时间协议实践的安全影响、外部安全实践对时间协议的性能影响，以及其他安全服务和时间同步之间的依赖关系。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7384.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7384.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................5
2.1. Requirements Language ......................................5
2.2. Abbreviations ..............................................6
2.3. Common Terminology for PTP and NTP .........................6
2.4. Terms Used in This Document ................................6
3. Security Threats ................................................7
3.1. Threat Model ...............................................8
3.1.1. Internal vs. External Attackers .....................8
3.1.2. Man in the Middle (MITM) vs. Packet Injector ........8
3.2. Threat Analysis ............................................9
3.2.1. Packet Manipulation .................................9
3.2.2. Spoofing ............................................9
3.2.3. Replay Attack .......................................9
3.2.4. Rogue Master Attack .................................9
3.2.5. Packet Interception and Removal ....................10
3.2.6. Packet Delay Manipulation ..........................10
3.2.7. L2/L3 DoS Attacks ..................................10
3.2.8. Cryptographic Performance Attacks ..................10
3.2.9. DoS Attacks against the Time Protocol ..............11
3.2.10. Grandmaster Time Source Attack (e.g., GPS Fraud) ..11
3.2.11. Exploiting Vulnerabilities in the Time Protocol ...11
3.2.12. Network Reconnaissance ............................11
3.3. Threat Analysis Summary ...................................12
4. Requirement Levels .............................................13
5. Security Requirements ..........................................14
5.1. Clock Identity Authentication and Authorization ...........14
5.1.1. Authentication and Authorization of Masters ........15
5.1.2. Recursive Authentication and Authorization
of Masters (Chain of Trust) ........................16
5.1.3. Authentication and Authorization of Slaves .........17
1. Introduction ....................................................4
2. Terminology .....................................................5
2.1. Requirements Language ......................................5
2.2. Abbreviations ..............................................6
2.3. Common Terminology for PTP and NTP .........................6
2.4. Terms Used in This Document ................................6
3. Security Threats ................................................7
3.1. Threat Model ...............................................8
3.1.1. Internal vs. External Attackers .....................8
3.1.2. Man in the Middle (MITM) vs. Packet Injector ........8
3.2. Threat Analysis ............................................9
3.2.1. Packet Manipulation .................................9
3.2.2. Spoofing ............................................9
3.2.3. Replay Attack .......................................9
3.2.4. Rogue Master Attack .................................9
3.2.5. Packet Interception and Removal ....................10
3.2.6. Packet Delay Manipulation ..........................10
3.2.7. L2/L3 DoS Attacks ..................................10
3.2.8. Cryptographic Performance Attacks ..................10
3.2.9. DoS Attacks against the Time Protocol ..............11
3.2.10. Grandmaster Time Source Attack (e.g., GPS Fraud) ..11
3.2.11. Exploiting Vulnerabilities in the Time Protocol ...11
3.2.12. Network Reconnaissance ............................11
3.3. Threat Analysis Summary ...................................12
4. Requirement Levels .............................................13
5. Security Requirements ..........................................14
5.1. Clock Identity Authentication and Authorization ...........14
5.1.1. Authentication and Authorization of Masters ........15
5.1.2. Recursive Authentication and Authorization
of Masters (Chain of Trust) ........................16
5.1.3. Authentication and Authorization of Slaves .........17
5.1.4. PTP: Authentication and Authorization of
P2P TCs by the Master ..............................18
5.1.5. PTP: Authentication and Authorization of
Control Messages ...................................18
5.2. Protocol Packet Integrity .................................19
5.2.1. PTP: Hop-by-Hop vs. End-to-End Integrity
Protection .........................................20
5.2.1.1. Hop-by-Hop Integrity Protection ...........20
5.2.1.2. End-to-End Integrity Protection ...........21
5.3. Spoofing Prevention .......................................21
5.4. Availability ..............................................22
5.5. Replay Protection .........................................23
5.6. Cryptographic Keys and Security Associations ..............23
5.6.1. Key Freshness ......................................23
5.6.2. Security Association ...............................24
5.6.3. Unicast and Multicast Associations .................24
5.7. Performance ...............................................25
5.8. Confidentiality ...........................................26
5.9. Protection against Packet Delay and Interception Attacks ..27
5.10. Combining Secured with Unsecured Nodes ...................27
5.10.1. Secure Mode .......................................28
5.10.2. Hybrid Mode .......................................28
6. Summary of Requirements ........................................29
7. Additional Security Implications ...............................31
7.1. Security and On-the-Fly Timestamping ......................31
7.2. PTP: Security and Two-Step Timestamping ...................31
7.3. Intermediate Clocks .......................................32
7.4. External Security Protocols and Time Protocols ............32
7.5. External Security Services Requiring Time .................33
7.5.1. Timestamped Certificates ...........................33
7.5.2. Time Changes and Replay Attacks ....................33
8. Issues for Further Discussion ..................................34
9. Security Considerations ........................................34
10. References ....................................................34
10.1. Normative References .....................................34
10.2. Informative References ...................................34
Acknowledgments ...................................................36
Contributors ......................................................36
Author's Address ..................................................36
5.1.4. PTP: Authentication and Authorization of
P2P TCs by the Master ..............................18
5.1.5. PTP: Authentication and Authorization of
Control Messages ...................................18
5.2. Protocol Packet Integrity .................................19
5.2.1. PTP: Hop-by-Hop vs. End-to-End Integrity
Protection .........................................20
5.2.1.1. Hop-by-Hop Integrity Protection ...........20
5.2.1.2. End-to-End Integrity Protection ...........21
5.3. Spoofing Prevention .......................................21
5.4. Availability ..............................................22
5.5. Replay Protection .........................................23
5.6. Cryptographic Keys and Security Associations ..............23
5.6.1. Key Freshness ......................................23
5.6.2. Security Association ...............................24
5.6.3. Unicast and Multicast Associations .................24
5.7. Performance ...............................................25
5.8. Confidentiality ...........................................26
5.9. Protection against Packet Delay and Interception Attacks ..27
5.10. Combining Secured with Unsecured Nodes ...................27
5.10.1. Secure Mode .......................................28
5.10.2. Hybrid Mode .......................................28
6. Summary of Requirements ........................................29
7. Additional Security Implications ...............................31
7.1. Security and On-the-Fly Timestamping ......................31
7.2. PTP: Security and Two-Step Timestamping ...................31
7.3. Intermediate Clocks .......................................32
7.4. External Security Protocols and Time Protocols ............32
7.5. External Security Services Requiring Time .................33
7.5.1. Timestamped Certificates ...........................33
7.5.2. Time Changes and Replay Attacks ....................33
8. Issues for Further Discussion ..................................34
9. Security Considerations ........................................34
10. References ....................................................34
10.1. Normative References .....................................34
10.2. Informative References ...................................34
Acknowledgments ...................................................36
Contributors ......................................................36
Author's Address ..................................................36
As time protocols are becoming increasingly common and widely deployed, concern about the resulting exposure to various security threats is increasing. If a time protocol is compromised, the applications it serves are prone to a range of possible attacks including Denial of Service (DoS) or incorrect behavior.
随着时间协议变得越来越普遍和广泛部署，人们越来越担心由此带来的各种安全威胁。如果时间协议被破坏，它所服务的应用程序容易受到一系列可能的攻击，包括拒绝服务（DoS）或错误行为。
This document discusses the security aspects of time distribution protocols in packet networks and focuses on the two most common protocols: the Network Time Protocol [NTPv4] and the Precision Time Protocol (PTP) [IEEE1588]. Note that although PTP was not defined by the IETF, it is one of the two most common time protocols; hence, it is included in the discussion.
本文档讨论分组网络中时间分配协议的安全方面，并重点讨论两种最常见的协议：网络时间协议[NTPv4]和精确时间协议（PTP）[IEEE1588]。请注意，尽管PTP未由IETF定义，但它是两种最常见的时间协议之一；因此，它被包括在讨论中。
The Network Time Protocol was defined with an inherent security protocol; [NTPv4] defines a security protocol that is based on a symmetric key authentication scheme, and [AutoKey] presents an alternative security protocol, based on a public key authentication scheme. [IEEE1588] includes an experimental security protocol, defined in Annex K of the standard, but this Annex was never formalized into a fully defined security protocol.
网络时间协议定义了一个固有的安全协议；[NTPv4]定义了基于对称密钥认证方案的安全协议，[AutoKey]提出了基于公钥认证方案的替代安全协议。[IEEE1588]包括本标准附录K中定义的实验性安全协议，但本附录从未正式成为完全定义的安全协议。
While NTP includes an inherent security protocol, the absence of a standard security solution for PTP undoubtedly contributed to the wide deployment of unsecured time synchronization solutions. However, in some cases, security mechanisms may not be strictly necessary, e.g., due to other security practices in place or due to the architecture of the network. A time synchronization security solution, much like any security solution, is comprised of various building blocks and must be carefully tailored for the specific system in which it is deployed. Based on a system-specific threat assessment, the benefits of a security solution must be weighed against the potential risks, and based on this trade-off an optimal security solution can be selected.
虽然NTP包含一个固有的安全协议，但PTP缺乏标准的安全解决方案无疑是广泛部署不安全时间同步解决方案的原因。然而，在某些情况下，安全机制可能不是严格必要的，例如，由于其他安全实践或由于网络架构的原因。时间同步安全解决方案与任何安全解决方案都非常相似，它由各种构建块组成，必须针对部署它的特定系统进行精心定制。基于特定于系统的威胁评估，必须权衡安全解决方案的好处和潜在风险，并基于此权衡选择最佳安全解决方案。
The target audience of this document includes:
本文件的目标受众包括：
o Timing and networking equipment vendors - can benefit from this document by deriving the security features that should be supported in the time/networking equipment.
o 计时和联网设备供应商-可从本文件中获益，其方法是获得时间/联网设备中应支持的安全功能。
o Standards development organizations - can use the requirements defined in this document when specifying security mechanisms for a time protocol.
o 标准开发组织-在指定时间协议的安全机制时，可以使用本文档中定义的要求。
o Network operators - can use this document as a reference when designing a network and its security architecture. As stated above, the requirements in this document may be deployed selectively based on a careful per-system threat analysis.
o 网络运营商-在设计网络及其安全体系结构时，可将本文档用作参考。如上所述，本文档中的需求可以根据仔细的每个系统威胁分析进行选择性部署。
This document attempts to add clarity to the time protocol security requirements discussion by addressing a series of questions:
本文件试图通过解决一系列问题，使时间协议安全要求讨论更加清晰：
(1) What are the threats that need to be addressed for the time protocol and what security services need to be provided (e.g., a malicious NTP server or PTP master)?
(1) 时间协议需要解决哪些威胁？需要提供哪些安全服务（例如，恶意NTP服务器或PTP主机）？
(2) What external security practices impact the security and performance of time keeping and what can be done to mitigate these impacts (e.g., an IPsec tunnel in the time protocol traffic path)?
(2) 哪些外部安全实践会影响计时的安全性和性能，以及可以采取哪些措施来减轻这些影响（例如，时间协议流量路径中的IPsec隧道）？
(3) What are the security impacts of time protocol practices (e.g., on-the-fly modification of timestamps)?
(3) 时间协议实践的安全性影响是什么（例如，即时修改时间戳）？
(4) What are the dependencies between other security services and time protocols? (For example, which comes first - the certificate or the timestamp?)
(4) 其他安全服务和时间协议之间的依赖关系是什么？（例如，哪个先到-证书还是时间戳？）
In light of the questions above, this document defines a set of requirements for security solutions for time protocols, focusing on PTP and NTP.
鉴于上述问题，本文件定义了时间协议安全解决方案的一组要求，重点是PTP和NTP。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
This document describes security requirements; thus, requirements are phrased in the document in the form "the security mechanism MUST/SHOULD/...". Note that the phrasing does not imply that this document defines a specific security mechanism, but that it defines the requirements with which every security mechanism should comply.
本文件描述了安全要求；因此，要求在文件中以“安全机制必须/应该/…”的形式表述。请注意，该措辞并不意味着本文档定义了特定的安全机制，而是定义了每个安全机制应遵守的要求。
BC Boundary Clock [IEEE1588]
BC边界时钟[IEEE1588]
BMCA Best Master Clock Algorithm [IEEE1588]
BMCA最佳主时钟算法[IEEE1588]
DoS Denial of Service
拒绝服务
MITM Man in the Middle
中间的米特曼
NTP Network Time Protocol [NTPv4]
NTP网络时间协议[NTPv4]
OC Ordinary Clock [IEEE1588]
OC普通时钟[IEEE1588]
P2P TC Peer-to-Peer Transparent Clock [IEEE1588]
P2P TC点对点透明时钟[IEEE1588]
PTP Precision Time Protocol [IEEE1588]
PTP精确时间协议[IEEE1588]
TC Transparent Clock [IEEE1588]
透明时钟[IEEE1588]
This document refers to both PTP and NTP. For the sake of consistency, throughout the document the term "master" applies to both a PTP master and an NTP server. Similarly, the term "slave" applies to both PTP slaves and NTP clients. The term "protocol packets" refers generically to PTP and NTP messages.
本文件同时涉及PTP和NTP。为了保持一致性，在整个文档中，“主机”一词同时适用于PTP主机和NTP服务器。类似地，术语“从机”同时适用于PTP从机和NTP客户端。术语“协议包”一般指PTP和NTP消息。
o Clock - A node participating in the protocol (either PTP or NTP). A clock can be a master, a slave, or an intermediate clock (see corresponding definitions below).
o 时钟-参与协议的节点（PTP或NTP）。时钟可以是主时钟、从时钟或中间时钟（参见下面的相应定义）。
o Control packets - Packets used by the protocol to exchange information between clocks that is not strictly related to the time. NTP uses NTP Control Messages. PTP uses Announce, Signaling, and Management messages.
o 控制数据包-协议用于在时钟之间交换与时间无关的信息的数据包。NTP使用NTP控制消息。PTP使用公告、信令和管理消息。
o End-to-end security - A security approach where secured packets sent from a source to a destination are not modified by intermediate nodes, allowing the destination to authenticate the source of the packets and to verify their integrity. In the context of confidentiality, end-to-end encryption guarantees that intermediate nodes cannot eavesdrop to en route packets. However, as discussed in Section 5, confidentiality is not a strict requirement in this document.
o 端到端安全-一种安全方法，其中从源发送到目的地的安全数据包不会被中间节点修改，从而允许目的地验证数据包的源并验证其完整性。在保密性方面，端到端加密保证中间节点不能窃听路由数据包。但是，如第5节所述，保密性在本文件中并非严格要求。
o Grandmaster - A master that receives time information from a locally attached clock device and not through the network. A grandmaster distributes its time to other clocks in the network.
o Grandmaster-从本地连接的时钟设备而不是通过网络接收时间信息的主机。特级大师将其时间分配给网络中的其他时钟。
o Hop-by-hop security - A security approach where secured packets sent from a source to a destination may be modified by intermediate nodes. In this approach intermediate nodes share the encryption key with the source and destination, allowing them to re-encrypt or re-authenticate modified packets before relaying them to the destination.
o 逐跳安全-一种安全方法，其中从源发送到目的地的安全数据包可由中间节点修改。在这种方法中，中间节点与源和目标共享加密密钥，允许它们在将修改后的数据包中继到目标之前重新加密或重新验证。
o Intermediate clock - A clock that receives timing information from a master and sends timing information to other clocks. In NTP, this term refers to an NTP server that is not a Stratum 1 server. In PTP, this term refers to a BC or a TC.
o 中间时钟-从主时钟接收定时信息并向其他时钟发送定时信息的时钟。在NTP中，此术语指的是不是第1层服务器的NTP服务器。在PTP中，该术语指BC或TC。
o Master - A clock that generates timing information to other clocks in the network. In NTP, 'master' refers to an NTP server. In PTP, 'master' refers to a master OC (aka grandmaster) or to a port of a BC that is in the master state.
o 主时钟-向网络中的其他时钟生成定时信息的时钟。在NTP中，“主”是指NTP服务器。在PTP中，“主”指的是主OC（又名grandmaster）或处于主状态的BC的端口。
o Protocol packets - Packets used by the time protocol. The terminology used in this document distinguishes between time packets and control packets.
o 协议数据包-时间协议使用的数据包。本文件中使用的术语区分时间包和控制包。
o Secured clock - A clock that supports a security mechanism that complies to the requirements in this document.
o 安全时钟-支持符合本文件要求的安全机制的时钟。
o Slave - A clock that receives timing information from a master. In NTP, 'slave' refers to an NTP client. In PTP, 'slave' refers to a slave OC or to a port of a BC that is in the slave state.
o 从属-从主时钟接收定时信息的时钟。在NTP中，“从”是指NTP客户端。在PTP中，“从”是指从OC或处于从状态的BC的端口。
o Time packets - Protocol packets carrying time information.
o 时间包-承载时间信息的协议包。
o Unsecured clock - A clock that does not support a security mechanism according to the requirements in this document.
o 不安全时钟-根据本文件要求，不支持安全机制的时钟。
This section discusses the possible attacker types and analyzes various attacks against time protocols.
本节讨论可能的攻击者类型，并分析针对时间协议的各种攻击。
The literature is rich with security threats of time protocols, e.g., [Traps], [AutoKey], [TimeSec], [SecPTP], and [SecSen]. The threat analysis in this document is mostly based on [TimeSec].
文献中有大量时间协议的安全威胁，例如，[Traps]、[AutoKey]、[TimeSec]、[SecPTP]和[SecSen]。本文件中的威胁分析主要基于[TimeSec]。
A time protocol can be attacked by various types of attackers.
时间协议可能会受到各种类型的攻击者的攻击。
The analysis in this document classifies attackers according to two criteria, as described in Sections 3.1.1 and 3.1.2.
本文中的分析根据两个标准对攻击者进行分类，如第3.1.1节和第3.1.2节所述。
In the context of internal and external attackers, the underlying assumption is that the time protocol is secured by either an encryption mechanism, an authentication mechanism, or both.
在内部和外部攻击者的情况下，基本假设是时间协议由加密机制、身份验证机制或两者都提供安全保护。
Internal attackers either have access to a trusted segment of the network or possess the encryption or authentication keys. An internal attack can also be performed by exploiting vulnerabilities in devices; for example, by installing malware or obtaining credentials to reconfigure the device. Thus, an internal attacker can maliciously tamper with legitimate traffic in the network as well as generate its own traffic and make it appear legitimate to its attacked nodes.
内部攻击者可以访问受信任的网络段，或者拥有加密或身份验证密钥。还可以利用设备中的漏洞进行内部攻击；例如，通过安装恶意软件或获取凭据来重新配置设备。因此，内部攻击者可以恶意篡改网络中的合法流量，并生成自己的流量，使其在受攻击节点看来合法。
Note that internal attacks are a special case of Byzantine failures, where a node in the system may fail in arbitrary ways; by crashing, by omitting messages, or by malicious behavior. This document focuses on nodes that demonstrate malicious behavior.
请注意，内部攻击是拜占庭失败的一种特殊情况，系统中的节点可能以任意方式失败；通过崩溃、忽略消息或恶意行为。本文档重点介绍显示恶意行为的节点。
External attackers, on the other hand, do not have the keys and have access only to the encrypted or authenticated traffic.
另一方面，外部攻击者没有密钥，只能访问加密或认证的通信量。
Obviously, in the absence of a security mechanism, there is no distinction between internal and external attackers, since all attackers are internal in practice.
显然，在缺乏安全机制的情况下，内部和外部攻击者之间没有区别，因为实际上所有攻击者都是内部攻击者。
MITM attackers are located in a position that allows interception and modification of in-flight protocol packets. It is assumed that an MITM attacker has physical access to a segment of the network or has gained control of one of the nodes in the network.
MITM攻击者位于允许拦截和修改飞行中协议数据包的位置。假设MITM攻击者可以物理访问网络的某个网段，或者已经获得对网络中某个节点的控制权。
A traffic injector is not located in an MITM position, but can attack by generating protocol packets. An injector can reside either within the attacked network or on an external network that is connected to the attacked network. An injector can also potentially eavesdrop on protocol packets sent as multicast, record them, and replay them later.
流量注入器不位于MITM位置，但可以通过生成协议包进行攻击。喷油器可以位于受攻击网络内，也可以位于连接到受攻击网络的外部网络上。注入器还可能窃听作为多播发送的协议数据包，记录它们，然后重新播放它们。
A packet manipulation attack results when an MITM attacker receives timing protocol packets, alters them, and relays them to their destination, allowing the attacker to maliciously tamper with the protocol. This can result in a situation where the time protocol is apparently operational but providing intentionally inaccurate information.
当MITM攻击者接收定时协议数据包，对其进行更改，并将其转发到目的地，从而允许攻击者恶意篡改协议时，就会产生数据包操纵攻击。这可能导致时间协议显然是可操作的，但故意提供不准确的信息。
In spoofing, an injector masquerades as a legitimate node in the network by generating and transmitting protocol packets or control packets. Two typical examples of spoofing attacks:
在欺骗中，注入器通过生成和传输协议包或控制包，伪装成网络中的合法节点。欺骗攻击的两个典型示例：
o An attacker can impersonate the master, allowing malicious distribution of false timing information.
o 攻击者可以模拟主机，从而允许恶意分发错误的计时信息。
o An attacker can impersonate a legitimate clock, a slave, or an intermediate clock, by sending malicious messages to the master, causing the master to respond to the legitimate clock with protocol packets that are based on the spoofed messages. Consequently, the delay computations of the legitimate clock are based on false information.
o 攻击者可以通过向主机发送恶意消息来模拟合法时钟、从时钟或中间时钟，从而使主机使用基于伪造消息的协议包响应合法时钟。因此，合法时钟的延迟计算基于错误信息。
As with packet manipulation, this attack can result in a situation where the time protocol is apparently operational but providing intentionally inaccurate information.
与数据包操纵一样，这种攻击可能导致时间协议显然是可操作的，但故意提供不准确的信息。
In a replay attack, an attacker records protocol packets and replays them at a later time without any modification. This can also result in a situation where the time protocol is apparently operational but providing intentionally inaccurate information.
在重播攻击中，攻击者记录协议数据包，并在以后不进行任何修改的情况下重播它们。这也可能导致时间协议显然是可操作的，但故意提供不准确的信息。
In a rogue master attack, an attacker causes other nodes in the network to believe it is a legitimate master. As opposed to the spoofing attack, in the rogue master attack the attacker does not fake its identity, but rather manipulates the master election process using malicious control packets. For example, in PTP, an attacker can manipulate the Best Master Clock Algorithm (BMCA) and cause other nodes in the network to believe it is the most eligible candidate to be a grandmaster.
在恶意主机攻击中，攻击者会使网络中的其他节点相信它是合法主机。与欺骗攻击相反，在流氓主机攻击中，攻击者不会伪造其身份，而是使用恶意控制数据包操纵主机选举过程。例如，在PTP中，攻击者可以操纵最佳主时钟算法（BMCA），并使网络中的其他节点相信它是最有资格成为特级大师的候选。
In PTP, a possible variant of this attack is the rogue TC/BC attack. Similar to the rogue master attack, an attacker can cause victims to believe it is a legitimate TC or BC, allowing the attacker to manipulate the time information forwarded to the victims.
在PTP中，这种攻击的一种可能变体是流氓TC/BC攻击。与盗贼主攻击类似，攻击者可以使受害者相信它是合法的TC或BC，从而允许攻击者操纵转发给受害者的时间信息。
A packet interception and removal attack results when an MITM attacker intercepts and drops protocol packets, preventing the destination node from receiving some or all of the protocol packets.
当MITM攻击者截获并丢弃协议数据包，阻止目标节点接收部分或全部协议数据包时，就会产生数据包截获和删除攻击。
In a packet delay manipulation scenario, an MITM attacker receives protocol packets and relays them to their destination after adding a maliciously computed delay. The attacker can use various delay attack strategies; the added delay can be constant, jittered, or slowly wandering. Each of these strategies has a different impact, but they all effectively manipulate the attacked clock.
在数据包延迟操纵场景中，MITM攻击者接收协议数据包，并在添加恶意计算的延迟后将其中继到目的地。攻击者可以使用各种延迟攻击策略；增加的延迟可以是恒定的、抖动的或缓慢的漂移。每种策略都有不同的影响，但它们都能有效地操纵被攻击的时钟。
Note that the victim still receives one copy of each packet, contrary to the replay attack, where some or all of the packets may be received by the victim more than once.
请注意，受害者仍然会收到每个数据包的一个副本，与重播攻击相反，在重播攻击中，受害者可能会多次收到部分或全部数据包。
There are many possible Layer 2 and Layer 3 DoS attacks, e.g., IP spoofing, ARP spoofing [Hack], MAC flooding [Anatomy], and many others. As the target's availability is compromised, the timing protocol is affected accordingly.
有许多可能的第2层和第3层DoS攻击，例如IP欺骗、ARP欺骗[Hack]、MAC洪泛[Anatomy]和许多其他攻击。当目标的可用性受到损害时，定时协议也相应受到影响。
In cryptographic performance attacks, an attacker transmits fake protocol packets, causing high utilization of the cryptographic engine at the receiver, which attempts to verify the integrity of these fake packets.
在加密性能攻击中，攻击者传输假协议数据包，导致接收方密码引擎的高利用率，从而试图验证这些假数据包的完整性。
This DoS attack is applicable to all encryption and authentication protocols. However, when the time protocol uses a dedicated security mechanism implemented in a dedicated cryptographic engine, this attack can be applied to cause DoS specifically to the time protocol.
此DoS攻击适用于所有加密和身份验证协议。但是，当时间协议使用专用加密引擎中实现的专用安全机制时，此攻击可应用于专门针对时间协议的DoS。
An attacker can attack a clock by sending an excessive number of time protocol packets, thus degrading the victim's performance. This attack can be implemented, for example, using the attacks described in Sections 3.2.2 and 3.2.4.
攻击者可以通过发送过多的时间协议数据包来攻击时钟，从而降低受害者的性能。例如，可以使用第3.2.2节和第3.2.4节中描述的攻击实施此攻击。
Grandmasters receive their time from an external accurate time source, such as an atomic clock or a GPS clock, and then distribute this time to the slaves using the time protocol.
大师从外部精确时间源（如原子钟或GPS时钟）接收时间，然后使用时间协议将时间分配给从属设备。
Time source attacks are aimed at the accurate time source of the grandmaster. For example, if the grandmaster uses a GPS-based clock as its reference source, an attacker can jam the reception of the GPS signal, or transmit a signal similar to one from a GPS satellite, causing the grandmaster to use a false reference time.
时间源攻击的目标是大师的精确时间源。例如，如果grandmaster使用基于GPS的时钟作为其参考源，攻击者可以干扰GPS信号的接收，或发送类似于GPS卫星的信号，从而导致grandmaster使用错误的参考时间。
Note that this attack is outside the scope of the time protocol. While various security measures can be taken to mitigate this attack, these measures are outside the scope of the security requirements defined in this document.
请注意，此攻击不在时间协议的范围内。虽然可以采取各种安全措施来缓解此攻击，但这些措施不在本文档中定义的安全要求的范围内。
Time protocols can be attacked by exploiting vulnerabilities in the protocol, implementation bugs, or misconfigurations (e.g., [NTPDDoS]). It should be noted that such attacks cannot typically be mitigated by security mechanisms. However, when a new vulnerability is discovered, operators should react as soon as possible, and take the necessary measures to address it.
利用协议中的漏洞、实现错误或错误配置（例如[NTPDDoS]），可以攻击时间协议。应该注意的是，这种攻击通常不能通过安全机制来缓解。但是，当发现新的漏洞时，运营商应尽快作出反应，并采取必要措施加以解决。
An attacker can exploit the time protocol to collect information such as addresses and locations of nodes that take part in the protocol. Reconnaissance can be applied by either passively eavesdropping on protocol packets or sending malicious packets and gathering information from the responses. By eavesdropping on a time protocol, an attacker can learn the network latencies, which provide information about the network topology and node locations.
攻击者可以利用时间协议收集参与协议的节点的地址和位置等信息。可以通过被动窃听协议数据包或发送恶意数据包并从响应中收集信息来实施侦察。通过窃听时间协议，攻击者可以了解网络延迟，从而提供有关网络拓扑和节点位置的信息。
Moreover, properties such as the frequency of the protocol packets, or the exact times at which they are sent, can allow fingerprinting of specific nodes; thus, protocol packets from a node can be identified even if network addresses are hidden or encrypted.
此外，诸如协议分组的频率或发送它们的确切时间之类的属性可以允许对特定节点进行指纹识别；因此，即使网络地址被隐藏或加密，也可以识别来自节点的协议分组。
The two key factors to a threat analysis are the impact and the likelihood of each of the analyzed attacks.
威胁分析的两个关键因素是所分析攻击的影响和可能性。
Table 1 summarizes the security attacks presented in Section 3.2. For each attack, the table specifies its impact, and its applicability to each of the attacker types presented in Section 3.1.
表1总结了第3.2节中介绍的安全攻击。对于每种攻击，该表规定了其影响，以及其对第3.1节中介绍的每种攻击者类型的适用性。
Table 1 clearly shows the distinction between external and internal attackers, and motivates the usage of authentication and integrity protection, significantly reducing the impact of external attackers.
表1清楚地显示了外部和内部攻击者之间的区别，并鼓励使用身份验证和完整性保护，显著降低了外部攻击者的影响。
The Impact column provides an intuitive measure of the severity of each attack, and the relevant Attacker Type column provides an intuition about how difficult each attack is to implement and, hence, about the likelihood of each attack.
“影响”列直观地度量了每次攻击的严重性，而相关的“攻击者类型”列直观地描述了每次攻击的实施难度，以及每次攻击的可能性。
The Impact column in Table 1 can have one of three values:
表1中的影响列可以有三个值之一：
o DoS - the attack causes denial of service to the attacked node, the impact of which is not restricted to the time protocol.
o DoS-攻击会导致被攻击节点拒绝服务，其影响不限于时间协议。
o Accuracy degradation - the attack yields a degradation in the slave accuracy, but does not completely compromise the slaves' time and frequency.
o 精度降低-攻击会导致从属精度降低，但不会完全影响从属的时间和频率。
o False time - slaves align to a false time or frequency value due to the attack. Note that if the time protocol aligns to a false time, it may cause DoS to other applications that rely on accurate time. However, for the purpose of the analysis in this section, we distinguish this implication from 'DoS', which refers to a DoS attack that is not necessarily aimed at the time protocol. All attacks that have a '+' for 'False Time' implicitly have a '+' for 'Accuracy Degradation'. Note that 'False Time' necessarily implies 'Accuracy Degradation'. However, two different terms are used, indicating two levels of severity.
o False time（错误时间）-由于攻击，从属设备与错误的时间或频率值对齐。请注意，如果时间协议与假时间对齐，则可能会导致依赖精确时间的其他应用程序拒绝服务。然而，为了本节的分析目的，我们将此含义与“DoS”区分开来，后者指的是不一定针对时间协议的DoS攻击。所有以“+”表示“假时间”的攻击都隐式地以“+”表示“精度降低”。请注意，“假时间”必然意味着“精度下降”。但是，使用了两个不同的术语，表示两种严重程度。
The Attacker Type column refers to the four possible combinations of the attacker types defined in Section 3.1.
“攻击者类型”列指第3.1节中定义的攻击者类型的四种可能组合。
+-----------------------------+-------------------++-------------------+
| Attack | Impact || Attacker Type |
| +-----+--------+----++---------+---------+
| |False|Accuracy| ||Internal |External |
| |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.|
+-----------------------------+-----+--------+----++----+----+----+----+
|Manipulation | + | | || + | | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Spoofing | + | | || + | + | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Replay attack | + | | || + | + | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Rogue master attack | + | | || + | + | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Interception and removal | | + | + || + | | + | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Packet delay manipulation | + | | || + | | + | |
+-----------------------------+-----+--------+----++----+----+----+----+
|L2/L3 DoS attacks | | | + || + | + | + | + |
+-----------------------------+-----+--------+----++----+----+----+----+
|Crypt. performance attacks | | | + || + | + | + | + |
+-----------------------------+-----+--------+----++----+----+----+----+
|Time protocol DoS attacks | | | + || + | + | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Master time source attack | + | | || + | + | + | + |
|(e.g., GPS spoofing) | | | || | | | |
+-----------------------------+-----+--------+----++----+----+----+----+
+-----------------------------+-------------------++-------------------+
| Attack | Impact || Attacker Type |
| +-----+--------+----++---------+---------+
| |False|Accuracy| ||Internal |External |
| |Time |Degrad. |DoS ||MITM|Inj.|MITM|Inj.|
+-----------------------------+-----+--------+----++----+----+----+----+
|Manipulation | + | | || + | | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Spoofing | + | | || + | + | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Replay attack | + | | || + | + | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Rogue master attack | + | | || + | + | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Interception and removal | | + | + || + | | + | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Packet delay manipulation | + | | || + | | + | |
+-----------------------------+-----+--------+----++----+----+----+----+
|L2/L3 DoS attacks | | | + || + | + | + | + |
+-----------------------------+-----+--------+----++----+----+----+----+
|Crypt. performance attacks | | | + || + | + | + | + |
+-----------------------------+-----+--------+----++----+----+----+----+
|Time protocol DoS attacks | | | + || + | + | | |
+-----------------------------+-----+--------+----++----+----+----+----+
|Master time source attack | + | | || + | + | + | + |
|(e.g., GPS spoofing) | | | || | | | |
+-----------------------------+-----+--------+----++----+----+----+----+
Table 1: Threat Analysis - Summary
表1：威胁分析-摘要
The threats discussed in this section provide the background for the security requirements presented in Section 5.
本节讨论的威胁为第5节提出的安全要求提供了背景。
The security requirements are presented in Section 5. Each requirement is defined with a requirement level, in accordance with the requirement levels defined in Section 2.1.
安全要求见第5节。根据第2.1节中定义的需求级别，每个需求都定义了一个需求级别。
The requirement levels in this document are affected by the following factors:
本文件中的需求水平受以下因素影响：
o Impact: The possible impact of not implementing the requirement, as illustrated in the Impact column of Table 1. For example, a requirement that addresses a threat that can be implemented by an external injector is typically a 'MUST', since the threat can be implemented by all the attacker types analyzed in Section 3.1.
o 影响：未实施需求的可能影响，如表1的影响栏所示。例如，解决可由外部注入器实施的威胁的要求通常是“必须”的，因为该威胁可由第3.1节中分析的所有攻击者类型实施。
o Difficulty of the corresponding attack: The level of difficulty of the possible attacks that become possible by not implementing the requirement. The level of difficulty is reflected in the Attacker Type column of Table 1. For example, a requirement that addresses a threat that only compromises the availability of the protocol is typically no more than a 'SHOULD'.
o 相应攻击的难度：由于未实现需求而可能发生的攻击的难度级别。难度级别反映在表1的攻击者类型列中。例如，针对仅影响协议可用性的威胁的需求通常不超过“应该”。
o Practical considerations: Various practical factors that may affect the requirement. For example, if a requirement is very difficult to implement, or is applicable to very specific scenarios, these factors may reduce the requirement level.
o 实际考虑：可能影响需求的各种实际因素。例如，如果一个需求很难实现，或者适用于非常特定的场景，这些因素可能会降低需求级别。
Section 5 lists the requirements. For each requirement, there is a short explanation detailing the reason for its requirement level.
第5节列出了要求。对于每个需求，都有一个简短的解释，详细说明了其需求级别的原因。
This section defines a set of security requirements. These requirements are phrased in the form "the security mechanism MUST/SHOULD/MAY...". However, this document does not specify how these requirements can be met. While these requirements can be satisfied by defining explicit security mechanisms for time protocols, at least a subset of the requirements can be met by applying common security practices to the network or by using existing security protocols, such as [IPsec] or [MACsec]. Thus, security solutions that address these requirements are outside the scope of this document.
本节定义了一组安全要求。这些要求以“安全机制必须/应该/可以…”的形式表述。但是，本文件未规定如何满足这些要求。虽然可以通过为时间协议定义明确的安全机制来满足这些要求，但至少可以通过将通用安全实践应用于网络或通过使用现有安全协议（如[IPsec]或[MACsec]）来满足这些要求的子集。因此，满足这些要求的安全解决方案不在本文档的范围之内。
Requirement
要求
The security mechanism MUST support authentication.
安全机制必须支持身份验证。
Requirement
要求
The security mechanism MUST support authorization.
安全机制必须支持授权。
Requirement Level
需求水平
The requirements in this subsection address the spoofing attack (Section 3.2.2) and the rogue master attack (Section 3.2.4).
本小节中的要求涉及欺骗攻击（第3.2.2节）和流氓主攻击（第3.2.4节）。
The requirement level of these requirements is 'MUST' since, in the absence of these requirements, the protocol is exposed to attacks that are easy to implement and have a high impact.
这些要求的要求级别是“必须”的，因为在没有这些要求的情况下，协议会受到易于实施且影响较大的攻击。
Discussion
讨论
Authentication refers to verifying the identity of the peer clock. Authorization, on the other hand, refers to verifying that the peer clock is permitted to play the role that it plays in the protocol. For example, some nodes may be permitted to be masters, while other nodes are only permitted to be slaves or TCs.
身份验证是指验证对等时钟的标识。另一方面，授权是指验证对等时钟是否被允许发挥它在协议中所起的作用。例如，某些节点可能被允许为主节点，而其他节点仅被允许为从节点或TC。
Authentication is typically implemented by means of a cryptographic signature, allowing the verification of the identity of the sender. Authorization requires clocks to maintain a list of authorized clocks, or a "black list" of clocks that should be denied service or revoked.
身份验证通常通过加密签名实现，允许验证发送方的身份。授权要求时钟维护授权时钟列表，或应拒绝服务或撤销的时钟“黑名单”。
It is noted that while the security mechanism is required to provide an authorization mechanism, the deployment of such a mechanism depends on the nature of the network. For example, a network that deploys PTP may consist of a set of identical OCs, where all clocks are equally permitted to be a master. In such a network, an authorization mechanism may not be necessary.
需要注意的是，虽然需要安全机制来提供授权机制，但这种机制的部署取决于网络的性质。例如，部署PTP的网络可以由一组相同的OCs组成，其中所有时钟都被平等地允许作为主时钟。在这样的网络中，可能不需要授权机制。
The following subsections describe five distinct cases of clock authentication.
以下小节描述了时钟身份验证的五种不同情况。
Requirement
要求
The security mechanism MUST support an authentication mechanism, allowing slaves to authenticate the identity of masters.
安全机制必须支持身份验证机制，允许从机对主机的身份进行身份验证。
Requirement
要求
The authentication mechanism MUST allow slaves to verify that the authenticated master is authorized to be a master.
身份验证机制必须允许从属服务器验证已验证的主服务器是否被授权为主服务器。
Requirement Level
需求水平
The requirements in this subsection address the spoofing attack (Section 3.2.2) and the rogue master attack (Section 3.2.4).
本小节中的要求涉及欺骗攻击（第3.2.2节）和流氓主攻击（第3.2.4节）。
The requirement level of these requirements is 'MUST' since, in the absence of these requirements, the protocol is exposed to attacks that are easy to implement and have a high impact.
这些要求的要求级别是“必须”的，因为在没有这些要求的情况下，协议会受到易于实施且影响较大的攻击。
Discussion
讨论
Clocks authenticate masters in order to ensure the authenticity of the time source. It is important for a slave to verify the identity of the master, as well as to verify that the master is indeed authorized to be a master.
时钟验证主机，以确保时间源的真实性。对于从机来说，验证主机的身份以及验证主机是否确实被授权为主机非常重要。
5.1.2. Recursive Authentication and Authorization of Masters (Chain of Trust)
5.1.2. 主服务器的递归身份验证和授权（信任链）
Requirement
要求
The security mechanism MUST support recursive authentication and authorization of the master, to be used in cases where time information is conveyed through intermediate clocks.
安全机制必须支持主机的递归身份验证和授权，以便在时间信息通过中间时钟传输的情况下使用。
Requirement Level
需求水平
The requirement in this subsection addresses the spoofing attack (Section 3.2.2) and the rogue master attack (Section 3.2.4).
本小节中的要求涉及欺骗攻击（第3.2.2节）和流氓主攻击（第3.2.4节）。
The requirement level of this requirement is 'MUST' since, in the absence of this requirement, the protocol is exposed to attacks that are easy to implement and have a high impact.
此要求的要求级别为“必须”，因为在没有此要求的情况下，协议会受到易于实施且影响较大的攻击。
Discussion
讨论
In some cases, a slave is connected to an intermediate clock that is not the primary time source. For example, in PTP, a slave can be connected to a Boundary Clock (BC) or a Transparent Clock (TC), which in turn is connected to a grandmaster. A similar example in NTP is when a client is connected to a Stratum 2 server, which is connected to a Stratum 1 server. In both the PTP and the NTP cases, the slave authenticates the intermediate clock, and the intermediate clock authenticates the grandmaster. This recursive authentication process is referred to in [AutoKey] as proventication.
在某些情况下，从机连接到不是主时间源的中间时钟。例如，在PTP中，从时钟可以连接到边界时钟（BC）或透明时钟（TC），后者又连接到主时钟。NTP中的一个类似示例是，客户机连接到第2层服务器，该服务器连接到第1层服务器。在PTP和NTP两种情况下，从机验证中间时钟，中间时钟验证主时钟。此递归身份验证过程在[AutoKey]中称为预验证。
Specifically in PTP, this requirement implies that if a slave receives time information through a TC, it must authenticate the TC to which it is attached, as well as authenticate the master from which it receives the time information, as per Section 5.1.1. Similarly, if a TC receives time information through an attached TC, it must authenticate the attached TC.
特别是在PTP中，该要求意味着，如果从机通过TC接收时间信息，则必须根据第5.1.1节的规定，对其连接的TC进行身份验证，并对接收时间信息的主机进行身份验证。同样，如果TC通过连接的TC接收时间信息，则必须对连接的TC进行身份验证。
Requirement
要求
The security mechanism MAY provide a means for a master to authenticate its slaves.
安全机制可为主设备提供认证其从设备的方法。
Requirement
要求
The security mechanism MAY provide a means for a master to verify that the sender of a protocol packet is authorized to send a packet of this type.
安全机制可以为主机提供一种手段，以验证协议分组的发送方被授权发送这种类型的分组。
Requirement Level
需求水平
The requirement in this subsection prevents DoS attacks against the master (Section 3.2.9).
本小节中的要求可防止针对主机的DoS攻击（第3.2.9节）。
The requirement level of this requirement is 'MAY' since:
本要求的要求级别为“可能”，因为：
o Its impact is low, i.e., in the absence of this requirement the protocol is only exposed to DoS.
o 它的影响很小，即，在没有此要求的情况下，协议仅暴露于DoS。
o Practical considerations: requiring an NTP server to authenticate its clients may significantly impose on the server's performance.
o 实际注意事项：要求NTP服务器对其客户端进行身份验证可能会显著影响服务器的性能。
Note that while the requirement level of this requirement is 'MAY', the requirement in Section 5.1.1 is 'MUST'; the security mechanism must provide a means for authentication and authorization, with an emphasis on the master. Authentication and authorization of slaves are specified in this subsection as 'MAY'.
注意，虽然本要求的要求级别为“可能”，但第5.1.1节中的要求为“必须”；安全机制必须提供身份验证和授权的手段，重点是主机。本小节将从属服务器的认证和授权规定为“可”。
Discussion
讨论
Slaves and intermediate clocks are authenticated by masters in order to verify that they are authorized to receive timing services from the master.
从时钟和中间时钟由主时钟验证，以验证它们是否有权从主时钟接收定时服务。
Authentication of slaves prevents unauthorized clocks from receiving time services. Preventing the master from serving unauthorized clocks can help in mitigating DoS attacks against the master. Note that the authentication of slaves might put a higher load on the master than serving the unauthorized clock; hence, this requirement is 'MAY'.
从属设备的身份验证可防止未经授权的时钟接收时间服务。防止主机提供未经授权的时钟有助于减轻针对主机的DoS攻击。请注意，与为未经授权的时钟提供服务相比，从机的身份验证可能会给主机带来更大的负载；因此，这一要求是“可以”。
Requirement
要求
The security mechanism for PTP MAY provide a means for a master to authenticate the identity of the P2P TCs directly connected to it.
PTP的安全机制可为主机提供认证直接连接到它的P2P tc的身份的方法。
Requirement
要求
The security mechanism for PTP MAY provide a means for a master to verify that P2P TCs directly connected to it are authorized to be TCs.
PTP的安全机制可以为主机提供一种方法，以验证直接连接到它的P2P tc被授权为tc。
Requirement Level
需求水平
The requirement in this subsection prevents DoS attacks against the master (Section 3.2.9).
本小节中的要求可防止针对主机的DoS攻击（第3.2.9节）。
The requirement level of this requirement is 'MAY' for the same reasons specified in Section 5.1.3.
出于第5.1.3节规定的相同原因，本要求的要求级别为“可能”。
Discussion
讨论
P2P TCs that are one hop from the master use the PDelay_Req and PDelay_Resp handshake to compute the link delay between the master and TC. These TCs are authenticated by the master.
距离主机一跳的P2P TC使用PDelay_Req和PDelay_Resp握手来计算主机和TC之间的链路延迟。这些TCs由主机进行身份验证。
Authentication of TCs, much like authentication of slaves, reduces unnecessary load on the master and peer TCs, by preventing the master from serving unauthorized clocks.
TCs的身份验证与从属TCs的身份验证非常类似，通过防止主TCs为未经授权的时钟提供服务，减少了主TCs和对等TCs上不必要的负载。
Requirement
要求
The security mechanism for PTP MUST support authentication of Announce messages. The authentication mechanism MUST also verify that the sender is authorized to be a master.
PTP的安全机制必须支持公告消息的身份验证。身份验证机制还必须验证发送方是否被授权为主机。
Requirement
要求
The security mechanism for PTP MUST support authentication and authorization of Management messages.
PTP的安全机制必须支持管理消息的身份验证和授权。
Requirement
要求
The security mechanism MAY support authentication and authorization of Signaling messages.
安全机制可支持信令消息的认证和授权。
Requirement Level
需求水平
The requirements in this subsection address the spoofing attack (Section 3.2.2) and the rogue master attack (Section 3.2.4).
本小节中的要求涉及欺骗攻击（第3.2.2节）和流氓主攻击（第3.2.4节）。
The requirement level of the first two requirements is 'MUST' since, in the absence of these requirements, the protocol is exposed to attacks that are easy to implement and have a high impact.
前两项要求的要求级别是“必须”的，因为在没有这些要求的情况下，协议会受到易于实施且影响较大的攻击。
The requirement level of the third requirement is 'MAY' since its impact greatly depends on the application for which the Signaling messages are used.
第三个需求的需求级别为“可能”，因为其影响在很大程度上取决于使用信令消息的应用程序。
Discussion
讨论
Master election is performed in PTP using the Best Master Clock Algorithm (BMCA). Each Ordinary Clock (OC) announces its clock attributes using Announce messages, and the best master is elected based on the information gathered from all the candidates. Announce messages must be authenticated in order to prevent rogue master attacks (Section 3.2.4). Note that this subsection specifies a requirement that is not necessarily included in Sections 5.1.1 or 5.1.3, since the BMCA is initiated before clocks have been defined as masters or slaves.
主选择使用最佳主时钟算法（BMCA）在PTP中执行。每个普通时钟（OC）使用宣布消息宣布其时钟属性，并根据从所有候选者收集的信息选择最佳主时钟。公告消息必须经过身份验证，以防止流氓主机攻击（第3.2.4节）。请注意，本小节规定的要求不一定包含在第5.1.1或5.1.3节中，因为BMCA是在时钟被定义为主时钟或从时钟之前启动的。
Management messages are used to monitor or configure PTP clocks. Malicious usage of Management messages enables various attacks, such as the rogue master attack or DoS attack.
管理消息用于监视或配置PTP时钟。恶意使用管理消息会导致各种攻击，如恶意主机攻击或DoS攻击。
Signaling messages are used by PTP clocks to exchange information that is not strictly related to time information or to master selection, such as unicast negotiation. Authentication and authorization of Signaling messages may be required in some systems, depending on the application for which these messages are used.
PTP时钟使用信令消息来交换与时间信息或主选择不严格相关的信息，例如单播协商。在某些系统中，可能需要对信令消息进行身份验证和授权，具体取决于使用这些消息的应用程序。
Requirement
要求
The security mechanism MUST protect the integrity of protocol packets.
安全机制必须保护协议数据包的完整性。
Requirement Level
需求水平
The requirement in this subsection addresses the packet manipulation attack (Section 3.2.1).
本小节中的要求涉及数据包操纵攻击（第3.2.1节）。
The requirement level of this requirement is 'MUST' since, in the absence of this requirement, the protocol is exposed to attacks that are easy to implement and have high impact.
此要求的要求级别为“必须”，因为在没有此要求的情况下，协议会受到易于实施且具有高影响的攻击。
Discussion
讨论
While Section 5.1 refers to ensuring the identity an authorization of the source of a protocol packet, this subsection refers to ensuring that the packet arrived intact. The integrity protection mechanism ensures the authenticity and completeness of data from the data originator.
虽然第5.1节提到确保协议数据包源的身份和授权，但本小节提到确保数据包完好无损地到达。完整性保护机制确保来自数据发起人的数据的真实性和完整性。
Integrity protection is typically implemented by means of an Integrity Check Value (ICV) that is included in protocol packets and is verified by the receiver.
完整性保护通常通过完整性检查值（ICV）实现，该值包括在协议分组中，并由接收器验证。
Specifically in PTP, when protocol packets are subject to modification by TCs, the integrity protection can be enforced in one of two approaches: end-to-end or hop-by-hop.
特别是在PTP中，当协议包受到TCs的修改时，完整性保护可以通过两种方法之一实施：端到端或逐跳。
Each hop that needs to modify a protocol packet:
需要修改协议数据包的每个跃点：
o Verifies its integrity.
o 验证其完整性。
o Modifies the packet, i.e., modifies the correctionField. Note: TCs improve the end-to-end accuracy by updating a correctionField (Clause 6.5 in [IEEE1588]) in the PTP packet by adding the latency caused by the current TC.
o 修改数据包，即修改更正字段。注：TCs通过添加当前TC引起的延迟来更新PTP数据包中的校正字段（见[IEEE1588]第6.5条），从而提高端到端的准确性。
o Re-generates the integrity protection, e.g., re-computes a Message Authentication Code (MAC).
o 重新生成完整性保护，例如，重新计算消息认证码（MAC）。
In the hop-by-hop approach, the integrity of protocol packets is protected by induction on the path from the originator to the receiver.
在逐跳方法中，协议数据包的完整性通过从发端到接收方的路径上的归纳得到保护。
This approach is simple, but allows rogue TCs to modify protocol packets.
这种方法很简单，但允许恶意TCs修改协议包。
In this approach, the integrity protection is maintained on the path from the originator of a protocol packet to the receiver. This allows the receiver to directly validate the protocol packet without the ability of intermediate TCs to manipulate the packet.
在这种方法中，完整性保护在从协议包的发起方到接收方的路径上保持。这允许接收机直接验证协议分组，而不需要中间tc操作分组。
Since TCs need to modify the correctionField, a separate integrity protection mechanism is used specifically for the correctionField.
由于TCs需要修改correctionField，因此专门为correctionField使用单独的完整性保护机制。
The end-to-end approach limits the TC's impact to the correctionField alone, while the rest of the protocol packet is protected on an end-to-end basis. It should be noted that this approach is more difficult to implement than the hop-by-hop approach, as it requires the correctionField to be protected separately from the other fields of the packet, possibly using different cryptographic mechanisms and keys.
端到端方法将TC的影响仅限于correctionField，而协议包的其余部分则在端到端的基础上受到保护。应该注意的是，这种方法比逐跳方法更难实现，因为它要求纠错字段与数据包的其他字段分开保护，可能使用不同的加密机制和密钥。
Requirement
要求
The security mechanism MUST provide a means to prevent master spoofing.
安全机制必须提供防止主机欺骗的方法。
Requirement
要求
The security mechanism MUST provide a means to prevent slave spoofing.
安全机制必须提供防止从属欺骗的方法。
Requirement
要求
PTP: The security mechanism MUST provide a means to prevent P2P TC spoofing.
PTP：安全机制必须提供防止P2P TC欺骗的手段。
Requirement Level
需求水平
The requirements in this subsection address spoofing attacks. As described in Section 3.2.2, when these requirements are not met, the attack may have a high impact, causing slaves to rely on false time information. Thus, the requirement level is 'MUST'.
本小节中的要求涉及欺骗攻击。如第3.2.2节所述，当不满足这些要求时，攻击可能会产生很大的影响，导致从机依赖错误的时间信息。因此，需求级别为“必须”。
Discussion
讨论
Spoofing attacks may take various forms, and they can potentially cause significant impact. In a master spoofing attack, the attacker causes slaves to receive false information about the current time by masquerading as the master.
欺骗攻击可能采取各种形式，并可能造成重大影响。在主机欺骗攻击中，攻击者伪装为主机，使从属服务器接收有关当前时间的错误信息。
By spoofing a slave or an intermediate node (the second example of Section 3.2.2), an attacker can tamper with the slaves' delay computations. These attacks can be mitigated by an authentication mechanism (Sections 5.1.3 and 5.1.4) or by other means, for example, a PTP Delay_Req can include a MAC that is included in the corresponding Delay_Resp message, allowing the slave to verify that the Delay_Resp was not sent in response to a spoofed message.
通过欺骗从属节点或中间节点（第3.2.2节的第二个示例），攻击者可以篡改从属节点的延迟计算。这些攻击可以通过身份验证机制（第5.1.3节和第5.1.4节）或其他方式减轻，例如，PTP Delay_Req可以包括包含在相应Delay_Resp消息中的MAC，从而允许从机验证Delay_Resp没有响应欺骗消息而发送。
Requirement
要求
The security mechanism SHOULD include measures to mitigate DoS attacks against the time protocol.
安全机制应包括缓解针对时间协议的DoS攻击的措施。
Requirement Level
需求水平
The requirement in this subsection prevents DoS attacks against the protocol (Section 3.2.9).
本小节中的要求可防止针对协议的DoS攻击（第3.2.9节）。
The requirement level of this requirement is 'SHOULD' due to its low impact, i.e., in the absence of this requirement the protocol is only exposed to DoS.
由于其影响较小，该要求的要求级别为“应”，即在没有该要求的情况下，协议仅暴露于DoS。
Discussion
讨论
The protocol availability can be compromised by several different attacks. An attacker can inject protocol packets to implement the spoofing attack (Section 3.2.2) or the rogue master attack (Section 3.2.4), causing DoS to the victim (Section 3.2.9).
协议可用性可能会受到多个不同攻击的影响。攻击者可以注入协议数据包来实施欺骗攻击（第3.2.2节）或流氓主机攻击（第3.2.4节），从而对受害者造成拒绝服务（第3.2.9节）。
An authentication mechanism (Section 5.1) limits these attacks strictly to internal attackers; thus, it prevents external attackers from performing them. Hence, the requirements of Section 5.1 can be used to mitigate this attack. Note that Section 5.1 addresses a wider range of threats, whereas the current section is focused on availability.
认证机制（第5.1节）将这些攻击严格限制为内部攻击者；因此，它可以防止外部攻击者执行这些操作。因此，第5.1节的要求可用于缓解该攻击。请注意，第5.1节涉及范围更广的威胁，而当前的章节主要关注可用性。
The DoS attacks described in Section 3.2.7 are performed at lower layers than the time protocol layer, and they are thus outside the scope of the security requirements defined in this document.
第3.2.7节中描述的DoS攻击是在时间协议层以下的层执行的，因此它们不在本文件中定义的安全要求的范围内。
Requirement
要求
The security mechanism MUST include a replay prevention mechanism.
安全机制必须包括重播预防机制。
Requirement Level
需求水平
The requirement in this subsection prevents replay attacks (Section 3.2.3).
本小节中的要求可防止重播攻击（第3.2.3节）。
The requirement level of this requirement is 'MUST' since, in the absence of this requirement, the protocol is exposed to attacks that are easy to implement and have a high impact.
此要求的要求级别为“必须”，因为在没有此要求的情况下，协议会受到易于实施且影响较大的攻击。
Discussion
讨论
The replay attack (Section 3.2.3) can compromise both the integrity and availability of the protocol. Common encryption and authentication mechanisms include replay prevention mechanisms that typically use a monotonously increasing packet sequence number.
重播攻击（第3.2.3节）可能会损害协议的完整性和可用性。常见的加密和身份验证机制包括重播预防机制，这些机制通常使用单调递增的数据包序列号。
Requirement
要求
The security mechanism MUST provide a means to refresh the cryptographic keys.
安全机制必须提供刷新加密密钥的方法。
The cryptographic keys MUST be refreshed frequently.
必须经常刷新加密密钥。
Requirement Level
需求水平
The requirement level of this requirement is 'MUST' since key freshness is an essential property for cryptographic algorithms, as discussed below.
此要求的要求级别为“必须”，因为密钥新鲜度是加密算法的基本属性，如下所述。
Discussion
讨论
Key freshness guarantees that both sides share a common updated secret key. It also helps in preventing replay attacks. Thus, it is important for keys to be refreshed frequently. Note that the term 'frequently' is used without a quantitative requirement, as the precise frequency requirement should be considered on a per-system basis, based on the threats and system requirements.
密钥新鲜度保证双方共享一个公共的更新密钥。它还有助于防止重播攻击。因此，频繁刷新密钥非常重要。请注意，“频繁”一词的使用没有量化要求，因为应根据威胁和系统要求，在每个系统的基础上考虑精确的频率要求。
Requirement
要求
The security protocol SHOULD support a security association protocol where:
安全协议应支持安全关联协议，其中：
o Two or more clocks authenticate each other.
o 两个或多个时钟相互验证。
o The clocks generate and agree on a cryptographic session key.
o 时钟生成并同意加密会话密钥。
Requirement
要求
Each instance of the association protocol SHOULD produce a different session key.
关联协议的每个实例都应该生成不同的会话密钥。
Requirement Level
需求水平
The requirement level of this requirement is 'SHOULD' since it may be expensive in terms of performance, especially in low-cost clocks.
该要求的要求级别为“应该”，因为它在性能方面可能很昂贵，尤其是在低成本时钟中。
Discussion
讨论
The security requirements in Sections 5.1 and 5.2 require usage of cryptographic mechanisms, deploying cryptographic keys. A security association (e.g., [IPsec]) is an important building block in these mechanisms.
第5.1节和第5.2节中的安全要求要求使用加密机制，部署加密密钥。安全关联（例如，[IPsec]）是这些机制中的一个重要构建块。
It should be noted that in some cases, different security association mechanisms may be used at different levels of clock hierarchies. For example, the association between a Stratum 2 clock and a Stratum 3 clock in NTP may have different characteristics than an association between two clocks at the same stratum level. On a related note, in some cases, a hybrid solution may be used, where a subset of the network is not secured at all (see Section 5.10.2).
应当注意的是，在某些情况下，不同的安全关联机制可用于不同级别的时钟层次结构。例如，NTP中的第2层时钟和第3层时钟之间的关联可能具有与同一层级别上的两个时钟之间的关联不同的特征。另一方面，在某些情况下，如果网络的一个子集根本不安全，则可以使用混合解决方案（见第5.10.2节）。
Requirement
要求
The security mechanism SHOULD support security association protocols for unicast and for multicast associations.
安全机制应支持单播和多播关联的安全关联协议。
Requirement Level
需求水平
The requirement level of this requirement is 'SHOULD' since it may be expensive in terms of performance, especially for low-cost clocks.
该要求的要求级别为“应该”，因为它在性能方面可能很昂贵，尤其是对于低成本时钟。
Discussion
讨论
A unicast protocol requires an association protocol between two clocks, whereas a multicast protocol requires an association protocol among two or more clocks, where one of the clocks is a master.
单播协议需要两个时钟之间的关联协议，而多播协议需要两个或多个时钟之间的关联协议，其中一个时钟是主时钟。
Requirement
要求
The security mechanism MUST be designed in such a way that it does not significantly degrade the quality of the time transfer.
安全机制的设计必须确保不会显著降低时间传输的质量。
Requirement
要求
The mechanism SHOULD minimize computational load.
该机制应尽量减少计算负载。
Requirement
要求
The mechanism SHOULD minimize storage requirements of client state in the master.
该机制应尽量减少主机中客户端状态的存储要求。
Requirement
要求
The mechanism SHOULD minimize the bandwidth overhead required by the security protocol.
该机制应将安全协议所需的带宽开销降至最低。
Requirement Level
需求水平
While the quality of the time transfer is clearly a 'MUST', the other three performance requirements are 'SHOULD', since some systems may be more sensitive to resource consumption than others; hence, these requirements should be considered on a per-system basis.
虽然时间传输的质量显然是“必须的”，但其他三项性能要求是“应该的”，因为某些系统可能比其他系统对资源消耗更敏感；因此，应在每个系统的基础上考虑这些要求。
Discussion
讨论
Performance efficiency is important since client restrictions often dictate a low processing and memory footprint and because the server may have extensive fan-out.
性能效率非常重要，因为客户端限制通常会导致较低的处理和内存占用，而且服务器可能有大量的扇出。
Note that the performance requirements refer to a time-protocol-specific security mechanism. In systems where a security protocol is used for other types of traffic as well, this document does not place any performance requirements on the security protocol performance. For example, if IPsec encryption is used for securing all information between the master and slave node, including information that is not part of the time protocol, the requirements in this subsection are not necessarily applicable.
请注意，性能要求是指特定于时间协议的安全机制。在安全协议也用于其他类型通信的系统中，本文档不对安全协议性能提出任何性能要求。例如，如果IPsec加密用于保护主节点和从节点之间的所有信息，包括不属于时间协议的信息，则本小节中的要求不一定适用。
Requirement
要求
The security mechanism MAY provide confidentiality protection of the protocol packets.
安全机制可以提供协议分组的机密性保护。
Requirement Level
需求水平
The requirement level of this requirement is 'MAY' since the absence of this requirement does not expose the protocol to severe threats, as discussed below.
该要求的要求级别为“可能”，因为没有该要求不会使协议面临严重威胁，如下所述。
Discussion
讨论
In the context of time protocols, confidentiality is typically of low importance, since timing information is usually not considered secret information.
在时间协议的上下文中，机密性通常不太重要，因为时间信息通常不被视为机密信息。
Confidentiality can play an important role when service providers charge their customers for time synchronization services; thus, an encryption mechanism can prevent eavesdroppers from obtaining the service without payment. Note that these cases are, for now, rather esoteric.
当服务提供商向其客户收取时间同步服务费用时，保密性可以发挥重要作用；因此，加密机制可以防止窃听者在不付费的情况下获得服务。请注意，这些案例目前相当深奥。
Confidentiality can also prevent an MITM attacker from identifying protocol packets. Thus, confidentiality can assist in protecting the timing protocol against MITM attacks such as packet delay (Section 3.2.6), manipulation and interception, and removal attacks. Note that time protocols have predictable behavior even after encryption, such as packet transmission rates and packet lengths. Additional measures can be taken to mitigate encrypted traffic analysis by random padding of encrypted packets and by adding random dummy packets. Nevertheless, encryption does not prevent such MITM attacks, but rather makes these attacks more difficult to implement.
机密性还可以防止MITM攻击者识别协议数据包。因此，保密性有助于保护定时协议免受MITM攻击，如数据包延迟（第3.2.6节）、操纵和拦截以及删除攻击。请注意，即使在加密之后，时间协议也具有可预测的行为，例如数据包传输速率和数据包长度。通过对加密数据包进行随机填充和添加随机伪数据包，可以采取其他措施来减轻加密流量分析。然而，加密并不能阻止此类MITM攻击，反而使这些攻击更难实施。
Requirement
要求
The security mechanism MUST include means to protect the protocol from MITM attacks that degrade the clock accuracy.
安全机制必须包括保护协议免受降低时钟精度的MITM攻击的方法。
Requirement Level
需求水平
The requirements in this subsection address MITM attacks such as the packet delay attack (Section 3.2.6) and packet interception attacks (Sections 3.2.5 and 3.2.1).
本小节中的要求涉及MITM攻击，如数据包延迟攻击（第3.2.6节）和数据包拦截攻击（第3.2.5节和第3.2.1节）。
The requirement level of this requirement is 'MUST'. In the absence of this requirement, the protocol is exposed to attacks that are easy to implement and have a high impact. Note that in the absence of this requirement, the impact is similar to packet manipulation attacks (Section 3.2.1); thus, this requirement has the same requirement level as integrity protection (Section 5.2).
该要求的要求级别为“必须”。在没有这一要求的情况下，该协议会受到易于实施且影响较大的攻击。注意，在没有此要求的情况下，影响类似于数据包操纵攻击（第3.2.1节）；因此，该要求与完整性保护要求相同（第5.2节）。
It is noted that the implementation of this requirement depends on the topology and properties of the system.
需要注意的是，此要求的实现取决于系统的拓扑结构和属性。
Discussion
讨论
While this document does not define specific security solutions, we note that common practices for protection against MITM attacks use redundant masters (e.g., [NTPv4]) or redundant paths between the master and slave (e.g., [DelayAtt]). If one of the time sources indicates a time value that is significantly different than the other sources, it is assumed to be erroneous or under attack and is therefore ignored.
虽然本文档未定义特定的安全解决方案，但我们注意到，防止MITM攻击的常见做法使用冗余主设备（例如[NTPv4]）或主设备和从设备之间的冗余路径（例如[DelayAtt]）。如果其中一个时间源指示的时间值与其他时间源显著不同，则假定该时间值错误或受到攻击，因此忽略该时间值。
Thus, MITM attack prevention derives a requirement from the security mechanism and a requirement from the network topology. While the security mechanism should support the ability to detect delay attacks, it is noted that in some networks it is not possible to provide the redundancy needed for such a detection mechanism.
因此，MITM攻击预防源于安全机制和网络拓扑。虽然安全机制应支持检测延迟攻击的能力，但应注意，在某些网络中，不可能提供此类检测机制所需的冗余。
Integrating a security mechanism into a time-synchronized system is a complex and expensive process, and hence in some cases may require incremental deployment, where new equipment supports the security mechanism, and is required to interoperate with legacy equipment without the security features.
将安全机制集成到时间同步系统是一个复杂且昂贵的过程，因此在某些情况下可能需要增量部署，其中新设备支持安全机制，并且需要与没有安全功能的遗留设备进行互操作。
Requirement
要求
The security mechanism MUST support a secure mode, where only secured clocks are permitted to take part in the time protocol. In this mode every protocol packet received from an unsecured clock MUST be discarded.
安全机制必须支持安全模式，其中仅允许安全时钟参与时间协议。在此模式下，必须丢弃从不安全时钟接收的每个协议数据包。
Requirement Level
需求水平
The requirement level of this requirement is 'MUST' since the full capacity of the security requirements defined in this document can only be achieved in secure mode.
本要求的要求级别为“必须”，因为本文件中定义的安全要求的全部容量只能在安全模式下实现。
Discussion
讨论
While the requirement in this subsection is similar to the one in Section 5.1, it refers to the secure mode, as opposed to the hybrid mode presented in the next subsection.
虽然本小节中的要求与第5.1节中的要求类似，但它指的是安全模式，而不是下一小节中介绍的混合模式。
Requirement
要求
The security protocol SHOULD support a hybrid mode, where both secured and unsecured clocks are permitted to take part in the protocol.
安全协议应支持混合模式，其中安全时钟和非安全时钟均允许参与协议。
Requirement Level
需求水平
The requirement level of this requirement is 'SHOULD'; on one hand, hybrid mode enables a gradual transition from unsecured to secured mode, which is especially important in large-scaled deployments. On the other hand, hybrid mode is not required in all systems; this document recommends deployment of the 'secure mode' described in Section 5.10.1, where possible.
该要求的要求级别为“应”；一方面，混合模式允许从不安全模式逐步过渡到安全模式，这在大规模部署中尤为重要。另一方面，并非所有系统都需要混合模式；本文件建议尽可能采用第5.10.1节所述的“安全模式”。
Discussion
讨论
The hybrid mode allows both secured and unsecured clocks to take part in the time protocol. NTP, for example, allows a mixture of secured and unsecured nodes.
混合模式允许安全时钟和非安全时钟参与时间协议。例如，NTP允许混合使用安全节点和非安全节点。
Requirement
要求
A master in the hybrid mode SHOULD be a secured clock.
混合模式下的主时钟应为安全时钟。
A secured slave in the hybrid mode SHOULD discard all protocol packets received from unsecured clocks.
混合模式下的安全从机应丢弃从不安全时钟接收的所有协议数据包。
Requirement Level
需求水平
The requirement level of this requirement is 'SHOULD' since it may not be applicable to all deployments. For example, a hybrid network may require the usage of unsecured masters or TCs.
此要求的要求级别为“应该”，因为它可能不适用于所有部署。例如，混合网络可能需要使用不安全的主机或tc。
Discussion
讨论
This requirement ensures that the existence of unsecured clocks does not compromise the security provided to secured clocks. Hence, secured slaves only "trust" protocol packets received from a secured clock.
该要求确保不安全时钟的存在不会损害为安全时钟提供的安全性。因此，安全从属仅从安全时钟接收“信任”协议数据包。
An unsecured slave can receive protocol packets from either unsecured clocks or secured clocks. Note that the latter does not apply when encryption is used. When integrity protection is used, the unsecured slave can receive secured packets ignoring the integrity protection.
非安全从机可以从非安全时钟或安全时钟接收协议数据包。请注意，使用加密时，后者不适用。使用完整性保护时，不安全的从属服务器可以接收安全数据包，而忽略完整性保护。
Note that the security scheme in [NTPv4] with [AutoKey] does not satisfy this requirement, since nodes prefer the server with the most accurate clock, which is not necessarily the server that supports authentication. For example, a Stratum 2 server is connected to two Stratum 1 servers: Server A, supporting authentication, and Server B, without authentication. If Server B has a more accurate clock than A, the Stratum 2 server chooses Server B, in spite of the fact it does not support authentication.
请注意，[NTPv4]中带有[AutoKey]的安全方案不满足此要求，因为节点更喜欢时钟最准确的服务器，而不一定是支持身份验证的服务器。例如，一个第2层服务器连接到两个第1层服务器：支持身份验证的服务器a和不支持身份验证的服务器B。如果服务器B的时钟比服务器a更精确，则第2层服务器选择服务器B，尽管它不支持身份验证。
+-----------+---------------------------------------------+--------+
| Section | Requirement | Type |
+-----------+---------------------------------------------+--------+
| 5.1 | Authentication & authorization of sender | MUST |
| +---------------------------------------------+--------+
| | Authentication & authorization of master | MUST |
| +---------------------------------------------+--------+
| | Recursive authentication & authorization | MUST |
| +---------------------------------------------+--------+
| | Authentication & authorization of slaves | MAY |
| +---------------------------------------------+--------+
| | PTP: Authentication & authorization of | MAY |
| | P2P TCs by master | |
+-----------+---------------------------------------------+--------+
+-----------+---------------------------------------------+--------+
| Section | Requirement | Type |
+-----------+---------------------------------------------+--------+
| 5.1 | Authentication & authorization of sender | MUST |
| +---------------------------------------------+--------+
| | Authentication & authorization of master | MUST |
| +---------------------------------------------+--------+
| | Recursive authentication & authorization | MUST |
| +---------------------------------------------+--------+
| | Authentication & authorization of slaves | MAY |
| +---------------------------------------------+--------+
| | PTP: Authentication & authorization of | MAY |
| | P2P TCs by master | |
+-----------+---------------------------------------------+--------+
+-----------+---------------------------------------------+--------+
|5.1 (cont) | PTP: Authentication & authorization of | MUST |
| | Announce messages | |
| +---------------------------------------------+--------+
| | PTP: Authentication & authorization of | MUST |
| | Management messages | |
| +---------------------------------------------+--------+
| | PTP: Authentication & authorization of | MAY |
| | Signaling messages | |
+-----------+---------------------------------------------+--------+
| 5.2 | Integrity protection | MUST |
+-----------+---------------------------------------------+--------+
| 5.3 | Spoofing prevention | MUST |
+-----------+---------------------------------------------+--------+
| 5.4 | Protection from DoS attacks against the | SHOULD |
| | time protocol | |
+-----------+---------------------------------------------+--------+
| 5.5 | Replay protection | MUST |
+-----------+---------------------------------------------+--------+
| 5.6 | Key freshness | MUST |
| +---------------------------------------------+--------+
| | Security association | SHOULD |
| +---------------------------------------------+--------+
| | Unicast and multicast associations | SHOULD |
+-----------+---------------------------------------------+--------+
| 5.7 | Performance: no degradation in quality of | MUST |
| | time transfer | |
| +---------------------------------------------+--------+
| | Performance: computation load | SHOULD |
| +---------------------------------------------+--------+
| | Performance: storage | SHOULD |
| +---------------------------------------------+--------+
| | Performance: bandwidth | SHOULD |
+-----------+---------------------------------------------+--------+
| 5.8 | Confidentiality protection | MAY |
+-----------+---------------------------------------------+--------+
| 5.9 | Protection against delay and interception | MUST |
| | attacks | |
+-----------+---------------------------------------------+--------+
| 5.10 | Secure mode | MUST |
| +---------------------------------------------+--------+
| | Hybrid mode | SHOULD |
+-----------+---------------------------------------------+--------+
+-----------+---------------------------------------------+--------+
|5.1 (cont) | PTP: Authentication & authorization of | MUST |
| | Announce messages | |
| +---------------------------------------------+--------+
| | PTP: Authentication & authorization of | MUST |
| | Management messages | |
| +---------------------------------------------+--------+
| | PTP: Authentication & authorization of | MAY |
| | Signaling messages | |
+-----------+---------------------------------------------+--------+
| 5.2 | Integrity protection | MUST |
+-----------+---------------------------------------------+--------+
| 5.3 | Spoofing prevention | MUST |
+-----------+---------------------------------------------+--------+
| 5.4 | Protection from DoS attacks against the | SHOULD |
| | time protocol | |
+-----------+---------------------------------------------+--------+
| 5.5 | Replay protection | MUST |
+-----------+---------------------------------------------+--------+
| 5.6 | Key freshness | MUST |
| +---------------------------------------------+--------+
| | Security association | SHOULD |
| +---------------------------------------------+--------+
| | Unicast and multicast associations | SHOULD |
+-----------+---------------------------------------------+--------+
| 5.7 | Performance: no degradation in quality of | MUST |
| | time transfer | |
| +---------------------------------------------+--------+
| | Performance: computation load | SHOULD |
| +---------------------------------------------+--------+
| | Performance: storage | SHOULD |
| +---------------------------------------------+--------+
| | Performance: bandwidth | SHOULD |
+-----------+---------------------------------------------+--------+
| 5.8 | Confidentiality protection | MAY |
+-----------+---------------------------------------------+--------+
| 5.9 | Protection against delay and interception | MUST |
| | attacks | |
+-----------+---------------------------------------------+--------+
| 5.10 | Secure mode | MUST |
| +---------------------------------------------+--------+
| | Hybrid mode | SHOULD |
+-----------+---------------------------------------------+--------+
Table 2: Summary of Security Requirements
表2：安保要求摘要
This section discusses additional implications of the interaction between time protocols and security mechanisms.
本节讨论时间协议和安全机制之间交互的其他含义。
This section refers to time protocol security mechanisms, as well as to "external" security mechanisms, i.e., security mechanisms that are not strictly related to the time protocol.
本节涉及时间协议安全机制，以及“外部”安全机制，即与时间协议不严格相关的安全机制。
Time protocols often require that protocol packets be modified during transmission. Both NTP and PTP in one-step mode require clocks to modify protocol packets based on the time of transmission and/or reception.
时间协议通常要求在传输过程中修改协议包。一步模式下的NTP和PTP都需要时钟根据传输和/或接收时间修改协议包。
In the presence of a security mechanism, whether encryption or integrity protection:
在存在安全机制的情况下，无论是加密还是完整性保护：
o During transmission the encryption and/or integrity protection MUST be applied after integrating the timestamp into the packet.
o 在传输过程中，必须在将时间戳集成到数据包中后应用加密和/或完整性保护。
To allow high accuracy, timestamping is typically performed as close to the transmission or reception time as possible. However, since the security engine must be placed between the timestamping function and the physical interface, it may introduce non-deterministic latency that causes accuracy degradation. These performance aspects have been analyzed in literature, e.g., [1588IPsec] and [Tunnel].
为了允许高精度，通常在尽可能接近发送或接收时间的情况下执行时间戳。但是，由于安全引擎必须位于时间戳功能和物理接口之间，因此可能会引入不确定性延迟，从而导致准确性降低。这些性能方面已在文献中进行了分析，例如[1588IPsec]和[Tunnel]。
PTP supports a two-step mode of operation, where the time of transmission of protocol packets is communicated without modifying the packets. As opposed to one-step mode, two-step timestamping can be performed without the requirement to encrypt after timestamping.
PTP支持两步操作模式，其中在不修改数据包的情况下传输协议数据包的时间。与一步模式相反，可以执行两步时间戳，而无需在时间戳后进行加密。
Note that if an encryption mechanism such as IPsec is used, it presents a challenge to the timestamping mechanism, since time protocol packets are encrypted when traversing the physical interface, and are thus impossible to identify. A possible solution to this problem [IPsecSync] is to include an indication in the encryption header that identifies time protocol packets.
注意，如果使用诸如IPsec之类的加密机制，则会对时间戳机制提出挑战，因为时间协议数据包在穿越物理接口时被加密，因此无法识别。此问题的一个可能解决方案[IPsecSync]是在加密报头中包含一个标识时间协议数据包的指示。
A time protocol allows slaves to receive time information from an accurate time source. Time information is sent over a path that often traverses one or more intermediate clocks.
时间协议允许从机从精确的时间源接收时间信息。时间信息通过通常穿过一个或多个中间时钟的路径发送。
o In NTP, time information originated from a Stratum 1 server can be distributed to Stratum 2 servers and, in turn, distributed from the Stratum 2 servers to NTP clients. In this case, the Stratum 2 servers are a layer of intermediate clocks. These intermediate clocks are referred to as "secondary servers" in [NTPv4].
o 在NTP中，来自第1层服务器的时间信息可以分发到第2层服务器，然后从第2层服务器分发到NTP客户端。在这种情况下，第2层服务器是中间时钟层。这些中间时钟在[NTPv4]中称为“辅助服务器”。
o In PTP, BCs and TCs are intermediate nodes used to improve the accuracy of time information conveyed between the grandmaster and the slaves.
o 在PTP中，BCs和TCs是中间节点，用于提高主节点和从节点之间传输的时间信息的准确性。
A common rule of thumb in network security is that end-to-end security is the best policy, as it secures the entire path between the data originator and its receiver. The usage of intermediate nodes implies that if a security mechanism is deployed in the network, a hop-by-hop security scheme must be used, since intermediate nodes must be able to send time information to the slaves, or to modify time information sent through them.
网络安全中的一个常见经验法则是，端到端安全是最佳策略，因为它保护了数据发起者和接收者之间的整个路径。中间节点的使用意味着，如果在网络中部署了安全机制，则必须使用逐跳安全方案，因为中间节点必须能够向从属节点发送时间信息，或者修改通过从属节点发送的时间信息。
This inherent property of using intermediate clocks increases the system's exposure to internal threats, as a large number of nodes possess the security keys.
由于大量节点拥有安全密钥，使用中间时钟的固有特性增加了系统面临内部威胁的风险。
Thus, there is a trade-off between the achievable clock accuracy of a system, and the robustness of its security solution. On one hand, high clock accuracy calls for hop-by-hop involvement in the protocol, also known as on-path support. On the other hand, a robust security solution calls for end-to-end data protection.
因此，系统可实现的时钟精度与其安全解决方案的鲁棒性之间存在权衡。一方面，高时钟精度要求在协议中逐跳参与，也称为路径支持。另一方面，强健的安全解决方案需要端到端数据保护。
Time protocols are often deployed in systems that use security mechanisms and protocols.
时间协议通常部署在使用安全机制和协议的系统中。
A typical example is the 3GPP Femtocell network [3GPP], where IPsec is used for securing traffic between a Femtocell and the Femto Gateway. In some cases, all traffic between these two nodes may be secured by IPsec, including the time protocol traffic. This use-case is thoroughly discussed in [IPsecSync].
一个典型的例子是3GPP毫微微蜂窝网络[3GPP]，其中IPsec用于保护毫微微蜂窝和毫微微网关之间的通信量。在某些情况下，这两个节点之间的所有通信都可以由IPsec保护，包括时间协议通信。[IPsecSync]中详细讨论了此用例。
Another typical example is the usage of MACsec encryption ([MACsec]) in L2 networks that deploy time synchronization [AvbAssum].
另一个典型的例子是在部署时间同步[AvbAssum]的二级网络中使用MACsec加密（[MACsec]）。
The usage of external security mechanisms may affect time protocols as follows:
使用外部安全机制可能会影响以下时间协议：
o Timestamping accuracy can be affected, as described in Section 7.1.
o 如第7.1节所述，时间戳的准确性可能会受到影响。
o If traffic is secured between two nodes in the network, no intermediate clocks can be used between these two nodes. In the [3GPP] example, if traffic between the Femtocell and the Femto Gateway is encrypted, then time protocol packets are necessarily transported over the underlying network without modification and, thus, cannot enjoy the improved accuracy provided by intermediate clock nodes.
o 如果网络中的两个节点之间的通信是安全的，则这两个节点之间不能使用中间时钟。在[3GPP]示例中，如果对Femtocell和Femto网关之间的业务进行了加密，则时间协议分组必须在不经修改的情况下在底层网络上传输，因此，不能享受中间时钟节点提供的改进精度。
Cryptographic protocols often use time as an important factor in the cryptographic algorithm. If a time protocol is compromised, it may consequently expose the security protocols that rely on it to various attacks. Two examples are presented in this section.
密码协议通常将时间作为密码算法中的一个重要因素。如果时间协议被破坏，它可能会使依赖它的安全协议遭受各种攻击。本节介绍了两个示例。
Certificate validation requires the sender and receiver to be roughly time synchronized. Thus, synchronization is required for establishing security protocols such as Internet Key Exchange Protocol version 2 (IKEv2) and Transport Layer Security (TLS). Other authentication and key exchange mechanisms, such as Kerberos, also require the parties involved to be synchronized [Kerb].
证书验证要求发送方和接收方大致实现时间同步。因此，需要同步来建立安全协议，如Internet密钥交换协议版本2（IKEv2）和传输层安全协议（TLS）。其他身份验证和密钥交换机制（如Kerberos）也要求相关方同步[Kerb]。
An even stronger interdependence between a time protocol and a security mechanism is defined in [AutoKey], which defines mutual dependence between the acquired time information, and the authentication protocol that secures it. This bootstrapping behavior results from the fact that trusting the received time information requires a valid certificate, and validating a certificate requires knowledge of the time.
[AutoKey]中定义了时间协议和安全机制之间更强大的相互依赖性，它定义了获取的时间信息和保护时间信息的身份验证协议之间的相互依赖性。这种引导行为的原因是，信任接收到的时间信息需要有效的证书，而验证证书需要知道时间。
A successful attack on a time protocol may cause the attacked clocks to go back in time. The erroneous time may expose cryptographic algorithms that rely on time, as a node may use a key that was already used in the past and has expired.
对时间协议的成功攻击可能会导致被攻击的时钟返回时间。错误的时间可能会暴露依赖于时间的加密算法，因为节点可能会使用过去已使用且已过期的密钥。
The Key distribution is outside the scope of this document. Although this is an essential element of any security system, it is outside the scope of this document.
密钥分发不在本文档的范围内。虽然这是任何安全系统的基本要素，但不在本文件的范围之内。
The security considerations of network timing protocols are presented throughout this document.
本文件中介绍了网络定时协议的安全注意事项。
[IEEE1588] IEEE, "1588-2008 - IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Standard 1588-2008, July 2008.
[IEEE1588]IEEE，“1588-2008——网络测量和控制系统精密时钟同步协议的IEEE标准”，IEEE标准1588-2008，2008年7月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[NTPv4] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>.
[NTPv4]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 59052010年6月<http://www.rfc-editor.org/info/rfc5905>.
[1588IPsec] Treytl, A. and B. Hirschler, "Securing IEEE 1588 by IPsec tunnels - An analysis", in Proceedings of 2010 International Symposium for Precision Clock Synchronization for Measurement, Control and Communication, ISPCS 2010, pp. 83-90, September 2010.
[1588IPsec]Treytl，A.和B.Hirschler，“通过IPsec隧道保护IEEE 1588-分析”，载于《2010年测量、控制和通信精密时钟同步国际研讨会论文集》，ISPCS 2010，第83-90页，2010年9月。
[3GPP] 3GPP, "Security of Home Node B (HNB) / Home evolved Node B (HeNB)", 3GPP TS 33.320 11.6.0, November 2012.
[3GPP]3GPP，“家庭节点B（HNB）/家庭演进节点B（HeNB）的安全”，3GPP TS 33.320 11.6.01212年11月。
[Anatomy] Nachreiner, C., "Anatomy of an ARP Poisoning Attack", 2003.
[解剖学]Nachreiner，C.，“ARP中毒攻击的解剖学”，2003年。
[AutoKey] Haberman, B., Ed., and D. Mills, "Network Time Protocol Version 4: Autokey Specification", RFC 5906, June 2010, <http://www.rfc-editor.org/info/rfc5906>.
[AutoKey]Haberman，B.，Ed.，和D.Mills，“网络时间协议版本4：自动密钥规范”，RFC 59062010年6月<http://www.rfc-editor.org/info/rfc5906>.
[AvbAssum] Pannell, D., "Audio Video Bridging Gen 2 Assumptions", IEEE 802.1 AVB Plenary, Work in Progress, May 2012.
[AvbAssum]Pannell，D.，“音频视频桥接第2代假设”，IEEE 802.1 AVB全体会议，正在进行的工作，2012年5月。
[DelayAtt] Mizrahi, T., "A game theoretic analysis of delay attacks against time synchronization protocols", accepted, to appear in Proceedings of the International IEEE Symposium on Precision Clock Synchronization for Measurement, Control and Communication, ISPCS, September 2012.
[DelayAtt]Mizrahi，T.，“针对时间同步协议的延迟攻击的博弈论分析”，已接受，将发表在国际IEEE测量、控制和通信精密时钟同步研讨会论文集上，ISPCS，2012年9月。
[Hack] McClure, S., Scambray, J., and G. Kurtz, "Hacking Exposed: Network Security Secrets and Solutions", McGraw-Hill, 2009.
[Hack]McClure，S.，Scambray，J.，和G.Kurtz，“暴露的黑客行为：网络安全秘密和解决方案”，McGraw-Hill，2009年。
[IPsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[IPsec]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月<http://www.rfc-editor.org/info/rfc4301>.
[IPsecSync] Xu, Y., "IPsec security for packet based synchronization", Work in Progress, draft-xu-tictoc-ipsec-security-for-synchronization-02, September 2011.
[IPsecSync]Xu，Y.，“基于数据包同步的IPsec安全”，正在进行的工作，草稿-Xu-tictoc-IPsec-security-for-synchronization-022011年9月。
[Kerb] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430, March 2006, <http://www.rfc-editor.org/info/rfc4430>.
[Kerb]Sakane，S.，Kamada，K.，Thomas，M.，和J.Vilhuber，“密钥的Kerberized互联网协商（扭结）”，RFC 4430，2006年3月<http://www.rfc-editor.org/info/rfc4430>.
[MACsec] IEEE, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Security", IEEE Standard 802.1AE, August 2006.
[MACsec]IEEE，“局域网和城域网IEEE标准-媒体访问控制（MAC）安全”，IEEE标准802.1AE，2006年8月。
[NTPDDoS] "Attackers use NTP reflection in huge DDoS attack", TICTOC mail archive, 2014.
[NTPDDoS]“攻击者在大规模DDoS攻击中使用NTP反射”，TICTOC邮件存档，2014年。
[SecPTP] Tsang, J. and K. Beznosov, "A Security Analysis of the Precise Time Protocol (Short Paper)," 8th International Conference on Information and Communication Security (ICICS) Lecture Notes in Computer Science Volume 4307, pp. 50-59, 2006.
[SecPTP]Tsang，J.和K.Beznosov，“精确时间协议的安全分析（短文）”，第八届信息和通信安全国际会议（ICICS）课堂讲稿，计算机科学卷4307，第50-59页，2006年。
[SecSen] Ganeriwal, S., Popper, C., Capkun, S., and M. B. Srivastava, "Secure Time Synchronization in Sensor Networks", ACM Trans. Inf. Syst. Secur., Volume 11, Issue 4, Article 23, July 2008.
[SecSen]Ganeriwal，S.，Popper，C.，Capkun，S.，和M.B.Srivastava，“传感器网络中的安全时间同步”，ACM Trans。信息系统。《秘书》，第11卷，第4期，第23条，2008年7月。
[TimeSec] Mizrahi, T., "Time synchronization security using IPsec and MACsec", ISPCS 2011, pp. 38-43, September 2011.
[TimeSec]Mizrahi，T.，“使用IPsec和MACsec的时间同步安全”，ISPCS 2011，第38-43页，2011年9月。
[Traps] Treytl, A., Gaderer, G., Hirschler, B., and R. Cohen, "Traps and pitfalls in secure clock synchronization" in Proceedings of 2007 International Symposium for Precision Clock Synchronization for Measurement, Control and Communication, ISPCS 2007, pp. 18-24, October 2007.
[陷阱]Treytl，A.，Gaderer，G.，Hirschler，B.，和R.Cohen，“安全时钟同步中的陷阱和陷阱”，2007年测量、控制和通信精密时钟同步国际研讨会论文集，ISPCS 2007，第18-24页，2007年10月。
[Tunnel] Treytl, A., Hirschler, B., and T. Sauter, "Secure tunneling of high-precision clock synchronisation protocols and other time-stamped data", in Proceedings of the 8th IEEE International Workshop on Factory Communication Systems (WFCS), pp. 303-313, May 2010.
[隧道]Treytl，A.，Hirschler，B.，和T.Sauter，“高精度时钟同步协议和其他时间戳数据的安全隧道”，第八届IEEE工厂通信系统国际研讨会论文集，第303-313页，2010年5月。
Acknowledgments
致谢
The author gratefully acknowledges Stefano Ruffini, Doug Arnold, Kevin Gross, Dieter Sibold, Dan Grossman, Laurent Montini, Russell Smiley, Shawn Emery, Dan Romascanu, Stephen Farrell, Kathleen Moriarty, and Joel Jaeggli for their thorough review and helpful comments. The author would also like to thank members of the TICTOC WG for providing feedback on the TICTOC mailing list.
作者感谢斯特凡诺·鲁菲尼、道格·阿诺德、凯文·格罗斯、迪特尔·西博尔德、丹·格罗斯曼、劳伦特·蒙蒂尼、拉塞尔·斯迈利、肖恩·埃莫里、丹·罗马斯卡努、斯蒂芬·法雷尔、凯瑟琳·莫里亚蒂和乔尔·贾格利的全面评论和有益评论。作者还想感谢TICTOC工作组成员就TICTOC邮件列表提供反馈。
Contributors
贡献者
Karen O'Donoghue ISOC
卡伦·奥多诺霍
EMail: odonoghue@isoc.org
EMail: odonoghue@isoc.org
Author's Address
作者地址
Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel
Tal Mizrahi Marvell 6 Hamada St.Yokneam，20692以色列
EMail: talmi@marvell.com
EMail: talmi@marvell.com