IETF Logo Mail Archive

[Ntp] Antw: [EXT] Re: I-D Action: draft-ietf-ntp-alternative-port-00.txt

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Fri, 30 October 2020 07:15 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 DBF053A0C28 for <ntp@ietfa.amsl.com>; Fri, 30 Oct 2020 00:15:04 -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 s-nlm6nB8wWd for <ntp@ietfa.amsl.com>; Fri, 30 Oct 2020 00:15:03 -0700 (PDT)
Received: from mx1.uni-regensburg.de (mx1.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:3:bdf7]) (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 D7D623A0B97 for <ntp@ietf.org>; Fri, 30 Oct 2020 00:15:02 -0700 (PDT)
Received: from mx1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 27EEB6000051 for <ntp@ietf.org>; Fri, 30 Oct 2020 08:14:59 +0100 (CET)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx1.uni-regensburg.de (Postfix) with ESMTP id B791B600004E for <ntp@ietf.org>; Fri, 30 Oct 2020 08:14:55 +0100 (CET)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Fri, 30 Oct 2020 08:14:55 +0100
Message-Id: <5F9BBD6D020000A10003C44F@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.2.1
Date: Fri, 30 Oct 2020 08:14:53 +0100
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: Steven Sommars <stevesommarsntp@gmail.com>, mlichvar@redhat.com
Cc: "ntp@ietf.org" <ntp@ietf.org>
References: <160251475240.1475.18009830719976625294@ietfa.amsl.com> <CAD4huA5UiS+yAjASKcj9FjWDuSCiVF4rEajZfkyzBSF61-yfvw@mail.gmail.com> <20201026173637.GE580262@localhost> <CAD4huA6h8Nt5z=HnUQZUq8m6tXkPMe3boZK7gXJEPRnKnPB_9w@mail.gmail.com>
In-Reply-To: <CAD4huA6h8Nt5z=HnUQZUq8m6tXkPMe3boZK7gXJEPRnKnPB_9w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/dwvMLQvCyk68AlfD4a6N_oKGhFA>
Subject: [Ntp] Antw: [EXT] Re: I-D Action: draft-ietf-ntp-alternative-port-00.txt
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Fri, 30 Oct 2020 07:15:05 -0000

>>> Steven Sommars <stevesommarsntp@gmail.com> schrieb am 27.10.2020 um 21:18 in
Nachricht
<CAD4huA6h8Nt5z=HnUQZUq8m6tXkPMe3boZK7gXJEPRnKnPB_9w@mail.gmail.com>:
> As the problems with blocking and rate-limiting are not specific to
> NTS-protected NTP packets, I think it would be nice to provide a
> workaround for all servers and clients, not just those that are using
> NTS. I don't think we can expect NTS to be instantly adopted everywhere.
> 
> Should blocking and rate limiting considerations be added to the NTP
> specifications?  If so where?

Hi!

Rate limiting in case of NTP means "random packet dropping"? In case of UDP this can happen any time, but I think past design philosophy was that the endpoint does not randomly drop packets without warning (KoD codes). So what exactly is the proposal?

Regards,
Ulrich

> Some hardware-based (e.g., FPGA) NTP implementations can handle 10Gbps of
> traffic, yet lack rate limiting mechanism.
> 
> The immediate effect of the alternate port is to bypass the current NTP
> filtering that can break NTS and that is currently causing problems for the
> NTP pool.
> I'm concerned that adding NTP(RFC5905) to ALTPORT may lead to ISP filtering
> of those UDP packets as well.
> 
> Do you suggest to reword the abstract to mention only that it makes NTP
> amplification-free?
> 
> That's the most it can do since with the current draft reflection attacks
> are still possible.
> [Using  ALTPORT=NTS-only would prevent reflection attacks.]
> 
> Maybe we could at least say that the number of servers dropped due to
> the attacks, no matter why exactly were the servers removed? The graph
> at this page clearly shows when it started:
> 
> https://www.ntppool.org/zone 
> 
> That's probably the best available reference.  For NTP WG email history
> here are two consequences of excessive NTP drops of the NTP Pool monitoring
> system probe packets.
> 1) Servers are deemed unreachable/poorly reachable and are temporarily
> removed from the NTP Pool
> 2) The volunteers offering their hosts as NTP Pool servers receive many
> email notifications of poor reachability and eventually drop out of the NTP
> Pool.

v2.23.0 | Report a Bug | By Email