Internet Engineering Task Force (IETF) T. Mizrahi
Request for Comments: 7821 Marvell
Category: Experimental March 2016
ISSN: 2070-1721
Internet Engineering Task Force (IETF) T. Mizrahi
Request for Comments: 7821 Marvell
Category: Experimental March 2016
ISSN: 2070-1721
UDP Checksum Complement in the Network Time Protocol (NTP)
网络时间协议（NTP）中的UDP校验和补码
Abstract
摘要
The Network Time Protocol (NTP) allows clients to synchronize to a time server using timestamped protocol messages. To facilitate accurate timestamping, some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing NTP packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes an extension field that includes a 2-octet Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets of the packet rather than in the UDP Checksum field. The behavior defined in this document is interoperable with existing NTP implementations.
网络时间协议（NTP）允许客户端使用时间戳协议消息同步到时间服务器。为了便于准确的时间戳，一些实现使用基于硬件的时间戳引擎，该引擎在传输期间将准确的传输时间集成到每个传出的NTP数据包中。由于这些数据包是通过UDP传输的，因此UDP校验和字段随后会更新以反映此修改。本文档提出了一个扩展字段，该字段包含2个八位字节的校验和补码，允许时间戳引擎在数据包的最后2个八位字节而不是UDP校验和字段中反映校验和修改。本文档中定义的行为可与现有NTP实现进行互操作。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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/rfc7821.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7821.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 ....................................................3
1.1. Intermediate Entities ......................................3
1.2. Updating the UDP Checksum ..................................4
2. Conventions Used in This Document ...............................5
2.1. Terminology ................................................5
2.2. Abbreviations ..............................................6
3. Using the UDP Checksum Complement in NTP ........................6
3.1. Overview ...................................................6
3.2. Checksum Complement in NTP Packets .........................7
3.2.1. Using the Checksum Complement .......................7
3.2.2. Transmission of NTP with Checksum Complement ........8
3.2.3. Updates of NTP with Checksum Complement .............8
3.2.4. Reception of NTP with Checksum Complement ...........8
3.3. Interoperability with Existing Implementations .............9
3.4. The Checksum Complement and Authentication .................9
4. Security Considerations ........................................10
5. IANA Considerations ............................................10
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................11
Appendix A. Checksum Complement Usage Example .....................13
Acknowledgments ...................................................14
Author's Address ..................................................14
1. Introduction ....................................................3
1.1. Intermediate Entities ......................................3
1.2. Updating the UDP Checksum ..................................4
2. Conventions Used in This Document ...............................5
2.1. Terminology ................................................5
2.2. Abbreviations ..............................................6
3. Using the UDP Checksum Complement in NTP ........................6
3.1. Overview ...................................................6
3.2. Checksum Complement in NTP Packets .........................7
3.2.1. Using the Checksum Complement .......................7
3.2.2. Transmission of NTP with Checksum Complement ........8
3.2.3. Updates of NTP with Checksum Complement .............8
3.2.4. Reception of NTP with Checksum Complement ...........8
3.3. Interoperability with Existing Implementations .............9
3.4. The Checksum Complement and Authentication .................9
4. Security Considerations ........................................10
5. IANA Considerations ............................................10
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................11
Appendix A. Checksum Complement Usage Example .....................13
Acknowledgments ...................................................14
Author's Address ..................................................14
The Network Time Protocol [NTPv4] allows clients to synchronize their clocks to a time server by exchanging NTP packets. The increasing demand for highly accurate clock synchronization motivates implementations that provide accurate timestamping.
网络时间协议[NTPv4]允许客户端通过交换NTP数据包将时钟同步到时间服务器。对高精度时钟同步的日益增长的需求促使实现提供准确的时间戳。
In this document, we use the term "intermediate entity" to refer to an entity that resides on the path between the sender and the receiver of an NTP packet and that modifies this NTP packet en route.
在本文档中，我们使用术语“中间实体”来指驻留在NTP数据包的发送方和接收方之间的路径上并在路由中修改该NTP数据包的实体。
In order to facilitate accurate timestamping, an implementation can use a hardware-based timestamping engine, as shown in Figure 1. In such cases, NTP packets are sent and received by a software layer, whereas a timestamping engine modifies every outgoing NTP packet by incorporating its accurate transmission time into the <Transmit Timestamp> field in the packet.
为了方便准确的时间戳，实现可以使用基于硬件的时间戳引擎，如图1所示。在这种情况下，NTP分组由软件层发送和接收，而时间戳引擎通过将每个传出NTP分组的准确传输时间合并到分组中的<Transmit Timestamp>字段来修改每个传出NTP分组。
NTP client/server
+-------------------+
| |
| +-----------+ |
Software | | NTP | |
| | protocol | |
| +-----+-----+ |
| | | +-----------------------+
| +-----+-----+ | / Intermediate entity |
| | Accurate | | / in charge of: |
ASIC/FPGA | | Timestamp | | /__ - Timestamping |
| | engine | | |- Updating checksum or |
| +-----------+ | | Checksum Complement |
| | | +-----------------------+
+---------+---------+
|
|NTP packets
|
___ v _
/ \_/ \__
/ \_
/ IP /
\_ Network /
/ \
\__/\_ ___/
\_/
NTP client/server
+-------------------+
| |
| +-----------+ |
Software | | NTP | |
| | protocol | |
| +-----+-----+ |
| | | +-----------------------+
| +-----+-----+ | / Intermediate entity |
| | Accurate | | / in charge of: |
ASIC/FPGA | | Timestamp | | /__ - Timestamping |
| | engine | | |- Updating checksum or |
| +-----------+ | | Checksum Complement |
| | | +-----------------------+
+---------+---------+
|
|NTP packets
|
___ v _
/ \_/ \__
/ \_
/ IP /
\_ Network /
/ \
\__/\_ ___/
\_/
ASIC: Application-Specific Integrated Circuit FPGA: Field-Programmable Gate Array
专用集成电路现场可编程门阵列
Figure 1: Accurate Timestamping in NTP
图1:NTP中的准确时间戳
The accuracy of clock synchronization over packet networks is highly sensitive to delay jitters in the underlying network; this dramatically affects clock accuracy. To address this challenge, the Precision Time Protocol (PTP) [IEEE1588] defines Transparent Clocks (TCs) -- switches and routers that improve end-to-end clock accuracy by updating a "Correction Field" in the PTP packet by adding the latency caused by the current TC. In NTP, no equivalent entity is currently defined, but future versions of NTP may define an intermediate node that modifies en-route NTP packets using a "Correction Field".
分组网络上时钟同步的准确性对底层网络中的延迟抖动高度敏感；这会极大地影响时钟精度。为了应对这一挑战，精确时间协议（PTP）[IEEE1588]定义了透明时钟（TCs）——交换机和路由器，通过添加当前TC引起的延迟来更新PTP数据包中的“校正字段”，从而提高端到端时钟精度。在NTP中，目前没有定义等效实体，但NTP的未来版本可能会定义一个中间节点，该节点使用“校正字段”修改路由NTP数据包。
When the UDP payload is modified by an intermediate entity, the UDP Checksum field needs to be updated to maintain its correctness. When using UDP over IPv4 [UDP], an intermediate entity that cannot update
当中间实体修改UDP有效负载时，需要更新UDP校验和字段以保持其正确性。在IPv4[UDP]上使用UDP时，无法更新的中间实体
the value of the UDP Checksum has no choice except to assign a value of zero to the Checksum field, causing the receiver to ignore the Checksum field and potentially accept corrupted packets. UDP over IPv6, as defined in [IPv6], does not allow a zero checksum, except in specific cases [ZeroChecksum]. As discussed in [ZeroChecksum], the use of a zero checksum is generally not recommended and should be avoided to the extent possible.
UDP校验和的值除了为校验和字段指定一个零值之外别无选择，这会导致接收器忽略校验和字段并可能接受损坏的数据包。[IPv6]中定义的IPv6上的UDP不允许零校验和，除非在特定情况下[ZeroChecksum]。如[ZeroChecksum]中所述，通常不建议使用零校验和，应尽可能避免使用零校验和。
Since an intermediate entity only modifies a specific field in the packet, i.e., the Timestamp field, the UDP Checksum update can be performed incrementally, using the concepts presented in [Checksum].
由于中间实体仅修改数据包中的特定字段，即时间戳字段，因此可以使用[Checksum]中介绍的概念以增量方式执行UDP校验和更新。
This document defines the Checksum Complement for [NTPv4]. The Checksum Complement is a 2-octet field that resides at the end of the UDP payload. It allows intermediate entities to update NTP packets and maintain the correctness of the UDP Checksum by modifying the last 2 octets of the packet, instead of updating the UDP Checksum field. This is performed by adding an NTP extension field at the end of the packet, in which the last 2 octets are used as a Checksum Complement.
本文档定义了[NTPv4]的校验和补码。校验和补码是一个2-octet字段，位于UDP有效负载的末尾。它允许中间实体更新NTP数据包，并通过修改数据包的最后2个八位字节来维护UDP校验和的正确性，而不是更新UDP校验和字段。这是通过在数据包的末尾添加一个NTP扩展字段来实现的，其中最后2个八位字节用作校验和补码。
The usage of the Checksum Complement can in some cases simplify the implementation, because if the packet data is processed in serial order, it is simpler to first update the Timestamp field and then update the Checksum Complement, rather than to update the timestamp and then update the UDP Checksum residing at the UDP header. Note that while it is not impossible to implement a hardware timestamper that updates the UDP Checksum, using the Checksum Complement instead can significantly simplify the implementation.
在某些情况下，校验和补码的使用可以简化实现，因为如果以串行顺序处理分组数据，则首先更新时间戳字段然后更新校验和补码比更新时间戳然后更新驻留在UDP报头处的UDP校验和更简单。请注意，虽然实现更新UDP校验和的硬件时间戳并非不可能，但使用校验和补码可以显著简化实现。
Note that the software layer and the intermediate entity (see Figure 1) are two modules in a single NTP clock. It is assumed that these two modules are in agreement regarding whether transmitted NTP packets include the Checksum Complement or not.
请注意，软件层和中间实体（见图1）是单个NTP时钟中的两个模块。假设这两个模块在传输的NTP分组是否包括校验和补码方面是一致的。
[RFC7820] defines the Checksum Complement mechanism for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP). A similar mechanism is presented in Annex E of [IEEE1588].
[RFC7820]定义了单向主动测量协议（OWAMP）和双向主动测量协议（TWAMP）的校验和补码机制。[IEEE1588]的附录E中介绍了类似的机制。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
MAC Message Authentication Code
MAC消息认证码
NTP Network Time Protocol
网络时间协议
PTP Precision Time Protocol
精确时间协议
UDP User Datagram Protocol
UDP用户数据报协议
The UDP Checksum Complement is a 2-octet field that is appended at the end of the UDP payload, using an NTP extension field. Figure 2 illustrates the packet format of an NTP packet with a Checksum Complement extension.
UDP校验和补码是一个2-octet字段，使用NTP扩展字段附加在UDP有效负载的末尾。图2说明了具有校验和补码扩展的NTP数据包的数据包格式。
+--------------------------------+
| IPv4/IPv6 Header |
+--------------------------------+
| UDP Header |
+--------------------------------+
^ | |
| | NTP packet |
| | |
| +--------------------------------+
UDP | Optional NTP Extension Fields |
Payload +--------------------------------+
| | UDP Checksum Complement |
| | Extension Field (28 octets) |
v +--------------------------------+
+--------------------------------+
| IPv4/IPv6 Header |
+--------------------------------+
| UDP Header |
+--------------------------------+
^ | |
| | NTP packet |
| | |
| +--------------------------------+
UDP | Optional NTP Extension Fields |
Payload +--------------------------------+
| | UDP Checksum Complement |
| | Extension Field (28 octets) |
v +--------------------------------+
Figure 2: Checksum Complement in NTP Packets
图2:NTP数据包中的校验和补码
The Checksum Complement is used to compensate for changes performed in the NTP packet by intermediate entities, as described in the Introduction (Section 1). An example of the usage of the Checksum Complement is provided in Appendix A.
校验和补码用于补偿中间实体在NTP数据包中执行的更改，如引言（第1节）所述。附录A中提供了使用校验和补码的示例。
NTP is transported over UDP, either over IPv4 or over IPv6. This document applies to both NTP over IPv4 and NTP over IPv6.
NTP通过UDP（通过IPv4或IPv6）传输。本文档适用于IPv4上的NTP和IPv6上的NTP。
NTP packets may include one or more extension fields, as defined in [NTPv4]. The Checksum Complement in NTP packets resides in a dedicated NTP extension field, as shown in Figure 3.
NTP数据包可以包括一个或多个扩展字段，如[NTPv4]中所定义。NTP数据包中的校验和补码位于专用NTP扩展字段中，如图3所示。
If the NTP packet includes more than one extension field, the Checksum Complement extension is always the last extension field. Thus, the Checksum Complement is the last 2 octets in the UDP payload and is located at (UDP Length - 2 octets) after the beginning of the UDP header. Note that the Checksum Complement is not used in authenticated NTP packets, as further discussed in Section 3.4.
如果NTP数据包包含多个扩展字段，则校验和补码扩展始终是最后一个扩展字段。因此，校验和补码是UDP有效负载中的最后2个八位字节，位于UDP报头开始后的（UDP长度-2个八位字节）。注意，如第3.4节中进一步讨论的，校验和补码不用于经过身份验证的NTP数据包。
As described in Section 1, an intermediate entity that updates the timestamp in the NTP packet can use the Checksum Complement in order to maintain the correctness of the UDP Checksum field. Specifically, if the value of the timestamp is updated, this update yields a change in the UDP Checksum value; thus, the intermediate entity assigns a new value in the Checksum Complement that cancels this change, leaving the current value of the UDP Checksum correct. An example of the usage of the Checksum Complement is provided in Appendix A.
如第1节所述，更新NTP数据包中时间戳的中间实体可以使用校验和补码来保持UDP校验和字段的正确性。具体地说，如果时间戳的值被更新，则该更新产生UDP校验和值的变化；因此，中间实体在校验和补码中分配一个新值以取消此更改，使UDP校验和的当前值保持正确。附录A中提供了使用校验和补码的示例。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type | Length = 28 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Checksum Complement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type | Length = 28 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Checksum Complement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NTP Checksum Complement Extension Field
图3:NTP校验和补码扩展字段
Field Type
字段类型
A dedicated Field Type value is used to identify the Checksum Complement extension. See Section 5.
专用字段类型值用于标识校验和补码扩展。见第5节。
Length
长
The Checksum Complement extension field length is 28 octets.
校验和补码扩展字段长度为28个八位字节。
This length guarantees that the host that receives the packet parses it correctly, whether the packet includes a MAC or not. [RFC7822] provides further details about the length of an extension field in the absence of a MAC.
此长度保证接收数据包的主机正确解析数据包，无论数据包是否包含MAC。[RFC7822]提供了在没有MAC的情况下扩展字段长度的更多详细信息。
MBZ
MBZ
The extension field includes a 22-octet MBZ (MUST be zero) field. This field MUST be set to 0 and MUST be ignored by the recipient. The MBZ field is used for padding the extension field to 28 octets.
扩展字段包括一个22八位字节MBZ（必须为零）字段。此字段必须设置为0，收件人必须忽略此字段。MBZ字段用于将扩展字段填充为28个八位字节。
Checksum Complement
校验和补码
The Checksum Complement extension includes the Checksum Complement field, residing in the last 2 octets of the extension.
校验和补码扩展包括校验和补码字段，位于扩展的最后2个八位字节中。
The transmitter of an NTP packet MAY include a Checksum Complement extension field.
NTP分组的发射机可以包括校验和补码扩展字段。
An intermediate entity that receives and alters an NTP packet containing a Checksum Complement extension MAY use the Checksum Complement to maintain a correct UDP Checksum value.
接收和更改包含校验和补码扩展的NTP数据包的中间实体可以使用校验和补码来保持正确的UDP校验和值。
This document does not impose new requirements on the receiving end of an NTP packet.
本文件不对NTP数据包的接收端提出新要求。
The UDP layer at the receiving end verifies the UDP Checksum of received NTP packets, and the NTP layer SHOULD ignore the Checksum Complement extension field.
接收端的UDP层验证接收到的NTP数据包的UDP校验和，NTP层应忽略校验和补码扩展字段。
The behavior defined in this document does not impose new requirements on the reception of NTP packets beyond the requirements defined in [RFC7822]. Note that, as defined in [RFC7822], a host that receives an NTP message with an unknown extension field SHOULD ignore the extension field and MAY drop the packet if policy requires it. Thus, transmitters and intermediate entities that support the Checksum Complement can transparently interoperate with receivers that are not Checksum Complement compliant, as long as these receivers ignore unknown extension fields. It is noted that existing implementations that discard packets with unknown extension fields cannot interoperate with transmitters that use the Checksum Complement.
本文件中定义的行为不会对NTP数据包的接收提出超出[RFC7822]中定义的要求的新要求。请注意，如[RFC7822]中所定义，接收到具有未知扩展字段的NTP消息的主机应忽略该扩展字段，并可在策略需要时丢弃该数据包。因此，支持校验和补码的发射机和中间实体可以透明地与不符合校验和补码的接收机进行互操作，只要这些接收机忽略未知的扩展字段。需要注意的是，丢弃具有未知扩展字段的数据包的现有实现无法与使用校验和补码的发送器进行互操作。
It should be noted that when hardware-based timestamping is used, it will likely be used at both ends, and thus both hosts that take part in the protocol will support the functionality described in this memo. If only one of the hosts uses hardware-based timestamping, then the Checksum Complement can only be used if it is known that the peer host can accept the Checksum Complement.
应注意，当使用基于硬件的时间戳时，可能会在两端使用，因此参与协议的两台主机都将支持本备忘录中描述的功能。如果只有一台主机使用基于硬件的时间戳，则只有在已知对等主机可以接受校验和补码的情况下，才能使用校验和补码。
A Checksum Complement MUST NOT be used when authentication is enabled. The Checksum Complement is useful in unauthenticated mode, allowing the intermediate entity to perform serial processing of the packet without storing and forwarding it.
启用身份验证时，不得使用校验和补码。校验和补码在未经验证的模式下很有用，允许中间实体执行数据包的串行处理，而无需存储和转发数据包。
On the other hand, when message authentication is used, an intermediate entity that alters NTP packets must also recompute the Message Authentication Code (MAC) accordingly. In this case, it is not possible to update the Checksum Complement; updating the Checksum Complement would result in having to recalculate the MAC, and there would be a cyclic dependency between the MAC and the Checksum Complement. Hence, when updating the MAC, it is necessary to update the UDP Checksum field, making the Checksum Complement field unnecessary in the presence of authentication.
另一方面，当使用消息认证时，改变NTP数据包的中间实体也必须相应地重新计算消息认证码（MAC）。在这种情况下，不可能更新校验和补码；更新校验和补码将导致必须重新计算MAC，并且MAC和校验和补码之间存在循环依赖关系。因此，在更新MAC时，有必要更新UDP校验和字段，使得校验和补码字段在存在身份验证时不必要。
This document describes how a Checksum Complement extension can be used for maintaining the correctness of the UDP Checksum. The security considerations of time protocols in general are discussed in [SecTime], and the security considerations of NTP are discussed in [NTPv4].
本文档描述如何使用校验和补码扩展来维护UDP校验和的正确性。一般时间协议的安全注意事项在[SecTime]中讨论，NTP的安全注意事项在[NTPv4]中讨论。
The purpose of this extension is to ease the implementation of accurate timestamping engines, as illustrated in Figure 1. The extension is intended to be used internally in an NTP client or server. This extension is not intended to be used by switches and routers that reside between the client and the server. As opposed to PTP [IEEE1588], NTP does not require intermediate switches or routers to modify the content of NTP messages, and thus any such modification should be considered as a malicious man-in-the-middle (MITM) attack.
此扩展的目的是简化精确时间戳引擎的实现，如图1所示。该扩展旨在在NTP客户端或服务器内部使用。此扩展不适用于驻留在客户端和服务器之间的交换机和路由器。与PTP[IEEE1588]相反，NTP不需要中间交换机或路由器来修改NTP消息的内容，因此任何此类修改都应被视为恶意中间人（MITM）攻击。
It is important to emphasize that the scheme described in this document does not increase the protocol's vulnerability to MITM attacks; a MITM attacker who maliciously modifies a packet and its Checksum Complement is logically equivalent to a MITM attacker who modifies a packet and its UDP Checksum field.
需要强调的是，本文件中描述的方案不会增加协议对MITM攻击的脆弱性；恶意修改数据包及其校验和补码的MITM攻击者在逻辑上等同于修改数据包及其UDP校验和字段的MITM攻击者。
The concept described in this document is intended to be used only in unauthenticated mode. As discussed in Section 3.4, if a cryptographic security mechanism is used, then the Checksum Complement does not simplify the implementation compared to using the conventional Checksum, and therefore the Checksum Complement is not used.
本文档中描述的概念仅用于未经验证的模式。如第3.4节所述，如果使用加密安全机制，则与使用常规校验和相比，校验和补码不会简化实现，因此不使用校验和补码。
IANA has allocated a new value in the "NTP Extension Field Types" registry:
IANA已在“NTP扩展字段类型”注册表中分配了一个新值：
0x2005 Checksum Complement
0x2005校验和补码
[Checksum] Rijsinghani, A., Ed., "Computation of the Internet Checksum via Incremental Update", RFC 1624, DOI 10.17487/RFC1624, May 1994, <http://www.rfc-editor.org/info/rfc1624>.
[校验和]Rijsinghani，A.，Ed.，“通过增量更新计算互联网校验和”，RFC 1624，DOI 10.17487/RFC1624，1994年5月<http://www.rfc-editor.org/info/rfc1624>.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[IPv6]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，DOI 10.17487/RFC2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，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, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>.
[NTPv4]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 5905，DOI 10.17487/RFC59052010年6月<http://www.rfc-editor.org/info/rfc5905>.
[RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, March 2016, <http://www.rfc-editor.org/info/rfc7822>.
[RFC7822]Mizrahi，T.和D.Mayer，“网络时间协议版本4（NTPv4）扩展字段”，RFC 7822，DOI 10.17487/RFC7822，2016年3月<http://www.rfc-editor.org/info/rfc7822>.
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[UDP]Postel，J.，“用户数据报协议”，STD 6，RFC 768，DOI 10.17487/RFC768，1980年8月<http://www.rfc-editor.org/info/rfc768>.
[IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, July 2008.
[IEEE1588]IEEE，“网络测量和控制系统精密时钟同步协议的IEEE标准”，IEEE标准1588-2008，DOI 10.1109/IEEESTD.2008.4579760，2008年7月。
[RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)", RFC 7820, DOI 10.17487/RFC7820, March 2016, <http://www.rfc-editor.org/info/rfc7820>.
[RFC7820]Mizrahi，T.，“单向主动测量协议（OWAMP）和双向主动测量协议（TWAMP）中的UDP校验和补码”，RFC 7820，DOI 10.17487/RFC7820，2016年3月<http://www.rfc-editor.org/info/rfc7820>.
[SecTime] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014, <http://www.rfc-editor.org/info/rfc7384>.
[SecTime]Mizrahi，T.，“分组交换网络中时间协议的安全要求”，RFC 7384，DOI 10.17487/RFC7384，2014年10月<http://www.rfc-editor.org/info/rfc7384>.
[ZeroChecksum] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, <http://www.rfc-editor.org/info/rfc6936>.
[ZeroChecksum]Fairhurst，G.和M.Westerlund，“使用具有零校验和的IPv6 UDP数据报的适用性声明”，RFC 6936，DOI 10.17487/RFC6936，2013年4月<http://www.rfc-editor.org/info/rfc6936>.
Consider an NTP packet sent by an NTP client to an NTP server.
考虑由NTP客户端发送到NTP服务器的NTP分组。
The client's software layer (see Figure 1) generates an NTP packet with an Origin Timestamp T and a UDP Checksum value U. The value of U is the checksum of the UDP header, UDP payload, and pseudo-header. Thus, U is equal to:
客户端的软件层（参见图1）生成一个NTP数据包，该数据包具有原始时间戳T和UDP校验和值U。U的值是UDP报头、UDP有效负载和伪报头的校验和。因此，U等于：
U = Const + checksum(T) (1)
U = Const + checksum(T) (1)
Where "Const" is the checksum of all the fields that are covered by the checksum, except the Origin Timestamp T.
其中“Const”是校验和所覆盖的所有字段的校验和，但原始时间戳T除外。
Recall that the client's software emits the NTP packet with a Checksum Complement extension field, which resides at the end of the PTP packet. It is assumed that the client initially assigns zero to the value of the Checksum Complement.
回想一下，客户机的软件发出带有校验和补码扩展字段的NTP数据包，该字段位于PTP数据包的末尾。假设客户端最初将校验和补码的值赋值为零。
The client's timestamping engine updates the Origin Timestamp field to the accurate time, changing its value from T to T'. The engine also updates the Checksum Complement field from zero to a new value C, such that:
客户机的时间戳引擎将原始时间戳字段更新为准确时间，将其值从T更改为T'。引擎还将校验和补码字段从零更新为新值C，以便：
checksum(C) = checksum(T) - checksum(T') (2)
checksum(C) = checksum(T) - checksum(T') (2)
When the NTP packet is transmitted by the client's timestamping engine, the value of the checksum remains U as before:
当客户机的时间戳引擎传输NTP数据包时，校验和的值与之前一样保持U：
U = Const + checksum(T) = Const + checksum(T) + checksum(T') -
checksum(T') = Const + checksum(T') + checksum(C) (3)
U = Const + checksum(T) = Const + checksum(T) + checksum(T') -
checksum(T') = Const + checksum(T') + checksum(C) (3)
Thus, after the timestamping engine has updated the timestamp, U remains the correct checksum of the packet.
因此，在时间戳引擎更新了时间戳之后，U保持分组的正确校验和。
When the NTP packet reaches the NTP server, the server performs a conventional UDP Checksum computation, and the computed value is U. Since the Checksum Complement is part of the extension field, its value (C) is transparently included in the computation, as per Equation (3), without requiring special treatment by the server.
当NTP数据包到达NTP服务器时，服务器执行常规UDP校验和计算，计算值为U。由于校验和补码是扩展字段的一部分，其值（C）根据等式（3）透明地包含在计算中，而无需服务器进行特殊处理。
Acknowledgments
致谢
The author gratefully thanks Danny Mayer, Miroslav Lichvar, Paul Kyzivat, Suresh Krishnan, and Brian Haberman for their review and helpful comments.
作者非常感谢Danny Mayer、Miroslav Lichvar、Paul Kyzivat、Suresh Krishnan和Brian Haberman的评论和有益的评论。
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