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

Miroslav Lichvar <> Thu, 05 August 2021 06:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2DC743A1150 for <>; Wed, 4 Aug 2021 23:53:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4HYC8ps81E7i for <>; Wed, 4 Aug 2021 23:53:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56BF63A1151 for <>; Wed, 4 Aug 2021 23:53:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20190719; t=1628146415; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XBtsfN3Fg+dVjHFRjPJLlFPlmgZ3lfPka7rLYbOs45U=; b=YDAjDuJ645FL+o2w+xg3KZRpAs/tlP7rpiBLRG27BT6dzJJiGVKAGCr4GEJq4oHcwzB6la 9YZnaDbECo+f4/YJYRnerCkkyic1hEoUh5+LSfZZP4mN4cW7Rpiwh0pS5TBciZ53PKVLOC s5DYADZ2fwwQBmyTcA7GlnFaRPnLBMM=
Received: from ( []) (Using TLS) by with ESMTP id us-mta-298-95Vw0PqnNKCIdQBu0v7rWA-1; Thu, 05 Aug 2021 02:53:32 -0400
X-MC-Unique: 95Vw0PqnNKCIdQBu0v7rWA-1
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C98E87122E; Thu, 5 Aug 2021 06:53:31 +0000 (UTC)
Received: from localhost ( []) by (Postfix) with ESMTPS id F1EAB27CA1; Thu, 5 Aug 2021 06:53:27 +0000 (UTC)
Date: Thu, 5 Aug 2021 08:53:26 +0200
From: Miroslav Lichvar <>
To: Harlan Stenn <>
Cc: Ulrich Windl <>, "" <>,
Message-ID: <YQuK5gqaxay/xR93@localhost>
References: <> <> <> <> <> <> <> <> <YQegwC/8qioEWJ/P@localhost> <>
MIME-Version: 1.0
In-Reply-To: <>
X-Scanned-By: MIMEDefang 2.84 on
Authentication-Results:; auth=pass smtp.auth=CUSA124A263
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Archived-At: <>
Subject: Re: [Ntp] =?utf-8?q?Antw=3A_Re=3A_Antw=3A_=5BEXT=5D_Re=3A_WGLC_on_dr?= =?utf-8?b?YWZ04oCRaWV0ZuKAkWFsdGVybmF0aXZl4oCRcG9ydOKAkTAx?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Aug 2021 06:53:42 -0000

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 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