IETF Logo Mail Archive

Re: [Ntp] Antw: Re: Antw: Re: Antw: [EXT] NTPv5 Loop Detection without Stratum

Miroslav Lichvar <mlichvar@redhat.com> Tue, 06 September 2022 08:04 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 20CB6C1526EF for <ntp@ietfa.amsl.com>; Tue, 6 Sep 2022 01:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.378
X-Spam-Level:
X-Spam-Status: No, score=-3.378 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_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 7oqPH9XTNC9m for <ntp@ietfa.amsl.com>; Tue, 6 Sep 2022 01:04:38 -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 58BDAC1522D8 for <ntp@ietf.org>; Tue, 6 Sep 2022 01:04:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1662451477; 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=wL89cnpe0CL3C3ZuuGQzaAqO/hdyw+33fK4fqzEC2UU=; b=DG407kdhYhIHQEORRPTjpMcvS99fnbzfwQ1GrdrrSobGsSkpA1n9W68mhAYZ748qid2BAi dpwyMxmA/VOC9oBreuKKyTrzAoNpp/53239q6oyfC1GtCAPI4SmOs2XHakVNzUR9TYP7fU CyeVaoVyHXisOPI5SF4VtRg+llQz8GI=
Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-575-KjedRsuCOPykO3RTcQ4CDQ-1; Tue, 06 Sep 2022 04:04:35 -0400
X-MC-Unique: KjedRsuCOPykO3RTcQ4CDQ-1
Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8798D1C0896D; Tue, 6 Sep 2022 08:04:35 +0000 (UTC)
Received: from localhost (unknown [10.43.135.229]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C0A58492C3B; Tue, 6 Sep 2022 08:04:34 +0000 (UTC)
Date: Tue, 06 Sep 2022 10:04:33 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Hal Murray <halmurray@sonic.net>
Cc: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, "ntp@ietf.org" <ntp@ietf.org>
Message-ID: <Yxb/EQU9U7zZqTUU@localhost>
References: <Ulrich.Windl@rz.uni-regensburg.de> <6316E754020000A10004D6D4@gwsmtp.uni-regensburg.de> <20220906070439.08DEE28C1D8@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
MIME-Version: 1.0
In-Reply-To: <20220906070439.08DEE28C1D8@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9
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/-i9WLkQfo65xj1pGFgPEfcEABHw>
Subject: Re: [Ntp] Antw: Re: Antw: Re: Antw: [EXT] NTPv5 Loop Detection without Stratum
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: Tue, 06 Sep 2022 08:04:39 -0000

On Tue, Sep 06, 2022 at 12:04:38AM -0700, Hal Murray wrote:
> It might make sense to have a separate packet format for SNTP request/response.  That would make sense if the packet format could be a lot simpler than the NTP request/response format.  So far, it seems OK to ignore a few fields.

At least with the current NTPv5 proposal, the protocol is already
"simple". It's much simpler than NTPv4 where the client/server mode is
specified as a subset of the complex symmetric mode. For the protocol,
I'm not sure if there is any need to specify SNTP.

The client request is already minimized. The only fields it has set
are version, mode, and cookie timestamp. We cannot make it any
simpler.

A simplified server could support only clients that don't use all
information from the server response. That doesn't make sense to me.

One thing we can do is to remove the requirement for servers to
support the reference IDs extension field if they don't use any
servers themselves. They cannot be in a loop if they only have a
reference clock.

-- 
Miroslav Lichvar

v2.23.0 | Report a Bug | By Email