On Jul 15, 2023, at 01:18, Danny Mayer <mayer@xxxxxxxxxxxxxxxxx> wrote:
Can this be added to the security considerations section of the
draft?
Definitely. I’ll do that.
Best, Michael
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 see
https://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 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
|
