Re: [Ntp] Antw: Re: Antw: [EXT] Re: WGLC on draft‑ietf‑alternative‑port‑01

[Miroslav Lichvar <[e-mail]>]

On Wed, Aug 04, 2021 at 12:46:21AM -0700, Harlan Stenn wrote:
> On 8/2/2021 12:37 AM, Miroslav Lichvar wrote:
> > On Mon, Aug 02, 2021 at 08:02:16AM +0200, Ulrich Windl wrote:
> >> I just wonder: Wouldn't rate limiting (or bandwidth limiting) be the correct
> >> way to do?
> > 
> > I think that's what they currently do. It effectively causes a DoS on
> > NTP.
> 
> I don't understand exactly what you mean here by "causes a DoS on NTP."
>  Clarify, please?

Rate limiting of NTP packets can cause a denial of the NTP service for
legitimate clients. They don't get a response to their requests and
cannot synchronize their clock. It doesn't matter if the rate limiting
is happening on the server or some middlebox in the network.

> > See the discussions at community.ntppool.org. Large numbers of
> > servers are randomly rejected from the pool due to heavy packet loss
> > specific to port 123 on the path to the monitoring system.
> 
> If the target system is receiving too many packets and is dropping them
> already the monitoring system needs to know this, and rank the target
> accordingly.

It's not the server dropping packets. It's major ISPs specifically
rate limiting packets on the UDP port 123. If you run mtr in the UDP
mode on that port, you will see a huge packet loss on the boundary of
their network. If you change the port number, the loss immediately
disappears. It's not a congested network or overloaded server.

We can speculate if this would have happened if ntpd promptly fixed
the mode 6 to not amplify traffic, or at least changed the defaults to
not allow remote access. We probably won't ever know. The damage is
done. The port is no longer usable on the global scale. We need to
move to a different port and restrict it to the non-amplifying subset
of the protocol, so this doesn't happen again. That's what this draft
is trying to do.

-- 
Miroslav Lichvar