---
tags: Time, Ethereum2.0
---
# Potential NTP pool attack

Beacon chain protocol assumes validator clocks are roughly synchronized, e.g. [fork choice specs](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#fork-choice) states:
> **Honest clocks**: Honest nodes are assumed to have clocks synchronized within SECONDS_PER_SLOT seconds of each other.

No mechanism to assure the assumption is specified, however. Thus, it's a validator responsibility. It's highly probable that many validators will use [NTP](https://en.wikipedia.org/wiki/Network_Time_Protocol) to synchronize their clocks to the world standard (i.e. UTC), since it's an easy to set up and alternatives can be expensive.

Then, it's also highly probable that such NTP setups will be using [NTP pool](https://www.pool.ntp.org/en/). An excerpt from the [NTP pool page](https://www.pool.ntp.org/en/):
> The pool is being used by hundreds of millions of systems around the world. It's the default "time server" for most of the major Linux distributions and many networked appliances

Or they can users servers from other public NTP server lists, e.g. http://support.ntp.org/bin/view/Servers/WebHome.

The NTP pool is free to enter (an excerpt from the the NTP pool page):
> Because of the large number of users we are in need of more servers. If you have a server with a static IP address always available on the internet, please consider adding it to the system.

THis can result in an implicit dependency of the beacon chain on the NTP pool (and/or other public NTP lists), if validator are not careful enough in configuring their NTP servers.

Such situation creates an opportunity for a [Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack) on the beacon chain protocol, under certain conditions. I.e. an adversary can populate the NTP pool (or any public NTP server list) with lots of Byzantine-faulty NTP servers, which will report wrong time to validator nodes.

NTP protocol can tolerate certain errors, e.g. detect "falsetickers", by comparing results form several NTP servers. However, in case there are many faulty NTP servers in the pool, there is a high probability that a correct server will look as a "falseticker".

NTP pool servers are also monitored by the pool software. However, if the adversary knows IP addresses of beacon chain protocol participants, its faulty NTP servers can report wrong time results only to clients which IP addresses in the list. This is why the NTP servers controlled by the adversary are considered as Byzantine-faulty (two-faced clocks).

If few validators' clocks are distorted by such an attack then beacon chain protocol can tolerate it. However, the key problem with the scenario is that many validators can be vulnerable to the attack, if they are not careful enough when setting NTP up. So, multiple correlated faults can be induced alone or together with other means to attack the beacon chain protocol.
E.g. p2p-inteface spec prescribes to [delay early messages](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/p2p-interface.md#global-topics), then such an attack can be used to delay or break message flow in the beacon chain p2p graph.
Note, that as non-validator nodes can participate in the p2p graph, then they can be used to attack the beacon chain protocol too.

The attack is described in more details in a separate [document](https://hackmd.io/X-uvqwe8TkmR-CJqMdfn6Q#NTP-level-attacks).

It's relatively easy to withstand the attack, e.g. beacon chain participants should be careful when configuring NTP. However, if it's risky to use NTP servers from public NTP server lists, where should they obtain NTP servers?

Using NTP servers controlled by big corporations, non-profit or government agencies can be a possibility, however, it can lead to a similar correlated implicit dependency and lack of decentralization. Which maybe not desirable for various reasons.

Wealthy validators can set up their own time servers, however it increases significantly an entry barrier to run a validator node.

We will elaborate in more details on possible ways of reliable clock synchronization in another document, including BFT clock synchronization solutions and/or anonymous access to public time services (e.g. GNSS, Radio clocks, public NTP servers, etc).

The main goal of the issues is to warn Ethereum 2.0 implementers and researchers that it can be dangerous to rely on the default NTP setup and public NTP server pools and lists.
It's also dangerous to assume most validators can set up NTP/time service in a secure manner.
Thus, it's a risk to the overall beacon chain protocol.

As very minimal counter-measures, we propose:
- add a warning somewhere in the beacon chain specs, clarifying that using a mis-configured NTP can implicitly introduce centralization and this can be dangerous to the beacon chain protocol security.
- the details of the warning are too be defined, but they should include typical problematic cases:
- using NTP pool can be dangerous
- using servers from public NTP lists can be dangerous
- possibly, certain public NTP servers (e.g. operated by big organizations) can be used, if they are accessed anonymously, in the sense that validator should use some different IP address to synchronize time, so that NTP server cannot detect that it's a validator
- establish guidelines on NTP setup

These minimal counter-measures are hardly enough, so the best solution would be to design BFT clock synchronization protocol, so that validator and non-validator node administrators are relieved from the secure Time Service setup burden.
However, such BFT protocol can be prohibitively expensive given expected beacon chain protocol scale (thousands of nodes), so a cheaper solutions are to be investigated too.

We stress out that beacon chain protocol can tolerate limited number of validators with vulnerable NTP setups, so probably a separate BFT clock synchronization protocol can be excessive, if there exists a way to prevent correlated NTP-level failures.