[要約] RFC 8877は、パケットのタイムスタンプを定義するためのガイドラインであり、ネットワーク通信における正確な時間情報の取得を目的としています。
Internet Engineering Task Force (IETF) T. Mizrahi
Request for Comments: 8877 Huawei
Category: Informational J. Fabini
ISSN: 2070-1721 TU Wien
A. Morton
AT&T Labs
September 2020
Guidelines for Defining Packet Timestamps
パケットタイムスタンプを定義するためのガイドライン
Abstract
概要
Various network protocols make use of binary-encoded timestamps that are incorporated in the protocol packet format, referred to as "packet timestamps" for short. This document specifies guidelines for defining packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The target audience of this document includes network protocol designers. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document.
様々なネットワークプロトコルは、短縮された「パケットタイムスタンプ」と呼ばれるプロトコルパケットフォーマットに組み込まれているバイナリエンコードタイムスタンプを利用する。このドキュメントは、さまざまなレイヤーのネットワークプロトコルでパケットタイムスタンプフォーマットを定義するためのガイドラインを指定しています。また、3つの推奨タイムスタンプフォーマットを表示します。この文書のターゲットオーディエンスには、ネットワークプロトコル設計者が含まれています。パケットのタイムスタンプを必要とする新しいネットワークプロトコルは、ほとんどの場合、推奨されるタイムスタンプフォーマットの1つを使用することが予想されます。推奨されるフォーマットのどれもプロトコル要件に適合しない場合、新しいプロトコル仕様はこの文書のガイドラインに従ってパケットタイムスタンプの形式を指定する必要があります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8877.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc8877で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction
1.1. Background
1.2. Scope of this Document
1.3. How to Use This Document
2. Terminology
2.1. Requirements Language
2.2. Abbreviations
2.3. Terms Used in This Document
3. Packet Timestamp Specification Template
4. Recommended Timestamp Formats
4.1. Using a Recommended Timestamp Format
4.2. NTP Timestamp Formats
4.2.1. NTP 64-Bit Timestamp Format
4.2.2. NTP 32-Bit Timestamp Format
4.3. The PTP Truncated Timestamp Format
5. Synchronization Aspects
6. Timestamp Use Cases
6.1. Example 1
6.2. Example 2
7. Packet Timestamp Control Field
7.1. High-Level Control Field Requirements
8. IANA Considerations
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Authors' Addresses
Timestamps are widely used in network protocols for various purposes: for logging or reporting the time of an event, for messages in delay measurement and clock synchronization protocols, and as part of a value that is unlikely to repeat (nonce) in security protocols.
タイムスタンプは、さまざまな目的のためにネットワークプロトコルで広く使用されています。イベントの時刻をログ記録または報告するために、遅延測定およびクロック同期プロトコルのメッセージの場合、およびセキュリティプロトコルで繰り返し（NONCE）を繰り返す可能性が低い値の一部として。
Timestamps are represented in the RFC series in one of two forms: text-based timestamps and packet timestamps. Text-based timestamps [RFC3339] are represented as user-friendly strings and are widely used in the RFC series -- for example, in information objects and data models, e.g., [RFC5646], [RFC6991], and [RFC7493]. Packet timestamps, on the other hand, are represented by a compact binary field that has a fixed size and are not intended to have a human-friendly format. Packet timestamps are also very common in the RFC series and are used, for example, for measuring delay and for synchronizing clocks, e.g., [RFC5905], [RFC4656], and [RFC7323].
タイムスタンプは、テキストベースのタイムスタンプとパケットのタイムスタンプのうちの2つの形式のRFCシリーズで表されます。テキストベースのタイムスタンプ[RFC3339]は、ユーザーフレンドリーな文字列として表され、RFCシリーズでは広く使用されています。例えば、情報オブジェクトやデータモデル、例えば[RFC5646]、[RFC6991]、[RFC7493]。一方、パケットタイムスタンプは、固定サイズを持つコンパクトなバイナリフィールドで表され、人間にやさしいフォーマットを持つことを意図しない。パケットタイムスタンプもRFCシリーズで非常に一般的であり、例えば、遅延を測定し、クロックを測定するために、例えば[RFC5905]、[RFC4656]、[RFC7323]を使用している。
This document presents guidelines for defining a packet timestamp format in network protocols. Three recommended timestamp formats are presented. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of these recommended timestamp formats. In some cases, a network protocol may use more than one of the recommended timestamp formats. However, if none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document.
この文書では、ネットワークプロトコルでパケットのタイムスタンプフォーマットを定義するためのガイドラインを示します。3つの推奨タイムスタンプフォーマットが表示されます。パケットのタイムスタンプを必要とする新しいネットワークプロトコルは、ほとんどの場合、これらの推奨タイムスタンプ形式のいずれかを使用することが予想されます。場合によっては、ネットワークプロトコルは、推奨されるタイムスタンプフォーマットを超える複数のタイムスタンプフォーマットを使用することがあります。ただし、推奨されるフォーマットがプロトコル要件に合わない場合、新しいプロトコル仕様はこの文書のガイドラインに従ってパケットタイムスタンプの形式を指定する必要があります。
The rationale behind defining a relatively small set of recommended formats is that it enables significant reuse; network protocols can typically reuse the timestamp format of the Network Time Protocol (NTP) [RFC5905] or the Precision Time Protocol (PTP) [IEEE1588], allowing a straightforward integration with an NTP- or PTP-based timer. Moreover, since accurate timestamping mechanisms are often implemented in hardware, a new network protocol that reuses an existing timestamp format can be quickly deployed using existing hardware timestamping capabilities.
比較的小さい推奨フォーマットのセットを定義することの背後にある根拠は、それが有意な再利用を可能にすることです。ネットワークプロトコルは通常、ネットワークタイムプロトコル（NTP）[RFC5905]またはPRECISION TIME PROTOCOL（PTP）[IEEE1588]のタイムスタンプフォーマットを再利用して、NTPまたはPTPベースのタイマーとの直接的な統合を可能にします。さらに、正確なタイムスタンプメカニズムがハードウェアで実装されることが多いため、既存のタイムスタンプフォーマットを再利用する新しいネットワークプロトコルは、既存のハードウェアタイムスタンプ機能を使用して迅速に展開できます。
This document is intended as a reference for network protocol designers. When defining a network protocol that uses a packet timestamp, the recommended timestamp formats should be considered first (Section 4). If one of these formats is used, it should be referenced along the lines of the examples in Sections 6.1 and 6.2. If none of the recommended formats fits the required functionality, then a new timestamp format should be defined using the template in Section 3.
この文書は、ネットワークプロトコル設計者のための参照として意図されています。パケットのタイムスタンプを使用するネットワークプロトコルを定義するときは、推奨されるタイムスタンプフォーマットを最初に考慮する必要があります（セクション4）。これらのフォーマットの1つが使用されている場合は、セクション6.1および6.2の例の行に沿って参照する必要があります。推奨されるフォーマットのどれも必要な機能に適合しない場合は、セクション3のテンプレートを使用して新しいタイムスタンプ形式を定義する必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきです。
NTP Network Time Protocol [RFC5905]
NTPネットワークタイムプロトコル[RFC5905]
PTP Precision Time Protocol [IEEE1588]
PTP精密時間プロトコル[IEEE1588]
TAI International Atomic Time
タイ国際原子時刻
UTC Coordinated Universal Time
UTC協定ユニバーサルタイム
Timestamp: A value that represents a point in time, corresponding to an event that occurred or is scheduled to occur.
timestamp：発生したイベントに対応する、または発生する予定のイベントに対応するポイント時間を表す値。
Timestamp error: The difference between the timestamp value and the value of a reference clock at the time of the event that the timestamp was intended to indicate.
タイムスタンプエラー：タイムスタンプが示すイベント時のタイムスタンプ値と基準クロックの値の差。
Timestamp format: The specification of a timestamp, which is represented by a set of attributes that unambiguously defines the syntax and semantics of a timestamp.
タイムスタンプフォーマット：タイムスタンプの指定は、タイムスタンプの構文と意味論を明確に定義する一連の属性によって表されます。
Timestamp accuracy: The mean over an ensemble of measurements of the timestamp error.
タイムスタンプの精度：タイムスタンプエラーの測定のアンサンブルの平均。
Timestamp precision: The variation over an ensemble of measurements of the timestamp error.
タイムスタンプ精度：タイムスタンプエラーの測定の集合の変動。
Timestamp resolution: The minimal time unit used for representing the timestamp.
タイムスタンプ解像度：タイムスタンプを表すために使用される最小タイムユニット。
This document recommends using the timestamp formats defined in Section 4. In cases where these timestamp formats do not satisfy the protocol requirements, the timestamp specification should clearly state the reasons for defining a new format. Moreover, it is recommended to derive the new timestamp format from an existing timestamp format, either a timestamp format from this document or any other previously defined timestamp format.
この文書はセクション4で定義されているタイムスタンプ形式を使用することをお勧めします。これらのタイムスタンプフォーマットがプロトコル要件を満たさない場合、タイムスタンプ仕様は新しいフォーマットを定義する理由を明確に述べるべきです。さらに、このドキュメントからのタイムスタンプ形式、または以前に定義されたタイムスタンプ形式のいずれかの既存のタイムスタンプ形式から新しいタイムスタンプフォーマットを導出することをお勧めします。
The timestamp specification must unambiguously define the syntax and semantics of the timestamp. The current section defines the minimum set of attributes, but it should be noted that in some cases, additional attributes or aspects will need to be defined in the timestamp specification.
タイムスタンプ仕様は、タイムスタンプの構文とセマンティクスを明確に定義する必要があります。現在のセクションは最小の属性セットを定義しますが、場合によっては、タイムスタンプ仕様で追加の属性または側面を定義する必要があることに注意してください。
This section defines a template for specifying packet timestamps. A timestamp format specification MUST include at least the following aspects:
このセクションでは、パケットタイムスタンプを指定するためのテンプレートを定義します。タイムスタンプ形式の指定は、少なくとも次の側面を含める必要があります。
Timestamp syntax: Size: The number of bits (or octets) used to represent the packet timestamp field. If the timestamp is comprised of more than one field, the size of each field is specified. Network order (big endian) is assumed by default; if this is not the case, then this section explicitly specifies the endianity.
timestamp構文：size：パケットのタイムスタンプフィールドを表すために使用されるビット数（またはオクテット）。タイムスタンプが複数のフィールドで構成されている場合は、各フィールドのサイズが指定されています。ネットワークオーダー（ビッグエンディアン）がデフォルトで想定されています。そうでない場合、このセクションではEndianityを明示的に指定します。
Timestamp semantics: Units: The units used to represent the timestamp. If the timestamp is comprised of more than one field, the units of each field are specified. If a field is limited to a specific range of values, this section specifies the permitted range of values.
タイムスタンプセマンティクス：単位：タイムスタンプを表すために使用される単位。タイムスタンプが複数のフィールドで構成されている場合は、各フィールドの単位が指定されています。フィールドが特定の値の範囲に制限されている場合、このセクションは許容値の範囲を指定します。
Resolution: The timestamp resolution; the resolution is equal to the timestamp field unit. If the timestamp consists of two or more fields using different time units, then the resolution is the smallest time unit.
解決策：タイムスタンプ解像度。解像度はタイムスタンプフィールドユニットに等しい。タイムスタンプが異なる時間単位を使用して2つ以上のフィールドで構成されている場合、解像度は最小の時間単位です。
Wraparound: The wraparound period of the timestamp; any further wraparound-related considerations should be described here.
ラップアラウンド：タイムスタンプのラップアラウンド期間。ここでは、任意のラップアラウンド関連の考慮事項について説明する必要があります。
Epoch: The origin of the timescale used for the timestamp; the moment in time used as a reference for the timestamp value. For example, the epoch may be based on a standard time scale, such as UTC. Another example is a relative timestamp, in which the epoch could be the time at which the device using the timestamp was powered up and is not affected by leap seconds (see the next attribute).
エポック：タイムスタンプに使用されるタイムスケールの原点。タイムスタンプ値の基準として使用される時間。例えば、エポックは、UTCなどの標準的な時間スケールに基づくことができる。もう1つの例は、タイムスタンプを使用しているデバイスが電源投入され、Leap Secondsの影響を受けない時間である可能性がある相対タイムスタンプです。
Leap seconds: This subsection specifies whether the timestamp is affected by leap seconds. If the timestamp is affected by leap seconds, then it represents the time elapsed since the epoch minus the number of leap seconds that have occurred since the epoch.
Leap Seconds：このサブセクションは、タイムスタンプがLEAP秒の影響を受けるかどうかを指定します。タイムスタンプがうるう秒の影響を受けている場合は、エポックから発生した経過時間を表します。
Synchronization aspects: The specification of a network protocol that makes use of a packet timestamp is expected to include the synchronization aspects of using the timestamp. While the synchronization aspects are not strictly part of the timestamp format specification, these aspects provide the necessary context for using the timestamp within the scope of the protocol. In some cases, timestamps are used without synchronization, e.g., a timestamp that indicates the number of seconds since power-up. In such cases, the Synchronization Aspects section will specify that the timestamp does not correspond to a synchronized time reference and may discuss how this affects the usage of the timestamp. Further details about synchronization aspects are discussed in Section 5.
同期の態様：パケットのタイムスタンプを利用するネットワークプロトコルの指定は、タイムスタンプを使用する同期の側面を含むと予想されます。同期側面はタイムスタンプフォーマット仕様の一部ではないが、これらの態様はプロトコルの範囲内でタイムスタンプを使用するために必要なコンテキストを提供する。場合によっては、タイムスタンプは同期せずに使用されます。例えば、電源投入中の秒数を示すタイムスタンプ。そのような場合、同期アスペクトセクションは、タイムスタンプが同期時間リファレンスに対応していないことを指定し、これがタイムスタンプの使用にどのように影響するかについて議論することができます。同期態様に関するさらなる詳細は、セクション5で説明されている。
This document defines a set of recommended timestamp formats. Clearly, different network protocols may have different requirements and constraints; consequently, they may use different timestamp formats. The choice of a specific timestamp format for a given protocol may depend on various factors. A few examples of factors that may affect the choice of the timestamp format include the following:
このドキュメントは、推奨されるタイムスタンプフォーマットのセットを定義します。明らかに、さまざまなネットワークプロトコルには、異なる要件と制約があります。その結果、異なるタイムスタンプフォーマットを使用することがあります。特定のプロトコルの特定のタイムスタンプフォーマットの選択は、さまざまな要因に依存する可能性があります。タイムスタンプ形式の選択に影響を与える可能性がある要因のいくつかの例としては、次のものがあります。
* Timestamp size: While some network protocols use a large timestamp field, in some cases, there may be constraints with respect to the timestamp size, affecting the choice of the timestamp format.
* TimesTampサイズ：ネットワークプロトコルによっては大きなタイムスタンプフィールドを使用していますが、場合によっては、タイムスタンプ形式の選択に影響を与えるタイムスタンプサイズに関して制約がある可能性があります。
* Resolution: The time resolution is another factor that may directly affect the selected timestamp format. A potentially important factor in this context is extensibility; it may be desirable to allow a timestamp format to be extensible to a higher resolution by extending the field. For example, the resolution of the NTP 32-bit timestamp format can be improved by extending it to the NTP 64-bit timestamp format in a straightforward way.
* 解決策：時間分解能は、選択したタイムスタンプ形式に直接影響を与える可能性があるもう1つの要因です。この文脈における潜在的に重要な要素は拡張性です。フィールドを拡張することによって、タイムスタンプフォーマットをより高い解像度に拡張できるようにすることが望ましいかもしれません。たとえば、NTP 32ビットのタイムスタンプフォーマットの解像度は、それを直接的な方法でNTP 64ビットのタイムスタンプ形式に拡張することで改善できます。
* Wraparound period: The length of the time interval in which the timestamp is unique may also be an important factor in choosing the timestamp format. Along with the timestamp resolution, these two factors determine the required number of bits in the timestamp.
* ラップアラウンド期間：タイムスタンプが一意である時間間隔の長さも、タイムスタンプ形式を選択する際に重要な要素になることがあります。タイムスタンプの解像度とともに、これら2つの要因はタイムスタンプの必要なビット数を決定します。
* Common format for multiple protocols: If there are two or more network protocols that use timestamps and are often used together in typical systems, using a common timestamp format should be preferred if possible. For example, if the network protocol that is being defined typically runs on a PC, then an NTP-based timestamp format may allow easier integration with an NTP-synchronized timer. In contrast, a protocol that is typically deployed on a hardware-based platform may make better use of a PTP-based timestamp, allowing more efficient integration with a PTP-synchronized timer.
* 複数のプロトコルのための共通フォーマット：タイムスタンプを使用し、典型的なシステムで頻繁に使用される2つ以上のネットワークプロトコルがある場合は、可能であれば、一般的なタイムスタンプフォーマットを使用する必要があります。たとえば、定義されているネットワークプロトコルがPC上で実行されている場合、NTPベースのタイムスタンプ形式では、NTP同期タイマーとのより容易な統合が可能になる可能性があります。対照的に、通常はハードウェアベースのプラットフォームに展開されているプロトコルは、PTPベースのタイムスタンプを使用することができ、PTP同期タイマーとのより効率的な統合を可能にすることができます。
A specification that uses one of the recommended timestamp formats should specify explicitly that this is a recommended timestamp format and point to the relevant section in the current document.
推奨されるタイムスタンプフォーマットの1つを使用する仕様は、これが推奨されるタイムスタンプ形式であり、現在のドキュメントの関連セクションを指すように明示的に指定する必要があります。
The Network Time Protocol (NTP) 64-bit timestamp format is defined in [RFC5905]. This timestamp format is used in several network protocols, including [RFC6374], [RFC4656], and [RFC5357]. Since this timestamp format is used in NTP, it should be preferred in network protocols that are typically deployed in concert with NTP.
ネットワークタイムプロトコル（NTP）64ビットタイムスタンプフォーマットは[RFC5905]で定義されています。このタイムスタンプ形式は、[RFC6374]、[RFC4656]、[RFC5357]を含む複数のネットワークプロトコルで使用されています。このタイムスタンプフォーマットはNTPで使用されているので、通常はNTPとコンサートで展開されているネットワークプロトコルに優先されるべきです。
The format is presented in this section according to the template defined in Section 3.
形式は、セクション3で定義されているテンプレートに従ってこのセクションに表示されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NTP 64-Bit Timestamp Format
図1：NTP 64ビットタイムスタンプフォーマット
Timestamp field format: Seconds: Specifies the integer portion of the number of seconds since the epoch.
タイムスタンプフィールド形式：秒：エポック以降の秒数の整数部分を指定します。
Size: 32 bits.
サイズ：32ビット。
Units: Seconds.
単位：秒。
Fraction: Specifies the fractional portion of the number of seconds since the epoch.
フラクション：エポック以降の秒数の小数部分を指定します。
Size: 32 bits.
サイズ：32ビット。
Units: The unit is 2^(-32) seconds, which is roughly equal to 233 picoseconds.
単位：ユニットは2 ^（ - 32）秒です。これは、233ピコ秒にほぼ同じです。
Epoch: The epoch is 1 January 1900 at 00:00 UTC.
エポック：エポックは1900年1月1日、00:00 UTCです。
Note: As pointed out in [RFC5905], strictly speaking, UTC did not exist prior to 1 January 1972, but it is convenient to assume it has existed for all eternity. The current epoch implies that the timestamp specifies the number of seconds since 1 January 1972 at 00:00 UTC plus 2272060800 (which is the number of seconds between 1 January 1900 and 1 January 1972).
注：[RFC5905]で指摘されているように、厳密に言えば、1972年1月1日にUTCは存在しませんでしたが、すべての永遠に存在していたと仮定するのに便利です。現在のエポックは、タイムスタンプが1972年1月1日から00:00 UTC Plus 2272060800（197年1月1日から1972年1月1日の秒数）で秒数を指定することを意味します。
Leap seconds: This timestamp format is affected by leap seconds. The timestamp represents the number of seconds elapsed since the epoch minus the number of leap seconds. Thus, during and possibly before and/or after the occurrence of a leap second, the value of the timestamp may temporarily be ambiguous, as further discussed in Section 5.
Leap Seconds：このタイムスタンプフォーマットはLeap秒の影響を受けます。タイムスタンプは、EpochからLEAP秒数を引いた秒数を表します。したがって、うるう2番目に、さらに、セクション5で説明したように、タイムスタンプの値は一時的に曖昧になる可能性がある。
Resolution: The resolution is 2^(-32) seconds.
解決策：解像度は2 ^（ - 32）秒です。
Wraparound: This time format wraps around every 2^(32) seconds, which is roughly 136 years. The next wraparound will occur in the year 2036.
ラップアラウンド：この時間フォーマットは2 ^（32）秒ごとにラップします。これはおおよそ136歳です。次のラップアラウンドは2036年に発生します。
The Network Time Protocol (NTP) 32-bit timestamp format is defined in [RFC5905]. This timestamp format is used in [METRICS] and [NSHMD]. This timestamp format should be preferred in network protocols that are typically deployed in concert with NTP. The 32-bit format can be used either when space constraints do not allow the use of the 64-bit format or when the 32-bit format satisfies the resolution and wraparound requirements.
ネットワークタイムプロトコル（NTP）32ビットタイムスタンプフォーマットは[RFC5905]で定義されています。このタイムスタンプフォーマットは[メトリクス]と[nshmd]で使用されます。このタイムスタンプフォーマットは、通常NTPとコンサートに展開されているネットワークプロトコルで優先されるべきです。スペースの制約が64ビットフォーマットの使用を許可しない場合、または32ビットフォーマットが解像度とラップアラウンドの要件を満たしている場合は、32ビット形式を使用できます。
The format is presented in this section according to the template defined in Section 3.
形式は、セクション3で定義されているテンプレートに従ってこのセクションに表示されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: NTP 32-Bit Timestamp Format
図2：NTP 32ビットタイムスタンプフォーマット
Timestamp field format: Seconds: Specifies the integer portion of the number of seconds since the epoch.
タイムスタンプフィールド形式：秒：エポック以降の秒数の整数部分を指定します。
Size: 16 bits.
サイズ：16ビット。
Units: Seconds.
単位：秒。
Fraction: Specifies the fractional portion of the number of seconds since the epoch.
フラクション：エポック以降の秒数の小数部分を指定します。
Size: 16 bits.
サイズ：16ビット。
Units: The unit is 2^(-16) seconds, which is roughly equal to 15.3 microseconds.
単位：ユニットは2 ^（ - 16）秒で、これはおよそ15.3マイクロ秒です。
Epoch: The epoch is 1 January 1900 at 00:00 UTC.
エポック：エポックは1900年1月1日、00:00 UTCです。
Note: As pointed out in [RFC5905], strictly speaking, UTC did not exist prior to 1 January 1972, but it is convenient to assume it has existed for all eternity. The current epoch implies that the timestamp specifies the number of seconds since 1 January 1972 at 00:00 UTC plus 2272060800 (which is the number of seconds between 1 January 1900 and 1 January 1972).
注：[RFC5905]で指摘されているように、厳密に言えば、1972年1月1日にUTCは存在しませんでしたが、すべての永遠に存在していたと仮定するのに便利です。現在のエポックは、タイムスタンプが1972年1月1日から00:00 UTC Plus 2272060800（197年1月1日から1972年1月1日の秒数）で秒数を指定することを意味します。
Leap seconds: This timestamp format is affected by leap seconds. The timestamp represents the number of seconds elapsed since the epoch minus the number of leap seconds. Thus, during and possibly before and/or after the occurrence of a leap second, the value of the timestamp may temporarily be ambiguous, as further discussed in Section 5.
Leap Seconds：このタイムスタンプフォーマットはLeap秒の影響を受けます。タイムスタンプは、EpochからLEAP秒数を引いた秒数を表します。したがって、うるう2番目に、さらに、セクション5で説明したように、タイムスタンプの値は一時的に曖昧になる可能性がある。
Resolution: The resolution is 2^(-16) seconds.
解決策：解像度は2 ^（ - 16）秒です。
Wraparound: This time format wraps around every 2^(16) seconds, which is roughly 18 hours.
ラップアラウンド：この時間フォーマットは2 ^（16）秒ごとにラップします。これはおおよそ18時間です。
The Precision Time Protocol (PTP) [IEEE1588] uses an 80-bit timestamp format. The truncated timestamp format is a 64-bit field, which is the 64 least significant bits of the 80-bit PTP timestamp. Since this timestamp format is similar to the one used in PTP, this timestamp format should be preferred in network protocols that are typically deployed in PTP-capable devices.
精密時間プロトコル（PTP）[IEEE1588]は80ビットのタイムスタンプフォーマットを使用します。切り捨てられたタイムスタンプフォーマットは64ビットフィールドです。これは、80ビットPTPタイムスタンプの64個の最下位ビットです。このタイムスタンプフォーマットはPTPで使用されているものと似ているので、このタイムスタンプ形式は、PTP対応デバイスに通常展開されているネットワークプロトコルで優先されるべきです。
The PTP truncated timestamp format was defined in [IEEE1588v1] and is used in several protocols, such as [RFC6374], [RFC7456], [RFC8186], and [ITU-T-Y.1731].
PTP切り捨てられたタイムスタンプ形式は[IEEE1588V1]で定義され、[RFC6374]、[RFC7456]、[RFC8186]、[ITU-T-Y.1731]など、いくつかのプロトコルで使用されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nanoseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PTP Truncated Timestamp Format
図3：PTP切り捨てられたタイムスタンプフォーマット
Timestamp field format: Seconds: Specifies the integer portion of the number of seconds since the epoch.
タイムスタンプフィールド形式：秒：エポック以降の秒数の整数部分を指定します。
Size: 32 bits.
サイズ：32ビット。
Units: Seconds.
単位：秒。
Nanoseconds: Specifies the fractional portion of the number of seconds since the epoch.
ナノ秒：エポック以降の秒数の小数部分を指定します。
Size: 32 bits.
サイズ：32ビット。
Units: Nanoseconds. The value of this field is in the range 0 to (10^(9))-1.
単位：ナノ秒。このフィールドの値は0から（10 ^（9）） - 1の範囲内です。
Epoch: The PTP [IEEE1588] epoch is 1 January 1970 00:00:00 TAI.
エポック：PTP [IEEE1588]エポックは1970年1月1日00:00:00 Taiです。
Leap seconds: This timestamp format is not affected by leap seconds.
Leap Seconds：このタイムスタンプ形式は、Leap Secondsの影響を受けません。
Resolution: The resolution is 1 nanosecond.
解決策：解像度は1ナノ秒です。
Wraparound: This time format wraps around every 2^(32) seconds, which is roughly 136 years. The next wraparound will occur in the year 2106.
ラップアラウンド：この時間フォーマットは2 ^（32）秒ごとにラップします。これはおおよそ136歳です。次のラップアラウンドは2106年に発生します。
A specification that defines a new timestamp format or uses one of the recommended timestamp formats should include a Synchronization Aspects section. Note that the recommended timestamp formats defined in this document (Section 4) do not include the synchronization aspects of these timestamp formats, but it is expected that specifications of network protocols that make use of these formats should include the synchronization aspects. Examples of a Synchronization Aspects section can be found in Section 6.
新しいタイムスタンプフォーマットを定義するか、または推奨されるタイムスタンプフォーマットの1つを使用する仕様は、同期側面セクションを含める必要があります。このドキュメント（セクション4）で定義されている推奨タイムスタンプフォーマットには、これらのタイムスタンプ形式の同期側面は含まれていませんが、これらのフォーマットを利用するネットワークプロトコルの仕様は同期側面を含める必要があります。同期態様の例は、セクション6に記載されています。
The Synchronization Aspects section should specify all the assumptions and requirements related to synchronization. For example, the synchronization aspects may specify whether nodes populating the timestamps should be synchronized among themselves and whether the timestamp is measured with respect to a central reference clock such as an NTP server. If time is assumed to be synchronized to a time standard such as UTC or TAI, it should be specified in this section. Further considerations may be discussed in this section, such as the required timestamp accuracy and precision.
同期側面セクションは、同期に関連するすべての仮定と要件を指定する必要があります。例えば、同期態様は、タイムスタンプを入力するノードを自分で同期させるべきか、およびタイムスタンプがNTPサーバのような中央基準クロックに関して測定されるべきかどうかを指定することができる。UTCやTAIなどの時間標準に時間を同期させる場合は、このセクションで指定する必要があります。必要なタイムスタンプ精度と精度など、このセクションではさらなる考慮事項について説明することができます。
Another aspect that should be discussed in this section is leap second [RFC5905] considerations. The timestamp specification template (Section 3) specifies whether the timestamp is affected by leap seconds. It is often the case that further details about leap seconds will need to be defined in the Synchronization Aspects section. Generally speaking, a leap second is a one-second adjustment that is occasionally applied to UTC in order to keep it aligned with solar time. A leap second may be either positive or negative, i.e., the clock may either be shifted one second forward or backward. All leap seconds that have occurred up to the publication of this document have been in the backward direction, and although forward leap seconds are theoretically possible, the text throughout this document focuses on the common case, which is the backward leap second. In a timekeeping system that considers leap seconds, the system clock may be affected by a leap second in one of three possible ways:
このセクションで議論する必要がある別の態様は、Leap Second [RFC5905]の考慮事項です。タイムスタンプ仕様テンプレート（セクション3）は、タイムスタンプがLEAP秒の影響を受けるかどうかを指定します。LEAP秒に関するさらなる詳細を同期態様のセクションで定義する必要がある場合がよくあります。一般的に言えば、うるう2番目は、太陽時間と整列させ続けるために時々UTCに適用される1秒の調整です。うるう2番目は、正または負のいずれかであり得る、すなわちクロックは1秒前または後方にシフトされてもよい。この文書の出版物まで発生したすべてのうるう秒は後方にありましたが、前進葉秒は理論的に可能ですが、この文書全体を通してのテキストは共通の場合に焦点を当てています。LEAP秒を考慮したタイムキーピングシステムでは、システムクロックは3つの可能な方法のうちの1つで最長秒の影響を受ける可能性があります。
* The clock is turned backwards one second at the end of the leap second.
* クロックはうるう2秒の終わりに1秒間後に回転されます。
* The clock is frozen during the duration of the leap second.
* 最初の秒の間にクロックは凍結されます。
* The clock is slowed down during the leap second and adjacent time intervals until the new time value catches up. The interval for this process, commonly referred to as "leap smear", can range from several seconds to several hours before, during, and/or after the occurrence of the leap second.
* 新しい時間値がキャッチされるまで、Leap Secondおよび隣接する時間間隔中にクロックが減速されます。このプロセスの間隔は、一般に「LEAP Smear」と呼ばれる間隔は、うるう2秒の発生の数秒から数時間の範囲です。
The way leap seconds are handled depends on the synchronization protocol and is thus not specified in this document. However, if a timestamp format is defined with respect to a timescale that is affected by leap seconds, the Synchronization Aspects section should specify how the use of leap seconds affects the timestamp usage.
LEAP秒間の処理方法は、同期プロトコルによって異なり、このドキュメントでは指定されていません。ただし、LEAP秒の影響を受けるタイムスケールに関してタイムスタンプ形式が定義されている場合、[同期側面]セクションは、LEAP秒の使用方法がタイムスタンプ使用に影響する方法を指定する必要があります。
Packet timestamps are used in various network protocols. Typical applications of packet timestamps include delay measurement, clock synchronization, and others. The following table presents a (non-exhaustive) list of protocols that use packet timestamps and the timestamp formats used in each of these protocols.
パケットタイムスタンプはさまざまなネットワークプロトコルで使用されます。パケットタイムスタンプの典型的なアプリケーションには、遅延測定、クロック同期などが含まれます。次の表は、パケットのタイムスタンプを使用するプロトコルの（非網羅的な）リストと、これらのプロトコルのそれぞれで使用されているタイムスタンプ形式を示しています。
+=================+======================================+=======+
| | Recommended Formats | Other |
+=================+============+============+============+=======+
| Protocol | NTP 64-Bit | NTP 32-Bit | PTP Trunc. | |
+=================+============+============+============+=======+
| NTP [RFC5905] | + | | | |
+-----------------+------------+------------+------------+-------+
| OWAMP [RFC4656] | + | | | |
+-----------------+------------+------------+------------+-------+
| TWAMP [RFC5357] | + | | | |
| TWAMP [RFC8186] | + | | + | |
+-----------------+------------+------------+------------+-------+
| TRILL [RFC7456] | | | + | |
+-----------------+------------+------------+------------+-------+
| MPLS [RFC6374] | | | + | |
+-----------------+------------+------------+------------+-------+
| TCP [RFC7323] | | | | + |
+-----------------+------------+------------+------------+-------+
| RTP [RFC3550] | + | | | + |
+-----------------+------------+------------+------------+-------+
| IPFIX [RFC7011] | | | | + |
+-----------------+------------+------------+------------+-------+
| BinaryTime | | | | + |
| [RFC6019] | | | | |
+-----------------+------------+------------+------------+-------+
| [METRICS] | + | + | | |
+-----------------+------------+------------+------------+-------+
| [NSHMD] | | + | + | |
+-----------------+------------+------------+------------+-------+
Table 1: Protocols That Use Packet Timestamps
表1：パケットタイムスタンプを使用するプロトコル
The rest of this section presents two hypothetical examples of network protocol specifications that use one of the recommended timestamp formats. The examples include the text that specifies the information related to the timestamp format.
このセクションの残りの部分は、推奨されるタイムスタンプフォーマットの1つを使用するネットワークプロトコル仕様の2つの仮説例を示しています。例としては、タイムスタンプ形式に関する情報を指定するテキストが含まれています。
Timestamp: The timestamp format used in this specification is the NTP [RFC5905] 64-bit format, as described in Section 4.2.1 of RFC 8877.
タイムスタンプ：RFC 8877のセクション4.2.1で説明されているように、この仕様で使用されているタイムスタンプフォーマットは、NTP [RFC5905] 64ビットフォーマットです。
Synchronization aspects: It is assumed that the nodes that run this protocol are synchronized to UTC using a synchronization mechanism that is outside the scope of this document. In typical deployments, this protocol will run on a machine that uses NTP [RFC5905] for synchronization. Thus, the timestamp may be derived from the NTP-synchronized clock, allowing the timestamp to be measured with respect to the clock of an NTP server. Since the NTP time format is affected by leap seconds, the current timestamp format is similarly affected. Thus, the value of a timestamp during and possibly before and/or after a leap second may be temporarily inaccurate.
同期側面：このプロトコルを実行するノードは、この文書の範囲外の同期メカニズムを使用してUTCに同期されていると仮定されています。一般的な展開では、このプロトコルは同期のためにNTP [RFC5905]を使用するマシン上で実行されます。したがって、タイムスタンプはNTP同期クロックから導出され、タイムスタンプがNTPサーバのクロックに対して測定されることを可能にする。NTPタイムフォーマットはLEAP秒の影響を受けるため、現在のタイムスタンプフォーマットも同様に影響を受けます。したがって、うるう2番目の瞬間後、および/または後に、そしておそらく、および/または後にタイムスタンプの値は一時的に不正確であり得る。
Timestamp: The timestamp format used in this specification is the PTP [IEEE1588] truncated format, as described in Section 4.3 of RFC 8877.
タイムスタンプ：RFC 8877のセクション4.3で説明されているように、この仕様で使用されているタイムスタンプフォーマットは、PTP [IEEE1588]切り捨て形式です。
Synchronization aspects: It is assumed that the nodes that run this protocol are synchronized among themselves. Nodes may be synchronized to a global reference time. Note that if PTP [IEEE1588] is used for synchronization, the timestamp may be derived from the PTP-synchronized clock, allowing the timestamp to be measured with respect to a PTP grandmaster clock.
同期側面：このプロトコルを実行するノードはそれ自体同期されていると仮定されています。ノードはグローバルな基準時間に同期されてもよい。PTP [IEEE1588]が同期に使用される場合、タイムスタンプはPTP同期クロックから導出され、PTPグランドマスタークロックに関してタイムスタンプを測定することができます。
In some cases, it is desirable to have a control field that describes the structure, format, content, and properties of timestamps. Control information about the timestamp format can be conveyed in some protocols using a dedicated control plane protocol or may be made available at the management plane, for example, using a YANG data model. An optional control field allows some of the control information to be attached to the timestamp.
場合によっては、タイムスタンプの構造、フォーマット、コンテンツ、およびプロパティを記述する制御フィールドを有することが望ましい。TIMESTAMPフォーマットに関する制御情報は、専用の制御プレーンプロトコルを使用して、あるプロトコルによって伝達することができ、または例えばYANDデータモデルを使用して管理プレーンで利用可能にされ得る。オプションの制御フィールドでは、いくつかの制御情報をタイムスタンプに接続することができます。
An example of a packet timestamp control field is the Error Estimate field, defined by Section 4.1.2 of [RFC4656], which is used in the One-Way Active Measurement Protocol (OWAMP) [RFC4656] and Two-Way Active Measurement Protocol (TWAMP) [RFC5357]. The Root Dispersion and Root Delay fields in the NTP header [RFC5905] are two examples of fields that provide information about the timestamp precision. Another example of an auxiliary field is the Correction Field in the PTP header [IEEE1588]; its value is used as a correction to the timestamp and may be assigned by the sender of the PTP message and updated by transit nodes (Transparent Clocks) in order to account for the delay along the path.
パケットタイムスタンプ制御フィールドの例は、一方向アクティブ測定プロトコル（OWAMP）[RFC4656]および双方向アクティブ測定プロトコルで使用されている[RFC4656]のセクション4.1.2で定義されたエラー推定フィールドです。TWAMP）[RFC5357]。NTPヘッダー[RFC5905]のルート分散フィールドとルート遅延フィールドは、タイムスタンプ精度に関する情報を提供するフィールドの例です。補助フィールドの別の例は、PTPヘッダ[IEEE1588]の補正フィールドです。その値はタイムスタンプに対する補正として使用され、パスに沿った遅延を考慮するためにPTPメッセージの送信者によって割り当てられ、トランジットノード（透過的なクロック）によって更新されてもよい。
This section defines high-level guidelines for defining packet timestamp control fields in network protocols that can benefit from such timestamp-related control information. The word "requirements" is used in its informal context in this section.
このセクションでは、そのようなタイムスタンプ関連の制御情報から利益を得ることができるネットワークプロトコルでパケットタイムスタンプ制御フィールドを定義するための高レベルのガイドラインを定義します。「要件」という単語は、このセクションの非公式のコンテキストで使用されています。
A control field for packet timestamps must offer an adequate feature set and fulfill a series of requirements to be usable and accepted. The following list captures the main high-level requirements for timestamp fields.
パケットタイムスタンプの制御フィールドは、適切な機能セットを提供し、使用可能かつ受け入れられるように一連の要件を満たす必要があります。次のリストは、TimesTampフィールドの主要な高レベルの要件をキャプチャします。
1. Extensible Feature Set: Protocols and applications depend on various timestamp characteristics. A timestamp control field must support a variable number of elements (components) that either describe or quantify timestamp-specific characteristics or parameters. Examples of potential elements include timestamp size, encoding, accuracy, leap seconds, reference clock identifiers, etc.
1. 拡張機能セット：プロトコルとアプリケーションはさまざまなタイムスタンプ特性によって異なります。タイムスタンプ制御フィールドは、タイムスタンプ固有の特性またはパラメータを記述または定量化する可変数の要素（コンポーネント）をサポートしている必要があります。潜在的な要素の例には、タイムスタンプサイズ、符号化、精度、跳躍秒、基準クロック識別子などが含まれる。
2. Size: Essential for an efficient use of timestamp control fields is the trade-off between supported features and control field size. Protocols and applications may select the specific control field elements that are needed for their operation from the set of available elements.
2. サイズ：タイムスタンプ制御フィールドを効率的に使用するには、サポートされている機能と制御フィールドサイズの間のトレードオフです。プロトコルとアプリケーションは、利用可能な要素のセットからの操作に必要な特定の制御フィールド要素を選択することができます。
3. Composition: Applications may depend on specific control field elements being present in messages. The status of these elements may be either mandatory, conditional mandatory, or optional, depending on the specific application and context. A control field specification must support applications in conveying or negotiating (a) the set of control field elements along with (b) the status of any element (i.e., mandatory, conditional mandatory, or optional) by defining appropriate data structures and identity codes.
3. 構成：アプリケーションは、メッセージ内に存在する特定の制御フィールド要素に依存し得る。これらの要素のステータスは、特定のアプリケーションとコンテキストに応じて、必須、条件付き必須、またはオプションのいずれかです。制御フィールド仕様は、適切なデータ構造および識別コードを定義することによって、（B）任意の要素の状態（すなわち、必須、条件付き必須、またはオプション）と共に（b）任意の要素のステータス（すなわち、必須、条件付き必須、またはオプション）と共に（b）と共に（b）任意の要素の状態（すなわち、必須、条件付き必須、またはオプション）を伝達または交渉することにおいてアプリケーションをサポートしなければならない。
4. Category: Control field elements can characterize either static timestamp information (e.g., timestamp size in bytes and timestamp semantics: NTP 64-bit format) or runtime timestamp information (e.g., estimated timestamp accuracy at the time of sampling: 20 microseconds to UTC). For efficiency reasons, it may be meaningful to support separation of these two concepts: while the former (static) information is typically valid throughout a protocol session and may be conveyed only once, at session establishment time, the latter (runtime) information augments any timestamp instance and may cause substantial overhead for high-traffic protocols.
4. カテゴリ：制御フィールド要素は、静的タイムスタンプ情報（例えば、バイトとタイムスタンプセマンティクス：NTP 64ビットフォーマット）またはランタイムタイムスタンプ情報（例えば、サンプリング時の推定タイムスタンプ精度20マイクロ秒）のいずれかを特徴付けることができます。効率的な理由から、これら2つの概念の分離をサポートすることは意味があるかもしれません：前者の（静的）情報は通常プロトコルセッション全体を通して有効であり、セッション確立時間において一度だけ伝えられるかもしれませんが、後者（ランタイム）情報は任意のものであればTimesTampインスタンスで、高トラフィックプロトコルにはかなりのオーバーヘッドを引き起こす可能性があります。
Proposals for timestamp control fields will be defined in separate documents and are out of scope of this document.
タイムスタンプ制御フィールドの提案は別々の文書で定義され、この文書の範囲外です。
This document has no IANA actions.
この文書にはIANAの行動がありません。
A network protocol that uses a packet timestamp MUST specify the security considerations that result from using the timestamp. This section provides an overview of some of the common security considerations of using timestamps.
パケットタイムスタンプを使用するネットワークプロトコルは、タイムスタンプを使用することから生じるセキュリティ上の考慮事項を指定する必要があります。このセクションでは、タイムスタンプを使用する一般的なセキュリティ上の考慮事項のいくつかの概要について説明します。
Any metadata that is attached to control or data packets, and specifically packet timestamps, can facilitate network reconnaissance; by passively eavesdropping on timestamped packets, an attacker can gather information about the network performance and the level of synchronization between nodes.
制御またはデータパケット、および特にパケットのタイムスタンプに接続されているメタデータは、ネットワークの偵察を容易にすることができます。タイムスタンプされたパケットを受動的に盗聴することによって、攻撃者はネットワーク性能とノード間の同期のレベルに関する情報を収集することができます。
In some cases, timestamps could be spoofed or modified by on-path attackers, thus attacking the application that uses the timestamps. For example, if timestamps are used in a delay measurement protocol, an attacker can modify en route timestamps in a way that manipulates the measurement results. Integrity protection mechanisms, such as Message Authentication Codes (MACs), can mitigate such attacks. The specification of an integrity protection mechanism is outside the scope of this document as, typically, integrity protection will be defined on a per-network-protocol basis and not specifically for the timestamp field.
場合によっては、タイムスタンプがスプーフ済みまたはオンパス攻撃者によって変更される可能性があり、タイムスタンプを使用するアプリケーションを攻撃することができます。たとえば、タイムスタンプが遅延測定プロトコルで使用されている場合、攻撃者は測定結果を操作する方法でENルートタイムスタンプを変更できます。メッセージ認証コード（MACS）などの完全性保護メカニズムは、そのような攻撃を軽減できます。整合性保護メカニズムの仕様は、通常、完全性保護はネットワークごとのプロトコルごとに定義され、具体的にはタイムスタンプフィールドでは定義されているため、この文書の範囲外です。
Another potential threat that can have a similar impact is delay attacks. An attacker can maliciously delay some or all of the en route messages, with the same harmful implications as described in the previous paragraph. Mitigating delay attacks is a significant challenge; in contrast to spoofing and modification attacks, the delay attack cannot be prevented by cryptographic integrity protection mechanisms. In some cases, delay attacks can be mitigated by sending the timestamped information through multiple paths, allowing detection of and resistance to an attacker that has access to one of the paths.
同様の影響を与えることができるもう一つの潜在的な脅威は遅れ攻撃です。攻撃者は、前の段落で説明されているのと同じ有害な影響を持つ、途中の経路メッセージの一部または全部を故意に遅らせることができます。遅延攻撃を軽減することは大きな課題です。スプーフィングや修正攻撃とは対照的に、暗号化された完全性保護メカニズムによって遅延攻撃を防ぐことはできません。場合によっては、複数のパスを介してタイムスタンプされた情報を送信することによって遅延攻撃を軽減することができ、そのパスの1つにアクセスできる攻撃者の検出を可能にします。
In many cases, timestamping relies on an underlying synchronization mechanism. Thus, any attack that compromises the synchronization mechanism can also compromise protocols that use timestamping. Attacks on time protocols are discussed in detail in [RFC7384].
多くの場合、タイムスタンプは基礎となる同期メカニズムに依存しています。したがって、同期メカニズムを犠牲にする攻撃は、タイムスタンプを使用するプロトコルも妥協する可能性があります。時間プロトコルの攻撃については、[RFC7384]で詳しく説明しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", DOI 10.1109/IEEESTD.2008.4579760, IEEE Std. 1588-2008, July 2008, <https://doi.org/10.1109/IEEESTD.2008.4579760>.
[IEEE1588] IEEE、「ネットワーク測定制御システム用精密クロック同期プロトコルのIEEE規格」、DOI 10.1109 / IEEEESTD.2008.4579760、IEEE STD。2008年7月、<https://doi.org/10.1109/ieeeestd.2008.4579760>。
[IEEE1588v1] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", DOI 10.1109/IEEESTD.2002.94144, IEEE Std. 1588-2002, October 2002, <https://doi.org/10.1109/IEEESTD.2002.94144>.
[IEEE1588V1] IEEE、「ネットワーク測定制御システムのための精密クロック同期プロトコルのためのIEEE規格」、DOI 10.1109 / IEEESTD.2002.94144、IEEE STD。2002年10月、<https://doi.org/10.1109/ieeeestd.2002.94144>。
[ITU-T-Y.1731] ITU-T, "Operations, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks", ITU-T Recommendation G.8013/Y.1731, August 2015.
[ITU-T-Y.1731] ITU-T、「操作、管理および保守（OAM）機能とイーサネットベースネットワークのメカニズム」、2015年8月、ITU-T勧告G.8013 / Y.1731。
[METRICS] Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, "Initial Performance Metrics Registry Entries", Work in Progress, Internet-Draft, draft-ietf-ippm-initial-registry-16, 9 March 2020, <https://tools.ietf.org/html/ draft-ietf-ippm-initial-registry-16>.
[Metrics]モートン、A.、Bagnulo、M.、Eardley、P.、K.D' Souza、「初期性能メトリックレジストリエントリー」、進行中の作業、インターネットドラフト、草案-IETF-IPPM-Initial-Registry-16、2020年3月9日、<https://tools.ietf.org/html/ proft-ietf-ietf-ippm-initial-registry-16>。
[NSHMD] Guichard, J., Smith, M., Kumar, S., Majee, S., and T. Mizrahi, "Network Service Header (NSH) MD Type 1: Context Header Allocation (Data Center)", Work in Progress, Internet-Draft, draft-ietf-sfc-nsh-dc-allocation-02, 25 September 2018, <https://tools.ietf.org/html/draft-ietf-sfc-nsh-dc-allocation-02>.
[NSHMD] Guichard、J.、Smith、M.、Kumar、S.、Majee、S.、T.Mizrahi、「ネットワークサービスヘッダ（NSH）MDタイプ1：コンテキストヘッダ割り当て（データセンター）」進捗状況、インターネットドラフト、ドラフト-IETF-SFC-NSH-DC-ALLOCATION-02,25,25、<https：//tools.ietf.org/html/draft-ietf-sfc-nsh-dc-allocation-02>。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[RFC3339] Klyne、G.およびC. NEWMAN、「インターネット上の日時：Timestamps」、RFC 3339、DOI 10.17487 / RFC3339、2002年7月、<https：//www.rfc-editor.org/info/rfc3339>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R.、およびV. Jacobson、「RTP：リアルタイムアプリケーション用輸送プロトコル」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、<https://www.rfc-editor.org/info/rfc3550>。
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.
[RFC4656] Shalunov、S.、Teitelbaum、B.、KARP、A.、Boote、J.、およびM.Zekauskas、「一方向アクティブ測定プロトコル（OWAMP）」、RFC 4656、DOI 10.17487 / RFC4656、9月2006年、<https：//www.rfc-editor.org/info/rfc4656>。
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.
[RFC5357] Hedayat、K.、Krzanowski、R.、Morton、A。、YUM、K。、およびJ.Babiarz、「双方向アクティブ測定プロトコル（TWAMP）」、RFC 5357、DOI 10.17487 / RFC5357、10月2008年、<https://www.rfc-editor.org/info/rfc5357>。
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5646] Phillips、A.、ED。そして、「言語を特定するためのタグ」、BCP 47、RFC 5646、DOI 10.17487 / RFC5646、2009年9月、<https：//www.rfc-editor.org/info/rfc5646>。
[RFC5905] 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, <https://www.rfc-editor.org/info/rfc5905>.
[RFC5905]ミルズ、D.、Martin、J.、Ed。、Burbank、J.、およびW. Kasch、「ネットワークタイムプロトコルバージョン4：プロトコルおよびアルゴリズム仕様」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月<https://www.rfc-editor.org/info/rfc5905>。
[RFC6019] Housley, R., "BinaryTime: An Alternate Format for Representing Date and Time in ASN.1", RFC 6019, DOI 10.17487/RFC6019, September 2010, <https://www.rfc-editor.org/info/rfc6019>.
[RFC6019] housley、R.、「BinaryTime：ASN.1の日付と時刻を表現するための代替形式」、RFC 6019、DOI 10.17487 / RFC6019、2010年9月、<https：//www.rfc-editor.org/info/ RFC6019>。
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, <https://www.rfc-editor.org/info/rfc6374>.
[RFC6374] Frost、D.およびS.ブライアント、「MPLSネットワークのパケット損失および遅延測定」、RFC 6374、DOI 10.17487 / RFC6374、2011年9月、<https：//www.rfc-editor.org/info/rfc6374>。
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC6991] Schoenwaelder、J.、Ed。、「共通ヤンデータ型」、RFC 6991、DOI 10.17487 / RFC6991、2013年7月、<https：//www.rfc-editor.org/info/rfc6991>。
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>.
[RFC7011] Claise、B、ED。、Trammell、B.、Ed。、およびP.Aitken、「フロー情報交換のIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、STD 77、RFC 7011、DOI 10.17487 / RFC7011、2013年9月、<https：//www.rfc-editor.org/info/rfc7011>。
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.
[RFC7323] Borman、D.、Braden、B.、Jacobson、V.、およびR.Scheffenegger、ED。、「高性能のためのTCP拡張」、RFC 7323、DOI 10.17487 / RFC7323、2014年9月、<https：//www.rfc-editor.org/info/rfc7323>。
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC7384] Mizrahi、T.、「パケット交換ネットワークにおける時間プロトコルのセキュリティ要件」、RFC 7384、DOI 10.17487 / RFC7384、2014年10月、<https：//www.rfc-editor.org/info/rfc7384>。
[RFC7456] Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and D. Eastlake 3rd, "Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL)", RFC 7456, DOI 10.17487/RFC7456, March 2015, <https://www.rfc-editor.org/info/rfc7456>.
[RFC7456] Mizrahi、T.、Senevirathne、T.、Salam、S.、Kumar、D.、D.イーストレーキ3RD、「ロットのロットの透明相互接続における損失・遅延測定（トリル）」、RFC 7456、DOI10.17487 / RFC7456、2015年3月、<https：//www.rfc-editor.org/info/rfc7456>。
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/info/rfc7493>.
[RFC7493] Bray、T.、Ed。、「I-JSONメッセージフォーマット」、RFC 7493、DOI 10.17487 / RFC7493、2015年3月、<https：//www.rfc-editor.org/info/rfc7493>。
[RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, <https://www.rfc-editor.org/info/rfc8186>.
[RFC8186] Mirsky、G.およびI.Meilik、「双方向アクティブ測定プロトコル（TWAMP）」、RFC 8186、DOI 10.17487 / RFC8186、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8186>。
Acknowledgments
謝辞
The authors thank Russ Housley, Yaakov Stein, Greg Mirsky, Warner Losh, Rodney Cummings, Miroslav Lichvar, Denis Reilly, Daniel Franke, Éric Vyncke, Ben Kaduk, Ian Swett, Francesca Palombini, Watson Ladd, and other members of the NTP Working Group for their many helpful comments. The authors gratefully acknowledge Harlan Stenn and the people from the Network Time Foundation for sharing their thoughts and ideas.
著者らは、Russ House、Yaakov Stein、Greg Mirsky、Warner Losh、Rodney Cummings、Miroslav Lichvar、Denis Reilly、Daniel Franke、Ins Swett、Francesca Palombini、Watsc Ladd、およびNTPワーキンググループのメンバー彼らの多くの役に立つコメントのために。著者らは、Harlan Stennと、ネットワークタイム基盤からの人々を彼らの考えやアイデアを共有するための人々に感謝します。
Authors' Addresses
著者の住所
Tal Mizrahi Huawei 8-2 Matam Haifa 3190501 Israel
タルミズラヒ・ハウエイ8-2 Matam Haifa 3190501イスラエル
Email: tal.mizrahi.phd@gmail.com
Joachim Fabini TU Wien Gusshausstrasse 25/E389 1040 Vienna Austria
Joachim Fabini Tu Wien Gusshausstrasse 25 / E389 1040ウィーンオーストリア
Phone: +43 1 58801 38813
Email: Joachim.Fabini@tuwien.ac.at
URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/
Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 United States of America
Al Morton At＆T Labs 200 Laurel Avenue南Middletown、NJ 07748アメリカ合衆国
Phone: +1 732 420 1571
Email: acmorton@att.com