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

[Hal Murray <[e-mail]>]

Thanks.

> In my tests responding to 25% of requests seems to be sufficient for clients
> like ntpd to keep the clock synchronized, although not very well. 

> The server needs to respond to some constant percentage of the requests and
> select them randomly. The attacker would need to send requests at a much
> higher rate in order to overload the network or the server to actually reduce
> the rate of responses that the victim gets. Doing that for a larger number of
> servers like pool.ntp.org would be impractical. 

If we let 25% of the bad traffic through, we have opened up the server for use 
as a reflector.  The bad guy will just have to find 3 other servers to get the 
same amount of traffic through.


[putting IP Address into cookie]
> Yes, that would help. The drawback is that the clients would need to restart
> NTS-KE after moving to a different network. 

Maybe that's the price we will have to pay for not letting NTP servers be used 
as reflectors.

Servers and workstations/PCs don't change IP Addresses very frequently.

For laptops, we could reduce the load by making the client store sets of 
cookies per IP Address.  That would cover the common case of a laptop that 
migrates from home to work each day.  I don't know enough about typical use 
cases for portable systems to go much farther than that.

The client could run in no-check-address mode until they lost a string of 
packets, aka appeared to be under attack, then switch to check-address mode.



-- 
These are my opinions.  I hate spam.