l as ensure the authenticity of the source. Because the hash includes a secret key (previously shared between sender and receiver by a key exchange), the ICV cannot be recalculated by an eavesdropper and the data cannot be modified without detection by the receiver. Of course, the key must be kept secret from any leavesdropper, or they could recalculate a valid ICV after changing the data in the message. There are two processing schemes proposed to use an ICV for integrity validation. Their names and main features are as follows: Immediate security processing: All intermediate and end nodes have shared the current key in advance, and the PTP data can be immediately validated through standard cryptographic techniques. Delayed security processing: The key used to generate the ICV is distributed only after it is no longer used (and cannot be used to generate new ICV fields). This allows the clock to validate the already-received PTP data at some point in the future once the key has been replaced. This method requires the receiver to store the messages until the required keys have been shared, and then the stored PTP messages can be verified. Of course, not having the current key in the delayed security processing mode makes it impossible to modify the correctionField at intermediate transparent clocks without invalidating the ICV. One approach to circumvent that problem is to assume the updatable fields (such as correctionField) are zero during the calculation of the hash, which means those fields can be changed without invalidat- ing the ICV-which seems to defeat the point of the whole scheme. As illustrated in Figure 11-15, it is also possible to combine both approaches on the same messages, SO that the PTP message could contain two TLVs, one for immediate processing and one for delayed processing. The TLV also includes a sequence number to prevent replay attacks (whereby previ- ously transmitted messages are re-sent later to mislead the slave clock with stale timestamps). There are two basic key distribution meth