idnits 2.17.1 draft-cui-tictoc-encrypted-synchronization-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 427 has weird spacing: '...rotocol for N...' -- The document date (February 29, 2012) is 4438 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE 1588' is mentioned on line 83, but not defined == Unused Reference: 'RFC2119' is defined on line 415, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'IEEE1588' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'I-D.xu-tictoc-ipsec-security-for-synchronization' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC5840' is defined on line 449, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TICTOC Working Group Y. Cui 3 Internet-draft Huawei 4 Intended Status: Informational M. Bhatia 5 Expires: September 1, 2012 Alcatel-Lucent 6 D. Zhang 7 Huawei 8 February 29, 2012 10 Practical solutions for encrypted synchronization protocol 11 draft-cui-tictoc-encrypted-synchronization-00 13 Abstract 15 This informational document analyzes the accuracy issues with time 16 synchronization protocols when time synchronization packets are 17 encrypted during transmission. In addition, several candidate 18 solutions on such issues are introduced. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 Internet draft 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2 Motivation Scenario . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1 Time Synchronization Operations of a Two-Step Protocol . . 4 63 2.2 Errors Imposed by Encryption and Decryption in Two-Step 64 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.3 Errors Imposed by Encryption in One-Step Protocols . . . . 6 66 3 Candidate Solutions . . . . . . . . . . . . . . . . . . . . . . 7 67 3.1 Strike Timestamp on Each Encrypted Packet (STEP) . . . . . 7 68 3.2 Strike Timestamp on Identified Encrypted Packets (STIP) . . 7 69 3.3 Strike Timestamp on Selective Encrypted Packets (STSP) . . 8 70 3.4 Comparison . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 72 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 73 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 74 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7.1 Normative References . . . . . . . . . . . . . . . . . . . 9 76 7.2 Informative References . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 79 Internet draft 81 1 Introduction 83 Time synchronization protocols (e.g., PTP [IEEE 1588] and NTP 84 [RFC5905]) have been widely adopted in LAN or Internet to synchronize 85 the clocks of geographically distributed network devices. Depending 86 on different application requirements, the accuracy of the 87 synchronization services can be various from sub-microseconds to 88 milliseconds. 90 In most conditions, timing information is not confidential and 91 transported over networks in plaintext. However, there are also many 92 cases where the time synchronization packets need to be encrypted 93 during transmission for better security (e.g., to prevent MITM 94 attacks [I-D.ietf-tictoc-security-requirements]) or higher efficiency 95 (e.g., to take advantage of existing IPsec ESP channels). For 96 instance, the [3GPP.33.320] specification mandates that all the 97 packets exchanged between a femtocell (a home access cellular base 98 station) and the security gateway must be encrypted and transported 99 through an IPsec tunnel as the femtocell and the security gateway are 100 connected with an un-secure backhaul network. In a typical 101 deployment, a security gateway may need to process the packets sent 102 from several hundred thousand femtocells. In this case, it is 103 reasonable to for a security gateway to exchange time synchronization 104 packets with its femtocells using already established IPsec tunnels 105 instead of generating additional security tunnels only providing 106 integrity protection although the timing information itself is not 107 confidential. 109 The encryption and decryption operations on time information will 110 introduce additional errors and negatively influence the accuracy of 111 the time synchronization mechanisms. This issue is discussed in 112 Section 2 with a simple example scenario. Then in Section 3, three 113 candidate solutions are introduced and compared. 115 2 Motivation Scenario 117 This section makes use of a typical PTP (IEEE 1588) implementation as 118 an example to explain how a time synchronization mechanism works and 119 why encryption and decryption operations may introduce errors on 120 clock synchronization. 122 To perform a high accurate synchronization service, the PTP system 123 implements the time-critical operations in the hardware component and 124 relatively slow operations in the software component. The hardware 125 component consists of a high-precision real-time clock and a 126 timestamp unit (TSU) for generating timestamps. The timestamps are 127 striked on the received timing packets, in the middle of the MAC 128 layer and PHY layer, such as, at the Media Independent Interface 130 Internet draft 132 (MII). The software component implements the actual PTP packets 133 processing functions which makes use of the real-time clock and the 134 TSU. 136 Messages in the PTP protocol include Master sync/follow up message, 137 Slave clock delay request messages, and Master delay response 138 message. 140 2.1 Time Synchronization Operations of a Two-Step Protocol 142 Clock synchronization normally requires one Master, and one or 143 multiple Slaves. The Master clock provides synchronization messages 144 to correct slaves'clocks. Both the master and the slaves generate 145 precise timestamps using their clocks and exchange them to calculate 146 network latency. Typically, the Master sends a sync message to the 147 slaves every two seconds, and a Slave sends a delay request message 148 every minute. 150 Figure 1 illustrate the initializing process of the protocol, Master 151 first sends a sync message to Slave. A timestamp T1 is struck as the 152 precise time when sync message is transmitted from Master. T1 is 153 sent to Slave in the follow up sync message. When Slave receives the 154 first sync message, the precise time is recorded in a timestamp T2. 155 Then, Slave replies with a delay request message. A timestamp T3 is 156 struck when the message is transmitted from Slave. Finally, a 157 timestamp T4 is struck when the delay request message arrives at 158 Master. 160 Master Slave 161 | | | 162 T1 |---------------\ sync message | | 163 | \----------------------->>| T2 | 164 | | | 165 |---------------\ sync follow up message | | 166 | \----------------------->>| | 167 | | V 168 | /-------------------------| T3 time 169 T4 |<--------------/ delay request message | 170 | | 171 |---------------\ delay response message | 172 | \------------------------>| 173 | | 175 Figure 1. Timestamping Procedure of PTP Protocol 177 During the above process, the outbound and inbound transmission delay 178 is T2-T1, and T4-T3 respectively. The one-way delay could be 179 calculated as ((T2-T1)+(T4-T3))/2, i.e. 181 Internet draft 183 one-way delay=((T2-T1)+(T4-T3))/2 (1) 185 Thus, the offset to correct Slave clock could be "outbound delay"- 186 "one-way delay", i.e. 188 offset=((T2-T1)-(T4-T3))/2 (2) 190 By notifying Slave that four timestamps T1~T4, it is able to 191 calculate the offset in order to adjust the clock or frequency with 192 Master clock. 194 2.2 Errors Imposed by Encryption and Decryption in Two-Step Protocols 196 From the above introduction, it is obvious to see that the execution 197 speed is significantly crucial to the accuracy of synchronization. 198 The time-critical part of protocol, such as timestamping, is 199 typically required to be implemented by hardware. 201 A direct impact of confidentiality protection of synchronization lies 202 in the fact that the encryption and decryption operations introduce 203 error during Slave time correction, and thus influences the precision 204 of the results. Moreover, it is difficult for TSU to strike the 205 timestamp on the packets including synchronization information in 206 this case, because the encrypted packet is not explicitly 207 distinguishable. 209 Master Slave 210 | | | 211 T1 |---------------\ (sync message) | | 212 | \----------------------->>| +d2 | 213 +e1 | | T2 | 214 |---------------\ (sync follow up message) | | 215 | \----------------------->>| +d' | 216 | | +e3 V 217 | /-------------------------| T3 time 218 +d4 |<--------------/ (delay request message) | 219 T4 | | 220 |---------------\ (delay response message) | 221 | \------------------------>| 222 | | 224 Figure 2. Timestamping with Encrypted Packets 226 Compared with the normal timestamping process of PTP, confidentiality 227 protection in Figure 2 increases (denoted by "+") processing time 228 from point T1 to T4, including: e1, d2, d', e3, d4, in which e1 and 229 e3 is the time needed to encrypt follow up message and delay request 231 Internet draft 233 message, respectively; d2, d' and d4 is the time needed to decrypt 234 ciphertext of sync message, follow up message and delay request 235 message, respectively. 237 From the equation (1),(2), it is easy to see that local time 238 correction is subject to the value of time difference (T2-T1) and 239 (T4-T3), but not those absolute value. Denote T1', T2', T3' and T4' 240 as the new timestamps captured for encrypted packets. Since T1' is 241 recorded when sync message is sent out, and transmitted by sync 242 follow up message instead of sync message itself, encryption time e1 243 does not affect the accuracy of T1'. Also, the sync follow up 244 message is only used for transmission of T1', decryption time d' does 245 not affect the calculation of time difference (T2'-T1') nor (T4'- 246 T3'). Besides, encryption corresponding to e3 is done before the T3' 247 is struck and T3' is not delivered to Master, thus it does not change 248 the time difference of (T4'-T3'), as well. 250 Thus, encryption time e1, e3 can be excluded where new time 251 differences to calculate the offset are as follows: 253 T2'-T1'=(T2+d2)-T1, 255 T4'-T3'=(T4+d4)-T3 257 Both d2 and d4 are typically in an order of milliseconds and may be 258 varied from one time to another. Therefore, it may seriously 259 influence the performance of a time synchronization mechanism with 260 accuracy in sub-milliseconds. 262 2.3 Errors Imposed by Encryption in One-Step Protocols 264 According to the above analysis, the two-step method that utilizes 265 sync message and sync follow up message in sequence is not subject to 266 the delay of encryption. However, it is doubtful whether one-step 267 protocol (i.e timestamp T1' is included and delivered in one sync 268 message) is immune from the additional delay by encryption. 270 Both PTP and NTP synchronization protocol permit one-step process for 271 sync request delivery. In this case the encryption delay occurs since 272 that encryption must be run after timestamp is struck. 274 A straightforward solution to mitigate this problem is to exclude an 275 estimated time of e1 in the final calculation. However, this solution 276 would be infeasible in the scenarios where high precision is 277 required. Another simple solution is to use the one-step protocol to 278 simulate a two-step one. In this solution, the sync message in the 279 one-step protocol is used to perform the function of sync follow up 280 message in two-step protocols. That is, the time contained in a sync 282 Internet draft 284 message is the time when the previous sync packet is generated. 286 3 Candidate Solutions 288 This section discusses three candidate methods that could be used to 289 eliminate the errors brought by encryption/decryption time for two- 290 step protocols, which could efficiently synchronize the Slave clock 291 for encrypted synchronization protocol. 293 3.1 Strike Timestamp on Each Encrypted Packet (STEP) 295 The most intuitive solution is to strike a timestamp on each 296 encrypted packet (STEP) when it is being received, and timing message 297 will be decoded later for local time correction. The STEP method is 298 able to avoid the delay produced by decryption (such as, d2 and d4 in 299 Sec. 2.1), because it captured timestamps first and then decoded the 300 encrypted messages, not further introducing delay of decrypting 301 operation. In other words, for PTP, there is T2'=T2, T4'=T4, and 302 (T2'-T1')=(T2-T1) and (T4'-T3')=(T4-T3), Slave time precision avoids 303 the delay by decryption. 305 Another advantage is that needs not select the synchronization 306 packets before decrypting them, which is beyond the capability of 307 current synchronization protocol. 309 In this exhaustive way of timestamp capture, the STEP method is able 310 to synchronize with encrypted protocols. On the other hand, however, 311 it raises the cost of timestamping, from a level of one time per 312 minute (typical frequency of PTP Slave) to a number of mega or kilo 313 times per second, which increases along with the actual network 314 throughput. It may be practical for hardware timestamp, but not 315 appropriate for software timestamp. Even for hardware 316 implementation, it is low efficient and degrades performance. 318 3.2 Strike Timestamp on Identified Encrypted Packets (STIP) 320 If timestamp striker is able to know which packet includes time 321 message for synchronization, then the protocol can work correctly as 322 before. To avoid the decryption time delay, such a solution could be 323 achieved by setting an explicit identifier on encrypted packets which 324 contain synchronization message. 326 From a timestamping point of view, it is the most efficient way to 327 capture the stamp only for those including time message. However, it 328 additionally requires the extension to the current ESP protocol. For 329 example, it is possible to include such an identifier in ESP header 330 or extended ESP (such as WESP, RFC5840) header, or IPv6 header, as 332 Internet draft 334 those parts are not encrypted and can carry additional information. 335 A specific solution by using STIP method has been proposed [I-D.xu- 336 tictoc-ipsec-security-for-synchronization]. 338 One concern may be raised that synchronization packets with 339 identifier could help distinguish crucial packets for both valid and 340 malicious users. Malicious users may make use of identifiers to delay 341 or block the synchronization protocol. However, it should be 342 clarified that the STIP method does not breach the security against 343 the underlying delay or block attacks, because such attacks exists no 344 matter whether STIP is employed or not. Attackers can delay or block 345 synchronization packets can, in principle, delay or block all the 346 traffic between Master and Slave. Countermeasures should be 347 considered further but is out of the scope of this draft. 349 Moreover, in the scenarios where timing information is not 350 confidential but still needs to be transported in an encrypted way to 351 reuse existing security channels, STIP shows its advantage. Compared 352 with the solution of generating new IPsec AH channels to transport 353 timing information, STIP effectively reduce the number of IPsec 354 channels but do not introduce any new security drawbacks since the 355 timing information transported through IPsec AH channels can be 356 easily detected by attackers as well. 358 3.3 Strike Timestamp on Selective Encrypted Packets (STSP) 360 As mentioned above, the STEP method is costly and low efficient. And 361 STIP method may give malicious users additional information in 362 encryption transfer mode, even though this does not breach the 363 security as we have analyzed. 365 One more solution is like a hybrid of STEP and STIP, which strike on 366 some of packets without using identifiers. More precisely, the 367 protocol predicts a time window that the next one will reach after 368 receiving a time synchronization packet and then strike the 369 timestamps on those packets received during that notified period. 370 This solution does not need to capture all the traffic packets for 371 timestamp, thus is more efficient than the STEP method. However, it 372 is only feasible in the conditions where the frequency of transiting 373 time synchronization messages is steady and known by both Master and 374 Slave, thus is limited. 376 3.4 Comparison 378 Synchronization methods on encrypted timing packets have been 379 introduced. STEP is straightforward and practical when the 380 performance is acceptable. STIP impacts the precision of 381 synchronization the least, and should be recommended when delay 383 Internet draft 385 attack is not a concern. STSP is a trade-off of STEP and STIP, but 386 useful only in limited cases. 388 4 IANA Considerations 390 This document makes no request of IANA. 392 Note to RFC Editor: this section may be removed on publication as an 393 RFC. 395 5 Security Considerations 397 In encrypted transfer mode (such as an IPsec ESP tunnel), both 398 confidentiality and integrity of the synchronization packets are 399 protected. 401 Note that in both unencrypted mode and encrypted mode, it is still 402 hard to prevent attackers who intend to block or delay the 403 synchronization protocol. Besides, if relay nodes in routing are 404 corrupted, then MITM (Man-in-the-Middle) attack to synchronization 405 also needs to be dealt with. Thus, a suite of security 406 countermeasures should be worked for preventing the underlying 407 attacks in the future. 409 6 Acknowledgements 411 7 References 413 7.1 Normative References 415 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 416 Requirement Levels", BCP 14, RFC 2119, March 1997. 418 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 419 RFC 4303, December 2005. 421 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 422 "Network Time Protocol Version 4: Protocol and Algorithms 423 Specification", RFC 5905, June 2010. 425 [IEEE1588] 426 IEEE, "Standard for A Precision Clock Synchronization 427 Protocol for Networked Measurement and Control Systems", 428 IEEE Std 1588-2008. 430 7.2 Informative References 432 [I-D.ietf-tictoc-security-requirements] 434 Internet draft 436 Mizrahi, T. and K. O'Donoghue, "TICTOC Security 437 Requirements", draft-ietf-tictoc-security-requirements-00 438 (work in progress), November 2011. 440 [I-D.xu-tictoc-ipsec-security-for-synchronization] 441 Xu, Y., "IPsec security for packet based synchronization", 442 draft-xu-tictoc-ipsec-security-for-synchronization-02 443 (work in progress), September 2011. 445 [3GPP.33.320] 446 3GPP, "Security of Home Node B (HNB) / Home evolved Node B 447 (HeNB)", 3GPP TS 33.320 10.3.0, June 2011. 449 [RFC5840] Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped 450 Encapsulating Security Payload (ESP) for Traffic 451 Visibility", RFC 5840, April 2010. 453 Authors' Addresses 455 Yang Cui 456 Huawei 457 Beijing, 458 China 460 Email: cuiyang@huawei.com 462 Manav Bhatia 463 Alcatel-Lucent 464 Bangalore 465 India 467 Email: manav.bhatia@alcatel-lucent.com 469 Dacheng Zhang 470 Huawei 471 Beijing, 472 China 474 Email: zhangdacheng@huawei.com