Hi Dave,
Thanks for your comments.
Please see my reply inline below (this time in purple).
Best,
Neta
On Mon, Jul 3, 2023 at 3:31 PM Dave Hart <davehart@xxxxxxxxx> wrote:
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.
>> a sole upstream provider will also have to forward all the panic mode queries so it could also just generate them by itself if it’s purpose is to flood the pool servers.
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.
>> DNS queries are only used when building the local pools and then stop, compared to NTP which performs a DNS query each polling interval. Moreover, Khronos DNS queries will enjoy the same cache used by NTP, so it is enough even a single other host of the ISP performed an NTP query in the last 150 secs, to save a query to all others. I still believe the DNS load will not increase significantly.
>> 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.
>> Panic mode will only occur under a very specific attack (when some attacker controls large portions of the pool or for a specific victim controls the traffic to most of the pool) and in this scenario, I am not sure that the extra NTP load is the main issue to consider.
Cheers,Dave Hart
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
