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

Miroslav Lichvar <mlichvar@redhat.com> Mon, 19 September 2022 07:36 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 4C189C157B36 for <ntp@ietfa.amsl.com>; Mon, 19 Sep 2022 00:36:09 -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 7leLh9ICJXpv for <ntp@ietfa.amsl.com>; Mon, 19 Sep 2022 00:36:08 -0700 (PDT)
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_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 4146EC14CE25 for <ntp@ietf.org>; Mon, 19 Sep 2022 00:36:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663572967; 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=rA50Lpf8oxAlHG4YOs4OLgyx5L9r2C+kiyoMnFBvWmI=; b=H0ExJakLjgFbJpXb16o8MhZU3OoJ+U3XYfbc8ji4dSZxSekNtemXzQ1nZB4Jq0EJblhe20 xA6d0cn+XBrLKiIaAVsJpayNu+GJMJsEX+v538BsMTJb1pA5EmAEwJEqG8uyw+Ykyvmh/i oVqV6OXNwwZLae/F9qLhR/d/SUiajtE=
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-322-PELghQ7QO8ul2O7DPgS26g-1; Mon, 19 Sep 2022 03:36:04 -0400
X-MC-Unique: PELghQ7QO8ul2O7DPgS26g-1
Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 24DB087A9E2; Mon, 19 Sep 2022 07:36:04 +0000 (UTC)
Received: from localhost (unknown [10.43.135.229]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 618D6492B04; Mon, 19 Sep 2022 07:36:03 +0000 (UTC)
Date: Mon, 19 Sep 2022 09:36:02 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Danny Mayer <mayer@pdmconsulting.net>
Cc: kristof.teichel=40ptb.de@dmarc.ietf.org, "ntp@ietf.org" <ntp@ietf.org>, Heiko Gerstung <heiko.gerstung=40meinberg.de@dmarc.ietf.org>
Message-ID: <Yygb4pt5JdyIszWU@localhost>
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> <10b1b402-9386-4fb3-4297-38d31bdc5c96@pdmconsulting.net> <Yx8I6sTGKTLKJr8c@localhost> <796c33e6-02dc-0665-c8a2-a143f9100bdd@pdmconsulting.net>
MIME-Version: 1.0
In-Reply-To: <796c33e6-02dc-0665-c8a2-a143f9100bdd@pdmconsulting.net>
X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10
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/HMliOSWUrfsTEyvXnzSvRZUD6ac>
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: Mon, 19 Sep 2022 07:36:09 -0000

On Sun, Sep 18, 2022 at 12:07:50PM -0400, Danny Mayer wrote:
> NTP looks at the selected candidates and chooses what it considers the best
> at that time. Only one source is the chosen system which as you note is
> marked as the one with the asterisk (*). You can only find that out with
> ntpq (mode 6) queries. That becomes the reference ID for any downstream NTP
> servers. I'm not sure what you are trying to point out.

The discussion started about synchronization loops and how can they be
detected and prevented. It's still in the subject.

An NTP client selects multiple sources for synchronization (in ntpq
marked as * and +). Loops can be happen over the * source and also the
+ sources.

You seem to be focused on the selection of the system peer (*), from
which is inherited stratum and other things. You are right that there
is only one system peer, but there are other sources which can form
synchronization loops.

> > > That's irrelevant. You are polling a server for time, what you do with it
> > > depends on the analysis done on the packets.
> > Right. So can you explain where measurements made in symmetric mode
> > are handled differently than in client/server mode? A pointer to the
> > RFC or code is sufficient.
> The NTP reference implementation does this.

I'm quite familiar with the "reference implementation", more than I'd
like actually, but I have not seen what you are suggesting.

Can you please tell us in which file and on what line we can see that
difference in handling of measurements made in client/server mode and
symmetric mode?

> > In symmetric mode each packet is a request and response at the same
> > time, i.e. the number of messages is halved when compared to two
> > client/server associations.
> No. See the source code.

Which file and line in the source code?

> > As the responses follow the polling interval and are not send
> > immediately when the request is received, this makes the symmetric
> > mode susceptible to replay attacks. In client/server mode each request
> > has its own response, independently from the polling of the other
> > client/server association.
> Not true. You misunderstand how symmetric mode works.

Which part do you think I misunderstood?

> A stratum-1 server that decides that it's reference clock is not reliable,
> or unavailable, is no longer a stratum-1 server, it's just a downstream
> server from it's selected server and is a stratum lower than that server.
> I'm not sure what your question is since it's very basic to NTP.

There was no question. I said clients of a stratum-1 server with a
poor reference clock would prefer another server, possibly with a
higher stratum, i.e. stratum doesn't indicate accuracy. You said it
would no longer be considered a stratum-1 server. I disagree.

-- 
Miroslav Lichvar