[Ntp] NTP over PTP

[Miroslav Lichvar <[e-mail]>]

The NTP WG was asked to secure the PTP unicast mode considering it has
experience with securing NTP. The problem is that the PTP unicast mode
is very different from the NTP client/server mode, the only mode which
I think we can claim to be well secured (by symmetric key and NTS).
The closest thing to the PTP unicast mode would be the NTP control
mode (6), which is not secured (e.g. against replay attacks).

I suspect there is nothing here to be reused to secure the unicast
PTP. There might be some practical advantages of sharing NTS-KE with
NTP, but I don't see any security benefits. The two drafts that were
discussed here just need TLS and might actually be simpler if they
used it directly.

With this WG still having NTP in its name, there is the uncomfortable
question that has to be asked. Why can't you just use the NTP
client/server mode instead of the PTP unicast mode?

A point was made that there is still a lot of hardware that supports
only plain PTP. It doesn't support PTP secured by IPSec, MACSec, DTLS,
etc, either. This was apparently one of the reasons for writing the
NTS4UPTP draft.

That has a simple solution. Use PTP as a transport for NTP messages.
The hardware doesn't care what is inside as long as it can recognize
the PTP header to trigger the timestamping.

I submit this idea as a (very short) draft:
https://datatracker.ietf.org/doc/html/draft-mlichvar-ntp-over-ptp-00

I understand some people won't like this as an answer to the question
of securing the unicast PTP. It would be useful in other cases too.

But is it worth trying to invent a PTP-specific solution to secure its
unicast mode, when the result cannot possibly be as good as what NTP
already has?

As I understand it, the unicast mode of PTP was invented mainly for
some of the telco profiles, which for the most part seem to emulate
NTP. What exactly was missing in NTP when those profiles were written?
IIRC someone mentioned it was discussed with the NTP WG at the time,
but I don't have any references.

-- 
Miroslav Lichvar