Subject: Re: [TICTOC] The draft for IPsec synchronization security

From: Jack Kohn <[email-masked]>
Date: Fri, 3 Dec 2010 06:18:34 +0530

Xie,

Is there a reason why you cant use the Security mechanism described in
Annex K of IEEE std 1588-2008?

Jack

On Mon, Nov 15, 2010 at 12:30 PM, Xie Lei <[email-masked]> wrote:
>
>
> Hi Jack
>
> Thanks for your information, i had discussed with RFC5840 authors in IETF
> 79# meeting. It is possible to use RFC5840 to fulfill this synchronization
> requirements. I will follow the progress and provide more information to
> Tictoc group.
>
> BR
>
> Rock
>
> ----- Original Message -----
> From: Jack Kohn
> To: [email-masked] ; [email-masked]
> Sent: Saturday, November 13, 2010 12:30 PM
> Subject: RE: The draft for IPsec synchronization security
> Xie:
>
> While i understand your motivation to secure the timing packets, you
> really dont need the extensions that you have defined in the below
> draft. You must look at RFC 5840 that extends ESP and see how that can
> be used for achieving the same functionality as you desire.
>
> Jack
>
>> Hi Yaakov and all
>> Huawei has submitted one draft for IPSec synchronization security, you can
>> find it in following link
>>
>> http://www.ietf.org/id/draft-xu-tictoc-ipsec-security-for-synchronization-00.txt
>>
>> We also attach one discussion document in this email, i hope we can
>> present it in IETF Beijing meeting.
>>
>> BR
>> Rock

---

From: "Greg Dowd" <[email-masked]>
Date: Thu, 2 Dec 2010 17:00:32 -0800

I believe the goal was not to suggest a method for adding security but a method for handling the security imposed by the LTE standard for femto.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jack Kohn
Sent: Thursday, December 02, 2010 4:49 PM
To: Xie Lei
Cc: [email-masked]
Subject: Re: [TICTOC] The draft for IPsec synchronization security

Xie,

Jack

>> present it in IETF Beijing meeting.
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: Jack Kohn <[email-masked]>
Date: Fri, 3 Dec 2010 23:42:19 +0530

Any pointers on where i can get the LTE standard for femto?

I was under the impression that this would also be used by 1588 for
delivering a solution for frequency distribution, when we need to
provide security between the master and the boundary clocks, etc.

---

From: Michel Ouellette <[email-masked]>
Date: Fri, 03 Dec 2010 13:49:52 -0500

Hi Jack,

Have a look at the following two internet-drafts for reference
http://tools.ietf.org/html/draft-xie-tictoc-femtocell-analysis-00
http://tools.ietf.org/html/draft-xu-tictoc-ipsec-security-for-synchronizatio
n-00

an example is 3GPP, "Security of Home Node B (HNB) / Home evolved Node B
(HeNB)", 3GPP TR 33.820 8.1.0, June 2009.

As Greg said, note that Annex K of IEEE1588 is an informative and
experimental Annex and might not represent the requirements of a particular
application like femtocells.

Can you clarify what you mean by "we need to provide security between the
master and the boundary clocks"?

Who is "we" and why do you think there is a need for security between a GM
and BC?

Bye.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jack Kohn
Sent: December 03, 2010 01:12 PM
To: Greg Dowd
Cc: [email-masked]
Subject: Re: [TICTOC] The draft for IPsec synchronization security

On Fri, Dec 3, 2010 at 6:30 AM, Greg Dowd <[email-masked]> wrote:
> I believe the goal was not to suggest a method for adding security but a
method for handling the security imposed by the LTE standard for femto.
>>> find it in following link
http://www.ietf.org/id/draft-xu-tictoc-ipsec-security-for-synchronization-00
.txt

---

From: Jack Kohn <[email-masked]>
Date: Sat, 4 Dec 2010 06:22:22 +0530

Hi Michel,

> (HeNB)", 3GPP TR 33.820 8.1.0, June 2009.

Thanks for the pointers.

> master and the boundary clocks"?

"we" was the provider.

You would need to provide security (data integrity) between the master
and the boundary so that no intermediary node can change the contents
of the PTP packet before it reaches the BC.

Jack

---

From: "Greg Dowd" <[email-masked]>
Date: Fri, 3 Dec 2010 17:22:18 -0800

Currently, the ITU Recommendation 8265.1 IEEE1588 profile for telecom (frequency delivery without support from network nodes) precludes the use of on-path support which makes part of the discussion somewhat moot.  However, emerging designs for phase are definitely leveraging PTP aware elements.  If there are trust issues on the link between the master and a BC, there are likely to be trust issues with the bearer traffic as well, again arguing for a common model.  However, it is true that a separate method such as Annex K would also work.  I would note that there is a significant error in the published standard in the security associated with the initialization of the session parameters which would need to be taken into account in any implementation.  I think Georg Gaderer (AAS) already published a review and a suggested method to correct this problem at one of the ISPCS meetings.  I would also point out that time is ephemeral and it is quite possible to maliciously interfere with a synchronization session merely by modulating the delay and/or introducing asymmetry which would not be mitigated by any encryption or authentication mechanism currently proposed.  This is a subject of longstanding discussion in the NTP community as well.

This is a good topic since we, as engineers, typically try to solve the problem logically but then find that some standards body forgot that synchronization is a fundamental concept and mandates something like backhaul being tunneled through an IPSec connection!  Then again, I have to admit that I sometimes forget that the packet network isn't there just to carry PTP but occasionally needs to push mail to my Droid :-)   Have a good weekend.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jack Kohn
Sent: Friday, December 03, 2010 4:52 PM
To: Michel Ouellette
Cc: [email-masked]
Subject: Re: [TICTOC] The draft for IPsec synchronization security

Hi Michel,

Thanks for the pointers.

"we" was the provider.

Jack