IETF Logo Mail Archive

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

Miroslav Lichvar <mlichvar@redhat.com> Thu, 22 September 2022 11:16 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 93A37C14CE47 for <ntp@ietfa.amsl.com>; Thu, 22 Sep 2022 04:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.379
X-Spam-Level:
X-Spam-Status: No, score=-3.379 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, 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 W3bFEzTdmxcA for <ntp@ietfa.amsl.com>; Thu, 22 Sep 2022 04:16:10 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.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 BFD17C14CE40 for <ntp@ietf.org>; Thu, 22 Sep 2022 04:16:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663845369; 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=+V2zeQ7FGfWgjdx21lpCdX00mAE0i/xgNWDXM1KbW+E=; b=fDI1FiGZvj43KBgSP/P9vjzHOGWXIKPMexS3Eah0rL1xMOhJ7rWa+KFLB94iXaCahhiu8R 7yCwMgxGvtPVBqjIPQ4x2k4wD3Jwu3KfOwvDoKp5Xw9Djm0vOkhSmOv5zWNrjo2AOWMduL CZWCgzY9d/M+vLrPl749EL6vVZEiUCs=
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-333-jjefzr80PQud6QbZmVRnNg-1; Thu, 22 Sep 2022 07:16:06 -0400
X-MC-Unique: jjefzr80PQud6QbZmVRnNg-1
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E57ED85A583; Thu, 22 Sep 2022 11:16:05 +0000 (UTC)
Received: from localhost (unknown [10.43.135.229]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5FC1040C83AD; Thu, 22 Sep 2022 11:16:05 +0000 (UTC)
Date: Thu, 22 Sep 2022 13:16:03 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
Cc: "ntp@ietf.org" <ntp@ietf.org>
Message-ID: <YyxD85osMKa6aFCy@localhost>
References: <419B8728020000DF6A6A8CFC@gwsmtp.uni-regensburg.de> <632C18BF020000A10004E004@gwsmtp.uni-regensburg.de> <Yyw7pYO9rlvgUB/I@localhost> <114E6FEE020000C76A6A8CFC@gwsmtp.uni-regensburg.de> <BBAE8F72020000195CC44D44@gwsmtp.uni-regensburg.de> <E42BB2AA020000A05AEBDC6A@gwsmtp.uni-regensburg.de> <419B8728020000DF6A6A8CFC@gwsmtp.uni-regensburg.de> <632C18BF020000A10004E004@gwsmtp.uni-regensburg.de> <B40F47C1020000466A6A8CFC@gwsmtp.uni-regensburg.de> <632C41FD020000A10004E037@gwsmtp.uni-regensburg.de>
MIME-Version: 1.0
In-Reply-To: <632C41FD020000A10004E037@gwsmtp.uni-regensburg.de>
X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1
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/jZcYLL-mSvUOm51-aqIt-P7MEqM>
Subject: Re: [Ntp] Antw: [EXT] Re: Antwort: 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 11:16:11 -0000

On Thu, Sep 22, 2022 at 01:07:41PM +0200, Ulrich Windl wrote:
> So it seems some OTP (on-time-password) mechanism would be needed for peers to kill the replay problem. However with lost packets that can be a bit tricky.

A key used only once for each (re)start of the association? That
doesn't seem very practical.

> > The other issue is replays from different addresses or ports can
> > create a large number of associations and cause a denial of service.
> 
> As written before, the requester (sender) should be part of the authenticated message. So at least the associations created would be limited to one, right?

What about peers that changed their address? Their old packets could
be still replayed if the key wasn't restricted to an address and
updated with each change, in which case you could specify the peer
directly in the config and avoid the trouble with ephemeral
associations.

-- 
Miroslav Lichvar

v2.23.0 | Report a Bug | By Email