Re: [Ntp] Pool and DNS

Miroslav Lichvar <mlichvar@redhat.com> Mon, 24 October 2022 08:40 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 16582C1522BC for <ntp@ietfa.amsl.com>; Mon, 24 Oct 2022 01:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.679
X-Spam-Level:
X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 PC6X-oNeTLjE for <ntp@ietfa.amsl.com>; Mon, 24 Oct 2022 01:40:54 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 44A43C1522B9 for <ntp@ietf.org>; Mon, 24 Oct 2022 01:40:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666600852; 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=9rPWlFQr70iiVz1H1jd3hj/BRs7P1//93zQu5YGYE9Y=; b=idpnxX+4zWu5p7GfLjrJDfuucH3CzjQ39Cm4W7kaUBYwc+vmCzQugC1KjVKO+wYHg/xbHL R85H0Vf5UZfuILJ56YaR/STD4TREsCfC0Aj6Iv1njBi9/p1+gsxrygv+iODXWYS0c+D6ow RFvWIkXHji4myNbQt9PsHUuJiAAZrzA=
Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-515-HQ6Zg0EjMgiSSRSZgbXeMw-1; Mon, 24 Oct 2022 04:40:49 -0400
X-MC-Unique: HQ6Zg0EjMgiSSRSZgbXeMw-1
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4AE7E101A52A; Mon, 24 Oct 2022 08:40:49 +0000 (UTC)
Received: from localhost (unknown [10.43.135.229]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CC4E11401C20; Mon, 24 Oct 2022 08:40:48 +0000 (UTC)
Date: Mon, 24 Oct 2022 10:40:47 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Hal Murray <halmurray@sonic.net>
Cc: ntp@ietf.org
Message-ID: <Y1ZPj6dRT3+K4TGH@localhost>
References: <20221023053430.6022728C1DB@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
MIME-Version: 1.0
In-Reply-To: <20221023053430.6022728C1DB@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7
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/f0xX1-S38n_7Z2qK-wrjmJJPero>
Subject: Re: [Ntp] Pool and DNS
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, 24 Oct 2022 08:40:56 -0000

On Sat, Oct 22, 2022 at 10:34:30PM -0700, Hal Murray wrote:
> Second, there is no established protocol between NTS-KE servers and NTP 
> servers.
> 
> NTPsec packages the KE server with ntpd so there is no need for that protocol. 
>  I don't know of any split implementations.  So as a practical matter, it 
> would be hard to put together a pool using that mechanism with available code.
> 
> 
> Miroslav: What does chrony do?

chronyd can be configured to load the NTS server keys from disk
instead of generating its own in order to run multiple NTS-KE servers
for a single NTP server. One instance is generating new keys (once
per week by default) and all other instances are loading it from disk.
The distribution of keys between the hosts is left up to the admin. A
daily cronjob using rsync might be the simplest solution.

The NTS key file includes one "future" key, so the key update doesn't
have to be synchronized with the rotation of the key-generating
instance in order to not break decoding of cookies.

I'm not sure how useful this really is for a pool. If you have/expect
so many clients that you need to add a new NTS-KE server, why not use
it also for NTP and share the NTP load, i.e. run independent
NTS-KE+NTP servers?

-- 
Miroslav Lichvar