Re: [Ntp] NTS Pools

Miroslav Lichvar <mlichvar@redhat.com> Mon, 26 February 2024 11:21 UTC

Return-Path: <mlichvar@redhat.com>
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 ECEDCC14F6A0 for <ntp@ietfa.amsl.com>; Mon, 26 Feb 2024 03:21:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
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 uBClKJiJo7rI for <ntp@ietfa.amsl.com>; Mon, 26 Feb 2024 03:21:35 -0800 (PST)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 1135FC14F696 for <ntp@ietf.org>; Mon, 26 Feb 2024 03:21:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1708946493; 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=kniVtN05Xy+FhNh9sA4NoaXAnLHYqZT6UWrhgeR+35g=; b=I47nTdb+2IroGYhfTawO540hPGNCR/UF0oLm0YOYrEtNKORxxP1M3og7QwxhqrPF+LRR11 kJCDJCRYepObhkKjJ48kMCsW2m9P4y0YttpV356QQjxEtSujS5dSARthrQhXbn+gFa+Y8m YUzuJsyqKKE3tI0/ZXr8gb9NfVxWZnM=
Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-522-pzDmNWMANPG9wHvPu14leA-1; Mon, 26 Feb 2024 06:21:30 -0500
X-MC-Unique: pzDmNWMANPG9wHvPu14leA-1
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (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 mimecast-mx02.redhat.com (Postfix) with ESMTPS id E3EBC280A9A3; Mon, 26 Feb 2024 11:21:29 +0000 (UTC)
Received: from localhost (unknown [10.43.135.229]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5540224D; Mon, 26 Feb 2024 11:21:28 +0000 (UTC)
Date: Mon, 26 Feb 2024 12:21:26 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: martin.langer=40ptb.de@dmarc.ietf.org
Cc: David Venhoek <david@venhoek.nl>, NTP WG <ntp@ietf.org>, Dieter.Sibold@ptb.de, Kristof.Teichel@ptb.de, Rainer Bermbach <r.bermbach@ostfalia.de>
Message-ID: <Zdx0Nst2_w1mEMKG@localhost>
References: <OF2E6B0FFD.229AD710-ONC1258ACB.004EFEAA-C1258ACB.0050896E@ptb.de>
MIME-Version: 1.0
In-Reply-To: <OF2E6B0FFD.229AD710-ONC1258ACB.004EFEAA-C1258ACB.0050896E@ptb.de>
X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/6QmYCWJa-vukLs0oaNgADZaoewM>
Subject: Re: [Ntp] NTS Pools
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, 26 Feb 2024 11:21:39 -0000

On Thu, Feb 22, 2024 at 03:39:40PM +0100, martin.langer=40ptb.de@dmarc.ietf.org wrote:
>    I was talking with Krisof Teichel, Dieter Sibold and Rainer Bermbach about
>    how we should handle NTS secured NTP pools. It's not easy as there are
>    different perspectives on the purpose, use cases and security
>    considerations. In general, I think I can provide support from the PTB
>    side, even though I have very little time for it at the moment.

I'm getting lost in these "NTS support in pools" discussions. I'd
appreciate if someone could clarify what exactly is meant by pool and
what is the intended use case in the different proposals.

For me, a pool is a set of servers available under the same DNS name,
which can be specified in the client's configuration with a pool
directive to use some number of the servers at the same time instead
of a single server. There is the well-known pool pool.ntp.org with
thousands of servers provided by volunteers and there are other
smaller pools run by different companies and organizations.

This DNS-based concept of a pool works with plain NTP and it works
also with NTS. There can be multiple NTS servers available under the
same name. The client can use more than one server at the same time.
The NTS-KE part can be separated from the NTS-NTP part. The client
doesn't care. I've been using my own mini pool of NTS servers without
any issues since NTS became a thing.

There are now three different proposals to solve some issues with NTS
wrt pools. There is the older one from Watson based on DNSSRV records
and two newer ones from David and Martin. Can anyone summarize what
issues do they solve and don't solve?

One idea seems to be to run one NTS-KE server with multiple NTS-NTP
servers and mix different implementations of NTS-KE and NTS-NTP. What
exactly is the use case for that? My understanding is that NTS-KE is
the weakest part of the whole system, most easily overloaded and it
the ratio should actually be inverted, run more NTS-KE servers for one
NTS-NTP server.

If NTS was to be supported in the pool.ntp.org pool, I think NTS-KE
servers would need to be run by the volunteers, not on the
pool's own limited resources. I'd not expect many of them to be
separated from NTS-NTP and even fewer of them mixing different
implementations.

If I have a limited number of computers to provide an NTS service, why
would I want to split them into NTS-KE and NTS-NTP servers, when they
can all provide both functions at the same time and provide a larger
capacity for NTS-KE and NTS-NTP?

-- 
Miroslav Lichvar