Kiss of Death packet is sent by the server when multiple NTP client packets are received with less spacing than two seconds in between. This is the case when “kod” parameter is in the configuration of the NTP server. At the time of standardizing that rule the (probably just implicit) assumption was that there is only one single NTP client behind one client IP address. I believe that this assumption is less and less true due to the widespread use of NAT. Client packets may interleave from multiple, different NTP clients behind the same NATed IP address, without respect of the required two seconds spacing in between.
I do not put the kod option in the configuration of the NTP servers I am managing. What is your take on that?
The system here may be affected by that, but the two second timeout may be to long ?. Ideally, a more granular approach might feature a system tunable to set that to lower value, or count the number from the same ip before sending a kod or dropping packets ?..
I disabled limited for the same reason, but afaics, kod needs limited to function, so it does nothing, included or not. Don’t restrict version and have seen a few ntp v1 clients in the tcpdump screen. Never knew that even existed…
Most clients don’t understand a KoD response. It can actually cause them to quickly send another request, which increases the traffic, opposite of what it is supposed to do. There is one case where I found it useful though. When decommissioning a server, I let it respond, but only for few hours, to all requests with KoD RATE and a large poll value. This greatly reduces the amount of traffic from old ntpd clients, which don’t switch to a different server when it becomes unreachable, but at least they can lower their polling rate to become insignificant.
This is a very interesting discussion. I hope it will result in a recommendation that will replace the current one on https://www.ntppool.org/join/configuration.html, because I do feel it is important that all participants of the pool are (more or less) on the same page.
By the way, I’ve seen cases where (non-spoofed) IP’s kept on hammering, even when I briefly disabled rate limiting.