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

[Miroslav Lichvar <[e-mail]>]

On Tue, Jun 01, 2021 at 04:18:09PM +0200, Heiko Gerstung wrote:
> > Am 01.06.21, 15:35 schrieb "Miroslav Lichvar" <[e-mail]>:
> > The idea is that DTLS protects everything except the sync and delay
> > request messages. The unicast negotiation would be protected, of
> > course.
> 
> OK, that is something you have to describe in detail. 

The PTP general port (320) would move to a new port, which would be
protected by DTLS. The client would open a DTLS session with the
server on that port and use it for all messages normally transmitted
on the general port. The key needed for authentication of event
messages could be generated by the client and provided to the server
in a new TLV together with the request-unicast-transmission TLV. The
server would use the key to authenticate sync messages for the client
and verify ICV in its delay requests. Just the first thing that came
to my mind. I'm sure it could be improved.

> > 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?
> 
> Yes, because unicast PTP does not work in the same way as NTP. NTP is based on a request/response exchange while unicast PTP is not. I would certainly be possible to put NTP4NTS messages into PTP, but that would have the same drawback that I see with Daniel's proposal to use NTP4NTS to secure the time error of PTP: you need to setup an NTS4NTP infrastructure and basically run two sync protocols plus one security/key exchange protocol in parallel. NTS4UPTP only requires you to run one sync protocol and a key exchange protocol. 

If you used only NTP4NTS over PTP, you would still have only one sync
protocol. Just the transport is different. That's a couple lines of
code.

> I would also not be happy with the efficiency, because an NTS4NTP packet probably has some redundant or unnecessary information in it that is not required when I run unicast PTP. And, the other way around, adding a full "dummy" PTP packet header to enable using the hw timestamping engine to hardware timestamp my NTS4NTP packets is a waste of bandwidth and CPU cycles. 

If you compare the PTP header to the NTS uniq ID and cookie, I don't
think it's so bad.

> Such a NTS4NTP protocol also does not address the other advantage that unicast PTP has over NTP: higher packet rates. You can change that too, of course. In the end you created a third time sync protocol which to me looks more like a Frankenstein monster version of NTP/PTP and is a completely different beast. It will be neither compliant to NTP, nor PTP.

I'm not sure I follow here. You can send NTP requests at any rate you
like. That doesn't require a new protocol. The poll field is a signed
8-bit integer if you had a server that actually looked in the content
of the field.

Yes, server performance might be worse due to the need to decode and
encode a cookie with each request, but that's a price you need to pay
if you want all the benefits of NTS4NTP. I'd expect in most cases the
HW-timestamping to be the bottleneck. If not, you could use
AES-GCM-SIV instead of AES-SIV-CMAC for cookie encryption to get a
better performance.

> It may work and add more accuracy to NTP4NTS, but has nothing to do with PTP. And yes, you can argue that nobody needs PTP anymore in that case, but I am not sure it will be a pleasant discussion.

Right. :)

-- 
Miroslav Lichvar