Subject: [TICTOC] Encrypting timing packets

From: Danny Mayer <[email-masked]>
Date: Tue, 27 Jul 2010 17:15:15 -0400

The subject of encrypting PTP (or NTP for that matter) packets came up
during the Working Group Meeting. However, noone has said why you would
bother to do so. The data is not private in any sense of
confidentiality; it's not useful if it's not consumed immediately on
arrival and there's lots of overhead in encrypting and decrypting
packets so why is even being considered. Is there a good use case for
this or are we just wasting cycles?

Danny

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 27 Jul 2010 23:25:24 +0200 (CEST)

> this or are we just wasting cycles?

Cryptographically signing something is often very similar to both signing 
and encrypting, so if the mechanism employed already supports both, why 
not support it so someone who want's to do encryption can do so?

I don't think we right now can foresee all use cases for the future so I 
see little harm in supporting both authentication and encryption.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Greg Dowd" <[email-masked]>
Date: Tue, 27 Jul 2010 14:48:36 -0700

Hi Danny,
	In particular, the issue has come up in the femtocell standards
where the device is installed in a customer premise and backhauled over
the customer broadband link.  In that scenario, there is definitely a
requirement to implement IPSec for the bearer traffic.  The devices
connect back to the operator network via a security gateway.  So, if the
PTP traffic is coming from inside the operator network, there "could" be
a requirement to run it through the IPSec tunnel already allocated by
the femtocell when it attached to the gateway.  There also appears to be
language that allows some "services" to run in clearchannel but then you
obviously need another address and traceability schema.  So there is not
a clear requirement for this functionality but it is something we are
anticipating could come up and we want to understand the ramifications
and alternatives.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Danny Mayer
Sent: Tuesday, July 27, 2010 2:15 PM
To: [email-masked]
Subject: [TICTOC] Encrypting timing packets

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

---

From: "Doug Arnold" <[email-masked]>
Date: Tue, 27 Jul 2010 16:01:25 -0700

Hi Greg,

I agree, and I suspect that femptocells is not the only application
where this will come up.  If a network operator is encrypting everything
else, they are not going to want to make an exception for ptp, just
because encryption isn't required.

Timing is often an afterthought on a network which was designed for
other things.  Timing has to work on a network that might be very
different from one which we would design to make timing work optimally.

//Doug Arnold

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Greg Dowd
Sent: Tuesday, July 27, 2010 2:49 PM
To: [email-masked]; [email-masked]
Subject: Re: [TICTOC] Encrypting timing packets

Hi Danny,

-----Original Message-----

Danny

---

From: Danny Mayer <[email-masked]>
Date: Tue, 27 Jul 2010 21:33:34 -0400

> because encryption isn't required.

I'm not suggesting you do something different for PTP packets than any
other packets, but if you start to use IPSec you must ask yourself the
followup question: IPSec is itself dependent on accurate time and
initially you don't know how accurate the clocks are. People forget that
there are builtin assumptions made about certificates and all of the
IPSec infrastructure that depends on the clock already being accurate.
Consider what happens when your system clock gets set back to 1969
because it doesn't have a TOY. Can you even create an IPSec connection?
This is the reason why NTP's Autokey (RFC 5906 - it's nice to finally
have an RFC to quote!) goes to such lengths in its authentication
mechanism to validate just the server. You cannot depend on the accuracy
of the clocks at either end while negotiating the autokey.

> different from one which we would design to make timing work optimally.

Agreed.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Tue, 27 Jul 2010 21:41:15 -0400

On 7/27/2010 5:25 PM, Mikael Abrahamsson wrote:
> Cryptographically signing something is often very similar to both
> signing and encrypting, so if the mechanism employed already supports
> both, why not support it so someone who want's to do encryption can do so?
> 

Because the overhead cost is huge compared to the benefit and you are
adding a major increase in latency and probably jitter as a result.
Small and nimble is much better.

> see little harm in supporting both authentication and encryption.

Leave out whatever you don't have use cases for. You are wasting a lot
of time and effort in defining, coming to a agreement on the
architecture of something you won't use and then people have to go off
and implement it but have no way of ensure that the non-existant use
cases can use it.

See above. Also no discussions have been held on how you authenticate a
server (or for that matter a client if that even has value) so that it
does not depend on the clocks of each node in the network.

Danny

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 28 Jul 2010 07:13:58 +0200 (CEST)

> Small and nimble is much better.

Is this a knee-jerk response or has this actually been investigated with a 
50+ year lifecycle of the protocol in mind? CPUs have gained 
AES-cryptography in hardware as of the past few years, the major reasons 
(that it's quite an addition to the workload) for not doing it is going 
away.

At least provide extensibility in the protocol so that this can be added 
later, especially with the challenges you mention in mind.

> does not depend on the clocks of each node in the network.

Then those discussions perhaps should be had.

If time and frequency is important then it's important enough for it to be 
properly authenticated, and if authentication/signing is implemented, then 
you've done most of the framework for encryption as well.

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 28 Jul 2010 08:42:47 +0300

> (that it's quite an addition to the workload) for not doing it is going away.

Yes, the symmetric key stuff is now done in hardware
but the public key part for authentication is still done in software.
And due to interactions between the software and hardware, 
requesting authentications can slow down other existing timing flows.

An interesting thing about public key algorithms is that their run time
is highly dependent on the data.
So in principle I can mount an attack by requesting authentications 
using successively "harder" keys followed by successively "easier" ones, 
thus adding hard-to-remove wander to the other timing flows.

Y(J)S

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 28 Jul 2010 07:50:08 +0200 (CEST)

> requesting authentications can slow down other existing timing flows.

What about just signing it the way it's done in DNSSEC, ie you have a 
certificate/key and each packet is signed before being sent out?

> thus adding hard-to-remove wander to the other timing flows.

In an multicore multithreaded environment, is this really that huge of a 
problem? Also if we count in that people who are really interested in this 
might have a device with a separated control plane and "data plane" just 
like high capacity routers are done as of 10 years approximately?

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 28 Jul 2010 11:40:27 +0300

Mikael, 

> certificate/key and each packet is signed before being sent out?

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.

> like high capacity routers are done as of 10 years approximately?

I think that this should be thoroughly tested. 
In systems that I have seen in the lab, 
the degradation rules out sub-microsecond accuracy.

Y(J)S

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 28 Jul 2010 10:45:37 +0200 (CEST)

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

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

---

From: Danny Mayer <[email-masked]>
Date: Wed, 28 Jul 2010 07:51:40 -0400

On 7/28/2010 1:13 AM, Mikael Abrahamsson wrote:
> Is this a knee-jerk response or has this actually been investigated with
> a 50+ year lifecycle of the protocol in mind? CPUs have gained

No, I've been there before. It's not a problem of adding a provision for
such things, provided you make the provisioning flexible enough and make
sure that the client can safely ignore whatever it doesn't understand.
That won't work for encypted packets since it cannot get to the
timestamp. That in turns requires that in order to accept encrypted
packets you have to require all nodes using them understand the same
encryption algorithm AND you need to provide them with keys to decrypt
them which is also a provisioning problem. What happens if you want to
change keys? Change algorithms?

>> See above. Also no discussions have been held on how you authenticate
>> a server (or for that matter a client if that even has value) so that
>> it does not depend on the clocks of each node in the network.
> 
> If time and frequency is important then it's important enough for it to
> be properly authenticated, and if authentication/signing is implemented,
> then you've done most of the framework for encryption as well.

The framework is one thing but decryption is something else again.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Wed, 28 Jul 2010 07:57:02 -0400

> certificate/key and each packet is signed before being sent out?

Yes, we do that in NTP autokey. It's much simpler to do. The main issue
there is that you need to provision the clients with keys in order to
validate the signature.

>> using successively "harder" keys followed by successively "easier"
>> ones, thus adding hard-to-remove wander to the other timing flows.
> 
> problem? Also if we count in that people who are really interested in
> this might have a device with a separated control plane and "data plane"
> just like high capacity routers are done as of 10 years approximately?

The perhaps surprising answer to this is yes, it is a problem in
multicore environments because each core has its own clocking and which
core's clock you use to timestamp makes a difference. We get lots of
jitter this way with NTP. We've had lots of discussions about this in NTP.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Wed, 28 Jul 2010 08:06:48 -0400

On 7/28/2010 4:45 AM, Mikael Abrahamsson wrote:
> 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) ?
> 
> 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.

> sub-microsecond isn't needed but one still wants to know the time is not

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.

Danny

---

From: "Stefano Ruffini" <[email-masked]>
Date: Wed, 28 Jul 2010 14:39:54 +0200

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:
>> 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.
> 
> (1588), then perhaps the same methodology could be used here, in that 
> a device might add a compensation factor that includes how long the 
> time, the signed stated time wouldn't be too much off (an attacker 
> could only tamper with the adjustment value) ?
> 

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.

> 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

---

From: Lindqvist Kurt Erik <[email-masked]>
Date: Fri, 30 Jul 2010 15:02:07 +0200

On 28 jul 2010, at 07.50, Mikael Abrahamsson wrote:

> What about just signing it the way it's done in DNSSEC, ie you have a certificate/key and each packet is signed before being sent out?

Many (all) DNSSEC responses are TCP or hand-shake. You really don't want to authenticate clients at the server as that is an easy way to construct a DDoS attack, just as you can with NSEC3 for DNSSEC. The otherway (which I think we in Paris also agreed was the most common use case), having a client authenticate a server is different though and can be made to scale (I think that is what you are suggesting above). 

Best regards,

- kurtis -

---

From: Danny Mayer <[email-masked]>
Date: Fri, 30 Jul 2010 12:49:18 -0400

> 
> Many (all) DNSSEC responses are TCP or hand-shake.

<DNS Hat>
That is absolutely untrue. DNSSEC uses UDP and EDNS0 and only falls back
to TCP if it cannot fit the responses in the packet size. EDNS0 signals
what packet size to use. See the RFC403x RFC's.

> You really don't want to authenticate clients at the server as that is an easy way to
construct a DDoS attack,

Agreed.

> just as you can with NSEC3 for DNSSEC.

No, that is not possible. NSEC3 is about (non)existence proofs of a RR
in a zone, and is just used in a response to a request.

</DNS hat>

 The otherway (which I think we in Paris also agreed was the most common use
case), having a client authenticate a server is different though and can
be made to scale (I think that is what you are suggesting above).

Yes.

Danny