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

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Mon, 26 July 2021 09:36 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 6838C3A231C for <ntp@ietfa.amsl.com>; Mon, 26 Jul 2021 02:36:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id WTO4TWeyb4Wc for <ntp@ietfa.amsl.com>; Mon, 26 Jul 2021 02:36:32 -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 F140A3A231A for <ntp@ietf.org>; Mon, 26 Jul 2021 02:36:31 -0700 (PDT)
Received: from mx4.uni-regensburg.de (localhost []) by localhost (Postfix) with SMTP id 263376000051 for <ntp@ietf.org>; Mon, 26 Jul 2021 11:36:24 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de []) by mx4.uni-regensburg.de (Postfix) with ESMTP id A38E86000050 for <ntp@ietf.org>; Mon, 26 Jul 2021 11:36:22 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Mon, 26 Jul 2021 11:36:22 +0200
Message-Id: <60FE8215020000A100042ABE@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.3.1
Date: Mon, 26 Jul 2021 11:36:21 +0200
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: <mayer@pdmconsulting.net>,<mlichvar@redhat.com>
Cc: "Dieter Sibold" <dsibold.ietf@gmail.com>,<watsonbladd@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>
In-Reply-To: <YP562akF+CL/9R5s@localhost>
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/LaXh0vx_cuXbR5fR4XZ4qqdDiKk>
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: Mon, 26 Jul 2021 09:36:36 -0000

>>> Miroslav Lichvar <mlichvar@redhat.com> schrieb am 26.07.2021 um 11:05 in
Nachricht <YP562akF+CL/9R5s@localhost>:
> 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
>> a conversation I had recently something like 70% of all traffic is still
>> 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.

Actually I think removing mode 6 from the protocol is a bad idea:
So (assuming there is a need for monitoring and dynamic configuration) every
implementer will do his/her own protocol.
As a matter of fact crony does not document the internal protocol being used.
Despite of not being compatible with the popular NTP implementation, that would
require to call a process instead of sending out a few network packets.
Obviously when monitoring a bigger landscape this is highly inefficient.
The implementation of NTP in Microsoft Windows is a similar case.

Ulrich Windl

> 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).
> ‑‑ 
> Miroslav Lichvar
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp