One can easily imagine a two step boot process, one where the time is
roughly determined using Autokey, and then the IPsec tunnel is set up,
and then further timing packets sent over the tunnel. I don't know the
precision of the timestamps, in IPsec certificates, but I doubt that it
is more than to the second, and more likely it is to the minute. If all
you care about is the validity of the certs, then it shouldn't take a
long time to get the time accurate to this level. If it were not for the
possibility of reverse engineering the femto station, the original auth
key scheme would work even better. But since the femto stations are
distributed to untrusted users (I use one for instance, and who would
trust me?) that wouldn't work.
On 08/29/12 17:43, Danny Mayer wrote:
I know that this is a rather old email message but when I was reviewing
it, it occurred to me that if IPSec requires accurate clocks to set
itself up then this won't work and you need, at least initially, to do
without IPSec.
Danny
On 3/19/2012 12:14 AM, Cui Yang wrote:
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
_______________________________________________
ntpwg mailing list
[email protected]
http://lists.ntp.org/listinfo/ntpwg
--
blu
Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live. - Martin Golding
-----------------------------------------------------------------------|
Brian Utterback - Solaris RPE, Oracle Corporation.
Ph:603-262-3916, Em:[email protected]
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
