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

[Heiko Gerstung <[e-mail]>]

Martin, 

if the term cookie implies outsourcing state information for you, that’s fine. As I wrote earlier, there is no state information required in the cookie in the proposed approach, just like with NTS4NTP it only contains the keys, a nonce and the algorithm. The state is stored (‚outsourced‘ to) in the unicast GM.

Regards,
Heiko

—
Heiko Gerstung 
Managing Director 
 
MEINBERG® Funkuhren GmbH & Co. KG 
Lange Wand 9 
D-31812 Bad Pyrmont, Germany 
Phone: [phone] 
Fax: [phone] 
 
Amtsgericht Hannover 17HRA 100322 
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 
 
Email: 
[e-mail]
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

> Am 08.03.2021 um 18:05 schrieb Langer, Martin <[e-mail]>:
> 
> 
> 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.: [phone]
> Web: https://www.ostfalia.de/cms/de/pws/bermbach/mitarbeiter/martin-langer
> 
> 
> 
> Von: Doug Arnold <[e-mail]>
> 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 <[e-mail]> on behalf of Heiko Gerstung <heiko.gerstung=[e-mail]>
> Date: Monday, March 8, 2021 at 11:32 AM
> To: Dieter Sibold <[e-mail]>, Miroslav Lichvar <[e-mail]>
> Cc: Watson Ladd <[e-mail]>, NTP WG <[e-mail]>, Langer, Martin <[e-mail]>
> Subject: Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp
> Am 08.03.21, 13:13 schrieb "Dieter Sibold" <[e-mail]>:
> 
> 
> 
> >    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
>  >   > [e-mail]
>  >   > 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: [phone] 
> Fax: [phone] 
>  
> Amtsgericht Hannover 17HRA 100322 
> Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 
>  
> Email: 
> [e-mail]
> 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
>  
>  
> 
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp