Sorry for duplicate mails. m(_ _)m Since Dacheng's outlook account failed to send to tictoc mailing list, I forward this answer to the list, instead.
Thanks ================== Yang Cui, Ph.D. Huawei Technologies [email protected] -----邮件原件----- 发件人: Zhangdacheng (Dacheng) 发送时间: 2012年3月19日 10:50 收件人: Yaakov Stein; Cui Yang 抄送: [email protected] 主题: 答复: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol Hi, Yaakov: Thanks a lot for your reply. I would like clarify again that I never try to discuss whether encrypting timing packets is necessary in this scenario. We can analyze this issue when giving comments to the security request draft. So, let's follow your comments here. Assume in this case, the timing packets are NOT confidential and need NOT to be encrypted. Now, if you are the designer of the system which choice will you make? To reuse the existing ipsec esp channels to transport the timing packets or try to convince your customer to pay extra money and bear the management complexity imposed by generating additional AH channels? In my personal opinion, reusing existing IPsec ESP channels seems more preferable. It is a bit strange in logic to say" service providers have to pay additional money to generate more IPsec AH channels because exising IPsec ESP channels are TOO secure to transport timing packets." Please correct me if there are any mistakes. ^_^ Some products of Cisco, Huawei, and AL have already supported the encryption of timing packets with IPsec ESP. The following link introduces how to configure IPsec ESP channel to transport NTP packets. http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080a5641e.shtml. We just try to compare possible solutions or processing encrypted timing packets and compare their performance. I don't try to say that timing packets are confidential in some case just because existing products have provided this functionality. This issue needs to be further discussed. But I would like to say that the reuse of existing IPsec ESP channels is not a corner case. Best Regards, Dacheng >> -----邮件原件----- >> 发件人: Yaakov Stein [mailto:[email protected]] >> 发送时间: 2012年3月18日 22:18 >> 收件人: Zhangdacheng (Dacheng); Cui Yang >> 抄送: [email protected] >> 主题: RE: [TICTOC] Please Comment on Practical Solutions for Encrypted >> Synchronization Protocol >> >> 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 protected]] >> Sent: Thursday, March 15, 2012 05:24 >> To: Yaakov Stein; Cui Yang >> Cc: [email protected] >> Subject: 答复: [TICTOC] Please Comment on Practical Solutions for Encrypted >> Synchronization Protocol >> >> 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 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 >> >> >> >> >> >> Y(J)S >> >> >> >> -----Original Message----- >> >> From: Cui Yang [mailto:[email protected]] >> >> Sent: Tuesday, March 13, 2012 04:51 >> >> To: Yaakov Stein; Danny Mayer >> >> Cc: [email protected] >> >> Subject: Re: [TICTOC] Please Comment on Practical Solutions for Encrypted >> >> Synchronization Protocol >> >> >> >> 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 protected] >> >> >> >> > -----邮件原件----- >> >> > 发件人: Yaakov Stein [mailto:[email protected]] >> >> > 发送时间: 2012年3月13日 0:47 >> >> > 收件人: Cui Yang; Danny Mayer >> >> > 抄送: [email protected] >> >> > 主题: RE: [TICTOC] Please Comment on Practical Solutions for Encrypted >> >> > Synchronization Protocol >> >> > >> >> > 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 protected] [mailto:[email protected]] On >> Behalf >> >> Of >> >> > Cui Yang >> >> > Sent: Thursday, March 08, 2012 03:44 >> >> > To: Danny Mayer >> >> > Cc: [email protected] >> >> > Subject: Re: [TICTOC] Please Comment on Practical Solutions for >> Encrypted >> >> > Synchronization Protocol >> >> > >> >> > Danny, >> >> > >> >> > Thanks for your comments. I will respond inline. >> >> > >> >> > > -----邮件原件----- >> >> > > 发件人: Danny Mayer [mailto:[email protected]] >> >> > > 发送时间: 2012年3月7日 20:56 >> >> > > 收件人: Cui Yang >> >> > > 抄送: [email protected] >> >> > > 主题: Re: [TICTOC] Please Comment on Practical Solutions for >> Encrypted >> >> > > Synchronization Protocol >> >> > > >> >> > > 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. >> >> > >> >> > [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. >> >> > >> >> > > 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 >> >> > >> >> > [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. >> >> > >> >> > > 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. >> >> > >> >> > [Cui Yang] That is our new draft trying to explain, please check it >> >> > before >> >> > posting your opinion. >> >> > >> >> > > The whole thing is a bad idea from what I can tell. >> >> > > >> >> > > Danny >> >> > > >> >> > >> >> > Thanks, >> >> > Yang >> >> > >> >> > >> >> > > On 3/6/2012 10:35 PM, Cui Yang wrote: >> >> > > > 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 protected] >> >> > _______________________________________________ >> >> > TICTOC mailing list >> >> > [email protected] >> >> > https://www.ietf.org/mailman/listinfo/tictoc >> >> _______________________________________________ >> >> TICTOC mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
