Re: [TICTOC] The draft for IPsec synchronization security

["Greg Dowd" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Jack Kohn
Sent: Friday, December 03, 2010 4:52 PM
To: Michel Ouellette
Cc: [e-mail]
Subject: Re: [TICTOC] The draft for IPsec synchronization security

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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Jack Kohn
> Sent: December 03, 2010 01:12 PM
> To: Greg Dowd
> Cc: [e-mail]
> 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 <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Jack Kohn
>> Sent: Thursday, December 02, 2010 4:49 PM
>> To: Xie Lei
>> Cc: [e-mail]
>> 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 <[e-mail]> 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: [e-mail] ; [e-mail]
>>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tictoc
>>
> _______________________________________________
> TICTOC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tictoc
>
>
_______________________________________________
TICTOC mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tictoc