Subject: Re: [TICTOC] Encrypting timing packets

From: "STUART VENTERS" <[email-masked]>
Date: Wed, 28 Jul 2010 09:13:06 -0500

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

---

From: "Greg Dowd" <[email-masked]>
Date: Wed, 28 Jul 2010 10:16:23 -0700

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

#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?)

Today's Topics:

Message: 1

Hi,

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

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

> 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

---

From: <[email-masked]>
Date: Thu, 29 Jul 2010 13:31:49 +0100

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 

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.

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

Today's Topics:

Message: 1

Hi,

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

SR: slide 7 in

Danny

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 29 Jul 2010 19:43:13 +0300

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.

Regards,

Mike

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

Today's Topics:

Message: 1

Hi,

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

SR: slide 7 in

Danny

---

From: <[email-masked]>
Date: Fri, 30 Jul 2010 09:54:28 +0100

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

We are talking about a scenario where everything is encrypted, including the 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.

Regards,

Mike

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

Today's Topics:

Message: 1

Hi,

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

SR: slide 7 in

Danny

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 30 Jul 2010 12:09:49 +0200 (CEST)

On Fri, 30 Jul 2010, [email-masked] wrote:

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

I believe time can be signed (and encrypted), the per-hop adjustment 
information probably cannot.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Stefano Ruffini" <[email-masked]>
Date: Fri, 30 Jul 2010 14:18:16 +0200

Hi,

This was one of the point that have been highlighted at last tictoc meeting (see http://www.ietf.org/proceedings/78/slides/tictoc-2.ppt). A possible approach could be to mark in some way the IPSEC tunnel to inform PTP packets are carried (e.g. RES bits), and rather than modify the correction field, implement some sort of control of the delays (this woudl also avoid layer vialoation issues). 
A related discussion was held at last Q13-Q4-Q2 joint meeting in Geneva.

Best Regards
Stefano 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: venerdì 30 luglio 2010 12.10
To: [email-masked]
Subject: Re: [TICTOC] Encrypting timing packets

On Fri, 30 Jul 2010, [email-masked] wrote:

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

I believe time can be signed (and encrypted), the per-hop adjustment information probably cannot.

---

From: Xie Lei <[email-masked]>
Date: Sat, 31 Jul 2010 11:30:20 +0800

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

  ----- Original Message ----- 
  From: Stefano Ruffini 
  To: Mikael Abrahamsson ; [email-masked] 
  Sent: Friday, July 30, 2010 8:18 PM
  Subject: Re: [TICTOC] Encrypting timing packets

  Hi,

  Best Regards
  Stefano