Internet DRAFT - draft-cui-tictoc-encrypted-synchronization
draft-cui-tictoc-encrypted-synchronization
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.
<Cui et al.> Expires <September 1, 2012> [Page 1]
Internet draft <Encrypted synchronization solution> <February 2012>
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
<Cui et al.> Expires <September 1, 2012> [Page 2]
Internet draft <Encrypted synchronization solution> <February 2012>
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
<Cui et al.> Expires <September 1, 2012> [Page 3]
Internet draft <Encrypted synchronization solution> <February 2012>
(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.
<Cui et al.> Expires <September 1, 2012> [Page 4]
Internet draft <Encrypted synchronization solution> <February 2012>
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
<Cui et al.> Expires <September 1, 2012> [Page 5]
Internet draft <Encrypted synchronization solution> <February 2012>
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
<Cui et al.> Expires <September 1, 2012> [Page 6]
Internet draft <Encrypted synchronization solution> <February 2012>
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
<Cui et al.> Expires <September 1, 2012> [Page 7]
Internet draft <Encrypted synchronization solution> <February 2012>
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
<Cui et al.> Expires <September 1, 2012> [Page 8]
Internet draft <Encrypted synchronization solution> <February 2012>
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]
<Cui et al.> Expires <September 1, 2012> [Page 9]
Internet draft <Encrypted synchronization solution> <February 2012>
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
<Cui et al.> Expires <September 1, 2012> [Page 10]
