Internet Engineering Task Force (IETF) T. Mizrahi
Request for Comments: 7822 Marvell
Updates: 5905 D. Mayer
Category: Standards Track Network Time Foundation
ISSN: 2070-1721 March 2016
Internet Engineering Task Force (IETF) T. Mizrahi
Request for Comments: 7822 Marvell
Updates: 5905 D. Mayer
Category: Standards Track Network Time Foundation
ISSN: 2070-1721 March 2016
Network Time Protocol Version 4 (NTPv4) Extension Fields
网络时间协议版本4（NTPv4）扩展字段
Abstract
摘要
The Network Time Protocol version 4 (NTPv4) defines the optional usage of extension fields. An extension field, as defined in RFC 5905, is an optional field that resides at the end of the NTP header and that can be used to add optional capabilities or additional information that is not conveyed in the standard NTP header. This document updates RFC 5905 by clarifying some points regarding NTP extension fields and their usage with Message Authentication Codes (MACs).
网络时间协议版本4（NTPv4）定义了扩展字段的可选用法。RFC 5905中定义的扩展字段是位于NTP标头末尾的可选字段，可用于添加可选功能或标准NTP标头中未传达的附加信息。本文档通过澄清有关NTP扩展字段及其与消息身份验证码（MAC）的用法的一些要点，更新了RFC 5905。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc7822.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7822.
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 ....................................................2
2. Conventions Used in This Document ...............................3
2.1. Terminology ................................................3
2.2. Terms and Abbreviations ....................................3
3. NTP Extension Fields - RFC 5905 Update ..........................3
4. Security Considerations .........................................6
5. References ......................................................7
5.1. Normative References .......................................7
5.2. Informative References .....................................7
Acknowledgments ....................................................8
Authors' Addresses .................................................8
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
2.1. Terminology ................................................3
2.2. Terms and Abbreviations ....................................3
3. NTP Extension Fields - RFC 5905 Update ..........................3
4. Security Considerations .........................................6
5. References ......................................................7
5.1. Normative References .......................................7
5.2. Informative References .....................................7
Acknowledgments ....................................................8
Authors' Addresses .................................................8
The NTP header format consists of a set of fixed fields that may be followed by some optional fields. Two types of optional fields are defined: Message Authentication Codes (MACs), and extension fields as defined in Section 7.5 of [NTPv4].
NTP标头格式由一组固定字段组成，这些字段后面可能有一些可选字段。定义了两种可选字段：消息验证码（MAC）和[NTPv4]第7.5节中定义的扩展字段。
If a MAC is used, it resides at the end of the packet. This field can be either 24 octets long, 20 octets long, or a 4-octet crypto-NAK.
如果使用MAC，则它位于数据包的末尾。此字段可以是24个八位字节长、20个八位字节长或4个八位字节的加密NAK。
NTP extension fields were defined in [NTPv4] as a generic mechanism that allows the addition of future extensions and features without modifying the NTP header format (Section 16 of [NTPv4]).
NTP扩展字段在[NTPv4]中定义为一种通用机制，允许在不修改NTP标题格式的情况下添加未来的扩展和功能（见[NTPv4]第16节）。
The only currently defined extension fields are those fields used by the Autokey protocol [Autokey] and the Checksum Complement [RFC7821]. The Autokey extension field is always followed by a MAC, and Section 10 of [Autokey] specifies the parsing rules that allow a host to distinguish between an extension field and a MAC. However, a MAC is not mandatory after an extension field; an NTPv4 packet can include one or more extension fields without including a MAC. This behavior is specified in Section 7.5 of [NTPv4] and in [Err3627], and is further clarified in this document.
当前唯一定义的扩展字段是自动密钥协议[Autokey]和校验和补码[RFC7821]使用的字段。自动密钥扩展字段后面总是紧跟着MAC，[Autokey]的第10节指定了允许主机区分扩展字段和MAC的解析规则。然而，MAC在扩展字段之后不是强制性的；NTPv4分组可以包括一个或多个扩展字段，而不包括MAC。该行为在[NTPv4]第7.5节和[Err3627]中有规定，并在本文件中进一步阐明。
This document updates [NTPv4] (RFC 5905) by clarifying some points regarding the usage of extension fields. These updates include changes to address errors found after the publication of [NTPv4] with respect to extension fields. Specifically, this document updates Section 7.5 of [NTPv4], clarifying the relationship between extension fields and MACs, and defining the behavior of a host that receives an unknown extension field.
本文档通过澄清有关扩展字段使用的一些要点来更新[NTPv4]（RFC 5905）。这些更新包括对[NTPv4]发布后发现的与扩展字段相关的错误的地址更改。具体而言，本文档更新了[NTPv4]第7.5节，澄清了扩展字段和MAC之间的关系，并定义了接收未知扩展字段的主机的行为。
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消息认证码
NTPv4 Network Time Protocol version 4 [NTPv4]
NTPv4网络时间协议版本4[NTPv4]
This document updates Section 7.5 of [NTPv4] as follows:
本文件将[NTPv4]第7.5节更新如下：
OLD:
旧的：
7.5. NTP Extension Field Format
7.5. NTP扩展字段格式
In NTPv4, one or more extension fields can be inserted after the header and before the MAC, which is always present when an extension field is present. Other than defining the field format, this document makes no use of the field contents. An extension field contains a request or response message in the format shown in Figure 14.
在NTPv4中，一个或多个扩展字段可以插入到报头之后和MAC之前，当存在扩展字段时，MAC始终存在。除定义字段格式外，本文档不使用字段内容。扩展字段包含如图14所示格式的请求或响应消息。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Value .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (as needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Value .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (as needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Extension Field Format
图14：扩展字段格式
All extension fields are zero-padded to a word (four octets) boundary. The Field Type field is specific to the defined function and is not elaborated here. While the minimum field length containing required fields is four words (16 octets), a maximum field length remains to be established.
所有扩展字段都以零填充到一个字（四个八位字节）边界。字段类型字段特定于已定义的函数，此处不再详述。虽然包含所需字段的最小字段长度为四个字（16个八位字节），但最大字段长度仍有待确定。
The Length field is a 16-bit unsigned integer that indicates the length of the entire extension field in octets, including the Padding field.
长度字段是一个16位无符号整数，以八位字节表示整个扩展字段的长度，包括填充字段。
NEW:
新的：
7.5. NTP Extension Field Format
7.5. NTP扩展字段格式
In NTPv4, one or more extension fields can be inserted after the header and before the MAC, if a MAC is present.
在NTPv4中，如果存在MAC，则可以在报头之后和MAC之前插入一个或多个扩展字段。
Other than defining the field format, this document makes no use of the field contents. An extension field contains a request or response message in the format shown in Figure 14.
除定义字段格式外，本文档不使用字段内容。扩展字段包含如图14所示格式的请求或响应消息。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Value .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (as needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Value .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (as needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Extension Field Format
图14：扩展字段格式
All extension fields are zero-padded to a word (four octets) boundary.
所有扩展字段都以零填充到一个字（四个八位字节）边界。
The Field Type, Value, and Padding fields are specific to the defined function and are not elaborated here; the Field Type value is defined in an IANA registry, and its Length, Value, and Padding values are defined by the document referred to by the registry. If a host receives an extension field with an unknown Field Type, the host SHOULD ignore the extension field and MAY drop the packet altogether if policy requires it.
字段类型、值和填充字段特定于已定义的函数，此处不再详述；字段类型值在IANA注册表中定义，其长度、值和填充值由注册表引用的文档定义。如果主机接收到具有未知字段类型的扩展字段，则主机应忽略该扩展字段，并且如果策略需要，可以完全丢弃该数据包。
While the minimum field length containing required fields is four words (16 octets), the maximum field length cannot be longer than 65532 octets, due to the maximum size of the Length field.
虽然包含必填字段的最小字段长度为四个字（16个八位字节），但由于长度字段的最大大小，最大字段长度不能超过65532个八位字节。
The Length field is a 16-bit unsigned integer that indicates the length of the entire extension field in octets, including the Padding field.
长度字段是一个16位无符号整数，以八位字节表示整个扩展字段的长度，包括填充字段。
7.5.1. Extension Fields and MACs
7.5.1. 扩展字段和MAC
7.5.1.1. Extension Fields in the Presence of a MAC
7.5.1.1. 存在MAC时的扩展字段
An extension field can be used in an NTP packet that includes a MAC -- for example, as defined in [Autokey]. A specification that defines a new extension field MUST specify whether the extension field requires a MAC or not. If the extension field requires a MAC, the extension field specification MUST define the algorithm to be used to create the MAC and the length of the MAC thus created. An extension field MAY allow for the use of more than one algorithm, in which case the information about which algorithm was used MUST be included in the extension field itself.
扩展字段可用于包含MAC的NTP数据包中——例如，如[Autokey]中所定义。定义新扩展字段的规范必须指定扩展字段是否需要MAC。如果扩展字段需要MAC，则扩展字段规范必须定义用于创建MAC的算法以及由此创建的MAC的长度。扩展字段可以允许使用多个算法，在这种情况下，关于使用哪种算法的信息必须包含在扩展字段本身中。
7.5.1.2. Multiple Extension Fields with a MAC
7.5.1.2. 具有MAC的多个扩展字段
If there are multiple extension fields that require a MAC, they MUST all require the use of the same algorithm and MAC length. Extension fields that do not require a MAC can be included with extension fields that do require a MAC.
如果有多个扩展字段需要MAC，则它们都必须使用相同的算法和MAC长度。不需要MAC的扩展字段可以包含在需要MAC的扩展字段中。
An NTP packet MUST NOT be sent with two or more extension fields that require a MAC with different algorithms.
NTP数据包不得与两个或多个扩展字段一起发送，这两个扩展字段需要具有不同算法的MAC。
If an NTP packet is received with two or more extension fields that this receiver recognizes and those fields require a MAC with different algorithms, the packet MUST be discarded.
如果接收到一个NTP数据包时有两个或多个扩展字段，且该接收器可识别这些字段，并且这些字段需要具有不同算法的MAC，则必须丢弃该数据包。
7.5.1.3. MAC in the Absence of an Extension Field
7.5.1.3. 没有扩展字段时的MAC
A MAC MUST NOT be longer than 24 octets if there is no extension field present, unless a longer MAC is agreed upon by both client and server. The client and server can negotiate this behavior using a previous exchange of packets with an extension field that defines the size and algorithm of the MAC transmitted in NTP packets.
如果不存在扩展字段，MAC的长度不得超过24个八位字节，除非客户机和服务器都同意使用更长的MAC。客户机和服务器可以使用先前交换的数据包与扩展字段协商此行为，扩展字段定义在NTP数据包中传输的MAC的大小和算法。
7.5.1.4. Extension Fields in the Absence of a MAC
7.5.1.4. 没有MAC时的扩展字段
If a MAC is not present, one or more extension fields can be inserted after the header, according to the following rules:
如果MAC不存在，则可以根据以下规则在标头后插入一个或多个扩展字段：
o If the packet includes a single extension field, the length of the extension field MUST be at least 7 words, i.e., at least 28 octets.
o 如果分组包括单个扩展字段，则扩展字段的长度必须至少为7个字，即至少28个八位字节。
o If the packet includes more than one extension field, the length of the last extension field MUST be at least 28 octets. The length of the other extension fields in this case MUST be at least 16 octets each.
o 如果数据包包含多个扩展字段，则最后一个扩展字段的长度必须至少为28个八位字节。在这种情况下，其他扩展字段的长度必须至少为16个八位字节。
The security considerations of time protocols in general are discussed in [SecTime], and the security considerations of NTP are discussed in [NTPv4].
一般时间协议的安全注意事项在[SecTime]中讨论，NTP的安全注意事项在[NTPv4]中讨论。
Distributed Denial-of-Service (DDoS) attacks on NTP servers involve flooding a server with a high rate of NTP packets. Malicious usage of extension fields cannot amplify such DDoS attacks; such malicious attempts are mitigated by NTP servers, since the servers ignore unknown extension fields (as discussed in Section 3) and only respond, if needed, with known extension fields. Extension fields from incoming packets are neither propagated by NTP servers nor included in any response. NTP servers create their own extension fields if needed for a response. A large number of extension fields should be flagged by an NTP server as a potential attack. Large extension field sizes should also be flagged, unless they are expected to be large.
NTP服务器上的分布式拒绝服务（DDoS）攻击涉及使用高速NTP数据包淹没服务器。恶意使用扩展字段不会放大此类DDoS攻击；由于NTP服务器忽略未知扩展字段（如第3节所述），并且仅在需要时使用已知扩展字段进行响应，因此NTP服务器可以减轻此类恶意尝试。来自传入数据包的扩展字段既不由NTP服务器传播，也不包含在任何响应中。如果响应需要，NTP服务器会创建自己的扩展字段。NTP服务器应将大量扩展字段标记为潜在攻击。大的扩展字段大小也应该被标记，除非预期它们是大的。
Middleboxes such as firewalls MUST NOT filter NTP packets based on their extension fields. Such middleboxes should not examine extension fields in the packets, since NTP packets may contain new extension fields that the middleboxes have not been updated to recognize.
防火墙等中间包不得根据其扩展字段过滤NTP数据包。此类中间盒不应检查数据包中的扩展字段，因为NTP数据包可能包含中间盒尚未更新以识别的新扩展字段。
[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>.
[Autokey] Haberman, B., Ed., and D. Mills, "Network Time Protocol Version 4: Autokey Specification", RFC 5906, DOI 10.17487/RFC5906, June 2010, <http://www.rfc-editor.org/info/rfc5906>.
[Autokey]Haberman，B.，Ed.，and D.Mills，“网络时间协议版本4：自动密钥规范”，RFC 5906，DOI 10.17487/RFC5906，2010年6月<http://www.rfc-editor.org/info/rfc5906>.
[Err3627] RFC Errata, Erratum ID 3627, RFC 5905.
[Err3627]RFC勘误表，勘误表ID 3627，RFC 5905。
[RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 2016, <http://www.rfc-editor.org/info/rfc7821>.
[RFC7821]Mizrahi，T.，“网络时间协议（NTP）中的UDP校验和补码”，RFC 7821，DOI 10.17487/RFC7821，2016年3月<http://www.rfc-editor.org/info/rfc7821>.
[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>.
Acknowledgments
致谢
The authors gratefully acknowledge Dave Mills for his insightful comments. The authors also thank Tim Chown, Sean Turner, Miroslav Lichvar, Suresh Krishnan, and Jari Arkko for their thorough review and helpful comments.
作者感谢戴夫·米尔斯（Dave Mills）的富有洞察力的评论。作者还感谢Tim Chown、Sean Turner、Miroslav Lichvar、Suresh Krishnan和Jari Arkko的全面审查和有益的评论。
Authors' Addresses
作者地址
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
Danny Mayer Network Time Foundation PO Box 918 Talent, OR 97540 United States
丹尼迈耶网络时代基金会PO盒918人才，或97540美国
Email: mayer@ntp.org
Email: mayer@ntp.org