[Ntp] Antw: [EXT] Re: Symmetric mode

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Thu, 22 September 2022 06:50 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
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 D40DDC14CE3A for <ntp@ietfa.amsl.com>; Wed, 21 Sep 2022 23:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 Pimjz_1yWLcj for <ntp@ietfa.amsl.com>; Wed, 21 Sep 2022 23:50:05 -0700 (PDT)
Received: from mx2.uni-regensburg.de (mx2.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:3:bdf8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357FEC14F6EC for <ntp@ietf.org>; Wed, 21 Sep 2022 23:50:04 -0700 (PDT)
Received: from mx2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 74E726000051 for <ntp@ietf.org>; Thu, 22 Sep 2022 08:50:00 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx2.uni-regensburg.de (Postfix) with ESMTP id 53C97600004D for <ntp@ietf.org>; Thu, 22 Sep 2022 08:50:00 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Thu, 22 Sep 2022 08:50:00 +0200
Message-Id: <632C0597020000A10004DFEA@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.4.1
Date: Thu, 22 Sep 2022 08:49:59 +0200
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: stenn@nwtime.org, mayer@pdmconsulting.net, halmurray@sonic.net
Cc: "ntp@ietf.org" <ntp@ietf.org>
References: <20220921030852.3C18228C1D8@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <cb8a1e68-2481-3414-394b-e451fc2397fe@pdmconsulting.net> <68d4ea33-1071-e125-ae47-c806f860d846@nwtime.org>
In-Reply-To: <68d4ea33-1071-e125-ae47-c806f860d846@nwtime.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/N7GyCKdyX_n_LctLOMe-5ZVvMvs>
Subject: [Ntp] Antw: [EXT] Re: 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: Thu, 22 Sep 2022 06:50:09 -0000

>>> Harlan Stenn <stenn@nwtime.org> schrieb am 22.09.2022 um 02:44 in Nachricht
<68d4ea33-1071-e125-ae47-c806f860d846@nwtime.org>:
> On 9/21/2022 4:32 PM, Danny Mayer wrote:
>> 
>> On 9/20/22 11:08 PM, Hal Murray wrote:
>>> mayer@pdmconsulting.net said:
>>>> It's extremely useful, particularly when you end up in orphan mode 
>>>> or  just
>>>> need to make sure that all systems in the local network are  
>>>> synchronized.
>>>> You really need to take the time to understand it.
>>> I need a hint as to what I should be looking for.
>>>
>>>
>>> What's the difference between Symmetric and a pair of client/servers?
>> Symmetric peers keep track of each other while the server in 
>> client/server doesn't care, it's just responding to just another request.
>> 
>> Danny
>> 
>>> I think there are 3 cases.
>>>
>>> Case 1:
>>>    A:  server B
>>>    B:  server A
>>> Case 2:
>>>    A:  peer B
>>> Case 3:
>>>    A:  peer B
>>>    B:  peer A
> 
> What's the point of case 3?  Case 2 is the proper use of peer mode 
> between A and B.

I'm surprised: I always thought case 3 is the proper way to do it, as in case 2 B still has to agree to "play peer for A".
I also think that case 2 is a poor choice security-wise. To me it's bit like a client is saying "You are my server!", and so the server trusts the client.

Regards,
Ulrich


> 
>> _______________________________________________
>> ntp mailing list
>> ntp@ietf.org 
>> https://www.ietf.org/mailman/listinfo/ntp 
>> 
> 
> -- 
> Harlan Stenn <stenn@nwtime.org>
> http://networktimefoundation.org - be a member!
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp