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

Danny Mayer <> Thu, 29 July 2021 14:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1CA6F3A24FE for <>; Thu, 29 Jul 2021 07:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gghARudjPalI for <>; Thu, 29 Jul 2021 07:47:52 -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 5B1693A24FF for <>; Thu, 29 Jul 2021 07:47:52 -0700 (PDT)
Received: from newusers-MBP.fios-router.home ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 4GbD0Q6nFvzMNW4; Thu, 29 Jul 2021 14:47:50 +0000 (UTC)
To: Ulrich Windl <>,,
Cc: Dieter Sibold <>, "" <>
References: <> <YNMbMd+3dDjAnIDP@localhost> <> <> <> <> <YP562akF+CL/9R5s@localhost> <> <>
From: Danny Mayer <>
Message-ID: <>
Date: Thu, 29 Jul 2021 10:47:49 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <>
Subject: Re: [Ntp] =?utf-8?b?QW50dzogW0VYVF0gUmU6ICBXR0xDIG9uIGRyYWZ04oCRaWV0?= =?utf-8?b?ZuKAkWFsdGVybmF0aXZl4oCRcG9ydOKAkTAx?=
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, 29 Jul 2021 14:47:55 -0000

On 7/29/21 3:08 AM, Ulrich Windl wrote:
>>>> Watson Ladd <> schrieb am 29.07.2021 um 05:12 in
> Nachricht
> <>om>:
>> On Mon, Jul 26, 2021 at 2:05 AM Miroslav Lichvar <>
> wrote:
>>> On Sun, Jul 25, 2021 at 07:46:28PM ‑0400, Danny Mayer wrote:
>>>> I have now come to the conclusion that this should NOT be accepted. Based
>> on
>>>> a conversation I had recently something like 70% of all traffic is still
>> NTP
>>>> V3 so this would not have any effect on them. Millions of firewalls
> would
>>>> need to be changed. While the idea is generally good, it's not
> practical.
>>> The draft is not specific to NTPv4. NTPv3 clients can be updated to
>>> use the alternative port too. On the public servers I'm running, with
>>> one exception (India), the observed NTPv3 share is below 10% anyway.
>>>> An easier and more practical proposal would be to remove mode 6 and 7
>>>> packets from the existing protocol and require that those types of
> packets
>>>> and information be done on a separate port or even use TCP.
>>> I don't see how would that be better. If you write a new document that
>>> forbids mode 6/7 on port 123, how will that fix the existing devices
>>> that still respond to it?
>>> It's now over 7 years since the large‑scale DDoS attacks started. If
>>> everyone fixed configuration of their devices to not respond to the
>>> modes, ISPs wouldn't be using the NTP rate‑limiting middleboxes and we
>>> wouldn't have this discussion.
>>> Port 123 seems to be doomed, at least for the near future. The
>>> alternative port gives us a way forward. Yes, the adoption on the
>>> global scale will probably take a long time, but at least people who
>>> are most impacted will be able to do something to fix it (update their
>>> NTP servers and clients).
>> We see issues at Cloudflare with packet delivery on port 123. ISP
>> middleboxes are going to police by length, and an alternative port is
>> the way forward. There is much less policing on the alternative ports.
> Actually I'd think teaching cloudflare would be better than changing the port.
> Otherwise: When do we change the port again?

When NTPv5 comes along it will have a larger packet size, so how is this 
different? In addition there's the problem of extension fields which 
also increase the size of the packet including the NTS-enabled ones. 
It's much more important to figure out how these middleboxes and 
firewalls should handle NTP packets and provide better guidance.