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

[Miroslav Lichvar <[e-mail]>]

On Thu, May 27, 2021 at 09:19:32AM -0400, Daniel Franke wrote:
> Under adversarial conditions, the potential error of my approach is
> ±half-RTT, ± some other miscellaneous error terms that don't amount to
> much by comparison. Without the fixes I've suggested, the potential
> error of your approach is unbounded. With these fixes, it again
> becomes the same as mine.

In a network that has a full hardware PTP support, but not NTP
support, the delay measured by PTP would be smaller than NTP. Whether
that allows a MITM attacker to do more interesting things, I'm not
sure. I think they can always simply stop forwarding the traffic and
let the clocks drift away on their own, even if they don't bother to
mess with their frequency by shifting delays in opposite directions.

> If you want to change my mind about this, I suggest you try convincing
> me that PTP has functions that are auxiliary to time synchronization
> that still need securing. Can an attacker do harm to an unsecured PTP
> deployment in ways other than just desynchronizing clocks?

There is quite a lot of data in the announce message used for various
purposes, which might have an impact further down the synchronization
chain. For example a wrong TAI-UTC offset wouldn't do anything to a
boundary clock keeping time in TAI, but it would have an impact on
leaf clients converting to UTC.

-- 
Miroslav Lichvar