IETF Logo Mail Archive

Re: [Ntp] NTS-KE server load pulse

"\"Patrik Fältström\"" <paf@paftech.se> Thu, 01 February 2024 11:44 UTC

Return-Path: <paf@paftech.se>
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 2F4E7C14F739 for <ntp@ietfa.amsl.com>; Thu, 1 Feb 2024 03:44:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=paftech.se
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 B_KD6xs7-i_g for <ntp@ietfa.amsl.com>; Thu, 1 Feb 2024 03:44:21 -0800 (PST)
Received: from mail.paftech.se (mail.paftech.se [192.165.72.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2335EC15107A for <ntp@ietf.org>; Thu, 1 Feb 2024 03:44:15 -0800 (PST)
Received: from [10.40.33.67] (unknown [130.242.58.14]) by mail.paftech.se (Postfix) with ESMTPSA id 031F64049F; Thu, 1 Feb 2024 12:44:11 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paftech.se; s=2022013001; t=1706787852; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LdO8CRzLKla4ZqaioKlLloVWVTcK+Ah9DPgjFgcUY7A=; b=PL1QTBNP8XFXjYRiSIvTFW7jqAp4e6LOYuKhuvMJUwoHkdsp8C/UBTTD2gOOkz2R84JSbj +o5JLB+tGBp99dlF72JOlzuTNHyZ4pj/DFyJxQ4eYchlLqsmBJ39DbsuX1f9knQwHkoZks Uk5YcgishSCqmrLFxIIxRQIjVWyyt6I=
From: "\"Patrik Fältström\"" <paf@paftech.se>
To: Hal Murray <halmurray@sonic.net>
Cc: ntp@ietf.org
Date: Thu, 01 Feb 2024 12:44:10 +0100
X-Mailer: MailMate (1.14r6014)
Message-ID: <858CFFC9-E60B-482B-BA41-1426FF1288AE@paftech.se>
In-Reply-To: <20240131210135.62B2528C065@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
References: <20240131210135.62B2528C065@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_38B2BF04-FB68-425A-8E19-A7B77B727717_="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/zl5Hgr9yyqM0X9OHip36YbOQxNs>
Subject: Re: [Ntp] 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: Thu, 01 Feb 2024 11:44:26 -0000

On 31 Jan 2024, at 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?

We might, but I think the solution is to engineer software so that this does not end up being a problem. For example, that the two processes are separated (enough) so problems with one do not create problems with the other. This in turn implies data can flow between them, like key material.

Yes, harder to do, but will lead to a much more resilient architecture.

An architecture like this also allows us to optimize the KE portion of NTS more independently from the NTP portion than if they are more tied together.

Sure, we still should think about implications and DOS-similar secondary effects. Just like we might get in DNS with DNSSEC. But we should not design around "the weakest link". We should instead strengthen that link.

Best, Patrik

v2.23.0 | Report a Bug | By Email