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

Danny Mayer <mayer@pdmconsulting.net> Thu, 29 July 2021 14:47 UTC

Return-Path: <mayer@pdmconsulting.net>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA6F3A24FE for <ntp@ietfa.amsl.com>; Thu, 29 Jul 2021 07:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gghARudjPalI for <ntp@ietfa.amsl.com>; Thu, 29 Jul 2021 07:47:52 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1693A24FF for <ntp@ietf.org>; Thu, 29 Jul 2021 07:47:52 -0700 (PDT)
Received: from newusers-MBP.fios-router.home (pool-108-26-179-179.bstnma.fios.verizon.net [108.26.179.179]) (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 chessie.everett.org (Postfix) with ESMTPSA id 4GbD0Q6nFvzMNW4; Thu, 29 Jul 2021 14:47:50 +0000 (UTC)
To: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, watsonbladd@gmail.com, mlichvar@redhat.com
Cc: Dieter Sibold <dsibold.ietf@gmail.com>, "ntp@ietf.org" <ntp@ietf.org>
References: <PH0PR06MB7061EF8C35B67CDE520E60F2C2349@PH0PR06MB7061.namprd06.prod.outlook.com> <YNMbMd+3dDjAnIDP@localhost> <CACsn0cnMR=E13wd06+=Jdr++s5hqvSt7VitE8euUzc2dF_SjtQ@mail.gmail.com> <a39454b6-31b2-a8f5-1070-3d1b3c155297@pdmconsulting.net> <492BFE65-30FD-42AC-8891-B9A7D007BC03@gmail.com> <ac4aa859-7d26-17ba-a33b-dec781258b52@pdmconsulting.net> <YP562akF+CL/9R5s@localhost> <CACsn0ckn+-MTrnd7KLVQCjyGnDPAPhPYYZm6W-w92vtd0PEAgQ@mail.gmail.com> <610253DA020000A100042C8B@gwsmtp.uni-regensburg.de>
From: Danny Mayer <mayer@pdmconsulting.net>
Message-ID: <1d377af6-68bc-5eb8-4a78-f3ed1ccc1a03@pdmconsulting.net>
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: <610253DA020000A100042C8B@gwsmtp.uni-regensburg.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/_tAJLsgVevo60kL_ud4a3B1i8_c>
Subject: Re: [Ntp] Antw: [EXT] Re: WGLC on draft‑ietf‑alternative‑port‑01
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=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 <watsonbladd@gmail.com> schrieb am 29.07.2021 um 05:12 in
> Nachricht
> <CACsn0ckn+-MTrnd7KLVQCjyGnDPAPhPYYZm6W-w92vtd0PEAgQ@mail.gmail.com>:
>> On Mon, Jul 26, 2021 at 2:05 AM Miroslav Lichvar <mlichvar@redhat.com>
> 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.

Danny