Re: [Ntp] NTP over PTP

[Doug Arnold <[e-mail]>]

The telecom industry is definitely going to use unicast PTP whether NTP is better or not.  They have invested a lot in PTP and it is all over in their standards.  The telecom industry won’t even go to the bathroom unless there is a standard for it.  People in the power industry sometimes use unicast PTP between substations because their substations are connected using technology barrowed the telecom industry.  Some people in finance also use unicast PTP.  Unicast PTP is here for foreseeable future.  We need to make it as robust as we can.

Doug

From: ntp <[e-mail]> on behalf of Miroslav Lichvar <[e-mail]>
Date: Monday, June 28, 2021 at 9:46 AM
To: Heiko Gerstung <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Ntp] NTP over PTP
On Fri, Jun 25, 2021 at 03:00:25PM +0200, Heiko Gerstung wrote:
> If I follow your argument that unicast PTP is like the NTP control mode then yes, both mode 6 and unicast PTP are not secured against replay and amplification attacks. The NTS4UPTP draft is exactly addressing this for unicast PTP and provides the required protection. I outlined in the draft that the proposed approach achieves most of the stated objectives/goals of NTS4NTP, which is well secured (we certainly agree on that).

If I understand it correctly, your draft is addressing the
amplification issue by requiring client authentication. That's
probably the best one can do, but it doesn't make it comparable to NTP
or NTS4NTP. The operator will still have to trust the clients to not
abuse their credentials and also trust them to not get compromised.
That's nothing like NTS4NTP where you can run a public server without
any worry about someone exploiting your server for amplification.

> In the interim meeting I believe there have been multiple participants that agreed that
> a) PTP should be secured (it is worth it)

At least for the normal non-unicast mode, I agree.

The unicast mode seems to be intended for networks with partial
on-path hardware support, where requirements on accuracy are less
strict, and I think this might already be better supported by NTP.

> Arguing that the two drafts on the table might just need TLS instead of NTS-KE is something I cannot understand, too. PTP already has a security mechanism that is standardized and, with some extensions (provided by the submitted drafts), can be used to significantly enhance security of the protocol. What is needed is a key exchange mechanism and some additional features to close the security holes (i.e. no protection for the source IP address) - again, exactly what the two drafts provide.

Ok, but to me it seems it would be simpler if you have skipped NTS-KE
and went with TLS directly. Anyway, for adopting the document that
shouldn't matter.

> Regarding "NTP over PTP": trying to trick the hardware timestamping engines of a large variety of vendors into timestamping a PTP packet is bound to fail IMHO. There is no standard for how these timestamping engines work, some may even look at sizes of packets (they should not do that, as PTP messages can theoretically carry TLVs, but sometimes hardware vendors take shortcuts). Some implementations will forward packets to a management CPU when the forwarding plane detects a PTP frame. The CPU will not recognize that this is NTP and will probably throw away the packet. Again, most likely not the right way to do it, but alas ...

If there is some hardware that can timestamp only fixed-length PTP
messages with no TLVs, then that will not work with any form of
NTS4UPTP either, right? There has to be some TLV to authenticate the
message and the hardware needs to accept that.

The same applies to one-step clocks. If implemented in silicon, that
will not work in any case.

--
Miroslav Lichvar

_______________________________________________
ntp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ntp