[Ntp] Antw: [EXT] Re: [tsvwg] [Tsv‑art] Tsvart early review of draft‑ietf‑ntp‑alternative‑port‑02

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Thu, 09 December 2021 07:25 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 C02643A0FB6; Wed, 8 Dec 2021 23:25:02 -0800 (PST)
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 hQz3pWDR8njg; Wed, 8 Dec 2021 23:24:58 -0800 (PST)
Received: from mx2.uni-regensburg.de (mx2.uni-regensburg.de [194.94.157.147]) (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 45B763A0AC4; Wed, 8 Dec 2021 23:24:55 -0800 (PST)
Received: from mx2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 752136000047; Thu, 9 Dec 2021 08:24:48 +0100 (CET)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx2.uni-regensburg.de (Postfix) with ESMTP id EFB5E6000051; Thu, 9 Dec 2021 08:24:46 +0100 (CET)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Thu, 09 Dec 2021 08:24:45 +0100
Message-Id: <61B1AF3C020000A100046288@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.3.1
Date: Thu, 09 Dec 2021 08:24:44 +0100
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: lear@lear.ch, mlichvar@redhat.com, touch@strayalpha.com
Cc: magnus.westerlund@ericsson.com, Steven Sommars <stevesommarsntp@gmail.com>, iana-port-experts@icann.org, draft-ietf-ntp-alternative-port.all@ietf.org, "ntp@ietf.org" <ntp@ietf.org>, tsv-art@ietf.org, tsvwg@ietf.org, martin.burnicki@meinberg.de, stenn@nwtime.org, mayer@pdmconsulting.net, halmurray@sonic.net
References: <20211204231206.A534228C17A@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <A803AF18-2BBD-4A54-9802-3EF693066E6C@strayalpha.com> <CAD4huA7RhF3xZJkdghz4yx3qk8uBjkfJv7Y_hDCvX1a=wATBkg@mail.gmail.com> <CACL_3VENkyebRf25W6EpW0yZY6ELYS41A4D_i+RnQE1M21P2hg@mail.gmail.com> <Ya3fLJCHUsm1wE28@localhost> <90723c26-0352-a4d1-f765-eb26b1522954@pdmconsulting.net> <bf78924b-69bc-760e-cc7f-e6896504e194@meinberg.de> <Ya81mYy8/EuH8ilY@localhost> <ABF8072B-C6C0-47F3-BD7B-BAFE927B5DE1@strayalpha.com> <d3d167ee-5a6d-0060-a350-6eb04ba0ae8b@lear.ch>
In-Reply-To: <d3d167ee-5a6d-0060-a350-6eb04ba0ae8b@lear.ch>
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/5euIREMZ-aAufDQgAsHrD1q49oU>
Subject: [Ntp] Antw: [EXT] Re: [tsvwg] [Tsv‑art] Tsvart early review of draft‑ietf‑ntp‑alternative‑port‑02
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, 09 Dec 2021 07:25:03 -0000

>>> Eliot Lear <lear@lear.ch> schrieb am 07.12.2021 um 20:43 in Nachricht
<d3d167ee-5a6d-0060-a350-6eb04ba0ae8b@lear.ch>:
> We have the following situation, as I understand it:
> 
> There remain servers out there that are open to control packets, and 
> those packets are amplified at target NTP servers. Deployments have 
> mitigated the attack by placing a firewall rule that matches the frame 
> size of a normal NTP query, rather than enumerating the NTP servers that 
> they permit.  Do I have the situation correct?
> 
> So we have a combination of a protocol weakness, open NTP servers, and a 
> common firewall rule set that won't let the right thing happen.  Does 
> anyone know how common?

I wonder why this hasn't been discussed (it's obvious that nothing of the
proposals will change any existing NTP deployment automagically):
What if the NTP control protocol were changed to require authentication even
for read operations? (a bit like SNMP's read/write communities)
Then non-authenticated requests simply wouldn't be answered, or be answered by
a fixed-size error packet.

Regards,
Ulrich

> 
> Eliot
> 
> 
> 
> On 07.12.21 17:31, touch@strayalpha.com wrote:
>>
>> —
>> Joe Touch, temporal epistemologist
>> www.strayalpha.com <http://www.strayalpha.com>
>>
>>> On Dec 7, 2021, at 2:21 AM, Miroslav Lichvar <mlichvar@redhat.com> wrote:
>>>
>>> On Tue, Dec 07, 2021 at 10:23:10AM +0100, Martin Burnicki wrote:
>>>> I find it ridiculous to start using a new port for NTP because some 
>>>> admins
>>>> block the original, well-known port because many years ago there was a
>>>> possibility for DDoS for servers that weren't properly configured.
>>>
>>> That possibility still exists. It's a security issue in the protocol.
>>
>> Again, IMO, that’s why protocols (including NTP) have version numbers.
>>
>> I look forward to a new NTP version that addresses these issues, but 
>> it should run on the existing port.
>>
>> This is the *same* issue every protocol encounters for any vulnerability.
>>
>> Joe
>>