doc: Add RFC documents

1 files changed, 699 insertions, 0 deletions

diff --git a/doc/rfc/rfc9523.txt b/doc/rfc/rfc9523.txt
new file mode 100644
index 0000000..edf66f9
--- /dev/null
+++ b/doc/rfc/rfc9523.txt
@@ -0,0 +1,699 @@
+
+
+
+
+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.
+
+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.
+
+   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.
+
+Copyright Notice
+
+   Copyright (c) 2024 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+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
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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'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 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:
+
+   *  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.
+
+   *  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.
+
+   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.
+
+   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.
+
+2.  Conventions Used in This Document
+
+2.1.  Terms and Abbreviations
+
+   NTPv4:  Network Time Protocol version 4.  See [RFC5905].
+
+   System process:  See the "Selection Algorithm" and the "Cluster
+      Algorithm" sections of [RFC5905].
+
+   Security Requirements:  See "Security Requirements of Time Protocols
+      in Packet Switched Networks" [RFC7384].
+
+   NTS:  Network Time Security.  See "Network Time Security for the
+      Network Time Protocol" [RFC8915].
+
+2.2.  Notations
+
+   When describing the Khronos algorithm, the following notation is
+   used:
+
+     +==========+====================================================+
+     | 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
+
+
+   The recommended values are discussed in Section 3.3.
+
+3.  Khronos Design
+
+   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.
+
+   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.
+
+   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.
+
+3.1.  Khronos Calibration - Gathering the Khronos Pool
+
+   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).
+
+   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.
+
+   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.
+
+3.2.  Khronos's Poll and System Processes
+
+   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'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).
+
+   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.
+
+   Khronos checks that the following two conditions hold for the
+   remaining sampled offsets (considering w and ERR defined in Table 1):
+
+   *  The maximal distance between every two offsets does not exceed 2w
+      (can be verified by considering just the minimum and the maximum
+      offsets).
+
+   *  The distance between the offset's average and the Khronos inter-
+      poll offset is ERR+2w at most.
+
+   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.
+
+   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.
+
+   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.
+
+   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).
+
+3.3.  Khronos's Recommended Parameters
+
+   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.
+
+   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's effect on precision and accuracy are discussed in Sections
+   5 and 7.
+
+4.  Operational Considerations
+
+   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).
+
+   Khronos can be used for devices that require and depend upon
+   timekeeping within a configurable constant distance from UTC.
+
+4.1.  Load Considerations
+
+   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.
+
+   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].
+
+   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.
+
+5.  Security Considerations
+
+5.1.  Threat Model
+
+   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]).
+
+   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),
+
+   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,
+
+   3.  a nation state with authority over the owners of NTP servers in
+       its jurisdiction, or
+
+   4.  an attacker capable of hijacking (e.g., through DNS cache
+       poisoning or BGP prefix hijacking) traffic to some of the
+       available NTP servers.
+
+   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.
+
+   Moreover, Khronos uses randomness to independently select the queried
+   servers in each poll interval, preventing attackers from exploiting
+   observations of past server selections.
+
+5.2.  Attack Detection
+
+   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.
+
+   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.
+
+5.3.  Security Analysis Overview
+
+   Time samples that are at most w away from UTC are considered "good",
+   whereas other samples are considered "malicious".  Two scenarios are
+   considered:
+
+   *  Scenario A: Less than two-thirds of the queried servers are under
+      the attacker's control.
+
+   *  Scenario B: The attacker controls more than two-thirds of the
+      queried servers.
+
+   Scenario A consists of two sub-cases:
+
+   1.  There is at least one good sample in the set of samples not
+       eliminated by Khronos (in the middle third of samples), and
+
+   2.  there are no good samples in the remaining set of samples.
+
+   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.
+
+   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].
+
+   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.
+
+
+     +========+==========+==========+==========+==========+==========+
+     | 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
+
+
+   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.
+
+   Further details about Khronos's security guarantees can be found in
+   [Khronos].
+
+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.
+
+7.  Precision vs. Security
+
+   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).
+
+   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.
+
+   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.
+
+8.  IANA Considerations
+
+   This document has no IANA actions.
+
+9.  References
+
+9.1.  Normative References
+
+   [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
+
+   [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.
+
+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