Re: [TICTOC] The draft for IPsec synchronization security

Jack Kohn <kohn.jack@gmail.com> Sat, 04 December 2010 00:51 UTC

Return-Path: <kohn.jack@gmail.com>
X-Original-To: tictoc@core3.amsl.com
Delivered-To: tictoc@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D7863A67F8 for <tictoc@core3.amsl.com>; Fri, 3 Dec 2010 16:51:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.077
X-Spam-Level:
X-Spam-Status: No, score=-3.077 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-n-7PUdAIvF for <tictoc@core3.amsl.com>; Fri, 3 Dec 2010 16:51:06 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id EF6173A67B1 for <tictoc@ietf.org>; Fri, 3 Dec 2010 16:51:05 -0800 (PST)
Received: by iwn40 with SMTP id 40so12391403iwn.31 for <tictoc@ietf.org>; Fri, 03 Dec 2010 16:52:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=R24GEattWCDA2nNdo1q0dhWdlGbkRJuA0WgpVr7PJm8=; b=Pd6h83aosR0qpAbrWCZJLkQmE8+F/+aDDc10kziPqAFsEhLAnhEOCx3cP7QLXJOjtC W1xL3wakcBN2joCJtDG8oiHvGFM6c9reizGt1MReLA8pmePX98PtebJGkp1NpgxLWMjW IFxkA5bh6O3iAvqEvrOqL2Ehz9cIqeKXSm9G0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GcK2Kpd5/SGzpKKfqbN9hwGEh39FFNirBxte/Cv3CjVFBTOdreFmWZF8JhJloAfwvl U1Bi9OdhJU5Ez1ZNTLyGGx8sS/R82X82K8OCUw73vVH9VuX7Mq8NU26pDw0Wx6vR6Uez xn/uWict8f4oOIARkY2yt3W34v4wu9a8Et99k=
MIME-Version: 1.0
Received: by 10.231.37.197 with SMTP id y5mr2551798ibd.165.1291423942760; Fri, 03 Dec 2010 16:52:22 -0800 (PST)
Received: by 10.231.206.133 with HTTP; Fri, 3 Dec 2010 16:52:22 -0800 (PST)
In-Reply-To: <082B1A87E77649DEB574DD78E5F160D2@china.huawei.com>
References: <AANLkTi=M+JWv+REtvHMkc1+sAWZeSuWS1LiKNeqWV4CS@mail.gmail.com> <00a401cb8492$da18ef70$51106f0a@china.huawei.com> <AANLkTikeXMTm+kMt4E-gC8ygyxCxoYwCTPqrpqWG8b+S@mail.gmail.com> <CB45EB047BD43041BF1F4CC7D6DB21BF05DF6B26@sjmail2.symmetricom.com> <AANLkTi=EXtnP5YO_qPEGk_yO3_K0qwXF2dVB7AcADaG0@mail.gmail.com> <082B1A87E77649DEB574DD78E5F160D2@china.huawei.com>
Date: Sat, 04 Dec 2010 06:22:22 +0530
Message-ID: <AANLkTinOPD2bnwof9nBfHytYu5gtyxDbQv=q578CvAu+@mail.gmail.com>
From: Jack Kohn <kohn.jack@gmail.com>
To: Michel Ouellette <michel.ouellette@huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: tictoc@ietf.org
Subject: Re: [TICTOC] The draft for IPsec synchronization security
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tictoc>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Dec 2010 00:51:07 -0000

Hi Michel,

> 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.

Thanks for the pointers.

>
> 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"?

"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

>
> Who is "we" and why do you think there is a need for security between a GM
> and BC?
>
> Bye.
>
> -----Original Message-----
> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of
> Jack Kohn
> Sent: December 03, 2010 01:12 PM
> To: Greg Dowd
> Cc: tictoc@ietf.org
> Subject: Re: [TICTOC] The draft for IPsec synchronization security
>
> 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.
>
> On Fri, Dec 3, 2010 at 6:30 AM, Greg Dowd <GDowd@symmetricom.com> 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.
>>
>> -----Original Message-----
>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf
> Of Jack Kohn
>> Sent: Thursday, December 02, 2010 4:49 PM
>> To: Xie Lei
>> Cc: tictoc@ietf.org
>> Subject: Re: [TICTOC] The draft for IPsec synchronization security
>>
>> 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 <xielei57471@huawei.com> 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: xielei57471@huawei.com ; tictoc@ietf.org
>>> 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
>> _______________________________________________
>> TICTOC mailing list
>> TICTOC@ietf.org
>> https://www.ietf.org/mailman/listinfo/tictoc
>>
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc
>
>