Re: [Ntp] Symmetric mode

Harlan Stenn <stenn@nwtime.org> Fri, 30 September 2022 23:27 UTC

Return-Path: <stenn@nwtime.org>
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 0C722C14CF0E for <ntp@ietfa.amsl.com>; Fri, 30 Sep 2022 16:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.105
X-Spam-Level:
X-Spam-Status: No, score=-1.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 8CSqKRHCcpd5 for <ntp@ietfa.amsl.com>; Fri, 30 Sep 2022 16:27:42 -0700 (PDT)
Received: from chessie.everett.org (unknown [IPv6:2001:470:1:205::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 8FB62C14CF0B for <ntp@ietf.org>; Fri, 30 Sep 2022 16:27:42 -0700 (PDT)
Received: from [10.208.75.149] (071-084-168-128.res.spectrum.com [71.84.168.128]) (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 4MfR4Q0qr4zMPCk; Fri, 30 Sep 2022 23:18:46 +0000 (UTC)
Message-ID: <415b7a7f-b9f6-8128-a9ae-467a93401945@nwtime.org>
Date: Fri, 30 Sep 2022 16:18:43 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0
Content-Language: en-US
To: Doug Arnold <doug.arnold=40meinberg-usa.com@dmarc.ietf.org>, Hal Murray <halmurray@sonic.net>, Miroslav Lichvar <mlichvar@redhat.com>
Cc: "ntp@ietf.org" <ntp@ietf.org>
References: <mlichvar@redhat.com> <YzWunE8uQwTh8suS@localhost> <20220930015229.B235628C1D8@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <AM7PR02MB5765D115CABA9E9B5A148711CF569@AM7PR02MB5765.eurprd02.prod.outlook.com>
From: Harlan Stenn <stenn@nwtime.org>
In-Reply-To: <AM7PR02MB5765D115CABA9E9B5A148711CF569@AM7PR02MB5765.eurprd02.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/GwORP-iG-oiWDoLoJCjhgjIdOF4>
Subject: Re: [Ntp] Symmetric mode
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: Fri, 30 Sep 2022 23:27:49 -0000

Client-server modes (3 and 4) are for a client to ask for the time from 
a server.

Peer modes (1/active and 2/passive) are for exchanging time between peers.

One might choose to have a set of machines that offer time to the a lot 
of client machines.  The machines that comprise the set of "time 
servers" would peer with each other.

The clients would use the "time server" machines as their time servers.

There is "mechanism", and there is "policy".  Mechanism should be robust 
enough to support policy goals.

"peer" (active or passive) and "client/server" are mechanism choices.

Local policy choices include "do we want to use peer mode on any machines?"

H

On 9/30/2022 7:23 AM, Doug Arnold wrote:
> Please enlighten me. I’ve been reading the discussion on symmetric ntp, 
> and I don’t understand the purpose. An ntp server can ask other servers 
> for time using client server ntp, and use that information to examine 
> its own time and that of the peer it is looking at.  Why is a different 
> over-the-wire version of the protocol needed?
> 
> Doug
> 
> *From: *ntp <ntp-bounces@ietf.org> on behalf of Hal Murray 
> <halmurray@sonic.net>
> *Date: *Thursday, September 29, 2022 at 9:52 PM
> *To: *Miroslav Lichvar <mlichvar@redhat.com>
> *Cc: *Hal Murray <halmurray@sonic.net>, ntp@ietf.org <ntp@ietf.org>
> *Subject: *Re: [Ntp] Symmetric mode
> 
> 
> mlichvar@redhat.com said:
>> You need to either add "disable auth" to ntp.conf, or configure a symmetric
>> key on both hosts and add it to the peer directive. 
> 
> Thanks.  That worked.  I now see the active/passive pair where the 
> passive is
> not a direct response to the active.  I assume the timing difference is the
> skew in the polling clocks.
> 
> 
>> ntpq -p (or ntpq -c peers) prints emphemeral symmetric associations, but only
>> if there was a valid response (reachable). 
> 
> That "only if reachable" is important.  That takes another polling 
> interval.
> Or something like that.  I got confused by not seeing it but while
> investigating it appeared.
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp 
> <https://www.ietf.org/mailman/listinfo/ntp>
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp

-- 
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!