Re: [Ntp] NTP over PTP

[Heiko Gerstung <[e-mail]>]

> Am 28.06.21, 15:46 schrieb "ntp im Auftrag von Miroslav Lichvar"
> <[e-mail] im Auftrag von [e-mail]>:
> 
> 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.
That is true and it is a result of the way the protocol is designed. 

>> 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.
They might be less strict but that does not mean they are worse/equal compared to NTP. With HW timestamping on the server and client, you can remove the impact of the multitasking OS network stack in the end devices and "partial" on path support means that at least some of the switches/routers can have PTP support. Plus there are use cases where you can have full on-path support because you are running a private network of a certain size (for example a whole full blown hyperscale DC). In those cases (and probably many more), NTP is not an alternative.

>> 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.

OK. 

>> 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.

No, that's not correct. The hardware timestamping is only required during phase 3 (packet transmission), which does not require an NTS TLV as it relies completely on the AUTHENTICATION_TLV and the integrated PTP security. See 3.3 of my draft. The NTS TLV is required in phase 2 where client and server only exchange messages to negotiate the transmission, and those are not hw timestamped. 

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

Again, depends on the implementation and the choices made by the designers. I do not want to say that such a flawed implementation is the rule, and I also do not want to imply that the whole concept cannot work, but I am sure that it is not the solution to the problem we wanted to solve with NTS4UPTP. 

Best 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