Re: [Ntp] NTS Objectives

Heiko Gerstung <heiko.gerstung@meinberg.de> Tue, 01 June 2021 07:52 UTC

Return-Path: <heiko.gerstung@meinberg.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 190FD3A1F01 for <ntp@ietfa.amsl.com>; Tue, 1 Jun 2021 00:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=meinberg.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6QBrUUfuN7V for <ntp@ietfa.amsl.com>; Tue, 1 Jun 2021 00:52:08 -0700 (PDT)
Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFADE3A1F00 for <ntp@ietf.org>; Tue, 1 Jun 2021 00:52:07 -0700 (PDT)
Received: from seppmail.py.meinberg.de (unknown [193.158.22.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id 2E93971C0940; Tue, 1 Jun 2021 09:52:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=dkim; t=1622533926; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4dxKDMgKJrBNz2cllT4RJY4vzIaB1p/aJdR4hrdbgGI=; b=ZtR4YA1eCztMH9I8Me8Luu8Bm4lB4oIV0kMsN7BJiEFbGmpObmlF9/x6ID04TNMtnqovNz wAAnl37odbvAmEhOynYRaMQqDwCf0m2vHkgNFhD1Gu9qmJXm2NSZXUtAjDwUUwWeKkSkC5 L+c4heBcCXHKid0WtMhd6pNvLxx2CrFUfa8t8cfYOVBOnDDFVMxcUZ+XC4vQkUdT4315gQ 4O7pSvzP8zJxbV2tFYAJVOL1/OM/nNi+Jxdelb6x1q7GpWOxZk7iJPzpVo5Mez61bXxQ1/ /ndXmW47etcfokWTMIZiHJzQWrV/PBKb8SMWBErx6lbpKOteGCmnrIN6q7ZQ3Q==
Received: from srv-kerioconnect.py.meinberg.de (srv-kerioconnect.py.meinberg.de [172.16.3.65]) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by seppmail.py.meinberg.de (Postfix) with ESMTPS; Tue, 1 Jun 2021 09:52:05 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.49.21050901
Date: Tue, 01 Jun 2021 09:52:04 +0200
Message-ID: <6047CE6C-3573-4C6A-AAEB-7E51AC6E5EAC@meinberg.de>
Thread-Topic: [Ntp] NTS Objectives
References: <OFEDE8A71A.C2598A3E-ONC12586E6.005999CC-C12586E6.005A9E99@ptb.de>
In-Reply-To: <OFEDE8A71A.C2598A3E-ONC12586E6.005999CC-C12586E6.005A9E99@ptb.de>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+MzkzYjBlZmRhZTQ1ZThmYg==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: "kristof.teichel@ptb.de" <kristof.teichel@ptb.de>, NTP WG <ntp@ietf.org>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----A05607203FC2C35EE4CF2227E37B4FAD"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/4KREWjpo3Fb3gGAo2E3m5Dk2whc>
Subject: Re: [Ntp] NTS Objectives
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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, 01 Jun 2021 07:52:14 -0000

> Von: ntp <ntp-bounces@ietf.org> im Auftrag von <kristof.teichel@ptb.de>

> Datum: Montag, 31. Mai 2021 um 18:30

 

> in light of the recent discussions about NTS4UPTP, I've studied the "Objectives"

> section of RFC8915 again.

> [...]

> Overall, I believe that this list is not a good basis to derive goals for other

> security approaches.

> In particular, it seems unsuited as a baseline for discussion of any kind of PTP

> security with NTS methods, as it seems unreasonable to presuppose any of those

> things for a PTP network.

I fully agree. 

 

> I want to remind the WG that NTS once used to be a generic concept, with a docum

> ent, and that "NTS for NTP" was supposed to be only one application of it.

> [...]

> Is there interest in a document that kind of sits between RFC7384 (Tal's require

> ments document) and RFC8915 (NTS for NTP)?

> I envision a document that talks about the specific requirements on the messages

> that a synchronization protocol exchanges and the generic blueprint that I thin

> k of as the state-of-the-art.

> This would basically be compiled from the results of three minor chapters of my

> doctoral thesis.

I am definitely interested in such a document, as it seems that this would have made it a lot easier for us to create a draft describing yet another application of NTS, but for a protocol that is working in a completely different way. I am, however, slightly concerned that it would require some careful design to make sure that NTS4NTP fits in and at the same time keep it flexible enough for other applications/use-cases. 

 

> I believe this could help us futureproof design and decision processes, and one

> of the first applications could be the discussions about (NTS-based) solutions f

> or PTP security.

 

Shame on me, I did not follow the discussion about this document back in 2019, but wonder why it was ignored by people? My guess would be that, as a conceptual document, it might not have attracted interest because people want/need to focus on standards that describe a protocol that can be applied directly. The document you describe seems to be aimed more at authors/designers of future NTS based protocols and will therefore only will be beneficial to users in an indirect way. I nevertheless believe that this would be very useful and we here at Meinberg would certainly support working on something like this. 

 

But we also have users waiting for a way to secure their unicast PTP use-cases and I therefore would prefer if we can do this in parallel. I know, this is not the ideal way of doing it, but since we cannot come up with something that is completely contrary to what has been done in RFC8915, I am sure it is possible to set the document up in a way that allows NTS4NTP to comply and ensure that something like NTS4UPTP, following as a minimum the same approach as NTS4NTP, is also applying the concepts that are clearly outlined in the new NTS document. 

 

Regards,

  Heiko

 


-- 

Heiko Gerstung 

Managing Director 

 

MEINBERG® Funkuhren GmbH & Co. KG 

Lange Wand 9 

D-31812 Bad Pyrmont, Germany 

Phone: +49 (0)5281 9309-404 

Fax: +49 (0)5281 9309-9404 

 

Amtsgericht Hannover 17HRA 100322 

Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 

 

Email: 

heiko.gerstung@meinberg.de

Web: 

Deutsch https://www.meinberg.de

English https://www.meinbergglobal.com

 

Do not miss our Time Synchronization Blog: 

https://blog.meinbergglobal.com

 

Connect via LinkedIn: 

https://www.linkedin.com/in/heikogerstung