Hi Miroslav,
You are referring to a part of the paper that motivates the Khronos approach by examining the drawbacks of a strawman solution in which Khronos watchdog queries are as frequent as NTPv4's (under the title "A Failed Simple Server-Assignment Scheme"). The relevant discussion is from Section C onwards.
Khronos can certainly be used with normal pool zones without introducing meaningful overhead. No fast servers are required. The reason is that (1) Khronos queries are much rarer than NTPv4's (see analysis), and (2) even in the highly unlikely event that panic mode is triggered multiple times, the overhead is not significant because every two triggers must be separated by multiple "normal" (and infrequent) querying rounds (see my previous email).
(The paper I referred to does indeed propose using a *subet of the current* NTP pool for *further enhancing security*, but it does not impose any lower bounds on their speed, since the induced overhead is low, and, while this could make security even better, I believe should be the topic of a future RFC. :)
Best,
Michael
On Wed, Jul 12, 2023 at 9:13 AM Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:
On Tue, Jul 11, 2023 at 10:03:19PM +0300, Michael Schapira wrote:
> 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
It seems your own analysis in the paper agrees that this indeed is
a serious problem. Quoting from page 11:
Overloading timeservers. We show that, if deployed at scale,
the above discussed simple heuristic for assigning servers to
clients, runs into the risk of inducing significant deviations
from today’s load distribution, in which a large fraction of the
timeservers experiences over 200x increase in load. Intuitively,
this is because today’s practice of assigning timeservers to NTP
clients with probability that is proportional to their netspeed
values (see Section III-B) is at odds with Chronos’ uniform
distribution of load across large sets of servers, irrespective
of their netspeed values (which is needed for establishing its
security guarantees [6]). Consequently, if the sets of servers
with which Chronos clients synchronize, and the frequency
of synchronization, are not chosen with care, low-netspeed
servers will experience a huge surge in load.
This definitely needs to be explained in the Khronos draft and maybe
spell it out that Khronos must not be used with the normal zones in
pool.ntp.org. The paper proposes a solution using a special zone where
only selected fast servers are included, but that doesn't seem to
exist yet. I don't remember seeing it proposed on the project's
discourse (https://community.ntppool.org).
--
Miroslav Lichvar
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
