This article has been accepted for publication in a future issue of this journal, but has not been

fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2019.2918597, IEEE
Transactions on Instrumentation and Measurement

Impact of Cyberattacks on Precision Time Protocol

Casimer DeCusatis, Robert M. John Houston, Paul Wojciak,
Lynch, William Kluge Steve Guendert
Marist College IBM
Poughkeepsie, NY USA Poughkeepsie, NY USA
casimer.decusatis@marist.edu jhouston@us.ibm.com

Abstract—The IEEE 1588 standard known as Precision Time Protocol (PTP) was developed to provide highly accurate and
synchronized clocks for a wide range of applications. In particular, it is critical for latency sensitive applications such as enterprise-class
financial transactions. In this paper, we analyze some of the security risks associated with this protocol, in particular cyberattacks that
disrupt synchronization between multiple PTP devices or synchronization between the system clock and PTP hardware. We construct
an experimental PTP test bed and perform baseline measurements of synchronization between multiple clocks. We then demonstrate
successful attacks that disrupt PTP synchronization, including vulnerabilities based on the lack of message authentication between
master and slave clocks. Proposed mitigations of these vulnerabilities are discussed, in an effort to improve next generation
implementations of this timing protocol or recommend additional external authentication devices in the network architecture.

Keywords—Precision time protocol, authentication, identity, security

I. INTRODUCTION
Enterprise-class data centers, telecommunications back haul systems, cloud service providers, and others rely on a timing
subsystem that is used to synchronize networked servers and other data processing equipment. Generally, such networks contain
a so-called “master clock” which provides a time reference to synchronize one or more “slave clocks”. Common examples of this
approach include the well-known network time protocol (NTP), first published as a request for comments (RFC 958) in 1985 and
later updated (RFC 5905) in 2010 [1]. Theoretically NTP can achieve timing accuracy of up to 1 ms, although in practice
accuracies of tens to hundreds of ms are fairly common. Recently, a need for more accurate time synchronization has emerged.
Regulatory agencies such as the non-profit entity Financial Industry Regulatory Agency (FINRA), the U.S. Securities and
Exchange Commission (SEC), and the European Securities Market Authority (ESMA) Markets in Financial Instruments Directive
(MiFID) are placing enhanced time accuracy demands on businesses. For example, FINRA has issued increasingly tighter time
synchronization requirements since 2008 [2]; currently, financial sector computers must be synchronized to within a 50
millisecond drift tolerance of the NIST atomic clock [3, 4]. Similarly, ESMA MiFID regulatory standards [5] increased the
tolerance of clocks to 100 microseconds or less. Both SEC and ESMA have proposed new requirements as low as one
microsecond for some applications. These timing synchronization requirements are significantly lower than NTP can achieve. For
enterprise financial markets, vendor proprietary timing protocols that exceed the capabilities of NTP have been developed in an
attempt to address this problem. High resolution time-of-day clocking was first introduced on the IBM System/370 mainframe
architecture [6]. This approach was enhanced by the IBM 9037 Sysplex Timer [7], the first timing protocol capable of
maintaining time-of-day synchronization over 100 km using specialized hardware. More recently, IBM Z Systems enterprise
servers have adopted the proprietary Server Time Protocol (STP), a message-based protocol in which timekeeping information is
passed over coupling links between servers in a coordinated timing network [6]. While STP is capable of 10-microsecond
accuracy, it is only supported by IBM enterprise servers. Also, STP compliance with FINRA and ESMA requires additional
wiring infrastructure that can be problematic and costly to deploy. Research on precise timing distribution for high performance
computing applications [8] faces significant technical and cost issues, including lack of backward compatibility with STP, which
precludes the adoption of such approaches in enterprise applications. Thus, there is a strong desire to design future enterprise
systems around an open industry standard clock protocol with improved accuracy. It is also desirable for future systems to be
compatible with extended distance links (using WDM) and emerging software-defined network (SDN) controllers, which can
impose unique timing requirements.

The IEEE 1588 standard, known as Precision Time Protocol (PTP) [8], is an emerging candidate for addressing increased
timing requirements in enterprise applications. The PTP standard defines a distributed network of clocks, or PTP nodes, arranged
in a master-slave hierarchy. A central clock, or grand master, coordinates time across the entire PTP network. Redundant,
secondary master clocks take over if communication with the grand master is lost. The protocol measures and compensates for
propagation time delays over the network (similar to the approach taken by earlier proprietary protocols). While NTP accuracy

0018-9456 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2019.2918597, IEEE
Transactions on Instrumentation and Measurement

was limited by timing jitter induced by messages passing through the network operating system stack, PTP improves accuracy by
timestamping packets at the lowest levels of the hardware. This is achieved using PTP-aware network interface cards (NICs),
which timestamp messages just before they are transmitted across the physical layer. Security was not a priority for early efforts
at network time synchronization using NTP, PTP, or other proprietary protocols. Time stamp information was not considered to
be sensitive data, and the perceived risk of attacks targeting clocks was considered too low to justify the use of additional, heavy
weight security mechanisms. In recent years, security functions have emerged as a more critical requirement for network time
synchronization in enterprise applications. This is due to a combination of factors, including increased numbers of interconnected
networked devices, decentralized systems, new use cases, regulatory requirements [9], and documented examples of attacks
against timing protocols [10-14]. Some forms of attacks against PTP have been proposed [15, 16] although these have not
previously been experimentally demonstrated. A threat model was proposed under RFC 7384 [14], which recognizes significant
risks posed by clock masquerade attacks, denial of service attacks at various network layers, and other issues. While time
information itself may not be secret data, there are privacy considerations associated with the identity of master and slave clocks.

The PTP standard defines a security extension in Annex K [17], which is intended to provide group source authentication and
message integrity, as well as preventing replay attacks that might affect clock integrity. However, Annex K was not well adopted
or implemented, and a number of weaknesses in this approach have been identified [18]. Consequently, Annex K does not
mitigate the attacks demonstrated in this paper. Much of the prior security work in this area addresses key distribution problems,
including proposals to use IPSec [19] and MACSec [20] or otherwise modify key distribution [21]. Alternative proposals for
improving the methodology of Annex K have led to revised internal recommendations of the IEEE security committee [22],
including the proposed Annex S [23]. The IEEE 1588 V3 draft standard is in the sponsor ballot phase, and the new standard,
including Annex S, is scheduled for a final ballot vote sometime in 2019. This version may include different approaches to
delayed authentication. As of this writing, work is ongoing in the PTP technical community, and it is unclear whether Annex S
will mitigate the attacks demonstrated in this paper. Further, once the specification is finalized, it must still be implemented and
tested, meaning that any potential mitigations are still some time away from widespread adoption.

In this paper, we present experimental results from a PTP test bed that demonstrate successful insider threat attacks. These
include a novel class of denial of service (DoS) spamming attacks that can permanently skew the slave’s clock, and a master clock
takeover attack. These attacks are relatively straightforward to implement for a skilled practitioner, and can significantly
compromise any application relying on PTP. We propose mitigation techniques that would require modification of the PTP
standard, and demonstrate mitigation using an identity-based authentication system. The remainder of this paper is organized as
follows. After an introduction to motivate the timing coordination problem and related background work on PTP, Section II
provides a brief overview of the PTP architecture and discusses features that will be used later in our analysis. Section III
develops our experimental test bed and establishes baseline PTP performance. In Section IV, we present experimental results of a
sync spoofing DoS attack and master clock spoofing attack, and discuss the potential impact and possible mitigation techniques.
Finally, Section V summarizes our conclusions and potential areas for future work.
II. PTP ARCHITECTURE AND SECURITY CONCERNS
The PTP protocol consists of three main layers, namely grand master election, sending timestamped messages, and a
management layer. Grand master election uses the Best Master Clock (BMC) algorithm, a form of distributed leader election that
runs continuously on all master-candidate PTP nodes. Each candidate node sends an ANNOUNCE message declaring the quality
of its time source and related management information, and the algorithm elects a grand master clock. The grand master then
multicasts its timestamp to all slave nodes. This is done via a SYNC message, sent to all nodes on a periodic basis. In principle,
PTP can thereby select the highest quality available time source. The difference in time between the slave and master clocks is
known as the master offset. In this paper, we will use the PTPv2 version of the standard, which makes use of several different
timing services. In particular, the PTP4L service is used to synchronize multiple PTP devices. This service, in turn, produces an
output that is used by a second service, PHC2SYS, responsible for synchronizing the system clock to the PTP hardware clock. In
order to evaluate cyberattacks against the PTP protocol, we will measure the time offsets in both the PTP4L and PHC2SYS
services; attacks which are capable of introducing an incorrect time offset in either or both of these services will have devastating
effects on the attached systems. To our knowledge, this is the first experimental verification of cyberattacks that disrupt
synchronization between multiple PTP devices or synchronization between the system clock and PTP hardware.

The IEEE 1588 security model is a multi-pronged approach involving PTP integrated security mechanisms, external transport
security mechanisms, and architecture mechanisms [22]. We will provide only a brief overview for our purposes. PTP integrated
security is based on a security TLV (Tag Length Value) that is added as an extension to the PTP message. The contents of the
security TLV depends on which PTP instance is communicating and which key management protocol is being utilized. While the
specification for key management is outside the scope of IEEE 1588, key sharing is typically achieved by group based key
management protocols, such as the Group Domain of Interpretation specified in RFC 6407 [24]. Implementation of this method

0018-9456 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2019.2918597, IEEE
Transactions on Instrumentation and Measurement

requires a centralized key distribution center that distributes symmetric session keys and security policy parameters to PTP
instances. Delayed key sharing is based on the Time Efficient Stream Loss-Tolerant Authentication (TESLA) method defined in
RFC 4082 [22]. This provides for the delayed distribution of a source authentication key, enabling delayed verification of PTP
message integrity between a sender and receiver. As we will demonstrate, this may not be sufficient to stop certain attacks.

Data centers rely on PTP to insure data integrity, including proper time ordering of transactions, meeting recovery time
objectives (RTO) and recovery point objectives (RPO) for business continuity and disaster backup, and much more. Security for
the timing network is essential, since there is no end to the damage a bad actor might accomplish if they could steer the clock or
make it unavailable. Many programs rely on a reference clock to establish time-of-day and unambiguously determine the ordering
of serialized events, such as updates to a database. Erroneous time stamping could result in events seeming to occur out of order,
or to lack any real certainty of when or whether they actually occurred. In cases where UTC is incorrectly configured or
distributed from the best master clock, the slave is said to be running in a temporal vortex [8, 9]. Further, if the master clock or
announce/sync messages could be corrupted, it may be possible to induce time skips or missing time (a condition in which the
slave clock is significantly out of sync with the master clock, so that scheduled events such as backups do not occur when
scheduled). If events can be made to occur out of order, it may be possible to generate backups with incorrect time stamps; this is
an example of inducing causality violation.

Hardware timestamping as used in PTP breaks support for most cryptographic primitives, since encryption applied by a higher
level in the software stack must happen before the message is sent. Further, there is a critical interdependence between security
mechanisms and timing synchronization. Many security solutions, such as signed keys or certificates, require an accurate time of
day clock to determine whether they are valid and for how long. Thus, we require accurate timing to establish a valid security
system, and a valid security system to confirm the accuracy of the time stamps. This fundamental issue is not easily addressed.
The Annex K security protocol is based on a pre-shared symmetric key, which is used to authenticate two PTP nodes via a 3-way
handshake. While prior work explores ways to extend Annex K to improve key distribution or establish secure channels between
PTP nodes, there has been comparatively little work in mitigating other types of threats to PTP networks. In particular, Annex K
does not consider insider threats, or attacks originating from elsewhere on the same PTP network. While there has been some
discussion of insider threats in the context of implementing elliptic-curve public key signatures for PTP [21], much remains to be
done in this area. Details of the proposed Annex S remain under development and subject to change as of this writing.
III. PTP TEST BED BASELINE PERFORMANCE
The following section describes experimental results, which establish a baseline for timing synchronization in our PTP test
bed. These baseline measurements will be used for comparison with our PTP security attacks, and to establish that the timing
variations seen during our attacks are not attributable to other factors in the test bed. This insures that our test bed results are
representative of realistic PTP applications. The measurements made in our test bed represent what a system administrator would
see in their management application. All measurements were conducted using PTP version 1.8, and were repeated several times to
improve accuracy; typical results are shown for each case. All tests were conducted using Intel x86 based servers, specifically
multiple identical IBM System X servers (x3550 M3) each equipped with Intel X540-AT2 PCI NICs and running Ubuntu Linux
17.1, All measurements reported in this paper were conducted in the Marist Innovation Lab at Marist College, Poughkeepsie, NY
and independently confirmed using a duplicate setup at the IBM system test floor, Poughkeepsie, NY.

Details of the PTP protocols and frame structures are provided in the IEEE 1588 standard and elsewhere [8, 9] and will not be
repeated here. Figure 1 shows the simplest possible use case, where two servers are directly connected with a short (10 meter)
copper cable. This should produce the minimal timing delay between two systems, for use as a baseline for comparison in our
subsequent measurements. The first server is configured as PTP master and the other as PTP slave. Following a brief start-up
period, the master and slave sync up and remain synchronized to within +/- 1 nanosecond worst case, for an hour-long
measurement period. This configuration serves as a baseline for comparison with our subsequent measurements.

Figure 1 - Direct server-to-server PTP connection. Time offset between master and slave over a period of about 5 minutes.

0018-9456 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2019.2918597, IEEE
Transactions on Instrumentation and Measurement

Our next step was to insert a single switch into the configuration to observe any differences. We first demonstrated the impact
of using a switch that does not support PTP (the Cisco G2050). As expected, the master/slave no longer remain in
synchronization; we observed intermittent, bursty excursions of the time offset, as high as 600-800 nanoseconds in some cases.
We then repeated the measurements using an IBM/Lenovo G8264 switch, which is capable of supporting PTP. The PTP links are
on the same shared network as a few other switch ports, which are carrying nominal traffic for this experiment. As expected with
PTP disabled at the switch, the resulting time offsets vary significantly, though not as much as for the switch that did not support
PTP (peak time excursions for the IBM/Lenovo switch with PTP disables were 100-150 nanoseconds). Enabling PTP on the
IBM/Lenovo switch (known as “transparent mode” in the PTP standard) under the same conditions described previously (PTP
port sharing a network with other ports running background traffic) yields reduced time offsets compared to the prior case as
expected, but still measurably worse than a direct server-to-server connection. Worst-case time excursions in this case are on the
order of 80 nanoseconds. Additional experiments were conducted with the PTP links isolated on their own dedicated timing
network for PTP traffic for comparison with the previous cases when PTP links shared a network with other traffic. The
maximum measured time excursions for a supported PTP switch in the network under different configuration conditions are
summarized in Table 1.

Table 1 – maximum time excursions with a PTP supported switch in the link (all times in nanoseconds)
PTP off PTP on
Shared traffic 100 – 150 80
network
Dedicated timing 100 50 - 80
network for PTP

Continuous availability of timing networks, achieved via redundancy, is essential for secure enterprise applications including
business continuity and backup/recovery operations. For NTP systems, redundancy is a client side responsibility, which often
entails following multiple NIST-certified clock sources. By contrast, in the PTP protocol failover and redundancy are the
responsibility of the server side. If a primary clock source becomes unavailable, there is a free wheel period during which clocks
may drift before a redundant secondary clock source becomes available. To evaluate these effects, we implemented a failover test
setup consisting of a grand master, secondary master, and slave. Initially, the grand master comes online with priority. The
secondary master then detects this condition, and slaves itself to the grand master. We then run a test program that turns off the
PTP4L service on the grand master; the secondary master comes online as a master clock when it detects this change. Two
minutes later, our test program restarts PTP4L on the original grand master, at which point the secondary master goes back into
slave mode and returns control to the original grand master. We repeat this test cycle every two minutes over a 30 minute test
interval, and observed peak time dispersion of 1 ms. We then repeated the failover measurements using a different test program,
which interrupts the NIC every two minutes rather than restarting the PTP4L process. This produced significantly larger time
dispersion between the slave and grand master, up to 1.3 seconds in some cases. The resynch time suggests that the freewheel
period is still much shorter than the drift associated with the grand master clock. In order to avoid disturbing jumps in the clock
timing, it will be important to insure that the grand master and its secondary master clock are tightly synchronized with each
other. The average timing excursion we measured before resynchronization occurs is 58 ns; based on this data, we should assume
a typical tolerance of +/- 58 ns for all subsequent measurements, keeping in mind that under some conditions the resync time can
be much larger.
IV. SELECTED ATTACK VECTORS AND MITIGATIONS
In the following section, we discuss a few specific attack scenarios that target time synchronization of PTP nodes, and provide
experimental demonstration of these attacks for the first time. We also discuss variations on the demonstrated attacks, along with
suggested mitigation techniques. We note that the effects discussed in this section may result from misconfigurations or other
non-malicious intent, in addition to deliberate cyber-attacks on PTP. The experimental test bed used to investigate PTP is shown
in figure 2 (although we used a single-tier network, this approach can easily be generalized to multi-tier hierarchical timing
networks). The attacks we describe are conducted from a server on the same timing network as the intended target (i.e. an insider
threat). The attack code is written in Python 3.6, and uses a Python tool called Scapy [26] to construct the spoofed packets used in
these attacks.

0018-9456 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2019.2918597, IEEE
Transactions on Instrumentation and Measurement

Figure 2 – Experimental test bed for PTP attack testing.

A. Master Spoof DoS Attack

This attack relies on spoofing high volumes of ANNOUNCE and SYNC packets against a PTP network, thereby forcing the
slave’s clock out of sync with the authentic master clock and the rest of the network. In order to create realistic spoofed packets,
we sniff the unencrypted PTP traffic from a grand master. Because of the way PTP networks use multicast addresses, an attacker
could subscribe to the addresses used by PTP, then listen for packets sent by the master clock. We ignore packets being returned
from the slave to the grand master, since they are not required for this attack and would add extra complexity (for example, an
attack using such packets would also have to belong to the same IGMP group as the slave). Since details of the packet structure
are available in the public domain, we could have also crafted spoofed packets from scratch and eliminated the network sniffing.
If we do not sniff packets, we would have to guess the clock ID of the grand master, to avoid packets being recognized as
illegitimate. We would also need to guess the proper sequence IDs for spoofed packets from the grand master. This is not
difficult since there is a limited range of monotonically increasing sequence IDs, and the protocol specifies that the sequence ID
should be the same for all slaves (so that any slave can accept PTP packets from the grand master). We might send a high volume
of packets with varying sequence IDs in order to eventually guess the correct value and cause a collision.

We launched a DoS attack by spamming the target slave with spoofed packets (292 packets per second). We effectively create
a rogue grand master, which is sending relatively high volumes of ANNOUNCE and SYNC packets to the PTP network at the
same time as the valid grand master is sending its own ANNOUNCE and SYNC packets at a much slower rate. It took only 37
seconds, including time to sniff packets, for the slave's PTP4L service to drop to an offset of -2149.5 minutes and a PHC2SYS
service offset of -35 seconds. The attack continued for a total of thirty minutes. During this time, we observed a maximum offset
of 2,306.9 minutes and a minimum of -2341.1 minutes for the PTP4L service. Incredibly, the maximum offset we observed in all
our testing from this type of attack was over 48 years. It is important to note that we did not attempt to forge the packet delay in
our spoofed packets. Packets only contained information relevant to identifying the master clock. We also did not need to disrupt
communication between the grand master and the target slave. Results are shown in figure 3. Based on our measurements, the
high volume of packets disrupts the PTP4L service, which then changes the clock frequency to incorrect values. It is difficult to
determine exactly what happens in the source code behavior to create this result.

Figure 3 – Slave PTP4L output master offset (vertical axis, minutes) vs time (horizontal axis, minutes) for pre-attack, attack, and post-attack periods (vertical
dashed lines)

0018-9456 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2019.2918597, IEEE
Transactions on Instrumentation and Measurement

We do not need to know the IP address of the slave since multicast is supported; the multicast address (224.0.1.129) and port
(320) always remain the same. The clock ID of the slave is also not required, as the PTP packets we send do not have that as a
field. We only need to know the MAC address of the PTP enabled switch in order to launch this attack. Although the slave
recognizes that something is wrong (as reflected in the syslog and management console details), it still accepts our spoofed SYNC
packets. Essentially, the slave receives many spoofed packets telling it to re-adjust its clock, overwhelming the valid SYNC
packets and causing the slave clock to drift away from the correct time. In this manner, we were able to steer to target slave’s
PTP4L service up to an offset of 2306.9 minutes from the master after only one or two minutes into the attack. Even after the
thirty minute attack period, the slave is unable to recover the correct time. Since many applications will be disrupted by much
smaller discrepancies in timing, this attack can significantly impact the PTP network. When the attack is launched against a PTP
node, all nodes below this one in the timing network hierarchy are impacted.

The hardware clock is also affected by this attack. We recorded the state of the PTP Hardware Clock (PHC) using the output of
the PHC2SYS service. Figure 4 shows the offset of the PHC. While, the PHC does not see the massive spikes during the attack
period like PTP4L, it still experiences much larger differences than during normal operation. In this test, the PHC2SYS service
had a maximum offset of seven seconds and a minimum of -1333.3 minutes. It should also be noted that PHC offsets may be
more attractive for an attacker, since they directly affects the system clock.

Figure 4 – PHC Offset (vertical axis, minutes) vs time (horizontal axis, minutes) for pre-attack, attack, and post-attack periods (vertical dashed lines)

Significantly, even after the 30 minute attack period had stopped, the target slave does not always recover the correct time
after the attack stops. In some cases, we allowed the network to run for over an hour after the attack stopped without the slave
clock showing any significant progress towards the correct time. Due to a feature of the Linux-ptp algorithm that limits the
amount the clock is able to adjust at one time, it was only able to recover 6.6 minutes during the thirty minute aftermath period
(clock re-adjustments are limited to a maximum of 0.1 second increments). While this slow re-adjustment period may be helpful
in keeping multiple clocks from moving too far out of synchronization, it will inhibit the slave’s ability to recover from being
very far out of sync with the grand master. While this feature is configurable, changing from the default adds the risk of other
attacks being able to rapidly change the clock. Since many applications will be disrupted by much smaller discrepancies in
timing, this attack can significantly impact the PTP network. When the attack is launched against a PTP node, all nodes below
the target in the timing network hierarchy are impacted, as well as the hardware clock (which depends on the output of the PTP4L
process). This attack is fairly simple to execute; our Python code to inject fake packets is only about 1500 lines, and easily fits on
a USB or other portable device. If a visitor to the data center has a few minutes of physical access to one of the servers, the attack
can be easily completed. Many variations are possible, including planting the packet spoofer as a logic bomb designed to trigger
at some later date, or as a worm or virus which propagates throughout the network, testing whether the servers, NICs, or routers it
encounters have PTP hardware timestamping enabled, and launching a spoofing attack against any such nodes that are
discovered.

When considering possible mitigations for this attack, it is important to recognize that the attack succeeds because there is no
way for the slave to verify the identity of its grand master. Thus, the slave will accept spoofed SYNC messages with the correct
sequence number, apparently originating from the grand master’s IP address. Put another way, the messages from the grand
master to the slave do not have any session semantics. The PTP header contains a sequence ID field, but this is only used to
distinguish one message from another. Further, there is no binding between the identity of the PTP master and the network ID
(i.e. IP address). This issue may be addressed in several ways. For example, we might construct the master clock ID from its
network ID, instead of the current method that uses IEEE EUI-64 assigned clock IDs [12]. It would then be possible to implement
a way for the slave to derive the master’s network address from its clock ID, and send messages back to the master clock, which
would verify whether the messages being sent to the slave were genuine. Alternately, we might modify the standard to append a
nonce to the first message originating from the master, and increment this value for each subsequent message. In this manner,

0018-9456 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2019.2918597, IEEE
Transactions on Instrumentation and Measurement

each packet sent from the master would have a unique ID within a given range of available IDs, and the slave could verify that a
received message ID matches this range.

Another possible form of mitigation relies on establishing a digital identity for master nodes, and only accepting packets at the
slave that originate from masters with a valid identity. One example of this approach is the use of first packet authentication
(FPA) with transport access control (TAC). We have discussed this approach in previous publications [27], and will only provide
a brief overview here. This approach authenticates the first packet of a network connection request using a 64-bit cryptographic
identity token. The token is inserted into the packet header by a software or hardware endpoint at the master clock. Tokens are
later authenticated by a gateway software or hardware appliance at the far end of an untrusted network. In this case, all slaves
(including the secondary master clock) would have an authentication gateway. When a secondary master clock takes over, it
would also begin to send authentication tokens to all remaining slaves. This approach, known as first packet authentication (FPA),
allows us to authenticate packets at the earliest possible time (i.e. when a network connection request is initially made between
two devices). Since the tokens are only valid for four seconds, the authentication application itself would still require a valid time
source (as discussed previously, there is a critical interdependence between security mechanisms and timing synchronization). To
address this, the token insertion/authentication applications derive their valid time stamps from the consensus of multiple trusted
clock sources, such as the atomic clocks at various NIST certified government laboratories. All unauthorized traffic (including
port scans) is then dropped at the transport level, so an unauthorized traffic source (such as our spoofed master clock) does not
receive any acknowledgment or feedback concerning its attempted attack. This approach, known as transport access control
(TAC), helps isolate and protect clock services from unauthorized access. Our test bed implements FPA and TAC using software-
based authentication gateways from Blackridge Technologies [27]. In our test bed, we were able to completely block this attack
using authentication gateways to insure that only master clocks with the correct digital identity were accepted by PTP slave
nodes.

A possible approach to detecting this attack and avoiding large time errors at the slave would involve checking the frequency
stability of the slave’s local oscillator. If the frequency stability between the grand master and slave is significantly worse than the
previously known frequency-stability of the slave, then we know that the grand master or the time-transmission path has
developed a problem. In this case, we could generate an alert to the system administrator. To avoid large time errors at the slave
we might disable the network timing and just use the slave local oscillator temporarily until the problem goes away. Of course, if
the master clock is disabled for a significant period of time, this defeats the purpose of having a remote time service.

As mentioned previously, this attack leaves recognizable fingerprints in the console manager and syslog. This can be used to
mitigate the attack. Although we could modify the attack to make these signatures less obvious (for example, by launching packet
bursts of different durations) it should be possible for a defender to dynamically filter the syslog for possible attack signatures.
Once the attack is identified, we can raise high priority alerts or take automated corrective action. This basic approach was
described in our previous work [25], in which we demonstrated the GrayLog open source log parser as a tool for detecting
conventional DDoS attacks. Using our cloud test bed, we have also demonstrated using a system orchestrator to dynamically
block such attacks; for example, by deploying a pre-defined “response recipe” that would block spoofed PTP packets with a
router’s access control list. We have written software to perform these operations (the Lightweight Cloud Application for Real-
Time Security (LCARS) [28]), as a first step towards developing autonomic, zero trust cloud networks. Details of this work have
been discussed previously, and our open source code is available from the Marist Innovation Lab GitHub site [29].

B. Announce packet DoS attack

A variation on the previous attack, which is simpler to implement, involves spoofing only the ANNOUNCE packets and
spamming the target slave. We used this attack to test if the undefined behavior of the slave during a DoS attack was simply due
to the volume of packets being sent, or if it occurred due to collisions in sequence IDs between the spoofed packets and authentic
packets. A sequence ID collision occurs when the sequence ID is the same for both spoofed and authentic packets. To study this
effect, the attack was performed in two different ways. First, we guaranteed there were no collisions between the authentic master
and spoofed master. This was done by sniffing packets from the authentic master to predict the sequence ID, and intentionally
avoiding that ID while incrementing the ID of our spoofed packets. Results of this test method are shown in figures 5(a-b).

0018-9456 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2019.2918597, IEEE
Transactions on Instrumentation and Measurement

Figure 5(a) – Slave PTP4L output master offset (vertical axis, minutes) vs time (horizontal axis, minutes) for pre-attack, attack, and post-attack periods (vertical
dashed lines), no sequence ID collisions.

Figure 5(b) – Slave PHC2SYS output master offset (vertical axis, minutes) vs time (horizontal axis, minutes) for pre-attack, attack, and post-attack periods
(vertical dashed lines), no sequence ID collisions.

Second, we repeated the test, again sniffing and predicting the sequence ID of the master, but in this case the spoofed packets
intentionally matched the ID of the authentic master. Results of this testing are shown in figure 6(a-b).

Figure 6(a) – Slave PTP4L output master offset (vertical axis, minutes) vs time (horizontal axis, minutes) for pre-attack, attack, and post-attack periods (vertical
dashed lines), with sequence ID collisions.

Figure 6(b) – Slave PHC2SYS output master offset (vertical axis, minutes) vs time (horizontal axis, minutes) for pre-attack, attack, and post-attack periods
(vertical dashed lines), with sequence ID collisions.

0018-9456 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2019.2918597, IEEE
Transactions on Instrumentation and Measurement

As shown in these figures, results from the two tests with and without sequence ID collisions are virtually indistinguishable.
This shows that for this attack to succeed, we do not need to know the sequence ID of the authentic master. Simply performing a
DoS attack on a PTP slave with spoofed announce packets is sufficient to cause a major disturbance in system timing. The same
basic types of mitigation described in the previous master spoof DoS attack are effective at mitigating this attack, including the
use of FPA with TAC. In our test bed, this attack was completely blocked by the use of FPA with TAC.

C. Master Clock Takeover Aattack

The final attack we discuss in this paper is perhaps the most serious, involving an evil twin of the master clock that can take
over control of the timing network. The PTP standard uses the so-called Best Master Clock (BMC) algorithm to select a primary
time source. It is possible to advertise a prospective master clock which claims to have atomic clock time precision (the highest
available precision), even if this prospective clock is an attacker masquerading as a real clock source. The bogus clock will then
be selected as the best master clock, allowing the attacker to arbitrarily adjust the time offsets. Since this attack involves selecting
an evil twin master clock, the attack would not normally be detected by the syslog while the attack is in progress. Forensic
analysis might reveal that a bogus master clock was used, but by this point the attack would already be complete.
The attack consists of two steps, namely a sniffing step that is done once and a spoofing step that is run on a loop for the
duration of the attack. First, packets are sniffed from the master clock source to determine the sequence ID and rate at which the
master clock sends out ANNOUNCE and SYNC packets. This enables the attacker to create a bogus clock with the same
attributes as other masters in the network. Second, the attacker crafts spoofed ANNOUNCE, SYNC, and DELAY_RESPONSE
packets for the duration of the attack. This is accomplished by sending ANNOUNCE and SYNC packets, then sniffing for and
replying to the DELAY_RESPONSE sent to the bogus master.
We have demonstrated this attack by simulating a master clock that advertises atomic precision, as shown in the WireShark
trace of figure 7. Results of the attack are shown in figure 8(a-b). This attack is significantly more complex than the previous ones
discussed in this paper, as it requires constant sniffing of packets from every slave server on the bogus master. It is not realistic
for only one slave to respond to the bogus master. Even in our test environment with only one dedicated slave, there will still be
more than one slave to our bogus master, as the genuine master in the network will also accept the bogus atomic clock as its own
master. The attack would still work without responding to multiple slaves, but it would be much easier to detect, as any slave not
getting a response would record timeouts in its logs. To sniff the packets fast enough, we created a separate thread from our main
attack program and used a custom implementation of Scapy's sniffing method to get the required information for a response.
Responses are crafted and sent as soon as a request is received.
Each test consisted of a thirty minute control period during which the real master and slave can sync, a thirty minute attack
period, and a thirty minute post-attack period where we observed the aftermath of the attack. These time periods are noted in
figure 8 along with the results of our attack. The packets from the bogus master clock had minimal changes to their time
correction values. All delay responses had a correction value of -1.0 ns. A variation of this attack could implement more precise
time steering by changing these values as necessary. Note that in our network, follow-up messages were sent outside the control
of our attack program. These follow-up messages had correction values of either -1.0 ns or -2147483649 ns. Their IP address was
identical to our bogus master, and their PreciseOriginTimestamp fields matched the OriginTimestamp fields for our bogus SYNC
messages. During the attack, the PTP4L service on the slave generated the message “port 1: received SYNC without timestamp”
for the duration of the attack. This message would normally indicate that a timestamp had been dropped while receiving a packet
(which is a rare event), and suggests the slave would not take action (due to lacking timestamp information), i.e. the PTP4L
service would be unresponsive. We also did not receive any report of offsets or frequencies from the PTP4L service. Despite this,
we observed that the PCH2SYS service still changed its offsets as one would expect during normal operation, and did not report
any messages aside from normal updates on offset and frequency adjustments. During this period of unresponsiveness from the
PTP4L service, the PHC2SYS service reported an average offset of -237 ms, including a large timing spike. By the end of the
attack, the PHC2SYS service was reporting an offset of six ns. When the attack completed, we observed a timing spike that
appears to be the inverse of the spike at the beginning of the attack. This suggests that the offsets seen during the attack are due to
the slave syncing with the bogus master, then readjusting to the authentic master when the attack is complete. Our data shows the
PTC2SYS service reporting changes, despite a lack of output from the PTP4L service This leads us to suspect that the PTP4L
service is still accepting packets and modifying its time, even though there is no log entry to indicate this behavior.

0018-9456 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2019.2918597, IEEE
Transactions on Instrumentation and Measurement

Figure 7 – WireShark trace showing a simulated master clock advertising atomic precision

Figure 8(a) – PTP4L offset from master; dashed vertical lines indicate pre-attack period, attack period, and post-attack period.

Figure 8(b) – PHC2SYS offset from master; dashed vertical lines indicate pre-attack period, attack period, and post-attack period.

This attack caused other effects on the slave besides the offset reported by the PTP4L and PHC2SYS services. The clock
frequency responded in a similar way, as shown in figure 9(a-b) (note the same gap in the PTP4L graph due to the lack of data
from the unresponsive PTP4L service). By controlling packets from the bogus master clock, we were able to steer the slaved
clocks a significant distance away from actual time. As noted previously, the attack succeeds because there is no way for the
slave to verify the identity or properties of the grand master.

0018-9456 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2019.2918597, IEEE
Transactions on Instrumentation and Measurement

Figure 9(a) – PTP4L frequency; dashed vertical lines indicate pre-attack period, attack period, and post-attack period.

Figure 9(b) – PHC2SYS frequency; dashed vertical lines indicate pre-attack period, attack period, and post-attack period.

Further, we note that unlike the previous two DoS attacks, the master takeover attack does not generate a significant change in
overall network traffic. This makes it much harder to detect, since network traffic during the attack is not discernable from
normal traffic patterns. This is illustrated by the network data shown in figure 10.

Figure 10 – Network traffic pattern to the slave during master takeover attack.

These experiments suggest that the PTP4L service is unable to endure situations outside of its intended operating parameters.
Although monitoring the PTP4L service is a good way to check for malicious events, we observed that the system management
outputs for this service do not necessarily describe what is actually occurring. Improved monitoring would improve this situation,
but will not mitigate the attack by itself. Possible mitigation methods for this attack might include implementing authentication on
the master clock with an external authentication appliance, or proposing a method for the slave to query and verify the master
clock’s IP address and attributes. In our test bed, we determined experimentally that the use of authentication appliances with
FPA and TAC completely blocked this attack.

V SUMMARY AND CONCLUSIONS

We have constructed a PTP experimental test bed, and characterized its baseline timing behavior. We then experimentally
demonstrated an insider threat in the form of a DoS attack, which floods the target with ANNOUNCE and SYNC packets to

0018-9456 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2019.2918597, IEEE
Transactions on Instrumentation and Measurement

incorrectly steer the clock. Timing dispersion for this attack was significantly higher than the normal synchronization tolerances for
our test bed. We also demonstrated a variation on this attack, which is easier to conduct, in which a flood of ANNOUNCE packets
is capable of disrupting the slave clock. Finally, we demonstrate a master clock takeover attack, in which we can spoof a master
clock that claims better time accuracy than other available alternatives. Mitigation techniques for these attacks are discussed,
including authentication schemes that may be designed into the system architecture using first packet authentication and transport
access control. There is ongoing development of the PTP standard, particularly the finalization and implementation of Annex S.
While we feel that the attacks discussed in this paper may remain viable after the final implementation of Annex S, this remains to
be tested as part of our future research.

ACKNOWLEDGMENT
We gratefully acknowledge the support of Marist College and the New York State Cloud Computing and Analytic Center (CCAC), as well as support from the
National Science Foundation under CC*DNI Integration (Area 4): Application Aware Software-Defined Networks for Secure Cloud Services (SecureCloud) Award
#1541384.

REFERENCES

[1] D. Mills, J. Martin (Editor), J. Brubank, and W. Kasch, “Network Time Protocol version 4: Protocol and Algorithm Specification”, RFC 5905, (June
2010) https://tools.ietf.org/html/rfc5905 (last accessed July 11, 2018)
[2] Financial Industries Regulatory Authority (FINRA) on SEC notice 16-23 (July 2016) http://www.finra.org/industry/notices/16-23 (last accessed July 11,
2018)
[3] J. Yao, J. Sherman, T. Fortier, H. Leopaldi, T. Parker, J. Levine, J. Savory, S. Romisch, W. McGrew, X. Zhang, D. Nicolodi, R. Fasano, S. Schäffer, K.
Beloy, and A. Ludlow, “Progress on Optical-clock-based Time Scale at NIST: Simulations and Preliminary Real-Data Analysis”, Navigation (Journal of the
Institute of Navigation), p. 1-8, May 2018 https://www.researchgate.net/publication/325116208_Progress_on_Optical-clock-
based_Time_Scale_at_NIST_Simulations_and_Preliminary_Real-Data_Analysis (last accessed April 4, 2019)
[4] J. Levine, “The statistical modeling of atomic clocks and the design of time scales”, invited review article, Review of Scientific Instruments vol 83, 021101
(28 pp.), (February 2012) https://tf.boulder.nist.gov/general/pdf/2531.pdf (last accessed April 4, 2019)
[5] MiFID Regulatory Technical Standard 25 Annex from the European Commission report (July 6, 2016)
http://ec.europa.eu/finance/securities/docs/isd/mifid/rts/160607-rts-25-annex_en.pdf (last accessed July 11, 2018)
[6] E. Chencinski, M. Check, C. DeCusatis, H. Deng, M. Grassi, T. Gregg, M. Helms, A. Koenig, L. Mohr, K. Pandey, T. Schlipf, T. Schober, H. Ulrich, and C.
Walters, “IBM System Z I/O subsystem”, IBM Journal of Research and Development, vol 53, no 1, paper 6, p. 6.1 - 6.13, (January 2009)
[7] F. Injey, N. Dhondy, G. Hutchinson, D. Jorna, G. Kozakos, I. Neville, “Server Time Protocol Planning Guide”, IBM Redbook SG24-7280, 185 pp. ,
available from www.ibm.com/redbooks (December 2006)
[8] J. Serrano, P. Alvarez, M. Cattin, E. Garcia Cota, J. Lewis, P. Moreira, T. Wlostowski, G. Gaderer, P. Loschmidt, J. Dedi, R. Bar, T. Fleck, M.Kreider, C.
Prados, and S. Rauch, “The White Rabbit Project”, paper TUC004, Proceedings of ICALEPCS2009, Kobe, Japan (2009)
[9] C. DeCusatis, Editor, Handbook of Fiber Optic Data Communication, 4th edition, Academic Press, N.Y., (2013)
[10] IEEE 1588-2008, IEEE Instrumentation and Measurement Society. TC-9 Sensor Technology, "IEEE standard for a precision clock synchronization protocol
for networked measurement and control systems", 2008.
[11] K. O’Donoghue, “Emerging solutions for time protocol security”, IEEE International Symposium on precise clock synchronization for measurement,
control, and communications (ISPCS) (Sept 4-9, 2016)
[12] A. Malhortra, I. Cohen, E. Brakke, and S. Goldberg, “Attacking the network time protocol”, IEEE Symposium on Network and Distributed Systems
(NDSS), Feb. 2016
[13] D. Plonka, “Flawed routers flood University of Wisconsin Internet Time Server,
http://pages.cs.wisc.edu/~plonka/netgear-sntp/ (last accessed Feb. 6, 2019)
[14] D. Goodin, “DoS attacks that took down big game sites abused Web’s time sync protocol”, http://arstechnica.com/security/2014/01/dosattacks-that-took-
down-big-game-sites-abused-webs-time-sync-protocol (last accessed October 5, 2018)
[15] L. Constatin, “Attackers use NTP reflection in huge DDoS attack”, http://www.computerworld.com/article/2487573/networksecurity/attackers-use-ntp-
reflection-in-huge-ddos-attack (accessed October 5, 2018)
[16] D. Arnold, “Options for PTP Security”, Presented at ITSF 2015, Eidenburgh, U.K. (2015)
[17] J. Tsang and K. Beznosov, “A security analysis of the Precise Time Protocol” (short paper), Proc. ICICS 2006 (P. Ning, S. Qing, and N. Li, editors), LNCS
4307, pp. 50-59 (Springer-Verlag, Berlin, 2006)
[18] T. Mizrahi, “Security requirements of time protocols in packet switched networks”, RFC 7384, DOI 10.17487/RFC7384, October 2014 http://www.rfc-
editor.org/info/rfc7384 (last accessed October 5, 2018)
[19] C. Onal and H. Kirrman, “Security improvements for IEEE 1588 Annex K: implementtion and comparison of authentication codes”, IEEE International
Symposium on precise clock synchronization for measurement, control, and communications (ISPCS) (Sept 24-28, 2012)
[20] E. Itkin and A Wool, “A security analysis and revised security extension for the precision time protocol”, Proc. IEEE Instrumentation and Measurement
Society (2016)
[21] C. Kaufman, P. Hoffman, Y. Nir, P. Fronen, and T. Kivinen, “Internal key exchange protocol version 2 (IKEv2)”, STD 79, RFC 7296, DOI
10.17487/RFC7296, October 2014 http://www.rfceditor.org/info/rfc7296 (last accessed October 5, 2018)
[22] IEEE 802.1AE, IEEE Standard for local and metropolitan area networks: media access control (MAC) security, August 2006
[23] D. Reilly, H. Stenn, D. Sibold, “Network time protocol best current practices” draft-ietf-ntp-bcp-00, July 2016 https://datatracker.ietf.org/doc/draft-ietf-ntp-
bcp (last accessed October 5, 2018)
[24] K. O’Donoghue, D. Sibold, and S. Fries, “New security mechanisms for network time synchronization protocols”, IEEE Instrumentation and Measurement
(2017)

0018-9456 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TIM.2019.2918597, IEEE
Transactions on Instrumentation and Measurement

[25] Annex S, Working Draft Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems, IEEE P1588/D1.4, p.
494-513 (July 2018)
[26] B. Weiss, S. Rowles, T. Hardjono, “The group domain of interpretation, RFC 6407, October 2011 https://tools.ietf.org/html/rfc6407 (last accessed October
5, 2018)
[27] A. Perrig, D. Song, R. Canetti, J.D. Tygar, and B. Briscoe, “Timed efficient stream loss-tolerant authentication (TESLA): multicast source authentication
transform introduction”, RFC 4082, June 2005 https://tools.ietf.org/html/rfc4082 (last accessed October 5, 2018)
[28] Scapy interactive packet maipulation tool, https://scapy.net/ (last accessed October 4, 2018)
[29] C. DeCusatis, P. Liengtiraphan, A. Sager, “Advanced Intrusion Prevention for Geographically Dispersed Higher Education Cloud Networks”, Proc.
IEEE/ACM International Conference on Remote Engineering & Virtual Instrumentation (REV 2017), Columbia University, New York, NY (March 15-17,
2017)
[30] D. Eidle, S. Ni, C. DeCusatis, and T. Sager, “Autonomic security for zero trust networks”, Proc. IEEE 8th annual ubiquitous computing, electronics, and
mobile communications conference, Columbia University, October 19-21, 2017
[31] Marist Innovation Lab Github, https://github.com/Marist-Innovation-Lab (last accessed October 4, 2018)

0018-9456 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.