[Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption

kristof.teichel@ptb.de Tue, 01 June 2021 20:15 UTC

Return-Path: <kristof.teichel@ptb.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 B45C53A25F4 for <ntp@ietfa.amsl.com>; Tue, 1 Jun 2021 13:15:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.417
X-Spam-Level:
X-Spam-Status: No, score=-1.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, HTML_NONELEMENT_30_40=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 XY9SZpJ6slvx for <ntp@ietfa.amsl.com>; Tue, 1 Jun 2021 13:15:09 -0700 (PDT)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (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 220423A25F3 for <ntp@ietf.org>; Tue, 1 Jun 2021 13:15:07 -0700 (PDT)
Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id 151KF5t2016573-151KF5t4016573 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 1 Jun 2021 22:15:05 +0200
Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id C2BB4B7481D; Tue, 1 Jun 2021 22:15:03 +0200 (CEST)
MIME-Version: 1.0
Sensitivity:
Importance: Normal
X-Priority: 3 (Normal)
In-Reply-To: <CAJm83bCwc9ShP4TPHN3Nz4iK_=+7m4hAYjoogArZ_ZjKfsaTcg@mail.gmail.com>
References: <CAJm83bCwc9ShP4TPHN3Nz4iK_=+7m4hAYjoogArZ_ZjKfsaTcg@mail.gmail.com>, <7F9B8D13-BC90-4E15-9BDF-81714DF0F0C6@meinberg.de> <YLYCLIEA4/unB6/5@localhost> <1DAA3605-CC04-46DE-8CFC-975BED7D4160@meinberg.de> <YLYheZYTSflAdlrF@localhost> <CEB3F4AA-E318-4540-BD6C-4437E3F5F58A@meinberg.de> <YLY3f2/5k1Hjebf7@localhost>
From: kristof.teichel@ptb.de
To: "Daniel Franke" <dfoxfranke@gmail.com>
Cc: "Miroslav Lichvar" <mlichvar@redhat.com>, "ntp@ietf.org" <ntp@ietf.org>, "Heiko Gerstung" <heiko.gerstung@meinberg.de>
Date: Tue, 1 Jun 2021 22:15:01 +0200
Message-ID: <OF159F93FF.03CE9704-ONC12586E7.006EE836-C12586E7.006F3D2F@ptb.de>
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/W8S96h8ZMfY5iG05PiPKLLKV_fQ>
Subject: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption
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 20:15:14 -0000

I think that is a helpful suggestion.
Thanks, Daniel!

I'll suggest to slightly modify the name of the Langer-Bermbach draft to something that more accurately represents a pretty important difference:
Most suggestions here seem to attempt to offer more or less complete solutions from zero to "full" security, while (AFAIK, I'm not very familiar with the 69 page document) this proposal seeks "only" to find a mechanism to do the key management for the PTP standard-defined security TLV solution.
So perhaps something like "NTS4PTP-KE" or "PTPsec/NTS", or even something with 1588 in the name that I can't come up with on the spot, because it is IMO most closely tied to the current 1588 standard document.

Also, apologies that I somehow thought the approach hadn't been suggested here. 
I've heard a lot about it on channels other than this mailing list recently, and apparently got confused.

(I was also thinking that it might be helpful to somehow find and agree on suitable monikers for using the defined PTP security TLV with different key management schemes, such as "PTPsec/GDOI" and "PTPsec/TESLA"; but that is a discussion for another WG I guess.)



-----"ntp" <ntp-bounces@ietf.org> schrieb: -----
An: "Miroslav Lichvar" <mlichvar@redhat.com>
Von: "Daniel Franke"
Gesendet von: "ntp"
Datum: 01.06.2021 21:28
Kopie: "ntp@ietf.org" <ntp@ietf.org>, "Heiko Gerstung" <heiko.gerstung@meinberg.de>
Betreff: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

On Tue, Jun 1, 2021 at 9:35 AM Miroslav Lichvar <mlichvar@redhat.com> wrote:
> Ok, if you need as much of NTS4NTP as possible and at the same time
> keep accuracy provided by hardware timestamping as is supported in
> current hardware, I think the solution is simple: NTS4NTP over PTP.
>
> You can wrap NTP messages in a PTP event message to get hardware
> timestamps and keep all the benefits of NTS4NTP. It seems your plan is
> to provide NTS4NTP in any case. Do you see any disadvantages?

All these long and similar initialisms for the various PTP security
proposals are getting unmanageable, so I'm going to create some new
ones:

* I'm going to start calling my proposal NSCoPE, for NTP Securely
Constraining PTP Errors.

* I'm going to call Miroslav's proposal PEN, for PTP-Encapsulated NTP.

* I'll keep using NTS4NTP for RFC 8915, NTS4UPTP for the
Gerstung-Rohde-Arnold draft, and NTS4PTP for the Langer-Bermbach
draft.

I agree with Miroslav that PEN likely requires a lot less development
effort than NTS4UPTP does, but it still requires changes to both the
server and the client, unlike NSCoPE which can be implemented
unilaterally on the client. There's a tremendous gulf between changing
one line of code on the server and changing zero. A one-line change
requires a full-blown standards-track effort involving multiple
standards bodies, interop testing between vendors, and lots of network
infrastructure that needs upgrading, even if the upgrade is just a
firmware patch. If only client-side changes are needed, none of this
coordination is required.

Maybe a better way to think of PEN is not as a security layer for PTP,
but rather as a way to improve the typical-case precision of NTP by
adding hardware timestamps. It strikes me as a better alternative to
interleaved mode, one which avoids the need for server state or for
sending follow-up packets. It's hardly PTP at all; the fact that
responses come back framed as PTP event messages is just a hack to get
existing hardware to cooperate. The fact that the NTP messages can use
NTS is pretty much incidental. You can do PEN with unauthenticated NTP
messages too and (as long as you're not under attack) get all the same
benefit to precision.

_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp