Subject: Re: [TICTOC] Encrypting timing packets

From: Danny Mayer <[email-masked]>
Date: Sun, 01 Aug 2010 23:40:39 -0400

On 7/30/2010 11:30 PM, Xie Lei wrote:
> Hi
> Currently, i only see the IPSec requirements for end to end frenquency
> synchronization for femtocell, femtocell needs to identify the PTP
> messages from all the encryped IPSec messages. As mentioned in last
> tictoc meeting, to mark the ptp message over IPSec could be the solution
> on this issue, i hope group could give more discussion on how to
> mark PTP messages in IPSec tunnel messages.
>  
> Best Regards
> Rock

Two questions here:
1) does femtocell only need frequency synchronization and not time
synchronization and if so how closely and what are the consequences of
frequency drift or error?
2) When you say identifying PTP messages in the IPSec tunnel are you
trying to identify the packets from outside the tunnel or are you inside
trying to identify them?

Danny

---

From: <[email-masked]>
Date: Thu, 5 Aug 2010 14:24:51 +0200

Hi,

Reading this thread, I think it might be useful to clarify the context (again...).
E.g. frequency or phase/time, and mono or multi-operator context.

The main use case which has been highlighted for transporting PTP into an IPSec tunnel is the femto cell application.

This application requires generally today only frequency, but might require in the future phase/time in some cases.
This application may be used in a mono-operator context (e.g. the entire network is owned by a single operator) or in a multi-operator context (the operator providing the femto cell service is using another operator's network).

If only frequency is needed (250ppb, which is a quite relaxed requirement), an end-to-end scenario where none of the boxes in the network have to recognise and process the PTP packets might be suitable, provided that the network is not generating too much PDV. In this case, the PTP packets might be encrypted (e.g. transported in the IPSec tunnel, as the rest of the traffic), again, provided that the encryption itself does not generate too much PDV. These points are applicable both to the mono and multi-operator cases.

If very accurate phase/time is needed (e.g. sub-µs accuracy), the situation is much more challenging, and an end-to-end scenario with a network not supporting specific hardware for PTP will likely not be suitable. As mentioned several times, an hop-by-hop scenario will very likely be required to meet this stringent requirement.

In this very accurate phase/time case, in the mono-operator case, it is likely that the phase/time reference will be delivered by the network infrastructure directly to the femto cell, via an hop-by-hop scheme, and therefore, that the PTP packets will not be included inside the IPSec tunnel. It is similar to the discussion regarding PTP over MPLS : if one want to use an hop-by-hop scheme, why to put the PTP packets into a tunnel, whereas at the end, the destination of the PTP packets is the next equipment? Note that in this case, the support for a single clock domain is enough.

For this very accurate phase/time case, in the multi-operator case now, it might be questioned if the PTP packets could be transported end-to-end into an IPSec tunnel over another operator's network. I personally believe that if this situation happens, then the µs accuracy requirement will not be met at the output of the carrier operator network. Except if the entire carrier operator network supports dedicated hardware for PTP to enable transporting transparently a "service phase/time clock", but I have real doubts that operators will invest money for such feature. Instead, they will very likely propose to deliver their own "network phase/time clock" as part of the service, and we are back to the previous mono-operator case, with single clock domain hop-by-hop scenario where PTP is outside the IPSec tunnel, since there is now only a single clock to be carried.

In conclusion: as far as I can anticipate the different scenarios today, the PTP packets would be carried in an IPSec tunnel only in the end-to-end scenario for frequency-only, where none of the boxes in the network have to recognise and process the PTP packets. I am therefore not convinced (once again, sorry) that there is really a problem to solve here...

Thanks.

BR,

Sébastien

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : vendredi 30 juillet 2010 10:54
À : [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [TICTOC] Encrypting timing packets

Yaakov, Valid point.

I was also thinking about the complexity if timing is part of a traffic flow that needs to be encrypted although hadn't really given it too much thought. Now think this through I really don't see how some form of hop by hop PTP will work in this case without issues.  

How do you recognise the packets as you point out? Do you have to decrypt the entire flow, process timing then inject it back in and encrypt.

If you don't surely you will break the encryption? If you do this process surely you will add significant delay and variability.

Would welcome some comment from those who have a better understanding on this.

Regards,

Mike

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: 29 July 2010 17:43
To: Gilson,MJ,Mike,DMQ7 R; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [TICTOC] Encrypting timing packets

Mike

I think that you are missing the point.

No-one is proposing purposely encrypting timing packets.

We are talking about a scenario where everything is encrypted, including the timing packets.

This makes it hard for a box in the middle to recognize timing packets.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, July 29, 2010 15:32
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [TICTOC] Encrypting timing packets

Several points.

Requirement for encryption is unclear, I can see a reason to authenticate and know where the timing packets have come from.

If encryption is required I think there are issues. Just reusing something designed for another application may just create more problems.

Regards,

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Dowd
Sent: 28 July 2010 18:16
To: STUART VENTERS; [email-masked]
Subject: Re: [TICTOC] Encrypting timing packets

Keep in mind that this requirement wasn't designed with timing or synchronization in mind.  This protocol is designed to backhaul phone calls across public IP domains.  As such, a strong security environment is an absolute requirement.  The fact that we MIGHT need to get sync through the same pipe is a footnote.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of STUART VENTERS
Sent: Wednesday, July 28, 2010 7:13 AM
To: [email-masked]
Subject: Re: [TICTOC] Encrypting timing packets

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Wednesday, July 28, 2010 7:40 AM
To: [email-masked]
Subject: TICTOC Digest, Vol 44, Issue 91

If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/tictoc

Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME.  You can set this option globally for all the list digests you receive at this point.

Send TICTOC mailing list submissions to
	[email-masked]

What threat model is this new feature attempting to protect from?
   1) Somebody observing the time.
   2) Somebody changing the time.

#1 seems feasible given enough resources, but I'm not sure what application cares.

#2 is interesting because time transfer is a strange application in that a man in the middle only needs to delay packets, modification and inspection are not required.  It's not clear to me how encryption helps this?

Unless it's used to put a defined bounds on the size of the time offset the attacker can cause?
   (Maybe Offset change < RTT change?)

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/tictoc
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of TICTOC digest..."

Today's Topics:

   1. Re:  Encrypting timing packets (Stefano Ruffini)

----------------------------------------------------------------------

Message: 1
Date: Wed, 28 Jul 2010 14:39:54 +0200
From: "Stefano Ruffini" <[email-masked]>
Subject: Re: [TICTOC] Encrypting timing packets
To: <[email-masked]>,	"Mikael Abrahamsson" <[email-masked]>
Cc: [email-masked]
Message-ID:
	
<[email-masked]>
	
Content-Type: text/plain;	charset="iso-8859-1"

Hi,

See answer to one question below

Best Regards
Stefano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Danny Mayer
Sent: mercoled? 28 luglio 2010 14.07
To: Mikael Abrahamsson
Cc: [email-masked]
Subject: Re: [TICTOC] Encrypting timing packets

On 7/28/2010 4:45 AM, Mikael Abrahamsson wrote:
> On Wed, 28 Jul 2010, Yaakov Stein wrote:
> 
>> The problem is that you have to put in a timestamp that reflects the 
>> time the packet is placed on the wire.
>> So you have to sign after timestamping, and unless this signature can

>> be computed in zero time (or with completely deterministic latency 
>> that can be pre-added) the signing degrades the timing accuracy.
> 
> Since things are timestamped on the ingress in the PHY in some cases 
> (1588), then perhaps the same methodology could be used here, in that 
> a device might add a compensation factor that includes how long the 
> signing took. This adjustment value would of course not be signed in 
> itself, but it could have a maximum value that would mean at least for

> time, the signed stated time wouldn't be too much off (an attacker 
> could only tamper with the adjustment value) ?
> 
> Or perhaps this doesn't really help, it's still a too big attack
vector?
> For server time setting it might be enough... Or is the recommendation

> to just run NTP over IPSEC so NTP itself doesn't have to care?
> 

Having NTP not care is much better except that the protocol used to transport the packets affect the latency and jitter of the timing offset. I'm not sure how you would even be able to measure that. It's one of the reasons that NTP will never use TCP for a transport.

>> I think that this should be thoroughly tested. In systems that I have

>> seen in the lab, the degradation rules out sub-microsecond accuracy.
> 
> I have little doubt of that, but I can imagine applications where 
> sub-microsecond isn't needed but one still wants to know the time is 
> not off by more than that?

Applications that don't need sub-microsecond accuracy can probably just stick with NTP. What I'm hearing in this WG is that the big potential consumers are areas like backhaul networks and femtocells. I haven't seen anyone spell out why they need sub-microsecond accuracy but I'm sure they have good reasons.

SR: slide 7 in
http://www.ietf.org/proceedings/78/slides/tictoc-4.ppt
provides a few examples (and related specifcation), for applications requiring accuracy in the microsecond level .

Danny
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

------------------------------

_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

End of TICTOC Digest, Vol 44, Issue 91
**************************************
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc