7/30/2019 05340224

1/6

Delay Attacks

- Implication on NTP and PTP Time

Synchronization -

Markus UllmannFederal Office 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 VogelerNXP Semiconductors

Business Line Identification

D-21147 Hamburg

Germany

WWW home page: http//www.nxp.com

Email: matthias.voegeler@nxp.com

AbstractIn this paper specific variants of delay attacks areexamined. First, the Network Time Protocol is regarded. Second,delay attacks and implications on the time synchronization of thePrecise Time Protocol are described. In particular, consequencesfor the offset calculation Oprox are regarded. At the end of thepaper possible countermeasurements are described.

Index TermsIEEE 1588 (v2, 2008), Precise Time Protocol(PTP), Network Time Protocol (NTP), delay attacks, implicationon time synchronization, countermeasurements, cryptographicprotocols

I. INTRODUCTION

A. Known Security Attacks

Regarding time synchronization, five threat types are dis-cussed, see [1] and [2].

1) Modification 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 influence

on a reliable time synchronization are the first four. Obviously,

specific cryptographic protocols are capable to counter the

mentioned attacks 1, 2 and 3. A first 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 sufficiently

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

Datagram Protocol (UDP) over the Internet Protocol (IP) or

fieldbus 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 communi-

cation 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 synchro-

nization are given. PTP claims to put a precise synchronizationof clocks into effect. Therefore, it has to be under examination

whether maliciously caused delay attacks induce specific 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 findings of this paper.

D. Used Notation

Figure 1 describes the used abbreviations within this article.

I I . NETWORK TIM E PROTOCOL

A. Delay Attacks

NTP is a protocol for synchronizing slave clocks of com-

puter 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 directlycalculates the time value of the slave clocktSC. Therefore, theslave clock sends a request for the current time to the master

clock. The slave clock measures the elapsed time T between

ISPCS 2009 International IEEE Symposium on Precision Clock

Synchronization for Measurement, Control and Communication

Brescia, Italy, October 12-16, 2009

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

7/30/2019 05340224

2/6

Abbreviation Semantics

DMS one-way propagation delay (master slave)

DSM one-way propagation delay (slave mas-ter)

T two-way propagation delay

TrefSync reference value two-way propagation de-lay (Sync message and response)

D genuine one-way propagation delayDprox approximated one-way propagation delaytMC time of the master clocktSC time of the slave clockTreq time interval between Sync message and

Delay Req message

O genuine offset of a slave clockOprox approximated offset of a slave clockd deceleration coefficients acceleration coefficient

Fig. 1. Abbreviations

Fig. 2. Network Time Protocol

sending the request and receiving the time response tMC fromthe master clock. The both-way communication lasts DSM forthe request and DMS for the time response. Figure 2 describesthe function of the NTP protocol to synchronize slave clocks.

The following system of equations can be established:tSC = tMC + DMS (1)

T = DSM + DMS (2)

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 simplification:

DSM = DMS (3)

Then the system of equations has the solution tSC = tMC +

Fig. 3. NTP, put the clock back attack

T /2 with Dprox = T /2.In reality, the assumption DSM = DMS 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 = tMC + Dprox, which results in a wrongtime 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 DMS = dDSM, d > 1, the computedtime is

tSC = tMC +d + 1

2DSM (4)

Now, tSC is byd 12

DSM behind the correct time tMC.Figure 3 illustrates this behavior.

If on the other hand an attacker delays DSM = dDMS,d > 1, the computed time is

tSC = tMC +d + 1

2DMS (5)

In this case tSC is byd 12

DMS ahead the correct timetMC. 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 tMC. 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 DMS + DSM exceedsa defined maximum propagation delay value Tmax. So, ifT Tmax the slave clock shall abort the current NTPprotocol run and shall start a new synchronization attempt.

7/30/2019 05340224

3/6

Fig. 4. NTP, clock forward attack

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 placeat 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 DELAY 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 synchro-

nization, 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 approximatedwith the following formulae, see [4] and [7],

Oprox = (t + O + DMS) tDprox (6)

= O + DMSDprox (7)

The propagation delay Dprox is measured and approximatedaccording following formulae, see [4].

Dprox =(t + O + DMS) t

2

+(t + Treq + DSM) (t + O + Treq)

2(8)

This equation is solved to:

Dprox =(DMS + DSM)

2(9)

Fig. 5. Precise Time Protocol

Equation 9 calculates the average of DMS and DSM.Obviously, the desired relation Oprox = O only holds ifDprox = DMS which is equivalent to

DMS = 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 DescriptionIn reality, the approximation of Dprox according formulae

(8) leads to a failure of the calculation of Oprox, if DMS =DSM. The IEEE 1588-2008 standard already mentions delayasymmetry, but do not cover this issue. In particular, for-

mulae (8) may not hold, especially if an attacker has to be

considered. In this case the slave clock would erroneously

apply the formulae Dprox = (DMS + DSM)/2, which resultsin an unprecise Dprox calculation and in consequence in anerroneously approximation of the time offset Oprox.

First, we assume an attacker who delays messages.

1) Delay Messages: Formulae 11 describes the propagation

delayDprox

if an attacker delays a Sync message.

If DMS = d DSM, d > 1:

Dprox = DSM1 + d

2, d > 1 (11)

As a consequence the failure of Dprox isd 12

DSM. Itfollows Oprox is by

d 12

DMS 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.

7/30/2019 05340224

4/6

Fig. 6. PTP, put all clocks back attack

Fig. 7. PTP, put a specific clock back attack

If, on the other hand, an attacker delays a Delay Req

message, DSM = d DMS, d > 1, formulae (12) holds forDprox:

Dprox = DMS1 + d

2

, d > 1 (12)

The deviation of Dprox from DMS isd 12

DMS. As aconsequence, the computed offset Oprox is by

d 12

DMSbehind the correct offset O. Also in this case, the slave clockis behind the correct time. Figure 7 represents this behavior.

It follows, if an attacker is able to delay one or both com-

munication directions (Sync message, Delay Req message) he

can induce an offset failure of Oprox. But in contrast to NTPhe cannot decide whether the slave clock is ahead or behind

the correct time. Summing up, a PTP signal delay always leads

Fig. 8. PTP, put all clocks back attack using accelerated Sync messages

to a lower Oprox value compared to the correct offset O. Inconsequence, the slave clock is d 1

2DMS resp.

d 12

DSMbehind the correct time t of the master clock.

2) Accelerated Messages: Now, we assume that an at-

tacker is able to accelerate messages, e.g. by changing

the network infrastructure (establishing faster communication

channels) or establishing faster communication routes. Formu-

lae 13 describes the effects on the propagation delay Dprox,if an attacker accelerates a Sync message.

Dprox = (1

2s+

1

2) DMS (13)

As a consequence the failure of Dprox is1/s 1

2 DMS. Itfollows that Dprox is

1/s 12

DMS greater than DMS. Hence,the approximated offset Oprox is less than O, see formulae (7).Now, all slave clocks, that have processed the accelerated Sync

message, are1/s 1

2DMS 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 = DMSs + 1

2, 0 < s < 1 (14)

Now, Dprox is1 s2

DMS less DMS and the consequenceis that the offset Oprox is by

1 s2

DMS 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. CONSEQUENCES

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 mea-

surement is initiated by each slave individually on an irregular

7/30/2019 05340224

5/6

Fig. 9. PTP, clock forward attack

basis using a Delay Req message between 4 and 60 secondsby default, see [7].

IfSync 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. Whilethe 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. COUNTERMEASURES

A. Principles

Three different approaches to detect asymmetric propaga-

tion delays in networks are conceivable.

1) Implementation of specific 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 ta-

bles e.g.) against malicious manipulation of the network

integrity

2) Measurements of propagation delays during initializa-

tion of the time synchronization and monitoring of the

propagation delays during the normal operation of the

time synchronization protocol. This approach has some

Fig. 10. PTP, measurement of propagation delays

similarities with intrusion detection technologies. Buthere 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 Val-

ues

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 specific PTP initialization phase is needed. Fur-

thermore, we assume that during this initialization phase delay

attacks are not performed. The aim of this initialization phase

is to measure reference values TrefSync and TrefDelay 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 specific reference

value TrefSync. Next, the master clock has to store the

reference values TrefSync.2) Also, each slave clock has to measure and store its own

reference value TrefDelay Req In this case the masterclock has directly to response to a receiving Delay Req

message.

The following figure 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 clockrespectively slave

clocks perform measurements of TSync and TDelay Req at

7/30/2019 05340224

6/6

random times. Furthermore, the master clock compares the

values TSync with the stored reference values of Tref

Sync.

The slave clocks check TDelay Req against TrefDelay Req.

If this comparisons show significant differences, an abnormal

behaviour is detected. One possible reason are maliciously

caused delay attacks.

The authors would like to stress, that the reference values

T

ref

Sync and T

ref

Delay Req are security relevant informationsand have to be protected against unauthorized modifications.

If an attacker is arbitrary able to modify the reference values

he can again cause propagation delays within the frame of

the modified values TrefSync and TrefDelay 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 . CONCLUSION

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 synchro-

nization messages influence the calculation of Dprox andOprox. Details are given in chapter III-B1 respectively III-B2.Moreover, an attacker can directly influence the sign and

absolute value of O Oprox by appropriately choosing thedeceleration coefficient d or the acceleration coefficient 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 first approach to limit the extent of the propa-

gation 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 briefly described countermeasurement. This should be the

issue of future research activities.

REFERENCES

[1] M. Bishop, A security analysis of the NTP protocol version 2, inProceedings of the 6th Annual Computer Security Application Confer-ence(ACSAC 1990), December 1990, pp. 2029.

[2] J. Tsang and K. Beznosov, A security analysis of the precise time pro-tocol (short paper), in Proceedings of the 8th International Conferenceon Information and Communication Security (ICICS 2006), November2006, pp. 5059.

[3] H. Krawczyk, M. Bellare, and R. Canetti, HMAC: Keyed-Hashing forMessage Authentication, RFC2104, IETF, February 1997.

[4] IEEE, Standard for a precision clock synchronization protocol fornetworked 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 Proto-

col, IEEE Transactions Communications, vol. COM-39, pp. 14821493,October 1991.

[7] J. Tsang and K. Beznosov, Technical report: A security analysis of theprecise time protocol, http://lersse-dl.ece.ubc.ca.htm.