On Mon, 3 Jul 2023 at 02:28, Neta R S <neta.r.schiff@xxxxxxxxx> wrote:
Hi Ask,Thanks for your feedback.Please see my reply inline (in blue).Best,NetaOn Sun, Jun 25, 2023 at 1:23 PM Ask Bjørn Hansen <ask@xxxxxxxxxxxxxx> wrote:Collecting ntp data from 1000 NTP Pool servers (a third!) to get a single server “safely in sync” is a severe abuse of the system and If widely implemented will lead to the system falling apart and going away.>> First, 1000 was meant as an upper bound. Second, the actual NTP-queried servers are just a small subset (tens) of the pool.
...except in "panic mode", when Khronos queries all of them essentially simultaneously. I realize it is claimed that is exceptionally unlikely in practice, but it could be forced relatively easily by a MiTM, such as within a sole upstream provider.
If other sources of hundreds+ NTP servers are available I imaging the outcome for those will be similar.>> The random selection of the few queried servers out of the (considerably bigger pool) is what prevents an attacker from anticipating them in advance.>> With respect to DNS traffic, I think that most hosts share local DNS servers with others (e.g., in data centers, cloud and/or ISPs) and as a result the actual number of extra (uncached) queries reaching the DNS pool will be much lower than the worst case.For the NTP Pool, meaningfully increasing the number of DNS queries to the system would be the most immediate resource constraint on the system already run for pennies.Are there other use cases for this than NTP pool servers? Adding extra load on a “free for the good of the internet” system run by volunteers for some marginal local gain seems wildly inappropriate. Assuming “NTP available for everyone” is a goal of the NTP protocol putting it under extra strain seems foolhardy at best.
The TTL for pool.ntp.org responses is 150s. Caching reduces authoritative queries only marginally.
>> With respect to NTP traffic, while Khronos queries around 3 times more servers per polling interval compared to NTPv4 (around 12 instead of 4), we suggest, in the draft, to use 10 times longer polling interval. Therefore, I don’t expect a significant increment to NTP servers’ load. If that is still a concern, we may consider using more lightweight default configuration as part of Khronos implementation.
Again you seem to be overlooking Khronos panic mode, which is from my perspective the most serious concern, with DNS query load second on my list.
Cheers,
Dave Hart
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
