[要約] RFC 7821は、ネットワークタイムプロトコル（NTP）におけるUDPチェックサムの補数に関するものであり、NTPのセキュリティと信頼性を向上させるための改善を提案しています。目的は、UDPパケットの整合性を確保し、データの改ざんやエラーを検出することです。
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オクテットのチェックサム補完を含む拡張フィールドを提案し、タイムスタンプエンジンがチェックサムの変更をUDPチェックサムフィールドではなく、パケットの最後の2オクテットに反映できるようにします。このドキュメントで定義されている動作は、既存のNTP実装と相互運用できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
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 ....................................................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パケットはソフトウェア層によって送受信されますが、タイムスタンプエンジンは、正確な送信時間をパケットの<Transmit Timestamp>フィールドに入力します。
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
ASIC：特定用途向け集積回路FPGA：フィールドプログラマブルゲートアレイ
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]は、透過クロック（TC）を定義しています。遅延を追加することにより、PTPパケットの「補正フィールド」を更新することにより、エンドツーエンドのクロック精度を向上させます。現在のTCが原因です。 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チェックサムフィールドは、その正確性を維持するために更新する必要があります。 UDP over IPv4 [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]で定義されているUDP over IPv6は、特定の場合[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].
中間エンティティはパケット内の特定のフィールド、つまりタイムスタンプフィールドのみを変更するため、[チェックサム]に示されている概念を使用して、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]のチェックサム補完を定義します。チェックサム補完は、UDPペイロードの最後にある2オクテットのフィールドです。中間エンティティは、UDPチェックサムフィールドを更新する代わりに、パケットの最後の2オクテットを変更することにより、NTPパケットを更新し、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クロック内の2つのモジュールであることに注意してください。これら2つのモジュールは、送信された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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。
MAC Message Authentication Code
MACメッセージ認証コード
NTP Network Time Protocol
NTPネットワークタイムプロトコル
PTP Precision Time Protocol
PTPプレシジョンタイムプロトコル
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チェックサム補完は、NTP拡張フィールドを使用して、UDPペイロードの最後に追加される2オクテットのフィールドです。図2は、チェックサム補完拡張を備えたNTPパケットのパケット形式を示しています。
+--------------------------------+
| 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.
概要（セクション1）で説明されているように、チェックサム補完は、中間エンティティによってNTPパケットで実行された変更を補正するために使用されます。チェックサム補完の使用例は、付録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は、IPv4またはIPv6を介してUDPを介して転送されます。このドキュメントは、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.
[NTPv4]で定義されているように、NTPパケットには1つ以上の拡張フィールドが含まれる場合があります。図3に示すように、NTPパケットのチェックサム補完は専用のNTP拡張フィールドに存在します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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チェックサム値を維持してもよい（MAY）。
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層はチェックサム補完拡張フィールドを無視する必要があります（SHOULD）。
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.
このドキュメントで定義されている動作は、[RFC7822]で定義されている要件を超えて、NTPパケットの受信に新しい要件を課しません。 [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.
ハードウェアベースのタイムスタンプが使用される場合、両端で使用される可能性が高いため、プロトコルに参加する両方のホストがこのメモで説明されている機能をサポートすることに注意してください。ホストの1つだけがハードウェアベースのタイムスタンプを使用する場合、ピアホストがチェックサム補完を受け入れることができることがわかっている場合にのみ、チェックサム補完を使用できます。
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。、編、「インクリメンタルアップデートによるインターネットチェックサムの計算」、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、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、DOI 10.17487 / RFC5905、2010年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、「Network Time Protocol Version 4（NTPv4）Extension Fields」、RFC 7822、DOI 10.17487 / RFC7822、March 2016、<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 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。
[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]ミズラヒ、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を参照）は、Origin Timestamp TとUDPチェックサム値Uを持つNTPパケットを生成します。Uの値は、UDPヘッダー、UDPペイロード、および疑似ヘッダーのチェックサムです。したがって、Uは次と等しくなります。
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」は、Origin Timestamp 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.
クライアントのソフトウェアは、PTPパケットの最後にあるチェックサム補完拡張フィールドを持つNTPパケットを発信することを思い出してください。クライアントは最初にチェックサム補数の値にゼロを割り当てると想定されています。
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:
クライアントのタイムスタンプエンジンは、Origin Timestampフィールドを正確な時刻に更新し、その値をTからT 'に変更します。エンジンはまた、チェックサム補完フィールドをゼロから新しい値Cに更新します。
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)
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 Israel
Email: talmi@marvell.com