IETF Logo Mail Archive

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

Harlan Stenn <stenn@nwtime.org> Wed, 04 August 2021 07:46 UTC

Return-Path: <stenn@nwtime.org>
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 D17453A0AB8 for <ntp@ietfa.amsl.com>; Wed, 4 Aug 2021 00:46:39 -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, 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 7AsGkbVl9EKV for <ntp@ietfa.amsl.com>; Wed, 4 Aug 2021 00:46:32 -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 DD7CE3A0AB7 for <ntp@ietf.org>; Wed, 4 Aug 2021 00:46:29 -0700 (PDT)
Received: from [10.208.75.157] (075-139-201-087.res.spectrum.com [75.139.201.87]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4GfkMM1NdjzMNWF; Wed, 4 Aug 2021 07:46:23 +0000 (UTC)
To: Miroslav Lichvar <mlichvar@redhat.com>, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
Cc: "ntp@ietf.org" <ntp@ietf.org>, halmurray+ietf@sonic.net
References: <FAD1C7620200006F824A10E1@gwsmtp.uni-regensburg.de> <31FF6970020000285AEBDC6A@gwsmtp.uni-regensburg.de> <9C21DF1F020000EB6A6A8CFC@gwsmtp.uni-regensburg.de> <D9104F8D020000FEAB59E961@gwsmtp.uni-regensburg.de> <610253DA020000A100042C8B@gwsmtp.uni-regensburg.de> <61025C79020000A100042C9B@gwsmtp.uni-regensburg.de> <2FCD5C39020000B9AB59E961@gwsmtp.uni-regensburg.de> <1E89B79A020000F55AEBDC6A@gwsmtp.uni-regensburg.de> <32C7A15902000060FDA5B133@gwsmtp.uni-regensburg.de> <61078A68020000A100042DD7@gwsmtp.uni-regensburg.de> <YQegwC/8qioEWJ/P@localhost>
From: Harlan Stenn <stenn@nwtime.org>
Message-ID: <c8e4130c-cd44-e426-4346-31ffb879e289@nwtime.org>
Date: Wed, 04 Aug 2021 00:46:21 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <YQegwC/8qioEWJ/P@localhost>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/Qfop3D6jTErcVQVrvmJ3paN_t04>
Subject: Re: [Ntp] Antw: Re: 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: Wed, 04 Aug 2021 07:46:40 -0000

On 8/2/2021 12:37 AM, Miroslav Lichvar wrote:
> On Mon, Aug 02, 2021 at 08:02:16AM +0200, Ulrich Windl wrote:
>> I just wonder: Wouldn't rate limiting (or bandwidth limiting) be the correct
>> way to do?
> 
> I think that's what they currently do. It effectively causes a DoS on
> NTP.

I don't understand exactly what you mean here by "causes a DoS on NTP."
 Clarify, please?

> See the discussions at community.ntppool.org. Large numbers of
> servers are randomly rejected from the pool due to heavy packet loss
> specific to port 123 on the path to the monitoring system.

If the target system is receiving too many packets and is dropping them
already the monitoring system needs to know this, and rank the target
accordingly.

>> I don't consider the smart solution to be smart actually.
>> Maybe even considering the input/output (request/response) ratio would be even
>> better.
> 
> That would require tracking each address separately. Good luck doing
> that at the network speeds the ISPs work with.
> 
> A more practical solution would be to specifically drop only NTP mode
> 6/7 packets, but even this functionality is missing in (most of?) the
> hardware.
> 

-- 
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!

v2.23.0 | Report a Bug | By Email