[Ntp] Re: [EXT] Re: NTPv5 Requirements vs. NTPv5 Spec

[Miroslav Lichvar <[e-mail]>]

On Tue, Jun 24, 2025 at 11:38:45PM -0500, Richard Laager wrote:
> Maybe repeated KoD should result in the client giving up? On the other hand,
> is that worthwhile? If the client got the server's IP from DNS (pool or
> otherwise), presumably that entry has changed or been removed. So if the
> client just re-resolves every so often, that solves the whole thing anyway.
> If the IP has been hardcoded in the configuration, I suppose a KoD can
> reduce the amount of queries, but it's never going to be able to make it
> stop completely. Even if the client NTP daemon stopped querying, once that
> daemon restarts, the config is still there and it'll start again.

Some existing (S)NTPv4 clients save the address of the server that
responded with a DENY/RSTR KoD to a file and will not poll it again
until the admin removes the file. That follows RFC 5905, but it's not
very practical. Even if it was a genuine/authenticated response and
the server does not change its policy, the IP address could change the
owner and there might be a public server running again at some point
in the future.

>From the client's point of view, if it doesn't have any other addresses
to try, it can either give up completely, or poll the address at a
reduced rate, hoping it will start working again.

> So probably the KoD => "minimum allowed interval" + a MUST to re-resolve DNS
> every week or two is sufficient.

Should it really be a MUST? That feels too strong to me.

Also, can we make any recommendations for the maximum accepted poll value
(the minimum allowed interval)? I think it should depend on whether
the response is authenticated. Accepting a poll of 25 (~1 year) from an
unauthenticated response is almost certainly wrong. Even for an
authenticated response it should be limited to maybe at most to 18 (~3
days)?

> From what I've seen as a victim, the amplification is generally mode 7 (and
> maybe mode 6) replies. For example, (maybe only) monlist.

Do you have a capture of the traffic you could check? It would be very
interesting to see what modes and commands are now used in the
amplification attacks.

-- 
Miroslav Lichvar