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
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Yaakov Stein
> Sent: Monday, March 12, 2012 6:47 PM
> To: Cui Yang; Danny Mayer
> Cc: [email protected]
> Subject: 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
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.
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
