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

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Thu, 29 July 2021 07:08 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
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 643773A154D for <ntp@ietfa.amsl.com>; Thu, 29 Jul 2021 00:08:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Ub26HXA26DVy for <ntp@ietfa.amsl.com>; Thu, 29 Jul 2021 00:08:19 -0700 (PDT)
Received: from mx4.uni-regensburg.de (mx4.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:4:4e7a]) (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 C03003A1547 for <ntp@ietf.org>; Thu, 29 Jul 2021 00:08:18 -0700 (PDT)
Received: from mx4.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 152B16000050 for <ntp@ietf.org>; Thu, 29 Jul 2021 09:08:13 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx4.uni-regensburg.de (Postfix) with ESMTP id EE30A600004E for <ntp@ietf.org>; Thu, 29 Jul 2021 09:08:11 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Thu, 29 Jul 2021 09:08:11 +0200
Message-Id: <610253DA020000A100042C8B@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.3.1
Date: Thu, 29 Jul 2021 09:08:10 +0200
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: <watsonbladd@gmail.com>,<mlichvar@redhat.com>
Cc: "Dieter Sibold" <dsibold.ietf@gmail.com>, "ntp@ietf.org" <ntp@ietf.org>,<mayer@pdmconsulting.net>
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>
In-Reply-To: <CACsn0ckn+-MTrnd7KLVQCjyGnDPAPhPYYZm6W-w92vtd0PEAgQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/mUqF7o471fppG1yhjdt42632OAg>
Subject: [Ntp] =?utf-8?b?QW50dzogW0VYVF0gUmU6ICBXR0xDIG9uIGRyYWZ04oCRaWV0?= =?utf-8?b?ZuKAkWFsdGVybmF0aXZl4oCRcG9ydOKAkTAx?=
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 07:08:23 -0000

>>> Watson Ladd <watsonbladd@gmail.com> schrieb am 29.07.2021 um 05:12 in
Nachricht
<CACsn0ckn+-MTrnd7KLVQCjyGnDPAPhPYYZm6W-w92vtd0PEAgQ@mail.gmail.com>om>:
> 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 teching cloudflare would be better than changing the port.
Otherwise: When do we change the port again?

> 
> Sincerely,
> Watson Ladd
> 
>>
>> ‑‑
>> Miroslav Lichvar
>>
> 
> 
> ‑‑
> Astra mortemque praestare gradatim
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp