Internet Engineering Task Force (IETF)                   N. Rozen-Schiff
Request for Comments: 9523                                      D. Dolev
Category: Informational                   Hebrew University of Jerusalem
ISSN: 2070-1721                                               T. Mizrahi
                                        Huawei Network.IO Innovation Lab
                                                             M. Schapira
                                          Hebrew University of Jerusalem
                                                           February 2024
        
A Secure Selection and Filtering Mechanism for the Network Time Protocol with Khronos
クロノスを使用したネットワークタイムプロトコルの安全な選択とフィルタリングメカニズム
Abstract
概要

The Network Time Protocol version 4 (NTPv4), as defined in RFC 5905, is the mechanism used by NTP clients to synchronize with NTP servers across the Internet. This document describes a companion application to the NTPv4 client, named "Khronos", that is used as a "watchdog" alongside NTPv4 and that provides improved security against time-shifting attacks. Khronos involves changes to the NTP client's system process only. Since it does not affect the wire protocol, the Khronos mechanism is applicable to current and future time protocols.

RFC 5905で定義されているネットワークタイムプロトコルバージョン4(NTPV4)は、インターネット上のNTPサーバーと同期するためにNTPクライアントが使用するメカニズムです。このドキュメントでは、NTPV4と並んで「ウォッチドッグ」として使用され、時間シフト攻撃に対するセキュリティの改善を提供する「クロノス」という名前のNTPV4クライアントへのコンパニオンアプリケーションについて説明します。Khronosには、NTPクライアントのシステムプロセスのみの変更のみが含まれます。ワイヤプロトコルに影響しないため、クロノスメカニズムは現在および将来の時間プロトコルに適用できます。

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/rfc9523.

このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9523で取得できます。

著作権表示

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(c)2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。

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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

このドキュメントは、BCP 78およびIETFドキュメント(https://trustee.ietf.org/license-info)に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。

Table of Contents
目次
   1.  Introduction
   2.  Conventions Used in This Document
     2.1.  Terms and Abbreviations
     2.2.  Notations
   3.  Khronos Design
     3.1.  Khronos Calibration - Gathering the Khronos Pool
     3.2.  Khronos's Poll and System Processes
     3.3.  Khronos's Recommended Parameters
   4.  Operational Considerations
     4.1.  Load Considerations
   5.  Security Considerations
     5.1.  Threat Model
     5.2.  Attack Detection
     5.3.  Security Analysis Overview
   6.  Khronos Pseudocode
   7.  Precision vs. Security
   8.  IANA Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgements
   Authors' Addresses
        
1. Introduction
1. はじめに

NTPv4, as defined in [RFC5905], is vulnerable to time-shifting attacks in which the attacker changes (shifts) the clock of a network device. Time-shifting attacks on NTP clients can be based on interfering with the communication between the NTP clients and servers or compromising the servers themselves. Time-shifting attacks on NTP are possible even if NTP communication is encrypted and authenticated. A weaker machine-in-the-middle (MITM) attacker can shift time simply by dropping or delaying packets, whereas a powerful attacker that has full control over an NTP server can do so by explicitly determining the NTP response content. This document introduces a time-shifting mitigation mechanism called "Khronos". Khronos can be integrated as a background-monitoring application (watchdog) that guards against time-shifting attacks in any NTP client. An NTP client that runs Khronos is interoperable with NTPv4 servers that are compatible with [RFC5905]. The Khronos mechanism does not affect the wire mechanism; therefore, it is applicable to any current or future time protocol.

[RFC5905]で定義されているNTPV4は、攻撃者がネットワークデバイスのクロックを変更(シフト)するタイムシフト攻撃に対して脆弱です。NTPクライアントに対するタイムシフト攻撃は、NTPクライアントとサーバー間の通信を妨害したり、サーバー自体を侵害したりすることに基づいています。NTP通信が暗号化され、認証されている場合でも、NTPに対するタイムシフト攻撃が可能です。より弱いマシンイン(MITM)攻撃者は、パケットをドロップまたは遅延させることで単純に時間をシフトできますが、NTPサーバーを完全に制御する強力な攻撃者は、NTP応答コンテンツを明示的に決定することでそうすることができます。このドキュメントでは、「クロノス」と呼ばれるタイムシフト緩和メカニズムを紹介します。Khronosは、NTPクライアントでの時間シフト攻撃に対して守るバックグラウンドモニタリングアプリケーション(WatchDog)として統合できます。Khronosを実行するNTPクライアントは、[RFC5905]と互換性のあるNTPV4サーバーと相互運用可能です。クロノスメカニズムは、ワイヤメカニズムに影響しません。したがって、現在または将来の時間プロトコルに適用できます。

Khronos is a mechanism that runs in the background, continuously monitoring the client clock (which is updated by NTPv4) and calculating an estimated offset (referred to as the "Khronos time offset"). When the offset exceeds a predefined threshold (specified in Section 5.2), this is interpreted as the client experiencing a time-shifting attack. In this case, Khronos updates the client's clock.

クロノスは、バックグラウンドで実行されるメカニズムであり、クライアントクロックを継続的に監視し(NTPV4によって更新されます)、推定オフセット(「クロノスタイムオフセット」と呼ばれる)を計算します。オフセットが事前定義されたしきい値(セクション5.2で指定)を超えると、これはクライアントがタイムシフト攻撃を経験していると解釈されます。この場合、クロノスはクライアントのクロックを更新します。

When the client is not under attack, Khronos is passive. This allows NTPv4 to control the client's clock and provides the ordinary high precision and accuracy of NTPv4. When under attack, Khronos takes control of the client's clock, mitigating the time shift while guaranteeing relatively high accuracy with respect to UTC and precision, as discussed in Section 7.

クライアントが攻撃を受けていない場合、クロノスは受動的です。これにより、NTPV4はクライアントのクロックを制御でき、NTPV4の通常の高精度と精度を提供します。攻撃を受けている場合、クロノスはクライアントのクロックを制御し、セクション7で説明したように、UTCと精度に関して比較的高い精度を保証しながら、時間シフトを軽減します。

By leveraging techniques from distributed computing theory for time synchronization, Khronos achieves accurate time even in the presence of powerful attackers who are in direct control of a large number of NTP servers. Khronos will prevent shifting the clock when the ratio of compromised time samples is below 2/3. In each polling interval, a Khronos client randomly selects and samples a few NTP servers out of a local pool of hundreds of servers. Khronos is carefully engineered to minimize the load on NTP servers and the communication overhead. In contrast, NTPv4 employs an algorithm that typically relies on a small subset of the NTP server pool (e.g., four servers) for time synchronization and is much more vulnerable to time-shifting attacks. Configuring NTPv4 to use several hundreds of servers will increase its security, but will incur very high network and computational overhead compared to Khronos and will be bounded by a compromised ratio of half of the time samples.

時間同期のために分散コンピューティング理論から手法を活用することにより、Khronosは、多数のNTPサーバーを直接制御している強力な攻撃者の存在下でも正確な時間を達成します。クロノスは、侵害された時間サンプルの比が2/3未満の場合、時計のシフトを防ぎます。各ポーリング間隔で、Khronosクライアントは、数百のサーバーのローカルプールからいくつかのNTPサーバーをランダムに選択およびサンプリングします。Khronosは、NTPサーバーの負荷と通信オーバーヘッドを最小限に抑えるために慎重に設計されています。対照的に、NTPV4は、通常、NTPサーバープールの小さなサブセット(4つのサーバーなど)の小さなサブセットに依存しているアルゴリズムを使用して、時間同期のために時間を変える攻撃に対してはるかに脆弱です。数百のサーバーを使用するようにNTPV4を構成すると、セキュリティが増加しますが、クロノスと比較して非常に高いネットワークと計算オーバーヘッドが発生し、時間の半分のサンプルの妥協比に制限されます。

A Khronos client iteratively "crowdsources" time queries across NTP servers and applies a provably secure algorithm for eliminating "suspicious" responses and for averaging over the remaining responses. In each Khronos poll interval, the Khronos client selects, uniformly at random, a small subset (e.g., 10-15 servers) of a large server pool (containing hundreds of servers). While Khronos queries around three times more servers per polling interval than NTP, Khronos's polling interval can be longer (e.g., 10 times longer) than NTPv4, thereby minimizing the load on NTP servers and the communication overhead. Moreover, Khronos's random server selection may even help to distribute queries across the whole pool.

Khronosクライアントは、NTPサーバー全体でタイムクエリを「クラウドソース」し、「疑わしい」応答を排除し、残りの応答を平均化するために、証拠的に安全なアルゴリズムを適用します。各クロノスの世論調査間隔で、クロノスのクライアントは、ランダムに均一に、大きなサーバープール(数百のサーバーを含む)の小さなサブセット(10〜15サーバー)を選択します。Khronosは、NTPの投票間隔ごとに3倍のサーバーの約3倍のサーバーを照会しますが、Khronosのポーリング間隔はNTPV4よりも長く(たとえば10倍長く)、NTPサーバーと通信オーバーヘッドの負荷を最小限に抑えることができます。さらに、Khronosのランダムサーバーの選択は、プール全体にクエリを配布するのに役立つ可能性さえあります。

Khronos's security was evaluated both theoretically and experimentally with a prototype implementation. According to this security analysis, if a local Khronos pool consists of, for example, 500 servers, one-seventh of whom are controlled by an attacker and Khronos queries 15 servers in each Khronos poll interval (around 10 times the NTPv4 poll interval), then over 20 years of effort are required (in expectation) to successfully shift time at a Khronos client by over 100 ms from UTC. The full exposition of the formal analysis of this guarantee is available at [Khronos].

Khronosのセキュリティは、プロトタイプの実装で理論的および実験的に評価されました。このセキュリティ分析によれば、地元のクロノスプールが500のサーバーで構成されている場合、そのうち17は攻撃者によって制御され、クロノスの各投票間隔でクロノスが15のサーバーをクエリします(NTPV4の世論調査間隔の約10倍)、その後、UTCから100ミリ秒以上クロノスのクライアントで時間を正常にシフトするために、20年以上の努力が必要です(予想)。この保証の正式な分析の完全な説明は、[クロノス]で入手できます。

Khronos maintains a time offset value (the Khronos time offset) and uses it as a reference for detecting attacks. This time offset value computation differs from the current NTPv4 in two key aspects:

クロノスは、タイムオフセット値(クロノスタイムオフセット)を維持し、攻撃を検出するための参照として使用します。今回のオフセット値計算は、2つの重要な側面で現在のNTPV4とは異なります。

* First, in each Khronos poll interval, Khronos periodically communicates with only a few (tens) randomly selected servers out of a pool consisting of a large number (e.g., hundreds) of NTP servers.

* まず、各クロノスの世論調査間隔で、クロノスは定期的に、多数の(数百)のNTPサーバーで構成されるプールから数個のランダムに選択されたサーバーと定期的に通信します。

* Second, Khronos computes the Khronos time offset based on an approximate agreement technique to remove outliers, thus limiting the attacker's ability to contaminate the time samples (offsets) derived from the queried NTP servers.

* 第二に、クロノスは、外れ値を除去するためのおおよその合意手法に基づいてクロノスタイムオフセットを計算し、攻撃者のクエリされたNTPサーバーから派生した時間サンプル(オフセット)を汚染する能力を制限します。

These two aspects allow Khronos to minimize the load on the NTP servers and to provide provable security guarantees against both MITM attackers and attackers capable of compromising a large number of NTP servers.

これらの2つの側面により、KhronosはNTPサーバーの負荷を最小限に抑え、多数のNTPサーバーを損なうことができるMITM攻撃者と攻撃者の両方に対して証明可能なセキュリティ保証を提供することができます。

We note that, to some extent, Network Time Security (NTS) [RFC8915] could make it more challenging for attackers to perform MITM attacks, but is of little impact if the servers themselves are compromised.

ある程度、ネットワークタイムセキュリティ(NTS)[RFC8915]は、攻撃者がMITM攻撃を実行することをより困難にする可能性があることに注意してください。

2. Conventions Used in This Document
2. このドキュメントで使用されている規則
2.1. Terms and Abbreviations
2.1. 用語と略語

NTPv4:

ntpv4:

Network Time Protocol version 4. See [RFC5905].

ネットワークタイムプロトコルバージョン4。[RFC5905]を参照してください。

System process:

システムプロセス:

See the "Selection Algorithm" and the "Cluster Algorithm" sections of [RFC5905].

[RFC5905]の「選択アルゴリズム」と「クラスターアルゴリズム」セクションを参照してください。

Security Requirements:

セキュリティ要件:

See "Security Requirements of Time Protocols in Packet Switched Networks" [RFC7384].

「パケット切り替えネットワークの時間プロトコルのセキュリティ要件」[RFC7384]を参照してください。

NTS:

NTS:

Network Time Security. See "Network Time Security for the Network Time Protocol" [RFC8915].

ネットワークタイムセキュリティ。「ネットワークタイムプロトコルのネットワークタイムセキュリティ」[RFC8915]を参照してください。

2.2. Notations
2.2. 表記

When describing the Khronos algorithm, the following notation is used:

Khronosアルゴリズムを説明するとき、次の表記が使用されます。

     +==========+====================================================+
     | Notation | Meaning                                            |
     +==========+====================================================+
     |    n     | The number of candidate servers in a Khronos pool  |
     |          | (potentially hundreds).                            |
     +----------+----------------------------------------------------+
     |    m     | The number of servers that Khronos queries in each |
     |          | poll interval (up to tens).                        |
     +----------+----------------------------------------------------+
     |    w     | An upper bound on the distance between any         |
     |          | "truechimer" NTP server (as in [RFC5905]) and UTC. |
     +----------+----------------------------------------------------+
     |    B     | An upper bound on the client's clock error rate    |
     |          | (ms/sec).                                          |
     +----------+----------------------------------------------------+
     |   ERR    | An upper bound on the client's clock error between |
     |          | Khronos polls (ms).                                |
     +----------+----------------------------------------------------+
     |    K     | The number of Khronos pool resamplings until       |
     |          | reaching "panic mode".                             |
     +----------+----------------------------------------------------+
     |    H     | Predefined threshold for a Khronos time offset     |
     |          | triggering clock update by Khronos.                |
     +----------+----------------------------------------------------+
        

Table 1: Khronos Notation

表1:クロノス表記

The recommended values are discussed in Section 3.3.

推奨される値については、セクション3.3で説明します。

3. Khronos Design
3. クロノスデザイン

Khronos periodically queries a set of m (tens) servers from a large (hundreds) server pool in each Khronos poll interval, where the m servers are selected from the server pool at random. Based on empirical analyses, to minimize the load on NTP servers while providing high security, the Khronos poll interval should be around 10 times the NTPv4 poll interval (i.e., a Khronos clock update occurs once every 10 NTPv4 clock updates). In each Khronos poll interval, if the Khronos time offset exceeds a predetermined threshold (denoted as H), an attack is indicated.

Khronosは、各Khronosポーリング間隔の大きな(数百)サーバープールからのM(TENS)サーバーのセットを定期的に照会し、Mサーバーがサーバープールからランダムに選択されます。経験的分析に基づいて、高いセキュリティを提供しながらNTPサーバーの負荷を最小限に抑えるために、Khronosの世論調査間隔はNTPV4の世論調査間隔の約10倍になるはずです(つまり、Khronosクロックの更新は10回のNTPV4クロック更新ごとに発生します)。各クロノスの世論調査間隔で、クロノスの時間オフセットが所定のしきい値(hと表される)を超える場合、攻撃が示されます。

Unless an attack is indicated, Khronos uses only one sample from each server (avoiding the "Clock Filter Algorithm" as defined in Section 10 of [RFC5905]). When under attack, Khronos uses several samples from each server and executes the "Clock Filter Algorithm" for choosing the best sample from each server with low jitter. Then, given a sample from each server, Khronos discards outliers by executing the procedure described in Section 3.2.

攻撃が示されない限り、Khronosは各サーバーのサンプルを1つだけ使用します([RFC5905]のセクション10で定義されている「クロックフィルターアルゴリズム」を回避します)。攻撃を受けている場合、Khronosは各サーバーからいくつかのサンプルを使用し、「Jitterの低いサーバーから各サーバーから最適なサンプル」を選択するために「クロックフィルターアルゴリズム」を実行します。次に、各サーバーからサンプルを与えられた場合、Khronosはセクション3.2で説明されている手順を実行することにより、外れ値を破棄します。

Between consecutive Khronos polls, Khronos keeps track of clock offsets, e.g., by catching clock discipline (as in [RFC5905]) calls. The sum of offsets is referred to as the "Khronos inter-poll offset" (denoted as tk), which is set to zero after each Khronos poll.

クロノスの連続した世論調査の間、クロノスは時計のオフセットを追跡します。たとえば、時計の規律([RFC5905]のように)の呼び出しをキャッチすることにより。オフセットの合計は、「クロノス間ポールオフセット」(TKと表される)と呼ばれ、各クロノスの世論調査の後にゼロに設定されています。

3.1. Khronos Calibration - Gathering the Khronos Pool
3.1. クロノスキャリブレーション - クロノスプールを集めます

Calibration is performed the first time Khronos is executed and periodically thereafter (once every two weeks). The calibration process generates a local Khronos pool of n (up to hundreds) NTP servers that the client can synchronize with. To this end, Khronos makes multiple DNS queries to the NTP pools. Each query returns a few NTP server IPs that Khronos combines into one set of IPs considered as the Khronos pool. The servers in the Khronos pool should be scattered across different regions to make it harder for an attacker to compromise or gain MITM capabilities with respect to a large fraction of the Khronos pool. Therefore, Khronos calibration queries general NTP server pools (e.g., pool.ntp.org) and not just the pool in the client's state or region. In addition, servers can be selected to be part of the Khronos pool manually or by using other NTP pools (such as NIST Internet time servers).

キャリブレーションは、クロノスが初めて実行され、その後定期的に(2週間に1回)実行されます。キャリブレーションプロセスは、クライアントが同期できるN(最大数百)NTPサーバーのローカルクロノスプールを生成します。この目的のために、クロノスはNTPプールに複数のDNSクエリを作成します。各クエリは、クロノスがクロノスプールと見なされる1つのIPSに結合するいくつかのNTPサーバーIPを返します。クロノスプールのサーバーは、異なる地域に散らばって、攻撃者がクロノスプールの大部分に関してMITM機能を妥協または獲得することを難しくする必要があります。したがって、Khronos Calibrationは、クライアントの状態または地域のプールだけでなく、一般的なNTPサーバープール(例:pool.ntp.org)を照会します。さらに、サーバーを選択して、クロノスプールの一部に手動で、または他のNTPプール(NISTインターネットタイムサーバーなど)を使用して選択できます。

The first Khronos update requires m servers, which can be found in several minutes. Moreover, it is possible to query several DNS pool names to vastly accelerate the calibration and the first update.

最初のクロノスアップデートでは、数分で見つけることができます。さらに、いくつかのDNSプール名を照会して、キャリブレーションと最初のアップデートを大幅に加速することができます。

The calibration is the only Khronos part where DNS traffic is generated. Around 125 DNS queries are required by Khronos to obtain addresses of 500 NTP servers, which is higher than Khronos pool size (n). Assuming the calibration period is two weeks, the expected DNS traffic generated by the Khronos client is less than 10 DNS queries per day, which is usually several orders of magnitude lower than the total daily number of DNS queries per machine.

キャリブレーションは、DNSトラフィックが生成される唯一のクロノス部分です。Khronosは、Khronosプールサイズ(N)よりも高い500のNTPサーバーのアドレスを取得するために、Khronosによって約125のDNSクエリが必要です。キャリブレーション期間が2週間であると仮定すると、Khronosクライアントによって生成される予想DNSトラフィックは1日あたり10 DNSクエリ未満です。これは通常、マシンあたりのDNSクエリの総数よりも数桁低くなります。

3.2. Khronos's Poll and System Processes
3.2. クロノスの世論調査とシステムプロセス

In each Khronos poll interval, the Khronos system process randomly chooses a set of m (tens) servers out of the Khronos pool of n (hundreds) servers and samples them. Note that the randomness of the server selection is crucial for the security of the scheme; therefore, any Khronos implementation must use a secure randomness implementation such as what is used for encryption key generation.

各クロノスの世論調査間隔で、Khronosシステムプロセスは、N(数百)サーバーのKhronosプールからM(TENS)サーバーのセットをランダムに選択し、それらをサンプリングします。サーバーの選択のランダム性は、スキームのセキュリティにとって重要であることに注意してください。したがって、Khronosの実装は、暗号化キー生成に使用されるものなど、安全なランダム性実装を使用する必要があります。

Khronos's polling times of different servers may spread uniformly within its poll interval, which is similar to NTPv4. Servers that do not respond during the Khronos poll interval are filtered out. If less than one-third of the m servers are left, a new subset of servers is immediately sampled in the exact same manner (which is called the "resampling" process).

異なるサーバーのKhronosのポーリング時間は、NTPV4に類似した投票間隔内で均一に広がる可能性があります。クロノスの世論調査間隔中に応答しないサーバーは除外されます。Mサーバーの3分の1未満が残っている場合、サーバーの新しいサブセットがまったく同じ方法ですぐにサンプリングされます(「再サンプリング」プロセスと呼ばれます)。

Next, out of the time samples received from this chosen subset of servers, the lowest third of the samples' offset values and the highest third of the samples' offset values are discarded.

次に、この選択したサーバーのサブセットから受け取ったサンプルのうち、サンプルの最低3分の1のサンプルとサンプルの最低3分の1のオフセット値が破棄されます。

Khronos checks that the following two conditions hold for the remaining sampled offsets (considering w and ERR defined in Table 1):

クロノスは、残りのサンプリングされたオフセットに対して次の2つの条件が当てはまることを確認します(表1で定義されているWおよびERRを考慮して)。

* The maximal distance between every two offsets does not exceed 2w (can be verified by considering just the minimum and the maximum offsets).

* 2つのオフセットごとの最大距離は2Wを超えません(最小値と最大オフセットのみを考慮することで検証できます)。

* The distance between the offset's average and the Khronos inter-poll offset is ERR+2w at most.

* オフセットの平均とクロノス間ポール間オフセットの間の距離は、せいぜい2Wです。

In the event that both of these conditions are satisfied, the average of the offsets is set to be the Khronos time offset. Otherwise, resampling is performed. This process spreads the Khronos client's queries across servers, thereby improving security against powerful attackers (as discussed in Section 5.3) and mitigating the effect of a DoS attack on NTP servers that renders them non-responsive. This resampling process continues in subsequent Khronos poll intervals until the two conditions are both satisfied or the number of times the servers are resampled exceeds a "panic trigger" (K in Table 1). In this case, Khronos enters panic mode.

これらの条件の両方が満たされた場合、オフセットの平均はクロノスタイムオフセットに設定されています。それ以外の場合、再サンプリングが実行されます。このプロセスは、クロノスのクライアントのクエリをサーバー全体に広げ、それにより強力な攻撃者に対するセキュリティを改善し(セクション5.3で説明したように)、それらを非応答性にするNTPサーバーに対するDOS攻撃の効果を軽減します。この再サンプリングプロセスは、2つの条件が満たされるか、サーバーが再サンプリングされる回数が「パニックトリガー」を超えるまで、その後のクロノス投票間隔で継続されます(表1のK)。この場合、クロノスはパニックモードに入ります。

In panic mode, Khronos queries all the servers in its local Khronos pool, orders the collected time samples from lowest to highest, and eliminates the lowest third and the highest third of the samples. The client then calculates the average of the remaining samples and sets this average to be the new Khronos time offset.

パニックモードでは、KhronosはローカルKhronosプールのすべてのサーバーを照会し、収集された時間サンプルを最低から最高から最高に注文し、サンプルの最低3分の1と3分の1を排除します。次に、クライアントは残りのサンプルの平均を計算し、この平均を新しいクロノスタイムオフセットに設定します。

If the Khronos time offset exceeds a predetermined threshold (H), it is passed on to the clock discipline algorithm in order to steer the system time (as in [RFC5905]). In this case, the user and/or admin of the client machine should be notified about the detected time-shifting attack, e.g., by a message written to a relevant event log or displayed on screen.

Khronosタイムオフセットが所定のしきい値(H)を超える場合、システム時間を操作するために時計分野のアルゴリズムに渡されます([RFC5905]のように)。この場合、クライアントマシンのユーザーおよび/または管理者に、たとえば、関連するイベントログに書かれたメッセージまたは画面に表示されるメッセージによって、検出されたタイムシフト攻撃について通知する必要があります。

Note that resampling immediately follows the previous sampling since waiting until the next polling interval may increase the time shift in face of an attack. This shouldn't generate high overhead since the number of resamples is bounded by K (after K resamplings, panic mode is in place) and the chances of ending up with repeated resampling are low (see Section 5 for more details). Moreover, in an interval following a panic mode, Khronos executes the same system process that starts by querying only m servers (regardless of previous panic).

次のポーリング間隔が攻撃に直面した時間シフトが増加するまで待機するため、再サンプリングはすぐに以前のサンプリングに続くことに注意してください。これは、再サンプルの数がKに制限されているため(Kの再サンプリング、パニックモードが整っている後)、繰り返しの再サンプリングで終わる可能性が低いため、これは高いオーバーヘッドを生成するものではありません(詳細についてはセクション5を参照)。さらに、パニックモードに続く間隔で、KhronosはMサーバーのみをクエリすることから始まる同じシステムプロセスを実行します(以前のパニックに関係なく)。

3.3. クロノスの推奨パラメーター

According to empirical observations (presented in [Khronos]), querying 15 servers at each poll interval (i.e., m=15) out of 500 servers (i.e., n=500) and setting w to be around 25 ms provides both high time accuracy and good security. Specifically, when selecting w=25 ms, approximately 83% of the servers' clocks are, at most, w away from UTC and within 2w from each other, satisfying the first condition of Khronos's system process. For a similar reason, the threshold for a Khronos time offset triggering a clock update by Khronos (H) should be between w and 2w; the default is 30 ms. Note that in order to support scenarios with congested links, using a higher w value, such as 1 second, is recommended.

経験的観測([Khronos]で提示)によると、500のサーバーのうち(つまり、n = 500)のうち各投票間隔(つまり、m = 15)で15のサーバーをクエリし、wを約25ミリ秒に設定すると、両方の時間精度の両方を提供します。そして良いセキュリティ。具体的には、W = 25ミリ秒を選択すると、サーバーのクロックの約83%が、せいぜいUTCから、互いに2W以内に離れており、クロノスのシステムプロセスの最初の条件を満たしています。同様の理由で、クロノス(H)によるクロックアップデートをトリガーするクロノス時間オフセットのしきい値は、Wと2Wの間である必要があります。デフォルトは30ミリ秒です。混雑したリンクでシナリオをサポートするには、1秒などのより高いW値を使用することをお勧めします。

Furthermore, according to Khronos security analysis, setting K to be 3 (i.e., if the two conditions are not satisfied after three resamplings, then Khronos enters panic mode) is safe when facing time-shifting attacks. In addition, the probability of an attacker forcing a panic mode on a client when K=3 is negligible (less than 0.000002 for each polling interval).

さらに、Khronosのセキュリティ分析によれば、Kを3に設定します(つまり、3回のリサンプリング後に2つの条件が満たされない場合、Khronosはパニックモードに入ります)。さらに、K = 3が無視できる場合、攻撃者がクライアントにパニックモードを強制する可能性はありません(各ポーリング間隔で0.000002未満)。

Khronos's effect on precision and accuracy are discussed in Sections 5 and 7.

精度と精度に対するクロノスの影響については、セクション5および7で説明します。

4. Operational Considerations
4. 運用上の考慮事項

Khronos is designed to defend NTP clients from time-shifting attacks while using public NTP servers. As such, Khronos is not applicable for data centers and enterprises that synchronize with local atomic clocks, GPS devices, or a dedicated NTP server (e.g., due to regulations).

クロノスは、パブリックNTPサーバーを使用しながら、タイムシフト攻撃からNTPクライアントを守るように設計されています。そのため、クロノスは、ローカルアトミッククロック、GPSデバイス、または専用のNTPサーバーと同期するデータセンターや企業には適用できません(たとえば、規制など)。

Khronos can be used for devices that require and depend upon timekeeping within a configurable constant distance from UTC.

Khronosは、UTCから構成可能な一定の距離内でのタイムキーピングを必要とするデバイスに使用できます。

4.1. Load Considerations
4.1. ロードに関する考慮事項

One requirement from Khronos is not to induce excessive load on NTP servers beyond that of NTPv4, even if it is widely integrated into NTP clients. We discuss below the possible causes for a Khronos-induced load on servers and how this can be mitigated.

Khronosからの1つの要件は、たとえNTPクライアントに広く統合されていても、NTPV4以外のNTPサーバーに過度の負荷を誘導することではありません。以下では、サーバー上のクロノス誘導負荷の可能性のある原因と、これをどのように緩和するかについて説明します。

Servers in pool.ntp.org are weighted differently by the NTP server pool when assigned to NTP clients. Specifically, server owners define a "server weight" (the "netspeed" parameter) and servers are assigned to clients probabilistically according to their proportional weight. Khronos's queries are equally distributed across a pool of servers. To avoid overloading servers, Khronos queries servers less frequently than NTPv4, with the Khronos query interval set to 10 times the default NTPv4 maxpoll (interval) parameter. Hence, if Khronos queries are targeted at servers in pool.ntp.org, any target increase in server load (in terms of multiplicative increase in queries or number of bytes per second) is controlled by the poll interval configuration, which was analyzed in [Ananke].

pool.ntp.orgのサーバーは、NTPクライアントに割り当てられた場合、NTPサーバープールによって異なる重み付けされています。具体的には、サーバーの所有者は「サーバーの重み」(「netspeed」パラメーター)を定義し、サーバーは比例した重みに応じて確率的にクライアントに割り当てられます。Khronosのクエリは、サーバーのプール全体に等しく配布されます。サーバーの過負荷を回避するために、KhronosはNTPV4よりも少ない頻度でサーバーをクエリします。Khronosクエリ間隔は、デフォルトのNTPV4 MAXPOLL(間隔)パラメーターの10倍に設定されています。したがって、Khronosクエリがpool.ntp.orgのサーバーをターゲットにしている場合、サーバー負荷のターゲットの増加(クエリの乗法上の増加または1秒あたりのバイト数の観点から)は、[[)]で分析された世論調査間設定によって制御されます。アナンケ]。

Consider the scenario where an attacker attempts to generate significant load on NTP servers by triggering multiple consecutive panic modes at multiple NTP clients. We note that to accomplish this, the attacker must have MITM capabilities with respect to the communication between each and every client in a large group of clients and a large fraction of all NTP servers in the queried pool. This implies that the attacker must either be physically located at a central location (e.g., at the egress of a large ISP) or launch a wide-scale attack (e.g., on BGP or DNS); thereby, it is capable of carrying similar and even higher impact attacks regardless of Khronos clients.

複数のNTPクライアントで複数の連続したパニックモードをトリガーすることにより、攻撃者がNTPサーバーに大きな負荷を生成しようとするシナリオを考えてみましょう。これを達成するには、攻撃者は、クライアントの大規模なグループの各クライアントとクエリプールのすべてのNTPサーバーの大部分との間の通信に関してMITM機能を持たなければならないことに注意してください。これは、攻撃者が物理的に中央の場所(大規模なISPの出口など)に物理的に配置するか、幅広い攻撃(BGPまたはDNSなど)を開始する必要があることを意味します。これにより、Khronosのクライアントに関係なく、同様のインパクト攻撃を運ぶことができます。

5. Security Considerations
5. セキュリティに関する考慮事項
5.1. Threat Model
5.1. 脅威モデル

The threat model encompasses a broad spectrum of attackers impacting a subset (e.g., one-third) of the servers in NTP pools. These attackers can range from a fairly weak (yet dangerous) MITM attacker that is only capable of delaying and dropping packets (e.g., using the Bufferbloat attack [RFC8033]) to an extremely powerful attacker who is in control of (even authenticated) NTP servers and is capable of fully determining the values of the time samples returned by these NTP servers (see detailed attacker discussion in [RFC7384]).

脅威モデルには、NTPプールのサーバーのサブセット(3分の1)に影響を与える幅広い攻撃者が含まれます。これらの攻撃者は、パケットを遅らせてドロップすることができるかなり弱い(まだ危険な)MITM攻撃者から(たとえば、バッファーブロート攻撃を使用して[RFC8033])、NTPサーバーを(認証されている)NTPサーバーを制御している非常に強力な攻撃者にまで及びます。また、これらのNTPサーバーによって返された時間サンプルの値を完全に判断することができます([RFC7384]の詳細な攻撃者のディスカッションを参照)。

For example, the attackers covered by this model might be:

たとえば、このモデルの対象となる攻撃者は次のとおりです。

1. in direct control of a fraction of the NTP servers (e.g., by exploiting a software vulnerability),

1. NTPサーバーの一部を直接制御する(例:ソフトウェアの脆弱性を活用することにより)、

2. an ISP (or other attacker at the Autonomous System level) on the default BGP paths from the NTP client to a fraction of the available servers,

2. NTPクライアントから利用可能なサーバーの一部までのデフォルトのBGPパス上のISP(または自律システムレベルの他の攻撃者)、

3. a nation state with authority over the owners of NTP servers in its jurisdiction, or

3. その管轄区域でNTPサーバーの所有者に対する権限を持つ国家、または

4. an attacker capable of hijacking (e.g., through DNS cache poisoning or BGP prefix hijacking) traffic to some of the available NTP servers.

4. 利用可能なNTPサーバーのいくつかへのトラフィックをハイジャックすることができる攻撃者(例:DNSキャッシュ中毒またはBGPプレフィックスハイジャック)。

The details of the specific attack scenario are abstracted by reasoning about attackers in terms of the fraction of servers with respect to which the attacker has adversarial capabilities. Attackers that can impact communications with (or control) a higher fraction of the servers (e.g., all servers) are out of scope. Considering the pool size across the world to be in the thousands, such attackers will most likely be capable of creating far worse damage than time-shifting attacks.

特定の攻撃シナリオの詳細は、攻撃者が敵対的能力を持っているサーバーの割合に関して攻撃者について推論することによって抽象化されています。サーバーの大部分(またはすべてのサーバーなど)との通信(または制御)に影響を与える可能性のある攻撃者は、範囲外です。世界中のプールサイズが数千人にあることを考慮すると、そのような攻撃者は、時間を変える攻撃よりもはるかに悪いダメージを与えることができるでしょう。

Notably, Khronos provides protection from MITM and powerful attacks that cannot be achieved by cryptographic authentication protocols since, even with such measures in place, an attacker can still influence time by dropping/delaying packets. However, adding an authentication layer (e.g., NTS [RFC8915]) to Khronos will enhance its security guarantees and enable the detection of various spoofing and modification attacks.

特に、クロノスは、そのような措置が整っていても、攻撃者がパケットをドロップ/遅延させることで時間に影響を与える可能性があるため、暗号化認証プロトコルでは達成できないMITMおよび強力な攻撃からの保護を提供します。ただし、認証レイヤー(例:NTS [RFC8915])をクロノスに追加すると、セキュリティ保証が強化され、さまざまなスプーフィングおよび修正攻撃の検出が可能になります。

Moreover, Khronos uses randomness to independently select the queried servers in each poll interval, preventing attackers from exploiting observations of past server selections.

さらに、Khronosはランダム性を使用して、各投票間隔でクエリのサーバーを独立して選択し、攻撃者が過去のサーバー選択の観察を悪用することを防ぎます。

5.2. Attack Detection
5.2. 攻撃検出

Khronos detects time-shifting attacks by constantly monitoring NTPv4's (or potentially any other current or future time protocol) clock and the offset computed by Khronos and checking whether the offset exceeds a predetermined threshold (H). NTPv4 controls the client's clock unless an attack was detected. Under attack, Khronos takes control over the client's clock in order to prevent its shift.

Khronosは、NTPV4(または潜在的に他の現在または将来のタイムプロトコル)クロックを絶えず監視し、クロノスによって計算されたオフセットを常に監視し、オフセットが所定のしきい値(H)を超えるかどうかを確認することにより、タイムシフト攻撃を検出します。NTPV4は、攻撃が検出されない限り、クライアントのクロックを制御します。攻撃を受けて、クロノスはシフトを防ぐためにクライアントの時計を制御します。

Analytical results (in [Khronos]) indicate that if a local Khronos pool consists of 500 servers, one-seventh of whom are controlled by a MITM attacker, and 15 of those servers are queried in each Khronos poll interval, then success in shifting time of a Khronos client by even a small degree (100 ms) takes many years of effort (over 20 years in expectation). See a brief overview of Khronos's security analysis below.

分析結果([クロノス]で)は、地元のクロノスプールが500のサーバーで構成されている場合、そのうち7分の1がMITM攻撃者によって制御され、それらのサーバーの15が各クロノスの世論調査の間に照会され、その後時間の変化に成功することを示しています。クロノスのクライアントのうち、わずかな程度(100ミリ秒)でさえ、長年の努力が必要です(20年以上の予想)。以下のクロノスのセキュリティ分析の概要をご覧ください。

5.3. Security Analysis Overview
5.3. セキュリティ分析の概要

Time samples that are at most w away from UTC are considered "good", whereas other samples are considered "malicious". Two scenarios are considered:

UTCからせいぜいw離れている時間サンプルは「良い」と見なされますが、他のサンプルは「悪意がある」と見なされます。2つのシナリオが考慮されます。

* Scenario A: Less than two-thirds of the queried servers are under the attacker's control.

* シナリオA:クエリサーバーの3分の2未満が攻撃者の制御下にあります。

* Scenario B: The attacker controls more than two-thirds of the queried servers.

* シナリオB:攻撃者は、クエリされたサーバーの3分の2以上を制御します。

Scenario A consists of two sub-cases:

シナリオAは、2つのサブケースで構成されています。

1. There is at least one good sample in the set of samples not eliminated by Khronos (in the middle third of samples), and

1. サンプルのセットには、クロノス(サンプルの中央の3分の1)によって排除されていないサンプルのセットには、少なくとも1つの良いサンプルがあります。

2. there are no good samples in the remaining set of samples.

2. 残りのサンプルセットには良いサンプルはありません。

In sub-case 1, the other remaining samples, including those provided by the attacker, must be close to a good sample (otherwise, the first condition of Khronos's system process in Section 3.2 is violated and a new set of servers is chosen). This implies that the average of the remaining samples must be close to UTC.

サブケース1では、攻撃者が提供するものを含む他の残りのサンプルは、良いサンプルに近いものでなければなりません(そうでなければ、セクション3.2のクロノスのシステムプロセスの最初の条件は違反され、新しいサーバーのセットが選択されます)。これは、残りのサンプルの平均がUTCに近いことを意味します。

In sub-case 2, since more than a third of the initial samples were good, both the (discarded) third-lowest-value samples and the (discarded) third-highest-value samples must each contain a good sample. Hence, all the remaining samples are bounded from both above and below by good samples, and so is their average value, implying that this value is close to UTC [RFC5905].

サブケース2では、初期サンプルの3分の1以上が良好だったため、(廃棄された)3番目の低価値サンプルと(破棄された)3番目の最も価値のあるサンプルの両方がそれぞれ良いサンプルを含める必要があります。したがって、残りのすべてのサンプルは、良好なサンプルによって上下の両方から境界を獲得し、その平均値も同様に、この値がUTCに近いことを意味します[RFC5905]。

In Scenario B, the worst possibility for the client is that all remaining samples are malicious (i.e., more than w away from UTC). However, as proved in [Khronos], the probability of this scenario is extremely low, even if the attacker controls a large fraction (e.g., one-fourth) of the n servers in the local Khronos pool. Therefore, the probability that the attacker repeatedly reaches this scenario decreases exponentially, rendering the probability of a significant time shift negligible. We can express the improvement ratio of Khronos over NTPv4 by the ratios of their single-shift probabilities. Such ratios are provided in Table 2, where higher values indicate higher improvement of Khronos over NTPv4 and are also proportional to the expected time until a time-shift attack succeeds once.

シナリオBでは、クライアントにとって最悪の可能性は、残りのすべてのサンプルが悪意があることです(つまり、UTCから離れたW以上)。ただし、[クロノス]で証明されているように、攻撃者がローカルクロノスプールのNサーバーの大部分(4分の1)を制御する場合でも、このシナリオの確率は非常に低いです。したがって、攻撃者がこのシナリオに繰り返し到達する可能性は指数関数的に減少し、重要な時間シフトの確率を無視できます。NTPV4を超えるクロノスの改善比を、シングルシフト確率の比率で表現できます。このような比率は表2に記載されています。ここでは、より高い値はNTPV4よりもクロノスのより高い改善を示し、タイムシフト攻撃が1回成功するまで予想される時間に比例します。

     +========+==========+==========+==========+==========+==========+
     | Attack |    6     |    12    |    18    |    24    |    30    |
     | Ratio  | Samples  | Samples  | Samples  | Samples  | Samples  |
     +========+==========+==========+==========+==========+==========+
     |  1/3   | 1.93e+01 | 3.85e+02 | 7.66e+03 | 1.52e+05 | 3.03e+06 |
     +--------+----------+----------+----------+----------+----------+
     |  1/5   | 1.25e+01 | 1.59e+02 | 2.01e+03 | 2.54e+04 | 3.22e+05 |
     +--------+----------+----------+----------+----------+----------+
     |  1/7   | 1.13e+01 | 1.29e+02 | 1.47e+03 | 1.67e+04 | 1.90e+05 |
     +--------+----------+----------+----------+----------+----------+
     |  1/9   | 8.54e+00 | 7.32e+01 | 6.25e+02 | 5.32e+03 | 4.52e+04 |
     +--------+----------+----------+----------+----------+----------+
     |  1/10  | 5.83e+00 | 3.34e+01 | 1.89e+02 | 1.07e+03 | 6.04e+03 |
     +--------+----------+----------+----------+----------+----------+
     |  1/15  | 3.21e+00 | 9.57e+00 | 2.79e+01 | 8.05e+01 | 2.31e+02 |
     +--------+----------+----------+----------+----------+----------+
        

Table 2: Khronos Improvement

表2:クロノスの改善

In addition to evaluating the probability of an attacker successfully shifting time at the client's clock, we also evaluated the probability that the attacker succeeds in launching a DoS attack on the servers by causing many clients to enter panic mode (and querying all the servers in their local Khronos pools). This probability (with the previous parameters of n=500, m=15, w=25, and K=3) is negligible even for an attacker who controls a large number of servers in clients' local Khronos pools, and it is expected to take decades to force a panic mode.

攻撃者がクライアントの時計で正常にシフトする確率を評価することに加えて、攻撃者が多くのクライアントがパニックモードに入る(そして彼らのすべてのサーバーをクエリすることでサーバーへのDOS攻撃を起動することに成功する確率も評価しました。地元のクロノスプール)。この確率(n = 500、m = 15、w = 25、およびk = 3の以前のパラメーターを使用)は、クライアントのローカルクロノスプールで多数のサーバーを制御する攻撃者でも無視できます。パニックモードを強制するために数十年かかります。

Further details about Khronos's security guarantees can be found in [Khronos].

クロノスのセキュリティ保証の詳細については、[クロノス]に記載されています。

6. Khronos Pseudocode
6. Khronos Pseudocode

The pseudocode for Khronos Time Sampling Scheme, which is invoked in each Khronos poll interval, is as follows:

各クロノスの世論調査間隔で呼び出されるクロノス時間サンプリングスキームの擬似コードは次のとおりです。

   counter = 0
   S = []
   T = []
   While counter < K do
      S = sample(m) //get samples from (tens of) randomly chosen servers
      T = bi_side_trim(S,1/3) //trim lowest and highest thirds
      if (max(T) - min(T) <= 2w) and (|avg(T) - tk| < ERR + 2w), then
          return avg(T) // Normal case
      end
      counter ++
   end
   // panic mode
   S = sample(n)
   T = bi-sided-trim(S,1/3) //trim lowest and highest thirds
   return avg(T)
        

Note that if clock disciplines can be called during this pseudocode's execution, then each time offset sample, as well as the final output (Khronos time offset), should be normalized with the sum of the clock disciplines offsets (tk) at the time of computing it.

この擬似コードの実行中にクロック懲戒を呼び出すことができる場合、その時点でオフセットサンプルと最終出力(クロノスタイムオフセット)は、計算時のクロック分野のオフセット(TK)の合計で正規化する必要があることに注意してください。それ。

7. Precision vs. Security
7. 精度とセキュリティ

Since NTPv4 updates the clock at times when no time-shifting attacks are detected, the precision and accuracy of a Khronos client are the same as NTPv4 at these times. Khronos is proved to maintain an accurate estimation of the UTC with high probability. Therefore, when Khronos detects that client's clock error exceeds a threshold (H), it considers it to be an attack and takes control over the client's clock. As a result, the time shift is mitigated and high accuracy is guaranteed (the error is bounded by H).

NTPV4は、タイムシフト攻撃が検出されない場合にクロックを更新するため、クロノスクライアントの精度と精度は、これらの時点でNTPV4と同じです。クロノスは、高い確率でUTCの正確な推定を維持することが証明されています。したがって、クロノスがクライアントのクロックエラーがしきい値(h)を超えることを検出すると、それが攻撃であると見なされ、クライアントのクロックを制御します。その結果、時間シフトが軽減され、高精度が保証されます(エラーはHによって境界を獲得します)。

Khronos is based on crowdsourcing across servers and regions, changes the set of queried servers more frequently than NTPv4 [Khronos], and avoids some of the filters in NTPv4's system process. These factors can potentially harm its precision. Therefore, a smoothing mechanism can be used where instead of a simple average of the remaining samples, the smallest (in absolute value) offset is used unless its distance from the average is higher than a predefined value. Preliminary experiments demonstrated promising results with precision similar to NTPv4.

Khronosは、サーバーと地域全体のクラウドソーシングに基づいており、NTPV4 [Khronos]よりも頻繁にクエリサーバーのセットを変更し、NTPV4のシステムプロセスの一部のフィルターを回避します。これらの要因は、その精度を潜在的に害する可能性があります。したがって、残りのサンプルの単純な平均の代わりに、平均からの距離が事前定義された値よりも高い場合を除き、最小の(絶対値)オフセットが使用される場合、平滑化メカニズムを使用できます。予備的な実験では、NTPV4と同様の精度で有望な結果が示されました。

In applications such as multi-source media streaming, which are highly sensitive to time differences among hosts, note that it is advisable to use Khronos at all hosts in order to obtain high precision, even in the presence of attackers that try to shift each host in a different magnitude and/or direction. Another approach that is more efficient for these cases may be to allow direct time synchronization between one host who runs Khronos to others.

ホスト間の時間の違いに非常に敏感なマルチソースメディアストリーミングなどのアプリケーションでは、各ホストをシフトしようとする攻撃者の存在下であっても、高精度を得るためにすべてのホストでクロノスを使用することをお勧めします異なる大きさや方向。これらのケースにより効率的な別のアプローチは、クロノスを他の人に実行する1人のホスト間で直接時間同期を許可することです。

8. IANA Considerations
8. IANAの考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションがありません。

9. References
9. 参考文献
9.1. Normative References
9.1. 引用文献
   [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>.
        
   [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>.
        
   [RFC8033]  Pan, R., Natarajan, P., Baker, F., and G. White,
              "Proportional Integral Controller Enhanced (PIE): A
              Lightweight Control Scheme to Address the Bufferbloat
              Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017,
              <https://www.rfc-editor.org/info/rfc8033>.
        
   [RFC8915]  Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
              Sundblad, "Network Time Security for the Network Time
              Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
              <https://www.rfc-editor.org/info/rfc8915>.
        
9.2. Informative References
9.2. 参考引用
   [Ananke]   Perry, Y., Rozen-Schiff, N., and M. Schapira, "A Devil of
              a Time: How Vulnerable is NTP to Malicious Timeservers?",
              Network and Distributed Systems Security (NDSS) Symposium,
              Virtual, DOI 10.14722/ndss.2021.24302, February 2021,
              <https://www.ndss-symposium.org/wp-content/uploads/
              ndss2021_1A-2_24302_paper.pdf>.
        
   [Khronos]  Deutsch, O., Rozen-Schiff, N., Dolev, D., and M. Schapira,
              "Preventing (Network) Time Travel with Chronos", Network
              and Distributed Systems Security (NDSS) Symposium, San
              Diego, CA, USA, DOI 10.14722/ndss.2018.23231, February
              2018, <https://www.ndss-symposium.org/wp-
              content/uploads/2018/02/ndss2018_02A-2_Deutsch_paper.pdf>.
        
Acknowledgements
謝辞

The authors would like to thank Erik Kline, Miroslav Lichvar, Danny Mayer, Karen O'Donoghue, Dieter Sibold, Yaakov (J) Stein, Harlan Stenn, Hal Murray, Marcus Dansarie, Geoff Huston, Roni Even, Benjamin Schwartz, Tommy Pauly, Rob Sayre, Dave Hart, and Ask Bjorn Hansen for valuable contributions to this document and helpful discussions and comments.

著者は、Erik Kline、Miroslav Lichvar、Danny Mayer、Karen O'Donoghue、Dieter Sibold、Yaakov(J)Stein、Harlan Stenn、Hal Murray、Marcus Dansarie、Geoff Huston、Roni EvEn、Benjamin Schwartz、Tommy Pauly、Rob Sayre、Dave Hart、およびBjorn Hansenに、この文書への貴重な貢献と有益な議論やコメントを求めてください。

Authors' Addresses
著者のアドレス
   Neta Rozen-Schiff
   Hebrew University of Jerusalem
   Jerusalem
   Israel
   Phone: +972 2 549 4599
   Email: neta.r.schiff@gmail.com
        
   Danny Dolev
   Hebrew University of Jerusalem
   Jerusalem
   Israel
   Phone: +972 2 549 4588
   Email: danny.dolev@mail.huji.ac.il
        
   Tal Mizrahi
   Huawei Network.IO Innovation Lab
   Israel
   Email: tal.mizrahi.phd@gmail.com
        
   Michael Schapira
   Hebrew University of Jerusalem
   Jerusalem
   Israel
   Phone: +972 2 549 4570
   Email: schapiram@huji.ac.il