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

[[e-mail]]

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" <[e-mail]>
An:     "NTP WG" <[e-mail]>
Kopie:  [e-mail], "Daniel Franke" <[e-mail]>
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: <[e-mail]> 
To: Daniel Franke <[e-mail]> 
Cc: NTP WG <[e-mail]> 
Sent: 7/24/2019 9:00 AM 
Subject: Re: [Ntp] Follow-up to yesterday's mic comment about PTP security 


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" <[e-mail]> schrieb am 23.07.2019 18:19:33:

> Von: "Daniel Franke" <[e-mail]> 
> An: "NTP WG" <[e-mail]> 
> Datum: 23.07.2019 18:20 
> Betreff: [Ntp] Follow-up to yesterday's mic comment about PTP security 
> Gesendet von: "ntp" <[e-mail]> 
> 
> 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.
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp


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