Can this be added to the security considerations section of the draft?
Danny
On 7/11/23 3:03 PM, Michael Schapira
wrote:
Hi everyone,
Following up on the above discussion, I wanted to point out that the load on NTP servers induced by Khronos is something that we have extensively analyzed, both theoretically and empirically. Please seehttps://www.michaelschapira.com/_files/ugd/3b1e1e_278d283d14bf4dc994128eb4be88484a.pdf for a detailed analysis. In fact, respecting today's load distribution is one of the requirements (see VI.A. therein). Importantly, *our analysis already takes into account the weighting of servers, as mentioned by Miroslav, and does not assume equal distribution of load* (VI.B+C). Recall that most NTP queries in our solution are made in NTPv4 mode, and so, of course, adhere to the weight distribution, whereas Khronos (watchdog) queries are more rare (see detailed analysis in the publication).
I want to highlight the following conclusions from the analysis:
- So long as panic mode isn't triggered, the overhead is negligible. In fact, even querying servers by Khronos 100x less frequently than NTPv4 yields substantial security benefits (VI.F.). If the attacker does not have man-in-the-middle (MitM) capabilities with respect to the communications between a Khronos client and a large fraction of the NTP servers in Khronos' pool (say 1/4), the probability of triggering a panic mode for that client even *a single time* is effectively non-existent (see analysis in https://www.cs.huji.ac.il/w~neta/ndss18-final231.pdf.
- We are left with the case of an attacker with MitM capabilities with respect to the communication between *each and every* client in *a large group of clients* (otherwise the load is not high) and *a large fraction* of all NTP servers in the Khronos pool. Even in this extreme scenario, the load can be kept low. This is because panic mode triggers are separated by multiple (the configurable parameter k in Khronos), infrequent, "regular" querying rounds. So, the attacker would not only have to maintain the attack for a very long time, but would also have limited impact (if k is set to be sufficiently high). We will clarify this point in the draft.
(As a side note, if an attacker is, in fact, capable of surpassing the very high bar presented in the previous bullet, that means that either the attacker is physically present a large ISP's egress point(s), or is launching an elaborate attack like BGP hijacking of multiple IP addresses. If an attacker is that powerful there are bigger concerns (and attack strategies for the attacker) than overloading the NTP pool :).
I hope this clarifies some of the technical aspects.
Best,Michael
On Tue, Jul 11, 2023 at 3:13 PM Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:
On Tue, Jul 11, 2023 at 12:21:44PM +0300, Tal Mizrahi wrote:
> Specifically, this concern about Khronos is addressed in the current
> version of the draft (as you indeed noted):
> While Khronos
> queries around 3 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.
The last sentence in the quoted paragraph actually points out another
problem. The servers in pool.ntp.org are not supposed to share the NTP
traffic equally. The owners set a connection speed for each NTP server
according to their traffic and CPU limits. It sets a weight of the
address on the DNS server. There is a 1:2000 ratio between the slowest
and fastest servers.
If a significant portion of the clients implement Khronos as currently
specified, it will effectively equalize the weights and increase
traffic to slower servers, which might force their owners to remove
them from the pool and decrease its global capacity.
--
Miroslav Lichvar
_______________________________________________ ntp mailing list ntp@xxxxxxxx https://www.ietf.org/mailman/listinfo/ntp
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
