headers
Jack Kohn | 3 Dec 2010 01:48
Picon

Re: 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 <at> 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 <at> huawei.com ; tictoc <at> 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
(Continue reading)

Permalink | Reply | 5 comments |
headers
Greg Dowd | 3 Dec 2010 02:00
Favicon

Re: The draft for IPsec synchronization security

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 <at> ietf.org [mailto:tictoc-bounces <at> ietf.org] On Behalf Of Jack Kohn
Sent: Thursday, December 02, 2010 4:49 PM
To: Xie Lei
Cc: tictoc <at> 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 <at> 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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jack Kohn | 3 Dec 2010 19:12
Picon

Re: 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 <at> 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 <at> ietf.org [mailto:tictoc-bounces <at> ietf.org] On Behalf Of Jack Kohn
> Sent: Thursday, December 02, 2010 4:49 PM
> To: Xie Lei
> Cc: tictoc <at> 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 <at> huawei.com> wrote:
>>
>>
>> Hi Jack
>>
>> Thanks for your information, i had discussed with RFC5840 authors in IETF
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michel Ouellette | 3 Dec 2010 19:49
Favicon

Re: The draft for IPsec synchronization security

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: tictoc-bounces <at> ietf.org [mailto:tictoc-bounces <at> ietf.org] On Behalf Of
Jack Kohn
Sent: December 03, 2010 01:12 PM
To: Greg Dowd
Cc: tictoc <at> ietf.org
Subject: Re: [TICTOC] The draft for IPsec synchronization security
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jack Kohn | 4 Dec 2010 01:52
Picon

Re: 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Greg Dowd | 4 Dec 2010 02:22
Favicon

Re: The draft for IPsec synchronization security

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: tictoc-bounces <at> ietf.org [mailto:tictoc-bounces <at> ietf.org] On Behalf Of Jack Kohn
Sent: Friday, December 03, 2010 4:52 PM
To: Michel Ouellette
Cc: tictoc <at> ietf.org
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bhatia, Manav (Manav | 4 Dec 2010 03:20
Favicon

The draft for IPsec synchronization security

Hi,

My understanding of the problem is as follows:

Currently nodes recognize 1588 packets at the physical ports and generate a timestamp on RX or TX at a
reference point between the PHY and the MAC. This becomes complicated when we throw Ipsec as the nodes will
now no longer be able to identify the 1588 packets that need to be timestamped/consumed. Ideally we would
like the nodes to recognize all such packets at the port level and therefore generate a time stamp that can
be later used after decrypting (or verifying Ipsec if its only being used for data integrity i.e.
ESP-NULL). The earlier we recognize the packets that need to be time stamped the better it is. 

There is also an issue at the intermediate nodes which need to know if there is a 1588 packet inside the Ipsec
tunnel so that it can be prioritized over the other packets.

I spoke to Rock and others in Beijing about this and I was told that having a separate Ipsec tunnel
exclusively for transporting 1588 packets is not scalable in the femto architecture and we need a
mechanism to unambiguously identify 1588 packets within an Ipsec tunnel that's also carrying other
service/data traffic. This, thus is the problem that
draft-xu-tictoc-ipsec-security-for-synchronization is attempting to solve.

Is this correct?

Cheers, Manav

--
Manav Bhatia,
IP Division, Alcatel-Lucent,
Bangalore - India
Permalink | Reply | 2 comments |
headers
Jack Kohn | 5 Dec 2010 02:58
Picon

Re: The draft for IPsec synchronization security

Your description appears to be correct.

Jack

On Sat, Dec 4, 2010 at 7:50 AM, Bhatia, Manav (Manav)
<manav.bhatia <at> alcatel-lucent.com> wrote:
> Hi,
>
> My understanding of the problem is as follows:
>
> Currently nodes recognize 1588 packets at the physical ports and generate a timestamp on RX or TX at a
reference point between the PHY and the MAC. This becomes complicated when we throw Ipsec as the nodes will
now no longer be able to identify the 1588 packets that need to be timestamped/consumed. Ideally we would
like the nodes to recognize all such packets at the port level and therefore generate a time stamp that can
be later used after decrypting (or verifying Ipsec if its only being used for data integrity i.e.
ESP-NULL). The earlier we recognize the packets that need to be time stamped the better it is.
>
> There is also an issue at the intermediate nodes which need to know if there is a 1588 packet inside the Ipsec
tunnel so that it can be prioritized over the other packets.
>
> I spoke to Rock and others in Beijing about this and I was told that having a separate Ipsec tunnel
exclusively for transporting 1588 packets is not scalable in the femto architecture and we need a
mechanism to unambiguously identify 1588 packets within an Ipsec tunnel that's also carrying other
service/data traffic. This, thus is the problem that
draft-xu-tictoc-ipsec-security-for-synchronization is attempting to solve.
>
> Is this correct?
>
> Cheers, Manav
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
bixiaoyu | 6 Dec 2010 10:08
Favicon

答复: The draft for IPsec synchronization security


Yes, you are right.

BR

-----邮件原件-----
发件人: Bhatia, Manav (Manav) [mailto:manav.bhatia <at> alcatel-lucent.com] 
发送时间: 2010年12月4日 10:20
收件人: tictoc <at> ietf.org
抄送: 'Xie Lei'; bixiaoyu
主题: The draft for IPsec synchronization security

Hi,

My understanding of the problem is as follows:

Currently nodes recognize 1588 packets at the physical ports and generate a
timestamp on RX or TX at a reference point between the PHY and the MAC. This
becomes complicated when we throw Ipsec as the nodes will now no longer be
able to identify the 1588 packets that need to be timestamped/consumed.
Ideally we would like the nodes to recognize all such packets at the port
level and therefore generate a time stamp that can be later used after
decrypting (or verifying Ipsec if its only being used for data integrity
i.e. ESP-NULL). The earlier we recognize the packets that need to be time
stamped the better it is. 

There is also an issue at the intermediate nodes which need to know if there
is a 1588 packet inside the Ipsec tunnel so that it can be prioritized over
the other packets.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane