Re: [Ntp] Symmetric mode

Danny Mayer <mayer@pdmconsulting.net> Tue, 20 September 2022 13:41 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 16AD8C1594AF for <ntp@ietfa.amsl.com>; Tue, 20 Sep 2022 06:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-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 rqQv2r66q9wJ for <ntp@ietfa.amsl.com>; Tue, 20 Sep 2022 06:41:41 -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 70129C1524B6 for <ntp@ietf.org>; Tue, 20 Sep 2022 06:41:39 -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)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4MX2l673gGzMP8V; Tue, 20 Sep 2022 13:41:38 +0000 (UTC)
Message-ID: <880b8ec4-e112-e2e2-f48c-c940064bc749@pdmconsulting.net>
Date: Tue, 20 Sep 2022 09:41:38 -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>, Hal Murray <halmurray@sonic.net>
Cc: "ntp@ietf.org" <ntp@ietf.org>
References: <mayer@pdmconsulting.net> <796c33e6-02dc-0665-c8a2-a143f9100bdd@pdmconsulting.net> <20220919024614.4AB8328C1E2@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <YygwAeTMeSHXXk6t@localhost>
From: Danny Mayer <mayer@pdmconsulting.net>
In-Reply-To: <YygwAeTMeSHXXk6t@localhost>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/yi96gPsKHIxtGeQHblT_S9tS6RI>
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: Tue, 20 Sep 2022 13:41:49 -0000

On 9/19/22 5:01 AM, Miroslav Lichvar wrote:
> On Sun, Sep 18, 2022 at 07:46:14PM -0700, Hal Murray wrote:
>> Is symmetric mode interesting enough that we should try to fix that?  If so,
>> would you please say a few words about why it is interesting?
> It's not very useful. I think the most interesting thing about it is
> that sources using the symmetric mode are marked differently in tools
> like ntpq, so it's more obvious to the admin that synchronization can
> work in both directions.
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.
> At the protocol level it's just trouble. It's difficult to implement
> if you want to handle all the corner cases and difficult to secure.
> The main problem is that there is no response for each request, so the
> peers have to select to which request they respond, i.e. guess which
> one was genuine. Authentication with a symmetric key doesn't prevent
> a replay attack.
See above.
>
> There are ephemeral associations, where only one peer is configured
> with the address of the other peer. This enables attackers to replay an
> authenticated message to create an unlimited number of associations on
> the peer. In the ntp.org implementation there is a possibility to
> limit keys to IP addresses to prevent that, but in that case it's
> easier to just specify the address directly as a peer in the
> configuration file and you don't have to worry about associations
> created on different ports of the address.
>
Not really. Again you need to understand how it works.

Danny