Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

"Langer, Martin" <mart.langer@ostfalia.de> Mon, 08 March 2021 17:05 UTC

Return-Path: <mart.langer@ostfalia.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 082413A10A0 for <ntp@ietfa.amsl.com>; Mon, 8 Mar 2021 09:05:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level:
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 yKo0pRxKNe8A for <ntp@ietfa.amsl.com>; Mon, 8 Mar 2021 09:05:07 -0800 (PST)
Received: from mx2.sonia.de (mx2.sonia.de [141.41.1.238]) (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 5C5853A118F for <ntp@ietf.org>; Mon, 8 Mar 2021 09:05:00 -0800 (PST)
Received: from mx2.sonia.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 571AB10800C5 for <ntp@ietf.org>; Mon, 8 Mar 2021 18:04:57 +0100 (CET)
Received: from exchange04.resource.sonia.de (exchange04.resource.sonia.de [141.41.8.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx2.sonia.de (Postfix) with ESMTPS id 50CE310800C0 for <ntp@ietf.org>; Mon, 8 Mar 2021 18:04:57 +0100 (CET)
From: "Langer, Martin" <mart.langer@ostfalia.de>
To: NTP WG <ntp@ietf.org>
Thread-Topic: [Ntp] Comments on draft-langer-ntp-nts-for-ptp
Thread-Index: AQHXEfmMSKND+BsUuke89/+0bAqpHap4wuQ/gAEYJYCAAAi0AIAAEEoAgABIUICAAAHKgIAAE+UD
Date: Mon, 8 Mar 2021 17:04:56 +0000
Message-ID: <cf069a4c93b349889290b8b382e53ce7@ostfalia.de>
References: <CACsn0cnz1GfKUKn6q61qmAbs=VPgTGFZnP=kEeQHk9CUxLACXg@mail.gmail.com> <f51dfb1db7c843ecaf58efac526d30ef@ostfalia.de> <6C614D22-A00E-432E-A65E-9A21F8B4476E@meinberg.de> <YEYHHhIrYv4ZhTkl@localhost> <675BBD71-AEE4-4DA5-A64F-40C86BB9755C@gmail.com>, <A069DFA5-ABBE-433A-8811-62CE860374BF@meinberg.de>, <AM7PR02MB5765CC7A3E0335C0A7828E50CF939@AM7PR02MB5765.eurprd02.prod.outlook.com>
In-Reply-To: <AM7PR02MB5765CC7A3E0335C0A7828E50CF939@AM7PR02MB5765.eurprd02.prod.outlook.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [141.41.8.54]
Content-Type: multipart/alternative; boundary="_000_cf069a4c93b349889290b8b382e53ce7ostfaliade_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/1_5ZHUzU_76SpzLkOhY1EmLY8kE>
Subject: Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp
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: Mon, 08 Mar 2021 17:05:11 -0000

Of course, I am also in favor of a solution that is as simple as possible.
Especially since our NTS4PTP design is already quite complex. But we
cannot jeopardize the security.

Whether 'ticket' or 'cookie' is a question of context and requirements. The
term cookie implies state outsourcing for me. And ticket is to me a data
set to get access to a resource. Much more interesting is the question of
what data needs to be exchanged and why.

I am currently under stress and thus I can only respond with some delay.
We should deal with everything objectively and contrast solutions if necessary.
I am thinking if Etherpad would be a possibility to present something like this
in a better way.


-martin-


-------------------
Martin Langer, M.Eng.
Ostfalia Hochschule für angewandte Wissenschaften
- Hochschule Braunschweig/Wolfenbüttel
University of Applied Sciences

Labor Datentechnik, Labor Design Digitaler Systeme
Fakultät Elektrotechnik
Salzdahlumer Straße 46/48
38302 Wolfenbüttel
Germany

Tel.: +49 5331 939 43370
Web: https://www.ostfalia.de/cms/de/pws/bermbach/mitarbeiter/martin-langer



________________________________
Von: Doug Arnold <doug.arnold@meinberg-usa.com>
Gesendet: Montag, 8. März 2021 17:38
An: Heiko Gerstung; Dieter Sibold; Miroslav Lichvar
Cc: Watson Ladd; NTP WG; Langer, Martin
Betreff: Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp


Most PTP Grandmasters are also NTP servers.  So we should think about how to efficiently implement such time servers, not PTP Grandmasters and NTP servers separately.



Doug



From: ntp <ntp-bounces@ietf.org> on behalf of Heiko Gerstung <heiko.gerstung=40meinberg.de@dmarc.ietf.org>
Date: Monday, March 8, 2021 at 11:32 AM
To: Dieter Sibold <dsibold.ietf@gmail.com>, Miroslav Lichvar <mlichvar@redhat.com>
Cc: Watson Ladd <watsonbladd@gmail.com>, NTP WG <ntp@ietf.org>, Langer, Martin <mart.langer@ostfalia.de>
Subject: Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

Am 08.03.21, 13:13 schrieb "Dieter Sibold" <dsibold.ietf@gmail.com>:



>    On 8 Mar 2021, at 12:14, Miroslav Lichvar wrote:
>
>   > On Mon, Mar 08, 2021 at 11:43:29AM +0100, Heiko Gerstung wrote:
>    >> As far as I can see, up until this point the mechanism can be very
>    >> similar to NTS4NTP. We most probably need a different cookie format,
>    >> but the rest should be OK. Once we did 1 + 2, the unicast master will
>    >> start the PTP packet transmission to the authenticated (via the
>    >> cookie) PTP client. The client will also start sending Delay Req
>    >> packets and requires the GM to respond with unicast delay responses.
>    >>
>    >> During this packet transmission phase I propose to use the S2C to
>    >> secure the packets from the GM to the client (ANNOUNCE, SYNC,
>    >> DELAY_RESP) and the C2S key to secure the packets from the NTS/PTP
>    >> client to the GM (i.e. DELAY_REQ).
>    >
>    > I don't think it makes sense to use NTS cookies in PTP, even if you
>    > limit the NTS support to the unicast mode. The main point of the
>    > cookies is to avoid having client-specific state on the server. That's
>    > not possible in PTP as announce and sync messages are not responses to
>    > requests. They are sent at their own interval, which can be different
>    > from the delay request interval.
>    >
>    > In PTP there has to be some client-specific state and the clients need
>    > to be authenticated. Very different from NTS-for-NTP.

>    I agree with Miroslav. There is already state information defined in the
>    IEEE 1588-2019 version in the context of the Authentication TLV. It
>    should be possible to use them also for this purpose. This would make
>    things easier compared to offload state information via cookies to the
>    slaves and would minimize computational for the master.

A PTP unicast master can respond to 128 delay req/s and send 128 sync packets per second to each slave, we are talking quite powerful machines here and I do not think we have to store state information in the cookie.

A client - just like with NTS4NTP - uses the cookies it gets from the NTS-KE server to authenticate itself vs the unicast GM. The cookies basically provide proof that the client successfully communicated with the NTS-KE and correctly ran phase 1. We would need a little bit of extra state information that needs to be stored on the unicast GM (which already stores state information for every client that successfully requested a unicast transmission).

My biggest point here is this: yes, it would be possible to design a more lean and more efficient protocol for PTP because PTP already requires some state information being stored on the server. But I believe that this would only save an insignificant number of bytes and CPU cycles on the GM and also on the unicast PTP client. As a benefit, we would get something that is close to how NTS4NTP works, allowing simpler implementation (the NTS-KE part is almost identical and an NTS-KE server would only require some minor modifications to work with unicast PTP clients) and a much faster adoption by the PTP hardware vendors.

Regards,
   Heiko



 >  >
 >   > --
 >   > Miroslav Lichvar
 >   >
 >   > _______________________________________________
 >   > ntp mailing list
 >   > ntp@ietf.org
 >   > https://www.ietf.org/mailman/listinfo/ntp


--
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