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