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

[Hal Murray <[e-mail]>]

> 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. 

UDP request-response is about as simple a protocol as you can get.  I find it 
amusing how complicated such a simple protocol can get.

Suppose the bad guys are trying to DoS somebody by sending enough forged 
requests to trigger rate limiting.

How did the bad guy figure out which servers the victim is using?  Can we 
fight that by using a few more?

Will responding to some requests be good enough?
What fraction of requests need to get answered for NTP to "work"?

Do the numbers work?  If the bad guy sends 1 packet per second and the victim 
sends 1 packet every 64 seconds and the server responds to 1 packet per 
second, the victim gets 1/2 or 1/65 depending on implementation details.  The 
bad guy can reduce the odds by sending faster.  This is an arms race.


I think we can fix this by adding an option to NTS to include the client's IP 
Address in the cookie.  That would let the server split rate limiting into 2 
piles, one for requests with a verified source, and the other for everybody 
else.


Note that if an NTS client misses 8 responses in a row and doesn't reuse 
cookies, then the NTS-KE server will get increased traffic.


-- 
These are my opinions.  I hate spam.