Re: [Ntp] [EXT] Re: NTPv5 KISS code support

[Miroslav Lichvar <[e-mail]>]

On Fri, Nov 03, 2023 at 07:47:22AM -0700, Hal Murray wrote:
> The second case is bad guys or broken software.  Broken software isn't going 
> to pay any attention to anything.  Bad guys can use UDP with a forged source 
> address to DoS a victim.
> 
> We have decided not to allow amplification.  Do we need rate limiting too?

NTPv5 shouldn't prevent rate limiting, but maybe it should provide
some guidance on how it should work to avoid security issues. If the
server completely stops responding to an address when it gets too many
request over an interval (I think the ntp.org implementation still
does this), it is a security issue (denial of service) which can be
exploited by attackers sending requests with spoofed source address at
the rate which triggers rate limiting. Instead, the server should
always respond to some fraction of requests selected randomly, so the
victim always gets some responses.

I think the main use case for rate limiting is saving network traffic
costs on broken clients. Anyone running a public server knows how
annoying these clients are. On my servers I set the rate limiting
threshold to 128 requests per second.

The Daniel's idea to provide clients with two values, a long-term
average interval and additionaly a short-term burst interval is
interesting.

-- 
Miroslav Lichvar