3 ms·
Stupid decision by SC for sure, but is there a reason there is no rate-limiting on the NTP servers? I'm not up to date on their structure. Maybe it's just not f
by CaptSpify 10y ago
Stupid decision by SC for sure, but is there a reason there is no rate-limiting on the NTP servers? I'm not up to date on their structure. Maybe it's just not feasible because they don't synchronize clients?
- dfox 10y agoEven without thinking about storing some context, replying to NTP request is probably similarly expensive as evaluating whether it should be rate limited.
- coderholic 10y agoYeah exactly this. Rate limiting isn't free. It's almost certainly more expensive to rate limit than to statelessly respond with the time.
- paulgear 10y agoNTP does store context for a limited number of clients (600 by default). https://www.eecis.udel.edu/~mills/ntp/html/miscopt.html https://www.eecis.udel.edu/~mills/ntp/html/miscopt.html
- devicenull 10y agoThe NTP servers are all run by random members of the community. There's no real coordination between them (outside of being part of the pool), so you can't really rate limit between servers. The library was only doing a couple request per NTP server, so rate limiting really wouldn't have helped.
- paulgear 10y agoNTP has rate limiting built into the protocol (https://www.eecis.udel.edu/~mills/ntp/html/accopt.html https://www.eecis.udel.edu/~mills/ntp/html/accopt.html), but Snapchat appear to be using a large list of servers. Also, NTP runs on UDP rather than TCP, and it only requires one packet from each party to exchange time, so it's harder to rate-limit it without making your server unreliable.
- takeda 10y agoRate limiting can only control number of responses issued by the server, it won't help reduce number of incoming UDP requests. NTP has KOD (Kiss of Death) which was meant for that situation, but it is often ignored/not handled properly by applications :/