RFC 9523

A Secure Selection and Filtering Mechanism for the Network Time Protocol with Khronos

📅 published February 2024, from ietf

A Secure Selection and Filtering Mechanism for the Network Time Protocol with Khronos ⏰🎀

Okay bestie, this is RFC 9523 from the IETF (Internet Engineering Task Force) 💖. It was written by N. Rozen-Schiff, D. Dolev, and M. Schapira from the Hebrew University of Jerusalem, plus T. Mizrahi from the Huawei Network.IO Innovation Lab 🦋. It's an Informational doc, so it's published for information and isn't a Standards Track spec ✨. The ISSN is 2070-1721 and it came out in February 2024 🌸. The title block doesn't list anything it obsoletes or updates, so there's no drama there 💅.

Abstract 🌈

Okay so, NTPv4 is defined in RFC 5905, and it's the thing NTP clients use to sync up with NTP servers across the whole Internet 🌐. This doc describes a companion app for the NTPv4 client called "Khronos" 🧚. Khronos runs as a "watchdog" right alongside NTPv4 and gives you way better protection against time-shifting attacks 🛡️. It only changes the client's system process and never touches the wire protocol 💜. Since the wire protocol isn't affected, Khronos works for current and future time protocols, no cap 🔥.

Status of This Memo ⭐

This doc is not an Internet Standards Track spec. It's published just for information 📖.

It's a product of the IETF, so it represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✅. Not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 🙈.

If you want the current status, any errata, or a way to send feedback, go to https://www.rfc-editor.org/info/rfc9523 🍓.

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this doc 📜. Code Components pulled out of this doc must include the Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come 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 🦋

Okay, so NTPv4 (defined in [RFC5905]) is vulnerable to time-shifting attacks 😭. That's when an attacker shifts the clock of a network device. Time-shifting attacks on NTP clients can work by messing with the communication between the clients and servers, or by compromising the servers themselves 💀. They're still possible even when NTP communication is encrypted and authenticated 🙈. A weaker machine-in-the-middle (MITM) attacker can shift time just by dropping or delaying packets 🌪️. A powerful attacker with full control over an NTP server can do it by choosing exactly what the NTP response says 👑.

This doc introduces a time-shifting mitigation mechanism called "Khronos" ✨. Khronos can plug in as a background-monitoring app (a watchdog) that guards against time-shifting attacks in any NTP client 🐶. A client running Khronos is interoperable with NTPv4 servers that are compatible with [RFC5905] 🫶. Khronos doesn't affect the wire mechanism, so it works with any current or future time protocol, periodt 💅.

Khronos is a mechanism that runs in the background 🧚. It keeps an eye on the client clock (which NTPv4 updates) and calculates an estimated offset, called the "Khronos time offset" 👀. When that offset goes over a predefined threshold (set in Section 5.2), Khronos reads it as the client being under a time-shifting attack 🚨. In that case, Khronos updates the client's clock 🔧.

When the client isn't under attack, Khronos just chills in the background 😌. That lets NTPv4 keep control of the clock, so you still get the usual high precision and accuracy from NTPv4 💖. When there's an attack, Khronos takes over the clock. It mitigates the time shift while keeping relatively high accuracy with respect to UTC and precision, as covered in Section 7 🎯.

Khronos uses distributed computing theory techniques for time sync, so it gets accurate time even when powerful attackers directly control a large number of NTP servers 🧠. Khronos will stop the clock from being shifted as long as the ratio of compromised time samples is below 2/3 🛑. In each polling interval, a Khronos client randomly picks and samples a few NTP servers out of a local pool of hundreds 🎲. Khronos is carefully engineered to keep the load on NTP servers and the communication overhead low 🍃. NTPv4, on the other hand, typically relies on a small subset of the NTP server pool (like four servers) for sync, which makes it way more vulnerable to time-shifting attacks 😬. Configuring NTPv4 to use several hundreds of servers does boost its security, but it comes with very high network and computational overhead compared to Khronos. It's also bounded by a compromised ratio of half of the time samples 📉.

A Khronos client keeps "crowdsourcing" time queries across NTP servers over and over, and it uses a provably secure algorithm to throw out "suspicious" responses and average the rest 🧁. In each Khronos poll interval, the client uniformly-at-random picks a small subset (like 10-15 servers) from a big server pool (hundreds of servers) 🎰. Khronos queries around three times more servers per polling interval than NTP does. But Khronos's polling interval can be longer (like 10 times longer) than NTPv4's, which keeps the load on NTP servers and the communication overhead down 💫. Also, Khronos's random server selection might even help spread queries across the whole pool 🌍.

Khronos's security was checked both in theory and with a prototype implementation 🧪. According to that analysis, say a local Khronos pool has 500 servers, one-seventh of which are controlled by an attacker, and Khronos queries 15 servers each poll interval (around 10 times the NTPv4 poll interval). Then you'd need over 20 years of effort (in expectation) to successfully shift time at a Khronos client by over 100 ms from UTC 😱. The full formal analysis of this guarantee is at [Khronos] 📚.

Khronos keeps a time offset value (the Khronos time offset) and uses it as a reference for spotting attacks 🔍. This way of computing the time offset is different from current NTPv4 in two key ways:

  • First, in each Khronos poll interval, Khronos periodically talks to only a few (tens of) randomly chosen servers out of a pool of a large number (like hundreds) of NTP servers 🎲.
  • Second, Khronos computes the Khronos time offset with an approximate agreement technique that removes outliers. That limits the attacker's ability to contaminate the time samples (offsets) it gets from the queried NTP servers 🧹.

Together, these two things keep the load on NTP servers low and give provable security guarantees against both MITM attackers and attackers who can compromise a large number of NTP servers 🛡️💖.

We should note that Network Time Security (NTS) [RFC8915] can make MITM attacks harder for attackers to pull off to some extent 🔐. But it doesn't help much 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 we describe the Khronos algorithm, we use the notation below 🧮:

  +==========+====================================================+
  | 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 ✨

okay bestie, so Khronos picks a random set of m servers (like tens of them) out of a big pool of servers (hundreds) in every Khronos poll interval 🎲. Based on empirical analyses, the Khronos poll interval should be around 10 times the NTPv4 poll interval, so a Khronos clock update happens once every 10 NTPv4 clock updates. That keeps the load on NTP servers low while still being super secure 🔒. In each Khronos poll interval, if the Khronos time offset goes over a predetermined threshold (called H), an attack is indicated 🚨.

Unless an attack is indicated, Khronos only uses one sample from each server, so it skips the "Clock Filter Algorithm" from Section 10 of [RFC5905] 🙈. When it's under attack though, it grabs several samples from each server and runs the "Clock Filter Algorithm" to pick the best one, the one with low jitter 👀. Then, with a sample from each server, Khronos tosses out the outliers by running the procedure in Section 3.2. Iconic behavior honestly 💅.

Between consecutive Khronos polls, Khronos keeps track of clock offsets, for example by catching clock discipline calls (as in [RFC5905]) 🧚. The sum of offsets is called the "Khronos inter-poll offset" (tk), and it gets reset to zero after each Khronos poll ✨.

3.1. Khronos Calibration - Gathering the Khronos Pool

Calibration happens the first time Khronos runs and then again every two weeks 📅. This is where it builds a local Khronos pool of n (up to hundreds) NTP servers that the client can sync with 🫶. To do that, Khronos makes multiple DNS queries to the NTP pools. Each query returns a few NTP server IPs, and Khronos combines them all into one set of IPs, which becomes the Khronos pool 🌸.

The servers in the Khronos pool should be scattered across different regions. That makes it way harder for an attacker to compromise or get MITM capabilities over a large chunk of the pool 🌍. So calibration queries general NTP server pools (like pool.ntp.org) and not just the pool in the client's own state or region 🗺️. Servers can also be picked manually for the pool, or by using other NTP pools (such as NIST Internet time servers) 🎀.

The first Khronos update needs m servers, and those can be found in several minutes ⏱️. Also, querying several DNS pool names can vastly speed up the calibration and that first update, which is such a glow-up 🚀.

Calibration is the only part of Khronos that generates DNS traffic 📡. It takes around 125 DNS queries to get addresses of 500 NTP servers, which is more than the Khronos pool size (n) 🙌. If the calibration period is two weeks, the expected DNS traffic from the Khronos client is less than 10 DNS queries per day. That's usually several orders of magnitude lower than the total daily number of DNS queries per machine, so it's basically nothing 🦋.

3.2. Khronos's Poll and System Processes

In each poll interval, the Khronos system process randomly chooses m (tens) servers out of the n (hundreds) servers in the Khronos pool and samples them 🎰. The randomness of the server selection is crucial for the security of the scheme, so any Khronos implementation must use a secure randomness implementation, like what's used for encryption key generation 🔐. Main character energy for randomness, no cap 😤.

Polling times for different servers may spread uniformly within the poll interval, which is similar to NTPv4 ⏳. Servers that don't respond during the Khronos poll interval get 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. This is called the "resampling" process 🔄.

Next, out of the time samples from this chosen subset of servers, the lowest third of the offset values and the highest third of the offset values get discarded 🗑️. Then Khronos checks that these two conditions hold for the remaining sampled offsets (considering w and ERR from Table 1) 🧐:

  • The maximal distance between every two offsets does not exceed 2w (you can verify this by just considering the minimum and the maximum offsets).
  • The distance between the offset's average and the Khronos inter-poll offset is ERR+2w at most.

If both conditions are satisfied, the average of the offsets becomes the Khronos time offset ✅. Otherwise, resampling happens 🌀. This whole thing spreads the Khronos client's queries across servers, which improves security against powerful attackers (as discussed in Section 5.3) and helps with a DoS attack that would make NTP servers unresponsive 🛡️. Resampling keeps going in later Khronos poll intervals until both conditions are satisfied, or until the number of times the servers get resampled goes over a "panic trigger" (K in Table 1). When that happens, Khronos enters panic mode 😱.

In panic mode, Khronos queries all the servers in its local Khronos pool and orders the collected time samples from lowest to highest 📊. It eliminates the lowest third and the highest third of the samples, then calculates the average of what's left and sets that average as the new Khronos time offset 🧮.

If the Khronos time offset goes over a predetermined threshold (H), it gets passed to the clock discipline algorithm so it can 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. That could be a message written to a relevant event log or shown on screen 📢. Don't ignore that notification bestie 💀.

Resampling immediately follows the previous sampling, because waiting until the next polling interval may increase the time shift in the face of an attack ⚡. This shouldn't create 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) 🦋. Also, in an interval following a panic mode, Khronos runs the same system process, which starts by querying only m servers, no matter what happened before 🌈.

According to empirical observations (presented in [Khronos]), querying 15 servers at each poll interval (m=15) out of 500 servers (n=500), and setting w to be around 25 ms, gives both high time accuracy and good security 🎯. Specifically, when w=25 ms is selected, approximately 83% of the servers' clocks are at most w away from UTC and within 2w of each other. That satisfies the first condition of Khronos's system process 💯.

For a similar reason, the threshold for a Khronos time offset that triggers a clock update by Khronos (H) should be between w and 2w, and the default is 30 ms ⏲️. Also, to support scenarios with congested links, using a higher w value, such as 1 second, is recommended 🚦.

Furthermore, according to the Khronos security analysis, setting K to be 3 is safe when facing time-shifting attacks. That means if the two conditions aren't satisfied after three resamplings, Khronos enters panic mode 🛟. 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 is 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 🛡️. So, Khronos isn't really applicable for data centers and enterprises that sync with local atomic clocks, GPS devices, or a dedicated NTP server (for example, due to regulations) 🏢.

That said, Khronos can be used for devices that require and depend on 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 what NTPv4 does, even though it's widely integrated into NTP clients 🫶. Below, we talk about the possible causes of a Khronos-induced load on servers and how that can be mitigated 💖.

Servers in pool.ntp.org are weighted differently by the NTP server pool when they're assigned to NTP clients. 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 them less frequently than NTPv4, with the Khronos query interval set to 10 times the default NTPv4 maxpoll (interval) parameter 🐢. So 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] 📈.

Now consider the scenario where an attacker tries to generate significant load on NTP servers by triggering multiple consecutive panic modes at multiple NTP clients 😈. We note that to pull this off, 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 🕵️‍♀️. That means the attacker must either be physically located at a central location (like the egress of a large ISP), or launch a wide-scale attack (like on BGP or DNS). Either way, they're capable of carrying out similar, and even higher impact, attacks regardless of Khronos clients 🚨.

5. Security Considerations ✨

5.1. Threat Model 💖

okay bestie, the threat model is wide 🔥 It covers attackers messing with a subset (like one-third) of the servers in NTP pools. They range from a kinda weak (but still dangerous) MITM who can only delay and drop packets (think the Bufferbloat attack [RFC8033]) all the way up to an extremely powerful attacker who controls even the authenticated NTP servers and can fully decide the values of the time samples those servers return (see the 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 get abstracted away by thinking about attackers in terms of the fraction of servers they have adversarial capabilities over ✨ Attackers who can impact communications with (or control) a higher fraction of the servers (e.g., all servers) are out of scope. With the pool size across the world in the thousands, those attackers would most likely be able to do way 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 those measures in place, an attacker can still influence time by dropping or 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, which stops attackers from exploiting observations of past server selections 🎀

5.2. Attack Detection 🦋

Khronos detects time-shifting attacks by constantly monitoring the clock of NTPv4 (or potentially any other current or future time protocol) and the offset computed by Khronos, then checking whether that 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 so the clock can't be shifted 👑

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 successfully shifting a Khronos client's time by even a small degree (100 ms) takes many years of effort (over 20 years in expectation) 🌈 Here's 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 has 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, which makes 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. Those ratios are in Table 2, where higher values mean a bigger improvement of Khronos over NTPv4, and they're 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

Besides checking the odds of an attacker successfully shifting time on the client's clock, the authors 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 query all the servers in their local Khronos pools). With the previous parameters of n=500, m=15, w=25, and K=3, this probability 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 the 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 those times. Khronos is proved to maintain an accurate estimation of UTC with high probability. Therefore, when Khronos detects that the client's clock error exceeds a threshold (H), it considers that 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, 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 by 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 running Khronos and others 🦋

8. IANA Considerations 🌸

This document has no IANA actions.

9. References 💅

9.1. Normative References 🔥

9.2. Informative References 👑

Acknowledgements ✨

okay bestie, the authors gotta thank these legends 🫶 for their super valuable contributions, helpful discussions, and comments on this doc: 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. the squad really showed up 💖💅

Authors' Addresses 🌸

Meet the authors, who are literally the brains behind this whole thing 🧠✨

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

that's the whole document, bestie, you did it!! 🌈🧚

📦 where this page comes from