TICTOC Working Group Y. Cui Internet-draft Huawei Intended Status: Informational M. Bhatia Expires: September 1, 2012 Alcatel-Lucent D. Zhang Huawei February 29, 2012 Practical solutions for encrypted synchronization protocol draft-cui-tictoc-encrypted-synchronization-00 Abstract This informational document analyzes the accuracy issues with time synchronization protocols when time synchronization packets are encrypted during transmission. In addition, several candidate solutions on such issues are introduced. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Expires [Page 1] Internet draft This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Motivation Scenario . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Time Synchronization Operations of a Two-Step Protocol . . 4 2.2 Errors Imposed by Encryption and Decryption in Two-Step Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Errors Imposed by Encryption in One-Step Protocols . . . . 6 3 Candidate Solutions . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Strike Timestamp on Each Encrypted Packet (STEP) . . . . . 7 3.2 Strike Timestamp on Identified Encrypted Packets (STIP) . . 7 3.3 Strike Timestamp on Selective Encrypted Packets (STSP) . . 8 3.4 Comparison . . . . . . . . . . . . . . . . . . . . . . . . 8 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1 Normative References . . . . . . . . . . . . . . . . . . . 9 7.2 Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Expires [Page 2] Internet draft 1 Introduction Time synchronization protocols (e.g., PTP [IEEE 1588] and NTP [RFC5905]) have been widely adopted in LAN or Internet to synchronize the clocks of geographically distributed network devices. Depending on different application requirements, the accuracy of the synchronization services can be various from sub-microseconds to milliseconds. In most conditions, timing information is not confidential and transported over networks in plaintext. However, there are also many cases where the time synchronization packets need to be encrypted during transmission for better security (e.g., to prevent MITM attacks [I-D.ietf-tictoc-security-requirements]) or higher efficiency (e.g., to take advantage of existing IPsec ESP channels). For instance, the [3GPP.33.320] specification mandates that all the packets exchanged between a femtocell (a home access cellular base station) and the security gateway must be encrypted and transported through an IPsec tunnel as the femtocell and the security gateway are connected with an un-secure backhaul network. In a typical deployment, a security gateway may need to process the packets sent from several hundred thousand femtocells. In this case, it is reasonable to for a security gateway to exchange time synchronization packets with its femtocells using already established IPsec tunnels instead of generating additional security tunnels only providing integrity protection although the timing information itself is not confidential. The encryption and decryption operations on time information will introduce additional errors and negatively influence the accuracy of the time synchronization mechanisms. This issue is discussed in Section 2 with a simple example scenario. Then in Section 3, three candidate solutions are introduced and compared. 2 Motivation Scenario This section makes use of a typical PTP (IEEE 1588) implementation as an example to explain how a time synchronization mechanism works and why encryption and decryption operations may introduce errors on clock synchronization. To perform a high accurate synchronization service, the PTP system implements the time-critical operations in the hardware component and relatively slow operations in the software component. The hardware component consists of a high-precision real-time clock and a timestamp unit (TSU) for generating timestamps. The timestamps are striked on the received timing packets, in the middle of the MAC layer and PHY layer, such as, at the Media Independent Interface Expires [Page 3] Internet draft (MII). The software component implements the actual PTP packets processing functions which makes use of the real-time clock and the TSU. Messages in the PTP protocol include Master sync/follow up message, Slave clock delay request messages, and Master delay response message. 2.1 Time Synchronization Operations of a Two-Step Protocol Clock synchronization normally requires one Master, and one or multiple Slaves. The Master clock provides synchronization messages to correct slaves'clocks. Both the master and the slaves generate precise timestamps using their clocks and exchange them to calculate network latency. Typically, the Master sends a sync message to the slaves every two seconds, and a Slave sends a delay request message every minute. Figure 1 illustrate the initializing process of the protocol, Master first sends a sync message to Slave. A timestamp T1 is struck as the precise time when sync message is transmitted from Master. T1 is sent to Slave in the follow up sync message. When Slave receives the first sync message, the precise time is recorded in a timestamp T2. Then, Slave replies with a delay request message. A timestamp T3 is struck when the message is transmitted from Slave. Finally, a timestamp T4 is struck when the delay request message arrives at Master. Master Slave | | | T1 |---------------\ sync message | | | \----------------------->>| T2 | | | | |---------------\ sync follow up message | | | \----------------------->>| | | | V | /-------------------------| T3 time T4 |<--------------/ delay request message | | | |---------------\ delay response message | | \------------------------>| | | Figure 1. Timestamping Procedure of PTP Protocol During the above process, the outbound and inbound transmission delay is T2-T1, and T4-T3 respectively. The one-way delay could be calculated as ((T2-T1)+(T4-T3))/2, i.e. Expires [Page 4] Internet draft one-way delay=((T2-T1)+(T4-T3))/2 (1) Thus, the offset to correct Slave clock could be "outbound delay"- "one-way delay", i.e. offset=((T2-T1)-(T4-T3))/2 (2) By notifying Slave that four timestamps T1~T4, it is able to calculate the offset in order to adjust the clock or frequency with Master clock. 2.2 Errors Imposed by Encryption and Decryption in Two-Step Protocols From the above introduction, it is obvious to see that the execution speed is significantly crucial to the accuracy of synchronization. The time-critical part of protocol, such as timestamping, is typically required to be implemented by hardware. A direct impact of confidentiality protection of synchronization lies in the fact that the encryption and decryption operations introduce error during Slave time correction, and thus influences the precision of the results. Moreover, it is difficult for TSU to strike the timestamp on the packets including synchronization information in this case, because the encrypted packet is not explicitly distinguishable. Master Slave | | | T1 |---------------\ (sync message) | | | \----------------------->>| +d2 | +e1 | | T2 | |---------------\ (sync follow up message) | | | \----------------------->>| +d' | | | +e3 V | /-------------------------| T3 time +d4 |<--------------/ (delay request message) | T4 | | |---------------\ (delay response message) | | \------------------------>| | | Figure 2. Timestamping with Encrypted Packets Compared with the normal timestamping process of PTP, confidentiality protection in Figure 2 increases (denoted by "+") processing time from point T1 to T4, including: e1, d2, d', e3, d4, in which e1 and e3 is the time needed to encrypt follow up message and delay request Expires [Page 5] Internet draft message, respectively; d2, d' and d4 is the time needed to decrypt ciphertext of sync message, follow up message and delay request message, respectively. From the equation (1),(2), it is easy to see that local time correction is subject to the value of time difference (T2-T1) and (T4-T3), but not those absolute value. Denote T1', T2', T3' and T4' as the new timestamps captured for encrypted packets. Since T1' is recorded when sync message is sent out, and transmitted by sync follow up message instead of sync message itself, encryption time e1 does not affect the accuracy of T1'. Also, the sync follow up message is only used for transmission of T1', decryption time d' does not affect the calculation of time difference (T2'-T1') nor (T4'- T3'). Besides, encryption corresponding to e3 is done before the T3' is struck and T3' is not delivered to Master, thus it does not change the time difference of (T4'-T3'), as well. Thus, encryption time e1, e3 can be excluded where new time differences to calculate the offset are as follows: T2'-T1'=(T2+d2)-T1, T4'-T3'=(T4+d4)-T3 Both d2 and d4 are typically in an order of milliseconds and may be varied from one time to another. Therefore, it may seriously influence the performance of a time synchronization mechanism with accuracy in sub-milliseconds. 2.3 Errors Imposed by Encryption in One-Step Protocols According to the above analysis, the two-step method that utilizes sync message and sync follow up message in sequence is not subject to the delay of encryption. However, it is doubtful whether one-step protocol (i.e timestamp T1' is included and delivered in one sync message) is immune from the additional delay by encryption. Both PTP and NTP synchronization protocol permit one-step process for sync request delivery. In this case the encryption delay occurs since that encryption must be run after timestamp is struck. A straightforward solution to mitigate this problem is to exclude an estimated time of e1 in the final calculation. However, this solution would be infeasible in the scenarios where high precision is required. Another simple solution is to use the one-step protocol to simulate a two-step one. In this solution, the sync message in the one-step protocol is used to perform the function of sync follow up message in two-step protocols. That is, the time contained in a sync Expires [Page 6] Internet draft message is the time when the previous sync packet is generated. 3 Candidate Solutions This section discusses three candidate methods that could be used to eliminate the errors brought by encryption/decryption time for two- step protocols, which could efficiently synchronize the Slave clock for encrypted synchronization protocol. 3.1 Strike Timestamp on Each Encrypted Packet (STEP) The most intuitive solution is to strike a timestamp on each encrypted packet (STEP) when it is being received, and timing message will be decoded later for local time correction. The STEP method is able to avoid the delay produced by decryption (such as, d2 and d4 in Sec. 2.1), because it captured timestamps first and then decoded the encrypted messages, not further introducing delay of decrypting operation. In other words, for PTP, there is T2'=T2, T4'=T4, and (T2'-T1')=(T2-T1) and (T4'-T3')=(T4-T3), Slave time precision avoids the delay by decryption. Another advantage is that needs not select the synchronization packets before decrypting them, which is beyond the capability of current synchronization protocol. In this exhaustive way of timestamp capture, the STEP method is able to synchronize with encrypted protocols. On the other hand, however, it raises the cost of timestamping, from a level of one time per minute (typical frequency of PTP Slave) to a number of mega or kilo times per second, which increases along with the actual network throughput. It may be practical for hardware timestamp, but not appropriate for software timestamp. Even for hardware implementation, it is low efficient and degrades performance. 3.2 Strike Timestamp on Identified Encrypted Packets (STIP) If timestamp striker is able to know which packet includes time message for synchronization, then the protocol can work correctly as before. To avoid the decryption time delay, such a solution could be achieved by setting an explicit identifier on encrypted packets which contain synchronization message. From a timestamping point of view, it is the most efficient way to capture the stamp only for those including time message. However, it additionally requires the extension to the current ESP protocol. For example, it is possible to include such an identifier in ESP header or extended ESP (such as WESP, RFC5840) header, or IPv6 header, as Expires [Page 7] Internet draft those parts are not encrypted and can carry additional information. A specific solution by using STIP method has been proposed [I-D.xu- tictoc-ipsec-security-for-synchronization]. One concern may be raised that synchronization packets with identifier could help distinguish crucial packets for both valid and malicious users. Malicious users may make use of identifiers to delay or block the synchronization protocol. However, it should be clarified that the STIP method does not breach the security against the underlying delay or block attacks, because such attacks exists no matter whether STIP is employed or not. Attackers can delay or block synchronization packets can, in principle, delay or block all the traffic between Master and Slave. Countermeasures should be considered further but is out of the scope of this draft. Moreover, in the scenarios where timing information is not confidential but still needs to be transported in an encrypted way to reuse existing security channels, STIP shows its advantage. Compared with the solution of generating new IPsec AH channels to transport timing information, STIP effectively reduce the number of IPsec channels but do not introduce any new security drawbacks since the timing information transported through IPsec AH channels can be easily detected by attackers as well. 3.3 Strike Timestamp on Selective Encrypted Packets (STSP) As mentioned above, the STEP method is costly and low efficient. And STIP method may give malicious users additional information in encryption transfer mode, even though this does not breach the security as we have analyzed. One more solution is like a hybrid of STEP and STIP, which strike on some of packets without using identifiers. More precisely, the protocol predicts a time window that the next one will reach after receiving a time synchronization packet and then strike the timestamps on those packets received during that notified period. This solution does not need to capture all the traffic packets for timestamp, thus is more efficient than the STEP method. However, it is only feasible in the conditions where the frequency of transiting time synchronization messages is steady and known by both Master and Slave, thus is limited. 3.4 Comparison Synchronization methods on encrypted timing packets have been introduced. STEP is straightforward and practical when the performance is acceptable. STIP impacts the precision of synchronization the least, and should be recommended when delay Expires [Page 8] Internet draft attack is not a concern. STSP is a trade-off of STEP and STIP, but useful only in limited cases. 4 IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5 Security Considerations In encrypted transfer mode (such as an IPsec ESP tunnel), both confidentiality and integrity of the synchronization packets are protected. Note that in both unencrypted mode and encrypted mode, it is still hard to prevent attackers who intend to block or delay the synchronization protocol. Besides, if relay nodes in routing are corrupted, then MITM (Man-in-the-Middle) attack to synchronization also needs to be dealt with. Thus, a suite of security countermeasures should be worked for preventing the underlying attacks in the future. 6 Acknowledgements 7 References 7.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [IEEE1588] IEEE, "Standard for A Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std 1588-2008. 7.2 Informative References [I-D.ietf-tictoc-security-requirements] Expires [Page 9] Internet draft Mizrahi, T. and K. O'Donoghue, "TICTOC Security Requirements", draft-ietf-tictoc-security-requirements-00 (work in progress), November 2011. [I-D.xu-tictoc-ipsec-security-for-synchronization] Xu, Y., "IPsec security for packet based synchronization", draft-xu-tictoc-ipsec-security-for-synchronization-02 (work in progress), September 2011. [3GPP.33.320] 3GPP, "Security of Home Node B (HNB) / Home evolved Node B (HeNB)", 3GPP TS 33.320 10.3.0, June 2011. [RFC5840] Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility", RFC 5840, April 2010. Authors' Addresses Yang Cui Huawei Beijing, China Email: cuiyang@huawei.com Manav Bhatia Alcatel-Lucent Bangalore India Email: manav.bhatia@alcatel-lucent.com Dacheng Zhang Huawei Beijing, China Email: zhangdacheng@huawei.com Expires [Page 10]