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

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 02 Aug 2021 08:02:16 +0200

>>> Hal Murray <[email-masked]> schrieb am 31.07.2021 um 07:18 in
Nachricht
<[email-masked]>:
>>  So how would using an alternative port make a difference?
> 
> Because the filters are looking for UDP port 123.  The smart ones do a 
> length 
> check and let 48 byte packets througg.  The dumb ones just nuke them all.

Hi!

I just wonder: Wouldn't rate limiting (or bandwidth limiting) be the correct
way to do?
I don't consider the smart solution to be smart actually.
Maybe even considering the input/output (request/response) ratio would be even
better.

Regards,
Ulrich

> 
> The recent discussion has focused on middleware.  It also happens on transit

> 
> links.
> 
> I have a pool server in London.  The monitoring station in the US frequently

> 
> kicks it out of the pool because it can't verify that it is responding.
> 
> We had significant troubles during the early NTS hackathons.  NTP packets 
> with 
> NTS extensions didn't get through.
> 
> 
> ‑‑ 
> These are my opinions.  I hate spam.
> 
> 
> 
> _______________________________________________
> ntp mailing list
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 2 Aug 2021 09:37:36 +0200

> I just wonder: Wouldn't rate limiting (or bandwidth limiting) be the correct

I think that's what they currently do. It effectively causes a DoS on
NTP. 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.

> Maybe even considering the input/output (request/response) ratio would be even

That would require tracking each address separately. Good luck doing
that at the network speeds the ISPs work with.

A more practical solution would be to specifically drop only NTP mode
6/7 packets, but even this functionality is missing in (most of?) the
hardware.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 4 Aug 2021 00:46:21 -0700

On 8/2/2021 12:37 AM, Miroslav Lichvar wrote:
> NTP.

I don't understand exactly what you mean here by "causes a DoS on NTP."
 Clarify, please?

> See the discussions at community.ntppool.org. Large numbers of

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.

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 5 Aug 2021 08:53:26 +0200

> I don't understand exactly what you mean here by "causes a DoS on NTP."

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.

> already the monitoring system needs to know this, and rank the target

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

---

From: Doug Arnold <[email-masked]>
Date: Thu, 5 Aug 2021 14:26:35 +0000

Miroslav is correct.  Once network appliances are deployed in the field, then some instances that still behave this way with respect to port 123 will be around for many years to come.

Doug

From: ntp <[email-masked]> on behalf of Miroslav Lichvar <[email-masked]>
Date: Thursday, August 5, 2021 at 2:53 AM
To: Harlan Stenn <[email-masked]>
Cc: Ulrich Windl <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Ntp] Antw: Re: Antw: [EXT] Re: WGLC on draft‑ietf‑alternative‑port‑01

--
Miroslav Lichvar