Re: [Ntp] A simpler way to secure PTP

[Heiko Gerstung <[e-mail]>]

Daniel, with hardware timestamping in the end nodes you can improve the delay measurement considerably. With hardware timestamping in the network infrastructure, e.g. using TCs, you can improve this even further. These mechanisms are not available to NTP nodes. Applying lucky packet filters at a packet rate of 128 packets/s will improve your calculated RTT by using only 1% of the RTT measurements. There is quite a lot you can do to improve accuracy over a network link that you cannot currently do with NTP. Due to all the above mentioned measures, the precision with which PTP can measure the RTT is typically orders of magnitudes higher than with NTP resulting in a much better “worst outcome”. 

 

As Doug already mentioned, there are quite a lot of PTP applications in the field which require better than 1us accuracy, and even more that require better than 10us accuracy. I do agree that, in a perfect network with (more or less) static delays and end nodes with low latency network stack implementations, you can achieve the same level of accuracy with NTP that you achieve with PTP, but there are many networks and applications out there with not-so-perfect conditions. I am sure we all do not want to get into a PTP vs NTP discussion here, there are just a lot of applications that require/use PTP and I believe it is a good idea to improve security for it. 

 

And, to me a network time security approach is not limited to a protection against time manipulation. It should also add protection against abusing the protocol to carry out amplification attacks and disrupt the protocol in any possible way. Yes, if you have a man-in-the-middle being able to simply drop your packets to deny synchronization to your end nodes, you are screwed. But at least your end nodes immediately notice that they do not receive any packets anymore. You can also carry out a delay attack and do a lot of other nasty things. However, protecting the protocol against some malicious attacker being able to inject arbitrary packets into the network is still a desirable goal IMHO.

 

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

 

 

 

Von: ntp <[e-mail]> im Auftrag von Daniel Franke <[e-mail]>
Datum: Montag, 10. Mai 2021 um 17:22
An: Doug Arnold <[e-mail]>
Cc: Miroslav Lichvar <[e-mail]>, NTP WG <[e-mail]>
Betreff: Re: [Ntp] A simpler way to secure PTP

 

On Mon, May 10, 2021 at 10:43 AM Doug Arnold <[e-mail]> wrote:

I have heard of people actually doing this in the field as a sanity check.

 

However, some applications that use PTP can be broken by introducing timing errors that are less than the expected difference between PTP and NTP.

 

You cannot solve this with cryptography. An adversarial network is, by definition, one where you can't rely on statistical behavior and can't neglect the probability of worst-case outcomes. The worst-case outcome for any unicast protocol is going to be at least half the measured RTT, and for a broadcast protocol the worst case is unbounded. As I've mentioned before, you can improve this a little bit if you know a lower bound on the physical distance `d` between the client and server, in which case you can shrink each of your bounds by `d/c` where `c` is the speed of light, but this still won't get you anywhere near the kind of precision you have in mind. If worst-case, let alone typical-case, NTS4NTP behavior is going to break your application in critical ways, then you MUST have a physically-secure link to your time source. If you have an adversary on your communication path, you're just screwed and cryptography can't save you.

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