[secdir] draft-ietf-ntp-over-ptp-06 ietf last call Secdir review

[Daniel Migault via Datatracker <[e-mail]>]

Document: draft-ietf-ntp-over-ptp
Title: NTP Over PTP
Reviewer: Daniel Migault
Review result: Has Nits

Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

The final paragraph of the introduction contains some minor issues.

In the security considerations, I understand that PTP correction cannot be
authenticated. If I am not mistaken, I believe that such authentication would
necessitate the PTP layer to be authenticated. I suspect that the PTP protocol
has an extension, and that DTLS, IPsec, or MACsec could also be utilized. While
in some instances this might contradict the original purpose of benefiting from
a hardware implementation of PTP, in other scenarios, such as the O-RAN
fronthaul, MACsec is currently proposed to secure Ethernet packets that
encapsulate PTP over eCPRI. For the IP fronthaul, MACsec, IPsec, and DTLS
remain potential candidates.

Naturally, authentication does not mitigate attacks based on delayed packets. I
have the impression that PTP recommends different paths.

Port randomization appears to be more of a privacy-related concern. However, I
have the impression that a single value is being utilized by every client. If
this is accurate, then the port does not facilitate session tracking.
Conversely, the two drawbacks are that using predictable ports may simplify
spoofing attacks even from outside the network. Furthermore, if port
randomization cannot be implemented system-wide due to PTP, it may not be
activated; however, I believe that the issue pertains to other applications
(not PTP). If this is correct, it seems to me that the draft should clarify
that the systems affected are those for which port randomization cannot be
activated or disabled on a service basis.

If the comment below were accurate, I believe that these could be reflected in
the security considerations section.

Yours,
Daniel