IETF Logo Mail Archive

Re: [Ntp] [EXT] Re: NTS-KE server load pulse

"Windl, Ulrich" <u.windl@ukr.de> Mon, 05 February 2024 07:08 UTC

Return-Path: <u.windl@ukr.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 26199C14F5F8 for <ntp@ietfa.amsl.com>; Sun, 4 Feb 2024 23:08:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTC4VHkEqMfU for <ntp@ietfa.amsl.com>; Sun, 4 Feb 2024 23:08:25 -0800 (PST)
Received: from mail01.ukr.de (mail01.ukr.de [193.175.194.181]) (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 C5076C14F5FE for <ntp@ietf.org>; Sun, 4 Feb 2024 23:08:23 -0800 (PST)
X-CSE-ConnectionGUID: iYoaCvCNS3y6kgpT67PXaw==
X-CSE-MsgGUID: 7+YErd8yRb2RIDRY4NpZtA==
X-ThreatScanner-Verdict: Negative
X-IronPort-AV: E=McAfee;i="6600,9927,10974"; a="608144"
X-IronPort-AV: E=Sophos;i="6.05,242,1701126000"; d="scan'208";a="608144"
Received: from unknown (HELO ukr-excmb02.ukr.local) ([172.24.6.62]) by dmz-infcsg01.ukr.dmz with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Feb 2024 08:08:19 +0100
Received: from ukr-excmb03.ukr.local (172.24.6.63) by ukr-excmb02.ukr.local (172.24.6.62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 5 Feb 2024 08:08:19 +0100
Received: from ukr-excmb03.ukr.local ([fe80::1cb4:6e0c:6da4:a8a0]) by ukr-excmb03.ukr.local ([fe80::1cb4:6e0c:6da4:a8a0%4]) with mapi id 15.01.2507.035; Mon, 5 Feb 2024 08:08:19 +0100
From: "Windl, Ulrich" <u.windl@ukr.de>
To: Marcus Dansarie <marcus@dansarie.se>, "ntp@ietf.org" <ntp@ietf.org>
Thread-Topic: [EXT] Re: [Ntp] NTS-KE server load pulse
Thread-Index: AQHaVUU3Lp1INvLOqk+iBeO2WvJYprD7WKbQ
Date: Mon, 05 Feb 2024 07:08:19 +0000
Message-ID: <fcb62539c6d44f0d966e881b250a4418@ukr.de>
References: <20240131210135.62B2528C065@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <eb8a3b88-39b7-4dad-a129-1aa676c9baa8@dansarie.se>
In-Reply-To: <eb8a3b88-39b7-4dad-a129-1aa676c9baa8@dansarie.se>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.24.3.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/hWF5c4v7MWsGalaozwXiXZrLr6Y>
Subject: Re: [Ntp] [EXT] Re: NTS-KE server load pulse
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
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, 05 Feb 2024 07:08:29 -0000

Hi!

But isn't the point that a DOS attack will take advantage of the fact that the backup id implemented in the clients to protect the server from being overloaded?
If the server queues requests, the DOS might cause an out of memory; if the server randomly discards (ignores) requests, clients might wait for a response for a very long time (but some iof the attackers' requests will be ignored, too)
I must admin that I'm not deep enough in the NTS protocol to suggest some better solution for the server.

Kind regards,
Ulrich

-----Original Message-----
From: ntp <ntp-bounces@ietf.org> On Behalf Of Marcus Dansarie
Sent: Thursday, February 1, 2024 8:31 PM
To: ntp@ietf.org
Subject: [EXT] Re: [Ntp] NTS-KE server load pulse

If clients implement a backoff as required by Section 4.2 of the RFC, 
the requests should be at least somewhat spread out when the NTS-KE 
server comes up again. If the NTS-KE server does go down from a load 
pulse, the backoff should help spread the load out even more that time.

I'm starting to think Mirja had a point when she fought us to have the 
backoff included...

Kind regards,
Marcus

On 2024-01-31 22:01, Hal Murray wrote:
> I'm assuming that a NTP server and its NTS-KE server are running on the same
> box and that the client doesn't reuse cookies.
> 
> Consider what happens if that box is down for X minutes.  If X is greater than
> 8 times a client's polling interval, the client will run out of cookies and go
> through NTS-KE again.
> 
> Are we going to run into troubles with the NTS-KE server getting overloaded
> when the server comes back up and all the clients jump on it trying to get new
> cookies?
> 
> 

_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp

v2.23.0 | Report a Bug | By Email