Re: [Ntp] I-D Action: draft-ietf-ntp-alternative-port-00.txt

[Steven Sommars <[e-mail]>]

As the problems with blocking and rate-limiting are not specific to
NTS-protected NTP packets, I think it would be nice to provide a
workaround for all servers and clients, not just those that are using
NTS. I don't think we can expect NTS to be instantly adopted everywhere.

Should blocking and rate limiting considerations be added to the NTP
specifications?  If so where?
Some hardware-based (e.g., FPGA) NTP implementations can handle 10Gbps of
traffic, yet lack rate limiting mechanism.

The immediate effect of the alternate port is to bypass the current NTP
filtering that can break NTS and that is currently causing problems for the
NTP pool.
I'm concerned that adding NTP(RFC5905) to ALTPORT may lead to ISP filtering
of those UDP packets as well.

Do you suggest to reword the abstract to mention only that it makes NTP
amplification-free?

That's the most it can do since with the current draft reflection attacks
are still possible.
[Using  ALTPORT=NTS-only would prevent reflection attacks.]

Maybe we could at least say that the number of servers dropped due to
the attacks, no matter why exactly were the servers removed? The graph
at this page clearly shows when it started:

https://www.ntppool.org/zone

That's probably the best available reference.  For NTP WG email history
here are two consequences of excessive NTP drops of the NTP Pool monitoring
system probe packets.
1) Servers are deemed unreachable/poorly reachable and are temporarily
removed from the NTP Pool
2) The volunteers offering their hosts as NTP Pool servers receive many
email notifications of poor reachability and eventually drop out of the NTP
Pool.