Hi, Yaakov, > 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. 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 protected] > -----邮件原件----- > 发件人: Yaakov Stein [mailto:[email protected]] > 发送时间: 2012年3月20日 1:16 > 收件人: Cui Yang > 抄送: [email protected]; Danny Mayer; Zhangdacheng (Dacheng) > 主题: RE: [TICTOC] Please Comment on Practical Solutions for Encrypted > Synchronization Protocol > > 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 protected]] > Sent: Monday, March 19, 2012 06:15 > To: Yaakov Stein > Cc: [email protected]; Danny Mayer; Zhangdacheng (Dacheng) > Subject: Re: [TICTOC] Please Comment on Practical Solutions for Encrypted > Synchronization Protocol > > 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 protected] > > > -----邮件原件----- > > 发件人: Yaakov Stein [mailto:[email protected]] > > 发送时间: 2012年3月18日 22:22 > > 收件人: Cui Yang > > 抄送: [email protected]; Danny Mayer > > 主题: RE: [TICTOC] Please Comment on Practical Solutions for Encrypted > > Synchronization Protocol > > > > 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 protected]] > > Sent: Thursday, March 15, 2012 05:30 > > To: Yaakov Stein > > Cc: [email protected]; Danny Mayer > > Subject: Re: [TICTOC] Please Comment on Practical Solutions for Encrypted > > Synchronization Protocol > > > > 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 protected] > > > > > -----邮件原件----- > > > 发件人: Yaakov Stein [mailto:[email protected]] > > > 发送时间: 2012年3月15日 2:36 > > > 收件人: Cui Yang > > > 抄送: [email protected]; Danny Mayer > > > 主题: RE: [TICTOC] Please Comment on Practical Solutions for Encrypted > > > Synchronization Protocol > > > > > > 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 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
