ISPCS 2009 International IEEE Symposium on Precision Clock Synchronization for Measurement, Control and Communication Brescia, Italy,

October 12-16, 2009

Delay Attacks - Implication on NTP and PTP Time Synchronization Markus Ullmann
Federal Ofce for Information Security D-53133 Bonn Germany WWW home page: http//www.bsi.bund.de and University of Applied Sciences Bonn-Rhein-Sieg Email: markus.ullmann@bsi.bund.de

Matthias V ogeler
NXP Semiconductors Business Line Identication D-21147 Hamburg Germany WWW home page: http//www.nxp.com Email: matthias.voegeler@nxp.com

AbstractIn this paper specic variants of delay attacks are examined. First, the Network Time Protocol is regarded. Second, delay attacks and implications on the time synchronization of the Precise Time Protocol are described. In particular, consequences for the offset calculation Oprox are regarded. At the end of the paper possible countermeasurements are described. Index TermsIEEE 1588 (v2, 2008), Precise Time Protocol (PTP), Network Time Protocol (NTP), delay attacks, implication on time synchronization, countermeasurements, cryptographic protocols

Datagram Protocol (UDP) over the Internet Protocol (IP) or eldbus communication (IEC 61158 Type 10) are given. In principle, delay attacks can be applied on all protocol layers, e.g. by manipulating switches, routers or gateways, IP communication or the routing using different communication routes for the Sync messages respectively Delay Req messages, see [5]. C. Structure of the Paper The rest of the paper is organized as follows: Section II starts with a description of delay attacks concerning the NTP protocol. Furthermore, implications on the NTP time synchronization are given. PTP claims to put a precise synchronization of clocks into effect. Therefore, it has to be under examination whether maliciously caused delay attacks induce specic time failures. In the following section III delay attacks on the PTP protocol are analyzed and described in detail. Consequences of this analysis are presented in section IV. Mechanisms to counter the mentioned delay attacks are exposed in section V. After all, section VI summarizes the ndings of this paper. D. Used Notation Figure 1 describes the used abbreviations within this article. II. N ETWORK T IME P ROTOCOL A. Delay Attacks NTP is a protocol for synchronizing slave clocks of computer systems over packet-switched data networks, see [6]. NTP uses UDP as transport protocol. In contrast to the PTP protocol, NTP does not approximate the offset Oprox of the slave clock. Instead, NTP directly calculates the time value of the slave clock tSC . Therefore, the slave clock sends a request for the current time to the master clock. The slave clock measures the elapsed time T between

I. I NTRODUCTION A. Known Security Attacks Regarding time synchronization, ve threat types are discussed, see [1] and [2]. 1) Modication of time values 2) Masquerading as the master clock 3) Replay of old messages 4) Denial of service attacks 5) Delay of synchronization messages Without doubt security attacks with the greatest inuence on a reliable time synchronization are the rst four. Obviously, specic cryptographic protocols are capable to counter the mentioned attacks 1, 2 and 3. A rst approach using a Message Authentication Code based on the HMAC function, see [3], and a message counter is already integrated in the new standard version [4]. But up to now the consequences of maliciously caused delay attacks (5) on NTP and especially PTP are not sufciently analyzed. That is the topic of this paper. B. PTP Communication Technologies The PTP protocol describes a standard to synchronize clocks that are connected with technologies like network comunication or local communication. In [4], PTP mappings for communication technologies like a layer-2 Ethernet, User

978-1-4244-4392-5/09/$25.00 2009 IEEE

Abbreviation DM S DSM T ref TSync D Dprox tM C tSC Treq O Oprox d s

Semantics one-way propagation delay (master slave) one-way propagation delay (slave master) two-way propagation delay reference value two-way propagation delay (Sync message and response) genuine one-way propagation delay approximated one-way propagation delay time of the master clock time of the slave clock time interval between Sync message and Delay Req message genuine offset of a slave clock approximated offset of a slave clock deceleration coefcient acceleration coefcient
Fig. 1. Abbreviations

Fig. 3.

NTP, put the clock back attack

T /2 with Dprox = T /2. In reality, the assumption DSM = DM S may not hold, especially if an attacker has to be considered by the slave clock. In this case the slave clock would erroneously apply the formulae tSC = tM C + Dprox , which results in a wrong time for the slave clock. It is exactly this implicit assumption, which can be exploited by an attacker to manipulate the time synchronization of a client. If an attacker delays DM S = dDSM , d > 1, the computed time is d+1 tSC = tM C + DSM (4) 2
1 Now, tSC is by d 2 DSM behind the correct time tM C . Figure 3 illustrates this behavior. If on the other hand an attacker delays DSM = dDM S , d > 1, the computed time is

Fig. 2.

Network Time Protocol

tSC = tM C + sending the request and receiving the time response tM C from the master clock. The both-way communication lasts DSM for the request and DM S for the time response. Figure 2 describes the function of the NTP protocol to synchronize slave clocks. The following system of equations can be established: tSC T = = tM C + DM S DSM + DM S (1) (2)

d+1 DM S 2

(5)

1 In this case tSC is by d 2 DM S ahead the correct time tM C . Figure 4 represents this behavior. It follows, if an attacker is able to delay both communication directions independently, he can decide whether the slave clock is ahead or behind the master clock tM C . And in addition the extent of the failure is initially not limited.

B. Limitation of Propagation Delay Failure Up to now, no mechanism is known to counter delay attacks completely. It is only possible to limit the extent of the propagation delay failure, if the following advice is followed: The time synchronization shall fail if DM S + DSM exceeds a dened maximum propagation delay value Tmax . So, if T Tmax the slave clock shall abort the current NTP protocol run and shall start a new synchronization attempt.

Obviously, this system of 2 equations has 3 unknowns and cannot be solved. The trick of the NTP-protocol is to add a 3rd relation by doing a simplication: DSM = DM S (3)

Then the system of equations has the solution tSC = tM C +

Fig. 4.

NTP, clock forward attack

Fig. 5.

Precise Time Protocol

Unfortunately, the described countermeasure enables denial of service attacks on the NTP protocol. If an attacker is permanently able to delay the NTP request or response signals, such that T Tmax , no time synchronization takes place at all. We would like to emphasize that delay attacks on NTP are even possible, if cryptographic protocols are used to realize authentic and replay free time synchronization processes. III. PTP D ELAY ATTACKS A. PTP Time Synchronization According [4], time synchronization is performed over three phases: master clock selection, time offset synchronization, and communication delay measurement. Here, we concentrate our description on the following phases: time offset synchronization, and communication delay measurement. Figure 5 describes the function of the Precise Time Protocol to synchronize client clocks. The time offset Oprox of the slave clocks is approximated with the following formulae, see [4] and [7], Oprox = = (t + O + DM S ) t Dprox O + DM S Dprox (6) (7)

Equation 9 calculates the average of DM S and DSM . Obviously, the desired relation Oprox = O only holds if Dprox = DM S which is equivalent to DM S = DSM . (10)

It is again this implicit assumption of the PTP protocol, which can be exploited by an attacker to manipulate the time synchronization of a client. Figure 5 describes the normal time behavior without any attack. B. Attack Description In reality, the approximation of Dprox according formulae (8) leads to a failure of the calculation of Oprox , if DM S = DSM . The IEEE 1588-2008 standard already mentions delay asymmetry, but do not cover this issue. In particular, formulae (8) may not hold, especially if an attacker has to be considered. In this case the slave clock would erroneously apply the formulae Dprox = (DM S + DSM )/2, which results in an unprecise Dprox calculation and in consequence in an erroneously approximation of the time offset Oprox . First, we assume an attacker who delays messages. 1) Delay Messages: Formulae 11 describes the propagation delay Dprox if an attacker delays a Sync message. If DM S = d DSM , d > 1: Dprox = DSM 1+d ,d > 1 2 (11)

The propagation delay Dprox is measured and approximated according following formulae, see [4]. (t + O + DM S ) t 2 (t + Treq + DSM ) (t + O + Treq ) + 2 This equation is solved to: Dprox = Dprox = (DM S + DSM ) 2

(8)

(9)

1 As a consequence the failure of Dprox is d 2 DSM . It d1 follows Oprox is by 2 DM S less O according formulae (7). Thus, all slave clocks, which have processed the delayed Sync message, are behind the correct time. Figure 6 illustrates this behavior.

Fig. 6.

PTP, put all clocks back attack

Fig. 8.

PTP, put all clocks back attack using accelerated Sync messages

to a lower Oprox value compared to the correct offset O. In 1 d1 consequence, the slave clock is d 2 DM S resp. 2 DSM behind the correct time t of the master clock. 2) Accelerated Messages: Now, we assume that an attacker is able to accelerate messages, e.g. by changing the network infrastructure (establishing faster communication channels) or establishing faster communication routes. Formulae 13 describes the effects on the propagation delay Dprox , if an attacker accelerates a Sync message. Dprox = ( 1 1 + ) DM S 2s 2 (13)

Fig. 7.

PTP, put a specic clock back attack

If, on the other hand, an attacker delays a Delay Req message, DSM = d DM S , d > 1, formulae (12) holds for Dprox : Dprox = DM S 1+d ,d > 1 2 (12)

As a consequence the failure of Dprox is 1/s 2 1 DM S . It follows that Dprox is 1/s 2 1 DM S greater than DM S . Hence, the approximated offset Oprox is less than O, see formulae (7). Now, all slave clocks, that have processed the accelerated Sync message, are 1/s 2 1 DM S behind of the correct master clock. Figure 8 demonstrates this situation. In the other case, if the Delay Req message is accelerated, formulae 14 holds for Dprox : Dprox = DM S s+1 ,0 < s < 1 2 (14)

1 The deviation of Dprox from DM S is d 2 DM S . As a 1 consequence, the computed offset Oprox is by d 2 DM S behind the correct offset O. Also in this case, the slave clock is behind the correct time. Figure 7 represents this behavior. It follows, if an attacker is able to delay one or both communication directions (Sync message, Delay Req message) he can induce an offset failure of Oprox . But in contrast to NTP he cannot decide whether the slave clock is ahead or behind the correct time. Summing up, a PTP signal delay always leads

s Now, Dprox is 1 2 DM S less DM S and the consequence s is that the offset Oprox is by 1 2 DM S greater the correct offset O. But now, only the particular slave clock is affected. Figure 9 illustrates this behavior. Overall, an acceleration of the Delay Req messages results in an Oprox calculation greater than O.

IV. C ONSEQUENCES A time offset correction using the Sync message is executed every synchronization interval, which is 2 seconds by default. In contrast to the period of the Sync message a delay measurement is initiated by each slave individually on an irregular

Fig. 9.

PTP, clock forward attack

Fig. 10.

PTP, measurement of propagation delays

basis using a Delay Req message between 4 and 60 seconds by default, see [7]. If Sync messages are delayed or accelerated all client clocks are affected in the according network segment. Because of the relative high frequency of Sync messages, a delay of only one Sync message affects Oprox only for a very short time. Conversely, a regular malicious delay or acceleration of Sync messages is the real threat. On the other hand, if only one Delay Req message is delayed or accelerated only the according slave clock is affected and the affect on Oprox is also very time restricted (4 - 60 seconds), which is a relative long time compared to the duration of the effect caused by one manipulated Sync message. In conclusion, the delay or acceleration of Sync messages effects the calculation of Oprox of all client clocks. While the delay or acceleration of Delay Req messages affects only the particular client clock. But as a consequence, regular maliciously caused delays or accelerations of Sync messages as well as Delay Req messages shall be detected. V. C OUNTERMEASURES A. Principles Three different approaches to detect asymmetric propagation delays in networks are conceivable. 1) Implementation of specic network security mechanisms (like secure boot operation, operation modes, privileges, access control mechanisms e.g.) to protect the whole network and its components (routers, clocks, routing tables e.g.) against malicious manipulation of the network integrity 2) Measurements of propagation delays during initialization of the time synchronization and monitoring of the propagation delays during the normal operation of the time synchronization protocol. This approach has some

similarities with intrusion detection technologies. But here the main issue is the detection of propagation delay variances during the run time of PTP and 3) Combinations of the approaches 1 and 2. Here, we give only a brief description of a mechanism following principle 2). B. Initial Measurements of Propagation Delay Reference Values As already mentioned in chapter II-A no mechanism is known to counter delay attacks completely. It is only possible to limit the extent of the propagation delay failure of the time synchronization. Here, we apply the mentioned mechanism concerning NTP, see chapter II-B, to the precise time protocol. Firstly, a specic PTP initialization phase is needed. Furthermore, we assume that during this initialization phase delay attacks are not performed. The aim of this initialization phase ref ref is to measure reference values TSync and TDelay Req . 1) During this initialization phase each slave clock has directly to response with a Delay Req message to a previous Sync message, once. If this Delay Req message contains the ID of the slave clock, the master clock is able to measure a slave clock specic reference ref value TSync . Next, the master clock has to store the ref reference values TSync . 2) Also, each slave clock has to measure and store its own ref reference value TDelay Req In this case the master clock has directly to response to a receiving Delay Req message. The following gure 10 illustrates this approach. We assume that this measured propagation delays do not change all along. C. Monitoring the Propagation Delay during PTP Operation During the operation of PTP master clock respectively slave clocks perform measurements of TSync and TDelay Req at

random times. Furthermore, the master clock compares the ref values TSync with the stored reference values of TSync . ref The slave clocks check TDelay Req against TDelay Req . If this comparisons show signicant differences, an abnormal behaviour is detected. One possible reason are maliciously caused delay attacks. The authors would like to stress, that the reference values ref ref TSync and TDelay Req are security relevant informations and have to be protected against unauthorized modications. If an attacker is arbitrary able to modify the reference values he can again cause propagation delays within the frame of ref ref the modied values TSync and TDelay Req without the possibility to detect them. Finally, it should be noted that the mentioned approach do not counter accelerated messages in any way. VI. C ONCLUSION Here, an abstract analysis of delay attacks and consequences for an offset calculation is given. In summary our results clearly show, that a delay or acceleration of time synchronization messages inuence the calculation of Dprox and Oprox . Details are given in chapter III-B1 respectively III-B2. Moreover, an attacker can directly inuence the sign and absolute value of O Oprox by appropriately choosing the deceleration coefcient d or the acceleration coefcient s. Obviously, the additional use of HMAC-SHA-1 security data according to [4] to assure message and node authentication do not counter the mentioned delay attacks. Moreover, a rst approach to limit the extent of the propagation delay failure is presented. Still missing is a real PTP penetration analysis using delay attacks in a real UDP/Ethernet network and an evaluation of the briey described countermeasurement. This should be the issue of future research activities. R EFERENCES
[1] M. Bishop, A security analysis of the NTP protocol version 2, in Proceedings of the 6th Annual Computer Security Application Conference(ACSAC 1990), December 1990, pp. 2029. [2] J. Tsang and K. Beznosov, A security analysis of the precise time protocol (short paper), in Proceedings of the 8th International Conference on Information and Communication Security (ICICS 2006), November 2006, pp. 5059. [3] H. Krawczyk, M. Bellare, and R. Canetti, HMAC: Keyed-Hashing for Message Authentication, RFC2104, IETF, February 1997. [4] IEEE, Standard for a precision clock synchronization protocol for networked measurement and control systems, IEEE 1588 (v2, 2008), http://ieee1588.nist.gov/intro.htm. [5] J. Joshi, S. Bagchi, B. Davie, A. Farrel, B. Foo, V. Garg, M. Glause, G. Modelo-Howard, P. Krishnamurtly, and P. Loshin, Network Security. Morgan Kaufmann, 2008. [6] D. L. Mills, Internet time synchronization: The Network Time Protocol, IEEE Transactions Communications, vol. COM-39, pp. 14821493, October 1991. [7] J. Tsang and K. Beznosov, Technical report: A security analysis of the precise time protocol, http://lersse-dl.ece.ubc.ca.htm.