Subject: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol

From: Cui Yang <[email-masked]>
Date: Wed, 07 Mar 2012 03:35:17 +0000

Hi, all,

I have posted a new draft that discusses the practical solutions for encrypted synchronization protocols.

Since we have discussed a lot on this problem, and the security requirement of synchronization also noted that confidentiality may need protection, especially in case that the confidentiality protection is mandatory. Synchronization should be available when the traffic is encrypted. The influences by the encryption are explained, and several possible solutions have been discussed.
The URL is below, please review and comment.

    Title      : Practical solutions for encrypted synchronization protocol
Author(s)  : Y. Cui,
M. Bhatia,
D. Zhang
Filename   : draft-cui-tictoc-encrypted-synchronization-00.txt
Pages     : 10
Date      : Mar. 1, 2012
   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.

A URL for this Internet-Draft is:
http://datatracker.ietf.org/doc/draft-cui-tictoc-encrypted-synchronization

Thanks,
Yang

==================

Yang Cui,  Ph.D.

Huawei Technologies

[email-masked]

---

From: Danny Mayer <[email-masked]>
Date: Wed, 07 Mar 2012 07:56:16 -0500

I have already said this before and I will repeat this for the purposes
of feedback.

Time packets do not need to be encrypted as not only do they not contain
anything secret, even if you knew the contents they are useless anytime
after the packet has been delivered.

You do yourself a disfavor in encrypting something that is not worth
encrypting. It takes processing overhead, increases packet size, and
there is no gain in doing so. You need to justify encrypting something
and please don't say that it is because some other document says to
encrypt everything. I want to know what is the benefit from doing so,
what are the risks in not doing so and what is the cost of doing so,
particularly in loss of accuracy, increased error budget, etc.

The whole thing is a bad idea from what I can tell.

Danny

On 3/6/2012 10:35 PM, Cui Yang wrote:
> Since we have discussed a lot on this problem, and the security
> requirement of synchronization also noted that confidentiality may need
> protection, especially in case that the confidentiality protection is
> mandatory. Synchronization should be available when the traffic is
> encrypted. The influences by the encryption are explained, and several
> possible solutions have been discussed.
>

---

From: Cui Yang <[email-masked]>
Date: Thu, 08 Mar 2012 01:44:23 +0000

Danny,

Thanks for your comments. I will respond inline.

> -----邮件原件-----
> 发件人: Danny Mayer [mailto:[email-masked]]
> 发送时间: 2012年3月7日 20:56
> 收件人: Cui Yang
> 抄送: [email-masked]
> 主题: Re: [TICTOC] Please Comment on Practical Solutions for Encrypted
> Synchronization Protocol
> 

[Cui Yang] I will repeat our motivation.
According to globally used 3GPP standard, there is a need for establish IPsec ESP tunnel for small home base station connecting to Security GW or other core network devices.
There have existed such a great number of IPsec ESP tunnels in the underlying use case.
For meeting the least security requirement, it is needed to set up IPsec AH or IPsec ESP-NULL for the integrity protection.
Then it will increase the security cost.

If there is a simple and practical solution for this problem, then why not let it be clarified?
So that, many engineers and customers can benefit from single IPsec tunnel protection each user, which saves the cost for both.

> there is no gain in doing so. You need to justify encrypting something

[Cui Yang] I am not doing myself a disfavor, but going to provide a solution for the practical and technical problem.
Integrity protection takes overhead, as well. 
In case confidentiality is mandatory, is it a good idea to protect integrity separately?
What we need to do, is to investigate and reduce the cost as small as possible first, and see whether it is acceptable or not.
That is our motivation of the new draft.

> encrypt everything. I want to know what is the benefit from doing so,

[Cui Yang] I just answered your previous email providing the referred section and document as you required, yesterday.

> particularly in loss of accuracy, increased error budget, etc.

[Cui Yang] That is our new draft trying to explain, please check it before posting your opinion.

Thanks,
Yang

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 08 Mar 2012 10:13:48 +0000

Danny

I could see that if the *only* channel he has for data is encrypted
then it would make sense to also send the timing encrypted.
However it is not clear that this is the only channel available
since there usually needs to be one in the clear to run the
key exchange.

There is an inconsistency between the introduction which
says that the service needs to be MITM resilient and section
3.2 which says that packet markers are a problem because
of MITM.

However I agree that timing packets have resilience that data
packets do not have and maybe it would be useful if someone
wrote a draft explaining this or pointing to material explaining
this so that the parameters and usefulness of any protection
scheme could be evaluated.

Stewart

On 07/03/2012 12:56, Danny Mayer wrote:
> _______________________________________________
> TICTOC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tictoc
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Dacheng Zhang(Dacheng)" <[email-masked]>
Date: Thu, 08 Mar 2012 11:08:58 +0000

>> since there usually needs to be one in the clear to run the
[Dacheng Zhang] Do you mean there should be a IPsec AH channel or ESP Null channel for key exchange? 
As far as I know, IKEv2 and IKE can secure themselves and don't need an additional security channel to exchange keys.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 08 Mar 2012 11:33:18 +0000

> As far as I know, IKEv2 and IKE can secure themselves and don't need an additional security channel to exchange keys. 
My point is that unless there is something unusual about your system the
two ends can exchange IP packets any time they wish and use of the
secure channel is always optional.

Stewart

---

From: Danny Mayer <[email-masked]>
Date: Sat, 10 Mar 2012 18:27:24 -0500

> secure channel is always optional.

Exactly my point. The packets are already encrypted by IPSec so there is
nothing further needed. You error budget probablu goes out the window
but at least noone else can read the packets. So what has been achieved
here?

Danny

---

From: Tal Mizrahi <[email-masked]>
Date: Sun, 11 Mar 2012 11:24:00 +0200

Hi Yang,

A couple of comments:

1.       The assumption in the draft is that one-step timestamping is not accurate. However, it is basically a question of implementation. It is possible to perform one-step timestamping and to perform constant-latency-encryption/decryption. Furthermore, there are existing products that do exactly that.
There are a few academic papers that deal with the accuracy of encrypted PTP, for example see A. Treytl, B. Hirschler, "Securing IEEE 1588 by IPsec tunnels - An analysis".

2.       If I understand the goal of this draft correctly, it appears to be presenting the motivation for draft-xu-tictoc-ipsec-security-for-synchronization. If this is indeed the case, you may want to consider integrating the two drafts.

BR
Tal Mizrahi.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Cui Yang
Sent: Wednesday, March 07, 2012 5:35 AM
To: [email-masked]
Subject: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol

Hi, all,

Thanks,
Yang

==================

Yang Cui,  Ph.D.

Huawei Technologies

[email-masked]<mailto:[email-masked]>

---

From: "Dacheng Zhang(Dacheng)" <[email-masked]>
Date: Mon, 12 Mar 2012 02:05:54 +0000

Hi, See the inline please..

>> 发送时间: 2012年3月11日 7:27
>> 收件人: [email-masked]
>> 抄送: Dacheng Zhang(Dacheng); [email-masked]
>> 主题: Re: ´ð¸´: [TICTOC] Please Comment on Practical Solutions for
>> Encrypted Synchronization Protocol
>> 
>> >> As far as I know, IKEv2 and IKE can secure themselves and don't need an
>> additional security channel to exchange keys.
>> >>
>> >>
[Dacheng Zhang] 
The condition that we have discussed is that the two ends are connected with an insecure network, and they are mandated to generate an IPsec channel. In this case, if we securely transport the timing information. Should we re-use the ipsec encryption channel or generate a new one? If we use the ipsec encryption channel, then we need to consider whether the encryption and the decryption of the timing packets will introduce any error.   
>> but at least noone else can read the packets. So what has been achieved
[Dacheng Zhang] 
If a timing packet is encrypted, then we need to removed the error introduced by the encryption and decryption... There can be multiple ways and it would be nice if we can list them and give a compare. Not very sure you like this idea.

---

From: Danny Mayer <[email-masked]>
Date: Mon, 12 Mar 2012 00:01:20 -0400

On 3/11/2012 10:05 PM, Dacheng Zhang(Dacheng) wrote:
>>> -----é‚®ä»¶åŽŸä»¶-----
>>> å‘ä»¶äºº: Danny Mayer [mailto:[email-masked]]
>>> å‘é€æ—¶é—´: 2012å¹´3æœˆ11æ—¥ 7:27
>>> æ”¶ä»¶äºº: [email-masked]
>>> æŠ„é€: Dacheng Zhang(Dacheng); [email-masked]
>>> ä¸»é¢˜: Re: Â´Ã°Â¸Â´: [TICTOC] Please Comment on Practical Solutions for
> The condition that we have discussed is that the two ends are
connected with an insecure network, and they are mandated to generate an
IPsec channel. In this case, if we securely transport the timing
information. Should we re-use the ipsec encryption channel or generate a
new one?

You lost me here. Why would you generate a new one if you already have
one? Is there some benefit to doing so?

 If we use the ipsec encryption channel, then we need to
consider whether the encryption and the decryption of the timing packets
will introduce any error.

Of course it will. You need to put the timestamp in the packet before it
gets put in the IPSec tunnel and the cost of the encryption of the
packets cannot be taken into account since you don't know a priori how
long it's going to take before it gets on the wire and you cannot have
the wire driver timestamp the packets as they go out. As I said before
your error budget has just gone out the window and the encryption does
not benefit you in any way just because some document says to encrypt
all packets.

> If a timing packet is encrypted, then we need to removed the error
introduced by the encryption and decryption... There can be multiple
ways and it would be nice if we can list them and give a compare. Not
very sure you like this idea.

Which gets back to the original question of why you are encrypting them
in the first place. While you might be able to estimate or time how long
it took to decrypt the packet on the receiving system. assuming you have
a way of measuring that, you have no way of measuring this on the
sender's system as it will only know after it's completed that action
and its costs will be different on each end, not just because it takes
different lengths of time (usually) to encrypt than to decrypt but also
because the processor speeds are normally different. The only way for
the receiver to know how long it took for the sender to encrypt the
packet is if the sender sends a follow-on packet with this information.

Danny

---

From: Cui Yang <[email-masked]>
Date: Mon, 12 Mar 2012 09:09:18 +0000

Hi, Tal

Thank you for your comments. Please find my answer in the following:

1.       I am afraid that “The one-step timestamping is not accurate”, is not an assumption but a conclusion, IMO.
As we have analyzed in the Sec 2 in the new draft, encryption time does not affect the two-step timestamping, but does influence the one-step protocol.
Because e1 (encryption time of sync message sent by Master) must be calculated after the timestamp was struck, it definitely introduces errors.
As you mentioned that  some existing products employ the one-step and constant latency method, I think it could be done but depend on the error margin.
Since protocols like PTP has accuracy in the range of micro-sec to mili-sec, and time of encryption or MAC calculation varies on different devices (typically in order of less than mili-sec), it is not easy to implement constant latency method with high accuracy.

While on the other hand, two-step timestamping could  remove the influence of e1, completely. So that , we can focus on dealing with the errors by decryption time.
But I think it is good to note this fact in Sec 2.3 that one existing method for one-step timestamping is to take care of the constant delay, if error margin is acceptable.

The academic paper you noted is interesting and the data that it provides is helpful, as well. We will include it in our reference later (and also for other papers someone commented before). Thanks for reminding me.

2.       The reason you mentioned is one of the motivations we submitted a new draft.
Others are that we would not like to restrict the solution uniquely to “identifier packets” by draft-xu-tictoc-ipsec-security-for-synchronization.  After a lengthy discussion (even continuing now), we feel it necessary clarifying use cases, and comparing all possible practical solutions.

Thank you!

Best regards,
Yang
==================
Yang Cui,  Ph.D.
Huawei Technologies
[email-masked]

发件人: Tal Mizrahi [mailto:[email-masked]]
发送时间: 2012年3月11日 17:24
收件人: Cui Yang; [email-masked]
主题: RE: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol

Hi Yang,

A couple of comments:

1.       The assumption in the draft is that one-step timestamping is not accurate. However, it is basically a question of implementation. It is possible to perform one-step timestamping and to perform constant-latency-encryption/decryption. Furthermore, there are existing products that do exactly that.
There are a few academic papers that deal with the accuracy of encrypted PTP, for example see A. Treytl, B. Hirschler, “Securing IEEE 1588 by IPsec tunnels - An analysis”.

BR
Tal Mizrahi.

Hi, all,

Thanks,
Yang

==================

Yang Cui,  Ph.D.

Huawei Technologies

---

From: Cui Yang <[email-masked]>
Date: Mon, 12 Mar 2012 10:03:40 +0000

Hi, Danny

Please see inline below.

==================
 Yang Cui,  Ph.D.
 Huawei Technologies
 [email-masked]

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Danny Mayer
> 发送时间: 2012年3月12日 12:01
> 收件人: Dacheng Zhang(Dacheng)
> 抄送: [email-masked]
> 主题: Re: [TICTOC] 答复: ´ð¸´: Please Comment on Practical Solutions for
> >>>>> [Dacheng Zhang] Do you mean there should be a IPsec AH channel or
> ESP
> >>> Null channel for key exchange?
[Cui Yang] It is recommended to encrypt all traffic in existing IPsec tunnel, since there has existed one, though IPsec AH or ESP-NULL is more essential.

> Of course it will. You need to put the timestamp in the packet before it
[Cui Yang] As we have analyzed in the new draft, encryption time has no influence to two-step protocol, and decryption time could be completely removed by using a "STEP method". So, there does exists practical solution for synchronization with encrypted timing packets, which does not decrease the time accuracy. Another proposal, is "identifier encrypted timing packets", named as "STIP method" in Sec 3.2, see also draft-xu-tictoc-ipsec-security-for-synchronization.

Our new draft has described and explained this. 

> the wire driver timestamp the packets as they go out. As I said before
[Cui Yang] This is only talking about the constant encryption/decryption delay case, as Tal just commented. But referring to Tal's mail, there exists some concrete product using the exact method to solve this problem.

> not benefit you in any way just because some document says to encrypt
[Cui Yang] This is not only from "some document", but from practical requirements. Lots of security GWs and other devices have been designed and deployed following the standard, which MUST support the implementation of all transportation in IPsec tunnel.

> packet is if the sender sends a follow-on packet with this information.
[Cui Yang]  So，there are cases where accurate synchronization is required when timing packets are transported in an encrypted way.

Thanks.

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 12 Mar 2012 14:00:44 +0200

Hi Yang,

> time of encryption or MAC calculation varies on different devices (typically in order of less than mili-sec), it is not easy to implement constant latency method with high accuracy.
The encryption latency is less relevant than the encryption latency jitter. Depending on the implementation, the latency jitter of the encryption block can be brought down to near-zero-jitter. I agree it is not easy to implement, but there are existing products that do this.
Of course I agree that from an implementation perspective it is easier to achieve the same latency in two-step timestamping, and this may be a more delicate way to phrase the idea in the draft.

> Since protocols like PTP has accuracy in the range of micro-sec to mili-sec, and
BTW, in some applications PTP accuracy is measured in nanoseconds nowadays. For example, in UMTS (ETSI TS 125 105) the requirement is for 65 ns accuracy.

BR
Tal.

From: Cui Yang [mailto:[email-masked]]
Sent: Monday, March 12, 2012 11:09 AM
To: Tal Mizrahi; [email-masked]
Subject: Re: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol

Hi, Tal

Thank you!

Best regards,
Yang
==================
Yang Cui,  Ph.D.
Huawei Technologies

Hi Yang,

A couple of comments:

BR
Tal Mizrahi.

Hi, all,

Thanks,
Yang

==================

Yang Cui,  Ph.D.

Huawei Technologies

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 12 Mar 2012 16:46:56 +0000

Yang

I fully understand your motivation (actually the 2nd motivation in your draft)
to handle cases where encryption of ALL packets is mandatory, including timing ones.

However, I am not sure that TS 33.320 really mandates encryption of timing packets.

First, 33.320 clearly states that while implementation of IPsec is mandatory,
usage is optional and based on operator policy
(with the possible exception of direct links between H(e)NBs, but these links are optional too).
If IPsec is not used, then a lower layer mechanism can be used 
(w/o any specification of what exactly this lower layer mechanism needs to do), 
a method assumedly running in HW and adding almost no delay and absolutely no delay variation.

Second, even if the operator decides to use IPsec, then the standard states 
"All signalling, user, and management plane traffic over the interface 
between H(e)NB and SeGW shall be sent through an IPsec ESP tunnel".
I think we can make the case that timing is neither signaling, nor user, nor management traffic,
and thus exempt from the IPsec requirement.
Perhaps we should send 3GPP a liaison to that effect, and get an explicit waiver.

So, we are left with no use case mandating encrypting of timing packets,
and the problem goes away.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cui Yang
Sent: Thursday, March 08, 2012 03:44
To: Danny Mayer
Cc: [email-masked]
Subject: Re: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol

Danny,

Thanks,
Yang

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 12 Mar 2012 16:56:52 +0000

Yaakov, and all,
IMHO and FWIW, encryption of the timing packets probably could be waived by 3GPP (unless they decide that they will not give you even the time of the day:-).

However, I think that the requirement for authentication and integrity of these packets is valid: you probably would rather not have the, say, the value of the correction field in your PTP packets being corrupted by a man-in-the-middle attacker without being able to drop these packets as corrupted...

I also think that in theory one could provide for authentication and integrity of these packets without adding substantial and/or variable delay.
But in practice maintaining two different secured channels could be an operational burden...

Regards,
     Sasha

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Yaakov Stein
> Sent: Monday, March 12, 2012 6:47 PM
> To: Cui Yang; Danny Mayer
> Cc: [email-masked]
> According to globally used 3GPP standard, there is a need for establish IPsec
> ESP tunnel for small home base station connecting to Security GW or other
> core network devices.
> For meeting the least security requirement, it is needed to set up IPsec AH
> or IPsec ESP-NULL for the integrity protection.
> So that, many engineers and customers can benefit from single IPsec tunnel
> protection each user, which saves the cost for both.
> 
> What we need to do, is to investigate and reduce the cost as small as
> possible first, and see whether it is acceptable or not.
> [Cui Yang] I just answered your previous email providing the referred
> section and document as you required, yesterday.
> 

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Cui Yang <[email-masked]>
Date: Tue, 13 Mar 2012 02:51:11 +0000

Hi, Yaakov,

Maybe my unclear description in the draft causes some confusion. Sorry for that. 
In the second motivation, we didn’t try to argue there is a scenario where timing packets must be encrypted. 
In contrast, we try to discuss the conditions where timing packets are transported in an insecure network and there are already IPsec ESP tunnel provided. 
When we try to transport the timing packets in a secure way, we can reuse the existing IPsec ESP tunnel even though the timing packets may not be confidential itself (But integrity protection is necessary, anyway).

Best regards,
Yang
==================
 Yang Cui,  Ph.D.
 Huawei Technologies
 [email-masked]

> -----邮件原件-----
> 发件人: Yaakov Stein [mailto:[email-masked]]
> 发送时间: 2012年3月13日 0:47
> 收件人: Cui Yang; Danny Mayer
> 抄送: [email-masked]
> For meeting the least security requirement, it is needed to set up IPsec AH or
> IPsec ESP-NULL for the integrity protection.
> What we need to do, is to investigate and reduce the cost as small as possible
> first, and see whether it is acceptable or not.

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 14 Mar 2012 18:36:23 +0000

Yang

Yes, I fully appreciate the scenario you are discussing, 
where ALL packets MUST be encrypted.

I am just questioning whether such a scenario is really mandated by any standard (I believe it is not),
in which case one can simply NOT encrypt the timing packets (even if you choose to encrypt the other packets).

Y(J)S

-----Original Message-----
From: Cui Yang [mailto:[email-masked]] 
Sent: Tuesday, March 13, 2012 04:51
To: Yaakov Stein; Danny Mayer
Cc: [email-masked]
Subject: Re: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol

Hi, Yaakov,

Best regards,
Yang
==================
 Yang Cui,  Ph.D.
 Huawei Technologies
 [email-masked]

---

From: Cui Yang <[email-masked]>
Date: Thu, 15 Mar 2012 03:30:05 +0000

Hi, Yaakov,

Thanks for your comments. Please find my answer in the following.

The IPsec tunnel functionality in backhaul link between femto and SeGW are mandatory to achieve by 3GPP Technical Specification TS.33.320 
http://www.3gpp.org/ftp/specs/html-info/33320.htm
-4.3.1 Backhaul link
-4.4.5 Requirements on Backhaul Link
-7.4 IPsec Tunnel Establishment
-etc. 

This requirement is originated from the typical use case of home based wireless base station (Femto), where the backhaul cable connection is commonly leased by telecom operator and through insecure networks, not belonging to operator’s own network. Since the regulation and laws on information security and privacy are strict in many countries, vendors are requested to set up this IPsec tunnel functionality to avoid the risk of information or privacy leakage. The contents encrypted in IPsec tunnel include not only data plane, but also control plane, where the former carries the customer’s data and voice, and the latter carries sensitive information, such as the secret keys for air interface encryption. For most of operators and vendors, it is considered necessary and responsible to protect customers’ privacy and communication security, where the best way known is IPsec tunnel.

Best regards,
Yang
==================
 Yang Cui,  Ph.D.
 Huawei Technologies
 [email-masked]

> 发送时间: 2012年3月15日 2:36
> 抄送: [email-masked]; Danny Mayer
> In contrast, we try to discuss the conditions where timing packets are
> transported in an insecure network and there are already IPsec ESP tunnel
> provided.
> When we try to transport the timing packets in a secure way, we can reuse
> the existing IPsec ESP tunnel even though the timing packets may not be
> confidential itself (But integrity protection is necessary, anyway).
> 
> Best regards,
> Yang
> ==================
>  Yang Cui,  Ph.D.
>  Huawei Technologies
>  [email-masked]
> 
> > -----邮件原件-----
> > (with the possible exception of direct links between H(e)NBs, but these
> links
> > are optional too).
> Of
> > Cui Yang
> or
> > If there is a simple and practical solution for this problem, then why not let
> it
> > be clarified?
> > [Cui Yang] I am not doing myself a disfavor, but going to provide a solution
> for
> > the practical and technical problem.
> possible

---

From: "Dacheng Zhang(Dacheng)" <[email-masked]>
Date: Thu, 15 Mar 2012 04:04:09 +0000

Hi, Yaakov:

Thanks a lot for your time. See the inline please..

>> 
>> Yes, I fully appreciate the scenario you are discussing, where ALL 
>> packets MUST be encrypted.
>> 
>> I am just questioning whether such a scenario is really mandated by 
>> any standard (I believe it is not), in which case one can simply NOT 
>> encrypt the timing packets (even if you choose to encrypt the other 
>> packets).

[Dacheng Zhang] 

Could you please answer a question first? Do you think it is really reasonable to send timing packets without any protection through an insecure network especially when they are critical for synchronizing distributed servers? I think the answer is no. Please correct me if I am wrong. ^_^ I just checked RFC 1305 and RFC 4330 again. They all mentioned that in such a condition, timing packets are vulnerable to different attacks and security protection is desired. So, no matter encryption is needed or not, we need to, at least, provide integrity protection and message origin authentication for timing packets. 

We have realized that there are several use cases mentioned in the security requirement draft where encryption may need to be provided. However, I don't think whether timing packets are confidential is the core point of this discussion. If we don't worry whether timing packet will be easily identified by attackers, then we don't have to encrypt them. However, considering an attacker may try to disrupt synchronization by sending fault timing information. We insist that there should be a security manner to protect the integrity, freshness, and validity of timing packets. 

Now, let's go back to the scenario where a gateway has generated a large amount of IPsec ESP channels with the enodeBs which it manages. If we try to generate additional IPsec AH channel to transport timing packets, then the number of IPsec channels will be doubled, which will cause additional management burden and service providers will have to pay extra money since the system needs to provide more IPsec channels concurrently, which is not desired. Thus, we believe that it would be nice if we could transport timing packets through those IPsec ESP channels instead of generating new IPsec AH channel.

However, the encryption and decryption of timing packets will introduce errors into the system. We just try to propose an informational draft and discuss whether we can efficiently and effectively address such issues. As mentioned in Tal's emails, there are efforts in transporting timing packets. Such information is very useful, and we will add it into our draft. 

Those are my humble opinions. ^_^

BR

Dacheng    

>> In contrast, we try to discuss the conditions where timing packets 
>> are transported in an insecure network and there are already IPsec 
>> ESP tunnel provided.
>> When we try to transport the timing packets in a secure way, we can 
>> reuse the existing IPsec ESP tunnel even though the timing packets 
>> may not be confidential itself (But integrity protection is necessary, anyway).
>> 
>> Best regards,
>> Yang
>> ==================
>>  Yang Cui,  Ph.D.
>>  Huawei Technologies
>>  [email-masked]
>> 
>> > -----邮件原件-----
>> > I fully understand your motivation (actually the 2nd motivation in 
>> > your draft) to handle cases where encryption of ALL packets is 
>> > mandatory, including timing ones.
>> >
>> > First, 33.320 clearly states that while implementation of IPsec is 
>> > mandatory, usage is optional and based on operator policy (with the 
>> > possible exception of direct links between H(e)NBs, but these links 
>> > are optional too).
>> > If IPsec is not used, then a lower layer mechanism can be used (w/o 
>> > any specification of what exactly this lower layer mechanism needs 
>> > to do), a method assumedly running in HW and adding almost no delay 
>> > and absolutely no delay variation.
>> >
>> > Second, even if the operator decides to use IPsec, then the 
>> > standard states "All signalling, user, and management plane traffic 
>> > over the interface between H(e)NB and SeGW shall be sent through an IPsec ESP tunnel".
>> > I think we can make the case that timing is neither signaling, nor 
>> > user, nor management traffic, and thus exempt from the IPsec 
>> > requirement.
>> > So, we are left with no use case mandating encrypting of timing 
>> > packets, and the problem goes away.
>> >
>> > Y(J)S
>> >
>> >
>> > > 主题: Re: [TICTOC] Please Comment on Practical Solutions for 
>> > > I have already said this before and I will repeat this for the 
>> > > purposes of feedback.
>> > >
>> > > Time packets do not need to be encrypted as not only do they not 
>> > > contain anything secret, even if you knew the contents they are 
>> > > useless anytime after the packet has been delivered.
>> >
>> > According to globally used 3GPP standard, there is a need for 
>> > establish IPsec ESP tunnel for small home base station connecting 
>> > to Security GW or other core network devices.
>> > So that, many engineers and customers can benefit from single IPsec 
>> > tunnel protection each user, which saves the cost for both.
>> >
>> > > You do yourself a disfavor in encrypting something that is not 
>> > > worth encrypting. It takes processing overhead, increases packet 
>> > > size, and there is no gain in doing so. You need to justify 
>> > > encrypting something
>> >
>> > > and please don't say that it is because some other document says 
>> > > to encrypt everything. I want to know what is the benefit from 
>> > > doing so,
>> >
>> > [Cui Yang] I just answered your previous email providing the 
>> > referred section and document as you required, yesterday.
>> >
>> > > what are the risks in not doing so and what is the cost of doing 
>> > > so, particularly in loss of accuracy, increased error budget, etc.
>> >
>> > > > I have posted a new draft that discusses the practical 
>> > > > solutions for encrypted synchronization protocols.
>> > > >
>> > > >
>> > > >
>> > > > requirement of synchronization also noted that confidentiality 
>> > > > may need protection, especially in case that the 
>> > > > confidentiality protection is mandatory. Synchronization should 
>> > > > be available when the traffic is encrypted. The influences by 
>> > > > the encryption are explained, and several possible solutions have been discussed.
>> > > >

---

From: Cui Yang <[email-masked]>
Date: Thu, 15 Mar 2012 06:52:52 +0000

Thanks, Tal and all

The new draft investigates the influence of encryption/decryption to synchronization, and is basically independent from the previous work.
We try to provide a simple and unambiguous informational document to help people who may face to similar problem in practice.
I think there are a few practical solutions, as we have analyzed in the new draft.

The information you mentioned is interesting and helpful, as you have said there exist some products that do this.
We would like to include this (with more details) in the next version.

>If I understand the goal of this draft correctly, it appears to be presenting the motivation for draft-xu-tictoc-ipsec-security-for-synchronization. If this is indeed the case, you may want to consider integrating the two drafts.

We will try to collect more feedback from the WG in the coming Paris meeting to decide whether we will spend more time on the previous draft,
draft-xu-tictoc-ipsec-security-for-synchronization .

Thanks,
Yang
==================
Yang Cui,  Ph.D.
Huawei Technologies
[email-masked]

发送时间: 2012年3月12日 20:01

Hi Yang,

BR
Tal.

Hi, Tal

Thank you!

Best regards,
Yang
==================
Yang Cui,  Ph.D.
Huawei Technologies

Hi Yang,

A couple of comments:

BR
Tal Mizrahi.

Hi, all,

Thanks,
Yang

==================

Yang Cui,  Ph.D.

Huawei Technologies

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 18 Mar 2012 14:18:26 +0000

Dacheng

To answer your question - I completely agree that "protecting" timing packets makes sense.
I completely disagree that encrypting timing packets makes sense.

We discussed this at great length at the beginning of the TICTOC WG.
What timing packets need is authentication of the master (or actually proventication).
On rare occasions authentication of the slave may be meaningful.

IPsec really does not help here.
ESP is not needed and AH is not enough by itself.

Y(J)S

-----Original Message-----
From: Dacheng Zhang(Dacheng) [mailto:[email-masked]] 
Sent: Thursday, March 15, 2012 05:24
To: Yaakov Stein; Cui Yang
Cc: [email-masked]
Subject: 答复: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol

Hi, Yaakov:

[Dacheng Zhang] 

Could you answer a question first? Do you think it is really reasonable to send timing packets without any protection through an insecure network especially when they are critical for synchronizing distributed servers? I think the answer is no. Please correct me if I am wrong. ^_^ I just checked RFC 1305 and RFC 4330 again. They all mentioned that in such a condition, timing packets are vulnerable to different attacks and security protection is desired. So, no matter encryption is needed or not, we need to, at least, provide integrity protection and message origin authentication for timing packets. 

BR

Dacheng

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 18 Mar 2012 14:22:01 +0000

Yang

What do you mean by "mandatory to achieve".

What 33.320 says is that IPsec is mandatory to implement in HW,
but optional to use.
Furthermore, my interpretation is that timing packets are explicitly not covered,
since they mention which types of packets should be protected,
and none of the types mentioned describe timing packets.

I have a question for you.
Were we to use NTP with Autokey and thus provide strong proventication,
would you see any benefit to using IPsec ?
Do you agree that there is a drawback to its use ?

Y(J)S

-----Original Message-----
From: Cui Yang [mailto:[email-masked]] 
Sent: Thursday, March 15, 2012 05:30
To: Yaakov Stein
Cc: [email-masked]; Danny Mayer
Subject: Re: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol

Hi, Yaakov,

Best regards,
Yang
==================
 Yang Cui,  Ph.D.
 Huawei Technologies
 [email-masked]

> contain
> tunnel

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 18 Mar 2012 15:06:50 +0000

Hi all,
I fully agree with Yaakov that encrypting timing packets does not make any sense.

I am not sure if authentication of the Slave is needed only on rare occasions:
Spoofing tons of Delay Requests from genuinely-looking slaves could be a nice way to attack a given Master until it crashes...

My 2c,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] on behalf of Yaakov Stein [[email-masked]]
Sent: Sunday, March 18, 2012 3:18 PM
To: Dacheng Zhang(Dacheng); Cui Yang
Cc: [email-masked]
Subject: Re: [TICTOC] Please Comment on Practical Solutions     for     Encrypted       Synchronization Protocol

Dacheng

Y(J)S

-----Original Message-----
From: Dacheng Zhang(Dacheng) [mailto:[email-masked]]
Sent: Thursday, March 15, 2012 05:24
To: Yaakov Stein; Cui Yang
Cc: [email-masked]
Subject: 答复: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol

Hi, Yaakov:

[Dacheng Zhang]

BR

Dacheng

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 18 Mar 2012 17:30:08 +0000

Sasha

The reason we were thinking about is charging for timing services.

Forcing an NTP server to authenticate clients will probably overload it faster than attacking a non-authenticating server.

A master that holds state will probably have the slaves configured,
or some strong authentication will be needed at the beginning of the process.

Y(J)S

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Sunday, March 18, 2012 17:07
To: Yaakov Stein; Dacheng Zhang(Dacheng); Cui Yang
Cc: [email-masked]
Subject: RE: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol

Hi all,

My 2c,
     Sasha

Dacheng

Y(J)S

-----Original Message-----
From: Dacheng Zhang(Dacheng) [mailto:[email-masked]]
Sent: Thursday, March 15, 2012 05:24
To: Yaakov Stein; Cui Yang
Cc: [email-masked]
Subject: 答复: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol

Hi, Yaakov:

[Dacheng Zhang]

BR

Dacheng

---

From: Cui Yang <[email-masked]>
Date: Mon, 19 Mar 2012 04:14:47 +0000

Hi, Yaakov,

I said the IPsec tunnel “functionality” is mandatory to achieve, which means the device MUST support IPsec ESP tunnel (confidentiality and integrity).  

More specifically, TS 33.320 does explicitly describe security requirement for time synchronization, where 
-Sec.6.3.1, Clock Synchronization Security Mechanisms for H(e)NB 
-“The H(e)NB requires time synchronization with a time server. The H(e)NB SHALL support receiving time synchronisation messages over the secure backhaul link between H(e)NB and the SeGW”
- “Optionally other secure clock servers may be used, which do not use the secure backhaul link. In this case the communication between these clock server(s) and H(e)NB SHALL be secured.”

From the above, my interpretation is,
-synchronization MUST be adequately protected
-synchronization mechanism MUST be supported by IPsec ESP tunnel mode (for devices)
-In the case that IPsec is not chosen to use (though the devices do support), separate secured clock mechanism MUST be used.

Therefore, if IPsec tunnel is deployed, then synchronization protocol must support it; 
otherwise different security mechanism is deployed, and a separate secure protection (more than IPsec AH) for synchronization must be provided.
From a vendor’s point of view, it is required to investigate this problem and compare the performances of different approaches. 

Finally, answering your question, Autokey is designed “based on the premise that IPsec schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy”[RFC5906].
But, what if the IPsec tunnel is available already? Is there any evaluation on this “severely” compromising accuracy? I wonder whether there is any benefit to setting up separate security mechanism, if the device already has end-to-end IPsec tunnel connection. 
And I believe that our investigation and analysis on this practical problem is necessary and meaningful, which still could be greatly improved via the discussion with you all.

Thanks,
Yang
==================
 Yang Cui,  Ph.D.
 Huawei Technologies
 [email-masked]

> 发送时间: 2012年3月18日 22:22
> The IPsec tunnel functionality in backhaul link between femto and SeGW are
> mandatory to achieve by 3GPP Technical Specification TS.33.320
> This requirement is originated from the typical use case of home based
> wireless base station (Femto), where the backhaul cable connection is
> commonly leased by telecom operator and through insecure networks, not
> belonging to operator’s own network. Since the regulation and laws on
> information security and privacy are strict in many countries, vendors are
> requested to set up this IPsec tunnel functionality to avoid the risk of
> information or privacy leakage. The contents encrypted in IPsec tunnel
> include not only data plane, but also control plane, where the former carries
> the customer’s data and voice, and the latter carries sensitive information,
> such as the secret keys for air interface encryption. For most of operators
> and vendors, it is considered necessary and responsible to protect customers’
> privacy and communication security, where the best way known is IPsec
> tunnel.
> 
> Best regards,
> Yang
> ==================
>  Yang Cui,  Ph.D.
>  Huawei Technologies
>  [email-masked]
> 
> > -----邮件原件-----
> > > However, I am not sure that TS 33.320 really mandates encryption of
> timing
> > > packets.
> > >
> mandatory,
> > > (w/o any specification of what exactly this lower layer mechanism needs
> to
> > > do),
> > > Subject: Re: [TICTOC] Please Comment on Practical Solutions for
> Encrypted
> > > Synchronization Protocol
> > >
> > > Danny,
> > >

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 19 Mar 2012 17:16:13 +0000

Yang

We agree, yet disagree.

I agree that 33.320 mandates that hardware support IPsec tunnels.
I think that you agree that they are not mandatory to implement.

I agree that 33.320 mandates that timing be "secured".
I think that you agreed that there has been no demonstration that this "security" includes packet encryption.
I disagree that IPsec AH or ESP provides meaningful "security" for timing - 
the only meaningful measure is proventication back to a grand master, 
not authenticating some networking device.

I agree that studying the effect of IPsec on timing packets is an meaningful exercise.
I believe that this study has been done before.
I am convinced that such studies are dependent on the IPsec implementation details,
and are thus probably more of interest to network designers
than to the IETF.

Finally, I disagree that IPsec is a fait accompli in this application,
while I agree that people who do not consider the possible negative effect
of IPsec on timing flows might blindly apply it.

Since the TICTOC agenda is quite full,
I suggest that we plan some f2f time next week,
and invite all those interested in the discussion to participate.

Y(J)S

-----Original Message-----
From: Cui Yang [mailto:[email-masked]] 
Sent: Monday, March 19, 2012 06:15
To: Yaakov Stein
Cc: [email-masked]; Danny Mayer; Zhangdacheng (Dacheng)
Subject: Re: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol

Hi, Yaakov,

Thanks,
Yang
==================
 Yang Cui,  Ph.D.
 Huawei Technologies
 [email-masked]

---

From: Cui Yang <[email-masked]>
Date: Wed, 21 Mar 2012 08:35:26 +0000

Hi, Yaakov,

> and invite all those interested in the discussion to participate.
Thanks for your kind arrangement, I think a f2f discussion is helpful and constructive.
If possible, shall we do that right after the tictoc meeting Monday morning, so that people who are interested could join us.

Thanks. See you in Paris!

Best regards,
Yang
==================
 Yang Cui,  Ph.D.
 Huawei Technologies
 [email-masked]

> 发送时间: 2012年3月20日 1:16
> 抄送: [email-masked]; Danny Mayer; Zhangdacheng (Dacheng)
> I said the IPsec tunnel “functionality” is mandatory to achieve, which means
> the device MUST support IPsec ESP tunnel (confidentiality and integrity).
> 
> -“The H(e)NB requires time synchronization with a time server. The H(e)NB
> SHALL support receiving time synchronisation messages over the secure
> backhaul link between H(e)NB and the SeGW”
> - “Optionally other secure clock servers may be used, which do not use the
> secure backhaul link. In this case the communication between these clock
> server(s) and H(e)NB SHALL be secured.”
> 
> -In the case that IPsec is not chosen to use (though the devices do support),
> separate secured clock mechanism MUST be used.
> 
> otherwise different security mechanism is deployed, and a separate secure
> protection (more than IPsec AH) for synchronization must be provided.
> From a vendor’s point of view, it is required to investigate this problem and
> compare the performances of different approaches.
> 
> Finally, answering your question, Autokey is designed “based on the premise
> that IPsec schemes cannot be adopted intact, since that would preclude
> stateless servers and severely compromise timekeeping accuracy”[RFC5906].
> But, what if the IPsec tunnel is available already? Is there any evaluation on
> this “severely” compromising accuracy? I wonder whether there is any
> benefit to setting up separate security mechanism, if the device already has
> end-to-end IPsec tunnel connection.
> And I believe that our investigation and analysis on this practical problem is
> necessary and meaningful, which still could be greatly improved via the
> discussion with you all.
> 
> Thanks,
> Yang
> ==================
>  Yang Cui,  Ph.D.
>  Huawei Technologies
>  [email-masked]
> 
> > -----邮件原件-----
> > > Maybe my unclear description in the draft causes some confusion. Sorry
> for
> > > that.
> reuse
> > > > 主题: RE: [TICTOC] Please Comment on Practical Solutions for
> Encrypted
> > > > Synchronization Protocol
> > > >
> > > > Yang
> > > >
> > > > to handle cases where encryption of ALL packets is mandatory,
> including
> > > > timing ones.
> > > >
> > > > I think we can make the case that timing is neither signaling, nor user,
> nor
> > > > management traffic,