Subject: [Ntp] Follow-up to yesterday's mic comment about PTP security

From: Daniel Franke <[email-masked]>
Date: Tue, 23 Jul 2019 12:19:33 -0400

My comments yesterday about PTP security shifted context a few times
so it may have been hard to follow what I was claiming. My assertions
were:

1. If you need 50ms precision, pick some good public NTP servers and use NTS.

2. If you need 100µs precision, colocate a time source in the same
datacenter as the client systems. Use NTP and NTS; you don't need PTP
for this.

3. If you need 1µs precision, use PTP and physically secure the link
between the time source and the clients so that cryptographic
authentication is unnecessary.

4. If you need 1µs precision over an adversarial network, good luck!
This is simply not achievable and no amount of cryptographic pixie
dust is ever going to save you.

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 24 Jul 2019 08:04:44 +0200

>>> Daniel Franke <[email-masked]> schrieb am 23.07.2019 um 18:19 in
Nachricht
> 1. If you need 50ms precision, pick some good public NTP servers and use 

Interestingly I think most data centers would like to have 1a: 100µs to 5ms.
Are you saying NTS can't do better than a few ms?

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

---

From: Hal Murray <[email-masked]>
Date: Tue, 23 Jul 2019 23:30:59 -0700

> Are you saying NTS can't do better than a few ms? 

It depends on your network connection and the availability of nearby good 
servers.  It's easy to do worse than 5ms.  It's hard to do 100 us over the big 
bad internet.

-- 
These are my opinions.  I hate spam.

---

From: [email-masked]
Date: Wed, 24 Jul 2019 09:00:54 +0200

Hey all,

first of all, I'm really glad if this whole thing (security of one-way 
mechanisms and mechanism selection) is a discussion that we're going to 
have in the WG.

To comment on your assertions, Daniel:

1. 
It is established in general (and I have a proof lying around for a model 
of NTS in particular) that a client performing a request-response exchange 
with NTS and using all relevant checks gets a strong guarantee that the 
error in its measured offset is no larger than half the added flight times 
of the packets (plus some negligibly small delta accounting for frequency 
instability of the clocks used on client and server side). 
For anyone wondering why we bothered to prove this again: this guarantee 
is 100%, and the new part is "no matter what a Man-in-the-Middle attacker 
did in the process".
So I would be careful about naming a specific amount, because flight times 
do depend on the specific client's connection - but 50ms seems like a good 
rule of thumb, and I overall agree with your assertion.

2.-3. 
If we're operating und the assumptions that 
a) you can only use one time sync mechanism at a time and keep track of 
one clock disciplined via data from that mechansim, and
b) end users always have exactly one requirement level for each of 
security and precision/accuracy and need to use the least-effort path to 
achieve them
... then I agree with your assertions whole-heartedly.

But I really think both assumptions deserve their own hard looks and 
considerations.
For example, it might be reasonable for someone, specifically a financial 
institute, to run NTP with NTS in their local network to obtain a 100% 
security guarantee for a 100us level (demanded by MiFID II for example) 
and also still use PTP / White Rabbit (unsecured for the time being) to 
have the precision/accuracy levels they actually want - with no strong 
guarantee, but still valid in the (most likely) case that their 
infrastructures are not currently under attack.

4.
Again, I agree with the assertion for the most part and in the given 
status quo.
But the underlying assumption that every relevant adversarial 2-way 
network also suffers from long, unpredictable and asymmetric travel times 
is mostly valid because the only candidate for such a network is the 
internet.
If someone built, say, a GNSS network where two-way communication (with 
satellites or between two ground stations) was readily available to 
everyone, the whole situation would be different:
That would still potentially qualify as an adversarial network, but with 
the proper crypto, your 100% security guarantees could be extended to much 
better precision/accuracy levels.
The same thing could be true for long-distance tree-topology fibre-based 
networks exclusively for time synchronization - which are kind of in the 
process of being built all over Europe.

Lengthy comments and caveats notwithstanding, I agree with and would 
endorse your 1.-4. decision making sheet as an excellent starting point.

Best regards,
Kristof

"ntp" <[email-masked]> schrieb am 23.07.2019 18:19:33:

> Von: "Daniel Franke" <[email-masked]>
> An: "NTP WG" <[email-masked]>
> Datum: 23.07.2019 18:20
> Betreff: [Ntp] Follow-up to yesterday's mic comment about PTP security
> Gesendet von: "ntp" <[email-masked]>
>

---

From: [email-masked]
Date: Wed, 24 Jul 2019 09:04:59 +0200

"ntp" <[email-masked]> schrieb am 24.07.2019 08:04:44:

> Von: "Ulrich Windl" <[email-masked]>
> An: "Daniel Franke" <[email-masked]>, "[email-masked]" 
<[email-masked]>
> Datum: 24.07.2019 08:05
> Betreff: [Ntp] Antw: Follow-up to yesterday's mic comment about PTP 
security
> > 1. If you need 50ms precision, pick some good public NTP servers and 
use 
> > NTS.

Depends on what you need: with NTS, you get a 100% security and 
correctness guarantee for the error in your measured offset being at most 
half of the flight time (plus a negligible delta).
Now, it is very likely that your measured offset is much better than that 
- but the more you're relying on the assumption of symmetric packet travel 
times, the less certainty you get - and the more susceptible you become 
towards delay attacks.

---

From: Daniel Franke <[email-masked]>
Date: Wed, 24 Jul 2019 10:09:19 -0400

On Wed, Jul 24, 2019 at 3:00 AM <[email-masked]> wrote:
> 1.
> It is established in general (and I have a proof lying around for a model of NTS in particular) that a client performing a request-response exchange with NTS and using all relevant checks gets a strong guarantee that the error in its measured offset is no larger than half the added flight times of the packets (plus some negligibly small delta accounting for frequency instability of the clocks used on client and server side).
> For anyone wondering why we bothered to prove this again: this guarantee is 100%, and the new part is "no matter what a Man-in-the-Middle attacker did in the process".

The "half the RTT" error bound can be improved somewhat if you know
the physical distance between yourself and the server. In which case
the error bound is ±(RTT/2 - distance / speed_of_light), because it is
safe to assume that the network adversary does not have a wormhole
through which to route your packets. (If you do have one, Akamai wants
your resume).

---

From: Watson Ladd <[email-masked]>
Date: Wed, 24 Jul 2019 09:10:55 -0700

> dust is ever going to save you.

Even if I use the wireless cards PLL, and align times with symbol
boundaries? That's probably beyond scope but NASA does it.

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 25 Jul 2019 07:44:58 +0200

>>> Daniel Franke <[email-masked]> schrieb am 24.07.2019 um 16:09 in
Nachricht
>> It is established in general (and I have a proof lying around for a model
of 
> NTS in particular) that a client performing a request-response exchange with

> NTS and using all relevant checks gets a strong guarantee that the error in

> its measured offset is no larger than half the added flight times of the 
> packets (plus some negligibly small delta accounting for frequency 
>> For anyone wondering why we bothered to prove this again: this guarantee is

> 100%, and the new part is "no matter what a Man-in-the-Middle attacker did
in 
> the process".

The probem is the "distance" here, as it definitely refers to "cable length",
or more specifically "route length". Back in the time when the WWW started,
connections inside Germany were routed via USA sometimes (that was the time
whan a "good" transferrate was near 5kB/s). To make matters worse, you cannot
safely assume that the route (length) from A to B will be the same as from B to
A.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 24 Jul 2019 23:24:52 -0700

> safely assume that the route (length) from A to B will be the same as from B to

A MITM can still do at least a delay attack.

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: [email-masked]
Date: Thu, 25 Jul 2019 09:06:30 +0200

> > whan a "good" transferrate was near 5kB/s). To make matters worse,you 
cannot
> A MITM can still do at least a delay attack.

None of that matters for what Daniel is saying.
A packet can still not have arrived *faster* than with lightspeed via the 
shortest line between the two devices.
And that's all you need to derive that the situation is in fact marginally 
better than "half of RTT (plus oscillator-related delta)".

---

From: [email-masked]
Date: Thu, 25 Jul 2019 09:14:19 +0200

Good morning all,

what you will really need from these folks, Doug, is a clear statement of 
whether they need their level of synchronicity (50ms, 100us, whatever) 
only locally between all their machines or also in reference to a global 
time scale such as UTC.
And maybe if they need different precision/accuracy levels for both, such 
as needing/wanting sub-ns level locally and a 100% guaranteed 100us within 
UTC or something like that (I suspect something like this will turn out to 
be true for most of them).

Using PTP to make sure that all of their devices agree on the time to a 
better-than-100us level is fine, but if they need actual guarantees with 
regard to UTC, it might be short-sighted to just go "well, our server is 
GPS-disciplined, so basically as good as UTC".

Best regards,
Kristof

Von:    "Doug Arnold" <[email-masked]>
An:     "NTP WG" <[email-masked]>
Kopie:  [email-masked], "Daniel Franke" <[email-masked]>
Datum:  24.07.2019 21:17
Betreff:        Re: [Ntp] Follow-up to yesterday's mic comment about PTP 
security

Hello Everyone,

Some financial companies only need 50 ms, and for them I recommend NTP. It 
is cheaper and easier to install than PTP, and the protocol is more mature 
and implementations are usually robust.  In general they prefer to have 
their own NTP servers, inside their network, and behind the fire wall.  I 
will be recommending NTS when available from their vendor.  That will be 
an easy sell, since they generally want to turn on security options for 
the protocols they use.

Some network operators tell me that achieving 100 us time synchronization 
in their network is near the edge of what they currently get using NTP, so 
they want to switch to PTP for this spec and the coming tighter specs. 
Most of them have switches and routers which have PTP on path support or 
the operators expect them to in the near future.  This will be an issue 
which needs discussion since that represents a security challenge.  If 
every switch is shaping the information, then there is either a "secret" 
every node knows, or many secrets, each of which must be kept.

Doug

From: <[email-masked]> 
To: Daniel Franke <[email-masked]> 
Cc: NTP WG <[email-masked]> 
Sent: 7/24/2019 9:00 AM 
Subject: Re: [Ntp] Follow-up to yesterday's mic comment about PTP security 

Hey all, 

1. 

2.-3. 

4. 

Best regards, 
Kristof

---

From: Heiko Gerstung <[email-masked]>
Date: Thu, 25 Jul 2019 09:38:19 +0200

I agree with Kristof that using GPS (or any other GNSS for that matter) does not automagically turns your PTP GM into a UTC traceable time source. The folks of NPL have shown that you can use PTP (without GNSS) to transfer UTC traceable time with a high level of accuracy (<1us) over long distances. So "PTP != UTC" is obviously as generalizing as "NTP/NTS = UTC". It doesn't depend on the network protocol. 

I get the point of Kristof that using GPS in the setup Doug described will not guarantee UTC, but funny as it is, the European MiFID II regulation specifically accepts using GNSS to obtain time and be compliant with the UTC requirements of ESMA. 

My goal is to work on using NTS-KE for PTP as well, if anyone is interested in joining us to work out something please let me know. 

Regards,

   Heiko

-- 

Heiko Gerstung 
Managing Director

MEINBERG® Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone:    +49 (0)5281 9309-404
Fax:        +49 (0)5281 9309-9404

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung

Email:
 [email-masked] 
Web:
 Deutsch   https://www.meinberg.de
 English    https://www.meinbergglobal.com

Do not miss our Time Synchronization Blog:
 https://blog.meinbergglobal.com 

Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung

Von: ntp <[email-masked]> im Auftrag von <[email-masked]>
Datum: Donnerstag, 25. Juli 2019 um 09:14
An: Doug Arnold <[email-masked]>
Cc: NTP WG <[email-masked]>, Daniel Franke <[email-masked]>
Betreff: Re: [Ntp] Follow-up to yesterday's mic comment about PTP security

Good morning all, 

what you will really need from these folks, Doug, is a clear statement of whether they need their level of synchronicity (50ms, 100us, whatever) only locally between all their machines or also in reference to a global time scale such as UTC. 
And maybe if they need different precision/accuracy levels for both, such as needing/wanting sub-ns level locally and a 100% guaranteed 100us within UTC or something like that (I suspect something like this will turn out to be true for most of them). 

Using PTP to make sure that all of their devices agree on the time to a better-than-100us level is fine, but if they need actual guarantees with regard to UTC, it might be short-sighted to just go "well, our server is GPS-disciplined, so basically as good as UTC". 

Best regards, 
Kristof 

Von:        "Doug Arnold" <[email-masked]> 
An:        "NTP WG" <[email-masked]> 
Kopie:        [email-masked], "Daniel Franke" <[email-masked]> 
Datum:        24.07.2019 21:17 
Betreff:        Re: [Ntp] Follow-up to yesterday's mic comment about PTP security 

Hello Everyone, 

Some financial companies only need 50 ms, and for them I recommend NTP.  It is cheaper and easier to install than PTP, and the protocol is more mature and implementations are usually robust.  In general they prefer to have their own NTP servers, inside their network, and behind the fire wall.  I will be recommending NTS when available from their vendor.  That will be an easy sell, since they generally want to turn on security options for the protocols they use. 

Some network operators tell me that achieving 100 us time synchronization in their network is near the edge of what they currently get using NTP, so they want to switch to PTP for this spec and the coming tighter specs.  Most of them have switches and routers which have PTP on path support or the operators expect them to in the near future.  This will be an issue which needs discussion since that represents a security challenge.  If every switch is shaping the information, then there is either a "secret" every node knows, or many secrets, each of which must be kept. 

Doug

Hey all, 

first of all, I'm really glad if this whole thing (security of one-way mechanisms and mechanism selection) is a discussion that we're going to have in the WG. 

1. 
It is established in general (and I have a proof lying around for a model of NTS in particular) that a client performing a request-response exchange with NTS and using all relevant checks gets a strong guarantee that the error in its measured offset is no larger than half the added flight times of the packets (plus some negligibly small delta accounting for frequency instability of the clocks used on client and server side). 
For anyone wondering why we bothered to prove this again: this guarantee is 100%, and the new part is "no matter what a Man-in-the-Middle attacker did in the process". 
So I would be careful about naming a specific amount, because flight times do depend on the specific client's connection - but 50ms seems like a good rule of thumb, and I overall agree with your assertion. 

2.-3. 
If we're operating und the assumptions that 
a) you can only use one time sync mechanism at a time and keep track of one clock disciplined via data from that mechansim, and 
b) end users always have exactly one requirement level for each of security and precision/accuracy and need to use the least-effort path to achieve them 
.... then I agree with your assertions whole-heartedly. 

But I really think both assumptions deserve their own hard looks and considerations. 
For example, it might be reasonable for someone, specifically a financial institute, to run NTP with NTS in their local network to obtain a 100% security guarantee for a 100us level (demanded by MiFID II for example) and also still use PTP / White Rabbit (unsecured for the time being) to have the precision/accuracy levels they actually want - with no strong guarantee, but still valid in the (most likely) case that their infrastructures are not currently under attack. 

4. 
Again, I agree with the assertion for the most part and in the given status quo. 
But the underlying assumption that every relevant adversarial 2-way network also suffers from long, unpredictable and asymmetric travel times is mostly valid because the only candidate for such a network is the internet. 
If someone built, say, a GNSS network where two-way communication (with satellites or between two ground stations) was readily available to everyone, the whole situation would be different: 
That would still potentially qualify as an adversarial network, but with the proper crypto, your 100% security guarantees could be extended to much better precision/accuracy levels. 
The same thing could be true for long-distance tree-topology fibre-based networks exclusively for time synchronization - which are kind of in the process of being built all over Europe. 

Lengthy comments and caveats notwithstanding, I agree with and would endorse your 1.-4. decision making sheet as an excellent starting point. 

Best regards, 
Kristof 

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

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 25 Jul 2019 09:46:34 +0200

> better than "half of RTT (plus oscillator-related delta)".

There is a variant that can be used in local networks with known
HW/topology. Instead of physical distance, which is negligible in
local networks, the metric is the number of network devices between
the stratum 1 server and client. If the minimum forwarding delay of
all devices is x (under all conditions) and packets between the server
and client always have to go over at least n devices, the root
delay reported by the client can be reduced by 2*n*x. The maximum
error of the client's clock (root distance) then may be shown to be
smaller than the required accuracy (e.g. 100 microseconds in the case
of MiFID).

With PTP (which assumes a constant network delay and doesn't have a
concept of root delay/dispersion) it's more difficult to determine the
maximum error.

-- 
Miroslav Lichvar

---

From: [email-masked]
Date: Thu, 25 Jul 2019 10:22:05 +0200

To be clear: I'm not trying to say that using NTP/NTS rather than PTP on 
campus (locally) helps you out in any significant way.
But using NTP/NTS rather than GNSS to *get UTC to your campus* (globally) 
helps you out on one critical aspect: guaranteed traceability - the other 
being precision/accuracy levels, (where NTP/NTS performs much worse than 
GNSS).
If you're able to use PTP (hopefully secured PTP soon) over a 
long-distance landline to synchronize to a master that is NMI-levels close 
to UTC, then that seems pretty close to ideal - but it does require the 
appropriate landline, which is not trivial and rules this option out for 
many users.

Regarding generalizations of protocol properties: some things do depend on 
the transmission protocol, specifically on whether it allows messages in 
both directions or just one.
We have proof that "NTP/NTS = (Time of NTP/NTS Server) +- (roughly half of 
RTT)" is actually valid. This holds because you get a crypto-secured 2-way 
exchange.
And it works if your NTP server in this case is the NTP server of your 
appropriate NMI, and they might be able to give you the additional 
uncertainty for how close to their utc(NMI) the NTP server is - and that 
gets you very close to actual, full on 100%-guaranteed (if you assume the 
worst-cases conservatively enough) traceability, proven by the properties 
of the transmission protocol.
That is something that you *cannot* get with any purely 1-way based 
transmission method, specifically with a GNSS receiver - no matter what 
crypto people throw onto the GNSS signal, because delay attacks exist and 
are not just unpreventable but unbounded in pure 1-way connections.

I know that MiFID II in particular does not acknowledge this and 
specifically accepts GNSS (I think even explicitly GPS) as satisfactory - 
but I think that this should be changed in the next guideline, and also 
carefully suspect that it actually might be.

Best regards,
Kristof

Von:    "Heiko Gerstung" <[email-masked]>
An:     "[email-masked]" <[email-masked]>, "Doug Arnold" 
<[email-masked]>
Kopie:  "NTP WG" <[email-masked]>, "Daniel Franke" <[email-masked]>
Datum:  25.07.2019 09:39
Betreff:        Re: [Ntp] Follow-up to yesterday's mic comment about PTP 
security
Gesendet von:   "ntp" <[email-masked]>

I agree with Kristof that using GPS (or any other GNSS for that matter) 
does not automagically turns your PTP GM into a UTC traceable time source. 
The folks of NPL have shown that you can use PTP (without GNSS) to 
transfer UTC traceable time with a high level of accuracy (<1us) over long 
distances. So "PTP != UTC" is obviously as generalizing as "NTP/NTS = 
UTC". It doesn't depend on the network protocol. 
 
I get the point of Kristof that using GPS in the setup Doug described will 
not guarantee UTC, but funny as it is, the European MiFID II regulation 
specifically accepts using GNSS to obtain time and be compliant with the 
UTC requirements of ESMA. 
 
My goal is to work on using NTS-KE for PTP as well, if anyone is 
interested in joining us to work out something please let me know. 
 
Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre 
Hartmann, Heiko Gerstung

Email:

Connect via LinkedIn: 

 
Good morning all, 

Best regards, 
Kristof 

Von:        "Doug Arnold" <[email-masked]> 
An:        "NTP WG" <[email-masked]> 
Kopie:        [email-masked], "Daniel Franke" 
<[email-masked]> 
Datum:        24.07..2019 21:17 
Betreff:        Re: [Ntp] Follow-up to yesterday's mic comment about PTP 
security 

Hello Everyone, 

Doug

Hey all, 

1. 

2.-3. 

4. 

Best regards, 
Kristof 

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

---

From: Daniel Franke <[email-masked]>
Date: Thu, 25 Jul 2019 07:48:23 -0400

> safely assume that the route (length) from A to B will be the same as from B to

For the purposes of determining an error bound using the formula I
gave, assuming a distance that is too short will give you a more
conservative bound. So the safest assumption is that you are
communicating in a straight line in both directions, through a vacuum
medium. Making more "realistic" assumptions will give you a tighter
bound, but then an adversary who can violate those assumptions can
violate your error bound.