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
- Re: [Ntp] NTS Pools Luke Valenta
- [Ntp] NTS Pools martin.langer
- Re: [Ntp] NTS Pools "Dr. Dieter Sibold"
- Re: [Ntp] NTS Pools martin.langer
- Re: [Ntp] NTS Pools Miroslav Lichvar
- Re: [Ntp] NTS Pools David Venhoek
- Re: [Ntp] NTS Pools Miroslav Lichvar
- Re: [Ntp] NTS Pools David Venhoek
- Re: [Ntp] NTS Pools Miroslav Lichvar
- Re: [Ntp] NTS Pools David Venhoek
- Re: [Ntp] NTS Pools Miroslav Lichvar
- Re: [Ntp] NTS Pools Windl, Ulrich
- Re: [Ntp] NTS Pools David Venhoek
- [Ntp] Antwort: Re: NTS Pools martin.langer
- Re: [Ntp] NTS Pools David Venhoek
- Re: [Ntp] NTS Pools Salz, Rich
- Re: [Ntp] NTS Pools Watson Ladd
- Re: [Ntp] NTS Pools Salz, Rich