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

[Heiko Gerstung <[e-mail]>]

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