The PTP AUTHENTICATION TLV

Five Minute Facts About Packet Timing

This is the next installment in our series: what is in the 2019 edition of IEEE 1588. Recently, I posted a discussion about GNSS spoofing, and what to do about it. However, the radio interface is not the only way that a hacker could disrupt the timing on your network. If they were to gain access to your network, then they could attack PTP itself. When I talked to network operators about this possibility, they responded with one of two reactions which could be classified as the first two stages of grieving about the lack of PTP security:

1. Denial: “I am not worried about security. Our network is very secure.” Perhaps, but I remember reading quite a few stories in the news about organizations who’s networks were “very secure,” but got hacked.
2. Anger: “Why doesn’t PTP have security. What are you standards people doing?” Accept it was phrased slightly less polite than that.

One of the principles of good security, is not just to have a good firewall, but also to have some security built into every network appliance and protocol. That is why web pages are usually served with the secure https, not http, even when they are within your enterprise network.

Unfortunately, we do not yet have a complete security solution for PTP yet. So reaction number 2 above seems fair. However, we do have an informative annex of security guidelines, I’ll talk about that next time. And we have the AUTHENTICATION TLV. It is customary to name TLVs in the 1588 standard with all capitals. It’s not that I’m shouting.

The idea of the AUTHENTICATON TLV is that a cryptographic integrity check value (ICV), sometimes called a hash code, can be appended to a PTP message. If anything in the message changes, then the receiving node can detect that by recomputing the ICV and comparing it to the one in the TLV. This involves performing mathematical operations on the bits in the message, except the ICV, and the secret key, resulting in the ICV. The trick is that it is practically impossible to get the right answer unless you know the key, so a man in the middle attack will be detected. Figure 1 shows how the AUTHENTICATION TLV can be added to a PTP message.

The structure of the TLV is shown in Figure 2. The security parameter pointer, or SPP, is an index into a table of security algorithms and associated parameters. This is needed because a PTP node could be exchanging messages with more than one other PTP node. In such a case there could be more than one set of negotiated algorithms and parameters. The security parameter index is an array of flags indicating whether optional fields are present in the TLV or not. The key ID indicates which key is being used. There is a field for a disclosed key, which is used when you have a scheme, such as TESLA, where keys are sent in clear text, only when they are no longer used to secure messages. In other words, if a PTP node is willing to wait after receiving a message until it also receives the key before authenticating the message, then the key distribution mechanism is simple. There is also a sequence number, although the PTP messages all have them as well. RES stands for reserved. That field could be defined in a future version of 1588 in case it turns out there is an important field we forgot to include.

When a PTP node sends a message with the AUTHENTICATION TLV, then the sequence of event is as show in Figure 3. Note that the ICV is calculated after the timestamp, otherwise the timestamp won’t be protected. That poses a challenge for designers of 1-step PTP equipment. For one step the length of time it takes to compute the ICV must be predictable or the timestamp accuracy will suffer, since the timestamp is supposed to correspond to when the message left the port.

Receiving a PTP message with the AUTHENTICATION TLV is a little more complicated. The receiving node checks for the presence of the TLV, computes the ICV and compares it to the one in the message, and checks for a new sequence number (to prevent replay attacks). If any of these checks fail the message is dropped. This is shown in Figure 4.

In order to secure PTP with the AUTHENTICATION TLV we need a system to securely distribute and refresh keys. There are some guidelines for this in the new edition, but a complete key management system has not been defined yet. I know, I know … we’re working on it.

If you have any questions about packet timing, don’t hesitate to send me an email at doug.arnold@meinberg-usa.com, or visit our website at www.meinbergglobal.com.