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

[Heiko Gerstung <[e-mail]>]

Hi Miroslav,

even if cookies would not be required, I would still want to keep this concept simply because we can re-use the whole NTS4NTP mechanism and do not have to invent yet another protocol etc. 

Plus, you do not need any state for the unicast negotiation itself. It is a short, quick packet exchange between a client and a GM and once it has been completed, the GM does not need to store any data about the client for the next unicast negotiation. When successful, the GM enters the packet transmission phase (which requires state as the GM needs to set up a packet transmission for a slave), but using the cookie concept for the unicast negotiation phase would allow a NTS-KE server to hand out cookies to a NTS/PTP client who could then use them to request packet transmission from a separate list of Unicast GMs. 

These Unicast GMs would not need any per-client information from the NTS-KE server instance as they can verify the cookie to make sure this is a valid and authorized NTS client. And then it can use the keys included in the cookie to secure the packet transmission.

If you look at this from  the viewpoint of NTS4NTS, you can basically have an identical phase 1 and phase 2 in NTS4NTP is the actual NTP req/resp exchange whereas in NTS4PTP this is the Unicast Transmission Request and Grant exchange. Up until this point, both can use the same mechanisms. Now, in PTP you have another phase (phase 3) which can have much higher traffic requirements (e.g. 128 pkt/s for one client) and therefore should only use the symmetric C2S and S2C keys. 

My proposal is to keep NTS identical between NTP and PTP for phases 1 and 2 and solve phase 3, e.g. by using the symmetric keys established/exchanged in phase 1.

If we choose to go for a completely different approach, this will most probably slow down adoption and we should really not call it NTS anymore... ;-) 

Best 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.21, 12:15 schrieb "Miroslav Lichvar" <[e-mail]>:

    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.

    -- 
    Miroslav Lichvar