 an Integrity Check Value (ICV) or hash to allow validation of the source of the message and confirm that the message has not been altered during transmis- sion. None of the standard data fields in the PTP message is encrypted, only this added check value allows the receiver to guarantee that it has received the data without having been altered. Generation and validation of the ICV requires a shared key at sender and receiver. This method for generation and sharing of keys is currently outside the scope of the standard, but it requires the building of a robust and secure infrastructure for key generation and distribution. Prong B: Transport Encryption and Security This prong includes methods to enhance the security of the timing signal by encrypting the PTP messages in transit. There are two possible methods for doing this: IPsec: IP security provides a security mechanism to protect data at the network layer (layer 3), which is the IP layer. That makes it possible to use IPsec for those profiles of PTP that use IP for their transport (namely G.8265.1 and G.8275.2). It is not applicable for layer 2 profiles of PTP (such as G.8275.1). IPsec is implemented as end-to-end encryption, which makes using a T-TC in the path almost impossible because it cannot read the PTP message and update the correctionField. Adding a T- BC to the path is also difficult because IPsec requires a lot of hardware resources to run at the speed needed to allow full encryption at line rate (such as multiple 10GE or 25GE links on a T- MACsec: Media Access Control security provides a security mechanism to protect data at the link or MAC layer (layer 2) or the Ethernet layer. This means that MACsec can be used for PT- PoE profiles such as G.8275.1 as well as for all the PTPoIP profiles. MACsec is normally implemented in the hardware of the interface, and any reasonable imple- mentation offers the ability to run at the line rate of the interface (although MACsec adds extra bytes, slightly reducing the throughput). Of course, the hardware to do th