Re: [Ntp] NTPv5 Loop Detection without Stratum - Why do we want this?

Danny Mayer <mayer@pdmconsulting.net> Thu, 08 September 2022 22:26 UTC

Return-Path: <mayer@pdmconsulting.net>
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 CE6A3C1533AC for <ntp@ietfa.amsl.com>; Thu, 8 Sep 2022 15:26:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.891
X-Spam-Level:
X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no
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 7cCmsXfBOIix for <ntp@ietfa.amsl.com>; Thu, 8 Sep 2022 15:26:50 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (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 D3F56C1522D7 for <ntp@ietf.org>; Thu, 8 Sep 2022 15:26:50 -0700 (PDT)
Received: from [192.168.1.156] (pool-108-26-202-2.bstnma.fios.verizon.net [108.26.202.2]) (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 chessie.everett.org (Postfix) with ESMTPSA id 4MNtn04kJNzMPXd; Thu, 8 Sep 2022 22:18:28 +0000 (UTC)
Message-ID: <10b1b402-9386-4fb3-4297-38d31bdc5c96@pdmconsulting.net>
Date: Thu, 08 Sep 2022 18:18:24 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.0
Content-Language: en-US
To: Miroslav Lichvar <mlichvar@redhat.com>
Cc: kristof.teichel=40ptb.de@dmarc.ietf.org, "ntp@ietf.org" <ntp@ietf.org>, Heiko Gerstung <heiko.gerstung=40meinberg.de@dmarc.ietf.org>
References: <DA1F1664-8A84-4197-844A-CA7E8DAA36B8@meinberg.de> <OF43150191.DABAA331-ONC12588B5.00362DC0-C12588B5.003861AF@ptb.de> <YxckOm2+TD3tTPN4@localhost> <7d7f0656-2fd2-b781-4913-526a4be8cb62@pdmconsulting.net> <Yxg4Cba58hI/aPKw@localhost> <aba44bbc-2204-735e-daff-a29a59dac9da@pdmconsulting.net> <YxmKlSVTzOQah/nc@localhost>
From: Danny Mayer <mayer@pdmconsulting.net>
In-Reply-To: <YxmKlSVTzOQah/nc@localhost>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/E3IEYXxKKH-wkw8JPa-kkIARH6g>
Subject: Re: [Ntp] NTPv5 Loop Detection without Stratum - Why do we want this?
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, 08 Sep 2022 22:26:58 -0000

On 9/8/22 2:24 AM, Miroslav Lichvar wrote:
> On Wed, Sep 07, 2022 at 02:50:23PM -0400, Danny Mayer wrote:
>> On 9/7/22 2:19 AM, Miroslav Lichvar wrote:
>>> If stratum came from the maximum from all selected sources, it would
>>> always terminate the loop, but I think it would lead to unstable
>>> selection. We can experiment with that.
>> Only one source is selected at a time so this makes no sense.
> An NTP client can select multiple sources at the same time for its
> synchronization. Look for "combine" in the NTP RFCs. With the "ntpq
> peers" command you would see sources marked with the * and + symbols.
Only is chosen (marked with a *). The + ones are possible candidates.
> The best source (in terms of root distance) determines stratum and
> root delay/dispersion of the client. That other sources don't.

Those are not the only criteria.


>>> In orphan mode stratum is interpreted differently. Symmetric mode or
>>> client/server mode makes no difference.
>> There is no symmetric mode for client/server. A client is by definition one
>> stratum value larger than the server. Peers can have the same stratum.
> This is about the onwire protocol, not about source selection or
> synchronization. A client polling a server can have a smaller, equal,
> or higher stratum than the server.
That's irrelevant. You are polling a server for time, what you do with 
it depends on the analysis done on the packets.
>
> The difference between the client/server and symmetric mode is that in
> symmetric mode a message is a request and response at the same time.
> A client/server association provides measurements (offset, delay) only
> for the client side. In symmetric mode the association provides
> measurements for both sides.
>
> Two client/server associations in opposite directions provide the same
> functionality as a symmetric association, except the number of
> exchanged messages is doubled, it's much easier to implement and
> understand, and there are no replay attacks.
That's a naive assumption. You can send any kind of replay no matter 
what the mode of the packet. Why do you think that you are sending twice 
as many packets in a symmetric association?
>
>>> If a local stratum-1 server had a poor reference clock (e.g. a GPS
>>> receiver without PPS), it would be better to use a distant server with
>>> higher stratum, i.e. stratum doesn't say much about accuracy.
>> Then it wouldn't be a stratum-1 server any more.
> What it would be?

I can only assume you have not read Section 3 of RFC5905 which tells you 
the answer.

Danny