, the PTP must try to determine which packets are PTP messages and forward the reception timestamp to the PTP servo to match to the incoming message. The issues with MACsec combined with PTP can be summarized as follows: The timestamp must be inserted into a packet before it goes through the MACsec block, after which the packet cannot be modified. Therefore, for one-step clocks, the use of PHY-based timestamping does not work. It is possible to try to predict the time that encryption will take and timestamp the PTP message before encryption with the predicted (future) time of transmission. Some vendors claim good results doing this. Two-step clocks might be able to help mitigate this problem and still use PHY timestamping, but if the packet is encrypted, the PHY will not be able to recognize the outgoing Sync as a PTP message, SO other means of tagging the PTP messages are required inside the network element. Even if only integrity checking (no encryption) is being used and the PHY is MACsec aware, the timestamp still must be read back and applied to the Follow_Up message, complicating the implementation. On reception, the PHY will not recognize an encrypted packet as being PTP, SO it would have to timestamp every packet and then match up the timestamps with the correct packets after MAC- sec processing. Some hardware implementations do this already (store the timestamp until the packet has been identified as PTP), SO it is not impossible, but it does complicate the hardware design. A PHY might be able to recognize a MACsec packet that only uses integrity checking (no en- cryption) if it is MACsec aware. What does this all mean? It means that using PTP over a MACsec-enabled link will not generate the same accuracy as a link that is not using MACsec. So, the current choice is either one of the following: Have a secure link Have an accurate timing transfer The PHY vendors have been working to resolve this issue for a couple of years, and components are now becoming available to the industry that allow both features