[要約] RFC 7822は、NTPv4の拡張フィールドに関する情報を提供する。目的は、NTPv4プロトコルの機能を拡張し、追加の情報を送信するためのフィールドを定義することである。
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).
Network Time Protocolバージョン4（NTPv4）は、拡張フィールドのオプションの使用法を定義します。 RFC 5905で定義されている拡張フィールドは、NTPヘッダーの末尾にあるオプションのフィールドであり、標準のNTPヘッダーでは伝達されないオプション機能または追加情報を追加するために使用できます。このドキュメントでは、NTP拡張フィールドと、メッセージ認証コード（MAC）での使用に関するいくつかのポイントを明確にすることにより、RFC 5905を更新しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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ヘッダー形式は、いくつかのオプションフィールドが後に続く可能性がある固定フィールドのセットで構成されます。 [NTPv4]のセクション7.5で定義されているように、メッセージ認証コード（MAC）と拡張フィールドの2つのタイプのオプションフィールドが定義されています。
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を使用する場合、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拡張フィールドは、NTPヘッダー形式を変更せずに将来の拡張機能を追加できる汎用メカニズムとして[NTPv4]で定義されました（[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プロトコル[Autokey]およびチェックサム補完[RFC7821]で使用されるフィールドです。 Autokey拡張フィールドの後には常にMACが続き、[Autokey]のセクション10は、ホストが拡張フィールドとMACを区別できるようにする解析ルールを指定します。ただし、拡張フィールドの後のMACは必須ではありません。 NTPv4パケットには、MACを含めずに1つ以上の拡張フィールドを含めることができます。この動作は、[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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。
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の前に1つ以上の拡張フィールドを挿入できます。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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
すべての拡張フィールドは、ワード（4オクテット）境界までゼロが埋め込まれます。フィールドタイプフィールドは定義された関数に固有であり、ここでは詳しく説明しません。必要なフィールドを含む最小フィールド長は4ワード（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の前に1つ以上の拡張フィールドを挿入できます。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Extension Field Format
図14：拡張フィールドの形式
All extension fields are zero-padded to a word (four octets) boundary.
すべての拡張フィールドは、ワード（4オクテット）境界までゼロが埋め込まれます。
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レジストリで定義され、その長さ、値、パディングの値はレジストリによって参照されるドキュメントによって定義されます。ホストが未知のフィールドタイプの拡張フィールドを受信した場合、ホストは拡張フィールドを無視し、ポリシーで必要な場合はパケットを完全にドロップする必要があります（SHOULD）。
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.
必須フィールドを含む最小フィールド長は4ワード（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の長さを定義しなければなりません（MUST）。拡張フィールドは、複数のアルゴリズムの使用を許可してもよい（MAY）。その場合、使用されたアルゴリズムに関する情報は、拡張フィールド自体に含まれていなければならない（MUST）。
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を必要とする2つ以上の拡張フィールドとともに送信してはなりません（MUST NOT）。
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.
このレシーバーが認識する2つ以上の拡張フィールドを含むNTPパケットが受信され、それらのフィールドが異なるアルゴリズムのMACを必要とする場合、パケットは破棄されなければなりません（MUST）。
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がクライアントとサーバーの両方によって合意されない限り、拡張フィールドが存在しない場合、MACは24オクテットより長くてはなりません（MUST）。クライアントとサーバーは、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が存在しない場合、次の規則に従って、1つ以上の拡張フィールドをヘッダーの後に挿入できます。
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サーバーからフラグを立てる必要があります。大きな拡張フィールドサイズも、それらが大きくなると予想されない限り、フラグを立てる必要があります。
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パケットをフィルタリングしてはなりません（MUST NOT）。このようなミドルボックスは、ミドルボックスが認識できるように更新されていない新しい拡張フィールドを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、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、DOI 10.17487 / RFC5905、2010年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。、およびD. Mills、「Network Time Protocol Version 4：Autokey Specification」、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 Errata、Erratum 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]ミズラヒ、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.
著者は彼の洞察に満ちたコメントのためにデーブ・ミルズに感謝して感謝します。著者はまた、徹底的なレビューと有益なコメントを提供してくれた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 Israel
Email: talmi@marvell.com
Danny Mayer Network Time Foundation PO Box 918 Talent, OR 97540 United States
Danny Mayer Network Time Foundation PO Box 918 Talent、OR 97540 United States
Email: mayer@ntp.org