Subject: [Ntp] A simpler way to secure PTP

From: Daniel Franke <[email-masked]>
Date: Sat, 8 May 2021 16:53:06 -0400

As an alternative to Martin's and Heiko's drafts, I'd like to propose a
simpler approach to securing PTP. It is compatible with all PTP features,
supports the same threat model as NTS-secured NTP, introduces zero jitter,
and can be implemented entirely on the client side without the knowledge or
cooperation of the rest of the PTP infrastructure.

The trick is: run NTS-secured NTP and regular, unauthenticated PTP
side-by-side. Do not use the NTP responses to set the clock; instead, use
them only to establish maximum error bounds on the current time, and then
clamp all PTP messages to within those bounds.

The client's on-wire interaction with the NTP server is the same as it is
in normal NTS-secured NTP, but the way it processes the server's responses
is different. The client maintains an estimate `theta` of the offset
between a local, unadjusted monotonic clock `t_raw` (implemented e.g. by
CLOCK_MONOTONIC_RAW on linux) and the server's realtime clock, along with a
continuously-changing error term `lamdba`.

Upon receiving an authentic response from an NTP server, let:

  t_1 = origin timestamp captured from t_raw.
  t_2 = packet receive timestamp
  t_3 = packet transmit timestamp
  t_4 = destination timestamp captured from t_raw.
  theta = ((t_2 - t_1) + (t_3 - t_4))/2
  DTAI = TAI - UTC offset

giving a current estimated TAI time of

  t_raw + theta + DTAI

For computing error bounds, let

  hrtt = (t_4 - t_1)/2
  rdel = packet root delay
  r_1 = local clock precision
  r_2 = packet clock precision
  PHI = some appropriate upper bound on our local clock's drift rate

and then our error term is plus-or-minus

  hrtt + rdel/2 + r_1 + r_2 + PHI*(t_raw - t_1)

Only the single best clock sample, from a given NTP server, i.e. the one
that gives the tightest error bounds, need be retained. Other things being
equal, newer samples will be preferable to older ones because the
PHI*(t_raw - t_1) term will be smaller, but sometimes this may be negated
by other terms such as hrtt being larger.

A client may gain resiliency by using multiple NTS-secured NTP servers. In
this case for N servers it lets f=floor((N-1)/2), then discards the f
lowest lower bounds and the f highest upper bounds, and then treats
anything inside any of the remaining bounds as plausible.

Any PTP message whose time (after applying the usual link-delay correction)
is plausible according to these bounds is processed as usual. Any PTP
message whose time is not plausible is first clamped to the nearest bound
and then processed as usual.

And that's all there is to it!

---

From: "Langer, Martin" <[email-masked]>
Date: Sat, 8 May 2021 23:30:40 +0000

Hello Daniel,

That's an interesting thought and reminds me of a similar approach that Kristof and I had
for securing TESLA for NTP. But I think the problem goes a bit deeper. ...at least for PTP
unicast. As far as I know, connections could be "reactivated" or cancelled by replay attacks.
Possibly other attacks could also be carried out by packet manipulation. ...but I need to
think this through further. ;)

have a nice day

-martin-

-------------------
Martin Langer, M.Eng.
Ostfalia Hochschule für angewandte Wissenschaften
- Hochschule Braunschweig/Wolfenbüttel
University of Applied Sciences

Labor Datentechnik, Labor Design Digitaler Systeme
Fakultät Elektrotechnik
Salzdahlumer Straße 46/48
38302 Wolfenbüttel
Germany

Tel.: +49 5331 939 43370
Web: https://www.ostfalia.de/cms/de/pws/bermbach/mitarbeiter/martin-langer

________________________________
Von: ntp <[email-masked]> im Auftrag von Daniel Franke <[email-masked]>
Gesendet: Samstag, 8. Mai 2021 22:53:06
An: NTP WG
Betreff: [Ntp] A simpler way to secure PTP

As an alternative to Martin's and Heiko's drafts, I'd like to propose a simpler approach to securing PTP. It is compatible with all PTP features, supports the same threat model as NTS-secured NTP, introduces zero jitter, and can be implemented entirely on the client side without the knowledge or cooperation of the rest of the PTP infrastructure.

The trick is: run NTS-secured NTP and regular, unauthenticated PTP side-by-side. Do not use the NTP responses to set the clock; instead, use them only to establish maximum error bounds on the current time, and then clamp all PTP messages to within those bounds.

The client's on-wire interaction with the NTP server is the same as it is in normal NTS-secured NTP, but the way it processes the server's responses is different. The client maintains an estimate `theta` of the offset between a local, unadjusted monotonic clock `t_raw` (implemented e.g. by CLOCK_MONOTONIC_RAW on linux) and the server's realtime clock, along with a continuously-changing error term `lamdba`.

  t_raw + theta + DTAI

  hrtt = (t_4 - t_1)/2
  rdel = packet root delay

Only the single best clock sample, from a given NTP server, i.e. the one that gives the tightest error bounds, need be retained. Other things being equal, newer samples will be preferable to older ones because the PHI*(t_raw - t_1) term will be smaller, but sometimes this may be negated by other terms such as hrtt being larger.

A client may gain resiliency by using multiple NTS-secured NTP servers. In this case for N servers it lets f=floor((N-1)/2), then discards the f lowest lower bounds and the f highest upper bounds, and then treats anything inside any of the remaining bounds as plausible.

Any PTP message whose time (after applying the usual link-delay correction) is plausible according to these bounds is processed as usual. Any PTP message whose time is not plausible is first clamped to the nearest bound and then processed as usual.

---

From: Daniel Franke <[email-masked]>
Date: Sat, 8 May 2021 21:10:54 -0400

This sort of denial-of-service attack is outside the scope of what NTS is
meant to prevent. More potent attacks are already possible at protocol
layers lower than anything we can control. You can DoS your local network
segment with ARP poisoning, and of course if you control any router on the
communication path then you can just drop the traffic altogether. If an
*off-path* adversary can DoS you just through blind packet spoofing then
that's more troubling, but on the sort of closed networks that PTP is
designed for, I think this can always be satisfactorily mitigated by the
reverse-path filtering that most routers do automatically and by default.
(If a random box on the other side of the Internet can spoof your PTP
grandmaster's IP address and that spoofed packet can make it all the way to
your endpoint systems rather than getting dropped at your firewall, fix
your network). The guarantee that my design is intended to provide is that
no attacker, not even one with a privileged network position, can
manipulate your clock outside the narrow bounds that NTS-secured NTP
establishes. I don't think the attacks you're describing violate that.

On Sat, May 8, 2021 at 7:30 PM Langer, Martin <[email-masked]>
wrote:

> ------------------------------
> *Von:* ntp <[email-masked]> im Auftrag von Daniel Franke <
> [email-masked]>
> *Gesendet:* Samstag, 8. Mai 2021 22:53:06
> *An:* NTP WG
> *Betreff:* [Ntp] A simpler way to secure PTP
>
> Any PTP message whose time (after applying the usual link-delay
> correction) is plausible according to these bounds is processed as usual.
> Any PTP message whose time is not plausible is first clamped to the nearest
> bound and then processed as usual.
>

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 10 May 2021 14:46:14 +0200

> clamp all PTP messages to within those bounds.

Makes sense to me.

In a more general approach, this is already possible with some
existing PTP and NTP implementations like linuxptp and chrony. PTP can
be specified as an untrusted reference clock, which will be used for
synchronization only if it agrees with trusted NTS-secured NTP
source(s). We recommend combining (multiple) PTP and NTP time sources
for better accuracy, resiliency, and security.

-- 
Miroslav Lichvar

---

From: Doug Arnold <[email-masked]>
Date: Mon, 10 May 2021 14:43:19 +0000

I have heard of people actually doing this in the field as a sanity check.

However, some applications that use PTP can be broken by introducing timing errors that are less than the expected difference between PTP and NTP.

Doug

From: ntp <[email-masked]> on behalf of Miroslav Lichvar <[email-masked]>
Date: Monday, May 10, 2021 at 8:47 AM
To: Daniel Franke <[email-masked]>
Cc: NTP WG <[email-masked]>
Subject: Re: [Ntp] A simpler way to secure PTP

Makes sense to me.

--
Miroslav Lichvar

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

---

From: Daniel Franke <[email-masked]>
Date: Mon, 10 May 2021 11:21:39 -0400

On Mon, May 10, 2021 at 10:43 AM Doug Arnold <[email-masked]>
wrote:

> However, some applications that use PTP can be broken by introducing
> timing errors that are less than the expected difference between PTP and
> NTP.
>

You cannot solve this with cryptography. An adversarial network is, by
definition, one where you can't rely on statistical behavior and can't
neglect the probability of worst-case outcomes. The worst-case outcome for
any unicast protocol is going to be at least half the measured RTT, and for
a broadcast protocol the worst case is unbounded. As I've mentioned before,
you can improve this a little bit if you know a lower bound on the physical
distance `d` between the client and server, in which case you can shrink
each of your bounds by `d/c` where `c` is the speed of light, but this
still won't get you anywhere near the kind of precision you have in mind.
If worst-case, let alone typical-case, NTS4NTP behavior is going to break
your application in critical ways, then you MUST have a physically-secure
link to your time source. If you have an adversary on your communication
path, you're just screwed and cryptography can't save you.

---

From: Doug Arnold <[email-masked]>
Date: Mon, 10 May 2021 16:18:39 +0000

Many of the applications of PTP I know of require time transfer accuracy better than half the RTT.  This is achieved using a variety of mechanisms, including:

  *   On-path support
  *   High message rates + lucky packet filters
  *   Synchronous Ethernet
  *   Networks with lightly loaded switches
  *   Preemptive switches
  *   Asymmetry calibration
  *   Multiple PTP domains with different paths to devices needing time
  *   Multiple sources of time, that is PTP, plus other non-PTP time transfer mechanisms in a redundant system

A switch in the middle could mount a delay attack, which is of course immune to cryptography, but the risk could be reduced by non-cryptographic defenses such as time source, or network path redundancy.

NTS4PTP could help against malicious agents which have gained access to the network and start sending bogus PTP messages, for example impersonating the Grandmaster.

Doug

From: Daniel Franke <[email-masked]>
Date: Monday, May 10, 2021 at 11:21 AM
To: Doug Arnold <[email-masked]>
Cc: Miroslav Lichvar <[email-masked]>, NTP WG <[email-masked]>
Subject: Re: [Ntp] A simpler way to secure PTP
On Mon, May 10, 2021 at 10:43 AM Doug Arnold <[email-masked]<mailto:[email-masked]>> wrote:
I have heard of people actually doing this in the field as a sanity check.

You cannot solve this with cryptography. An adversarial network is, by definition, one where you can't rely on statistical behavior and can't neglect the probability of worst-case outcomes. The worst-case outcome for any unicast protocol is going to be at least half the measured RTT, and for a broadcast protocol the worst case is unbounded. As I've mentioned before, you can improve this a little bit if you know a lower bound on the physical distance `d` between the client and server, in which case you can shrink each of your bounds by `d/c` where `c` is the speed of light, but this still won't get you anywhere near the kind of precision you have in mind. If worst-case, let alone typical-case, NTS4NTP behavior is going to break your application in critical ways, then you MUST have a physically-secure link to your time source. If you have an adversary on your communication path, you're just screwed and cryptography can't save you.

---

From: "Langer, Martin" <[email-masked]>
Date: Mon, 10 May 2021 16:49:54 +0000

"NTS4PTP could help against malicious agents which have gained access to the network and start sending bogus PTP messages, for example impersonating the Grandmaster. "

I had the same thought. Simply hang a small device on the PTP network, which pretends to be the best clock via Announce messages.
The BMCA does the rest and adjusts the topology. After that I can roughly fluctuate between about +/- RTT/2 before an NTS/NTP watchdog
intervenes. Thus, the accuracy of the PTP network can be easily decreased. I would imagine that delay attacks can be detected quite well in PTP
networks, since links between PTP nodes typically don't change.  ...Especially since it is a local network. An unauthenticated PTP node that can
freely adjust the time within a certain range, even if it is only 1-2 milliseconds, seems more dangerous in my eyes.

Nevertheless, NTS-secured NTP is a good monitoring solution.

best regards,
martin

-------------------
Martin Langer, M.Eng.

Tel.: +49 5331 939 43370

________________________________
Von: ntp <[email-masked]> im Auftrag von Doug Arnold <doug.arnold=[email-masked]>
Gesendet: Montag, 10. Mai 2021 18:18:39
An: Daniel Franke
Cc: Miroslav Lichvar; NTP WG
Betreff: Re: [Ntp] A simpler way to secure PTP

  *   On-path support

Doug

---

From: [email-masked]
Date: Mon, 10 May 2021 19:05:29 +0200

@Doug: Daniel is correct; you can apply all kinds of magic, but ultimately, your hard, 100% certain guarantees are going to be at best "half of RTT" for two-way time transfer and "none at all" for one-way transfer.

You can make it *more likely* that what you measured and came up with is better than that.

But if you're going to try to appease some kind of regulatory thing where you have to demonstrably and undoubtably be below an offset better than half of RTT of your best two-way transfer, you might just be out of luck.

@Daniel: I think this is an argument for putting crypto on PTP / White Rabbit, though.

In the end, using two-way transfer with hardware-assisted timestamps is going to be the only way to dissolve the dilemma.

I do like your approach; as Martin hinted at, we've been looking at how to formalize something like it for a while.

Even if it offers no better hard guarantee than NTS alone, it still seems the most reasonable and readily available way forward.

Best regards,

Kristof

-----"ntp" <[email-masked]> schrieb: -----

An: "Daniel Franke" <[email-masked]>
Von: "Doug Arnold"
Gesendet von: "ntp"
Datum: 10.05.2021 18:19
Kopie: "Miroslav Lichvar" <[email-masked]>, "NTP WG" <[email-masked]>
Betreff: Re: [Ntp] A simpler way to secure PTP

On-path support

High message rates + lucky packet filters

Synchronous Ethernet

Networks with lightly loaded switches

Preemptive switches

Asymmetry calibration

Multiple PTP domains with different paths to devices needing time

Multiple sources of time, that is PTP, plus other non-PTP time transfer mechanisms in a redundant system

Doug

From:
Daniel Franke <[email-masked]>

On Mon, May 10, 2021 at 10:43 AM Doug Arnold <[email-masked]> wrote:

You cannot solve this with cryptography. An adversarial network is, by definition, one where you can't rely on statistical behavior and can't neglect the probability of worst-case outcomes. The worst-case outcome for any unicast protocol
 is going to be at least half the measured RTT, and for a broadcast protocol the worst case is unbounded. As I've mentioned before, you can improve this a little bit if you know a lower bound on the physical distance `d` between the client and server, in which
 case you can shrink each of your bounds by `d/c` where `c` is the speed of light, but this still won't get you anywhere near the kind of precision you have in mind. If worst-case, let alone typical-case, NTS4NTP behavior is going to break your application
 in critical ways, then you MUST have a physically-secure link to your time source. If you have an adversary on your communication path, you're just screwed and cryptography can't save you.

---

From: Daniel Franke <[email-masked]>
Date: Mon, 10 May 2021 13:09:40 -0400

You get the most leverage out of the PTP + NTS4NTP approach in situations
where having as much precision as possible is desirable, but having your
clock be a decade off is far worse than having it be a half-RTT off.
Perhaps your system is running different applications with different levels
of criticality that use the clock in different ways.

You're of course correct that if you have multiple independent links, you
can get a secure result if you're able to assume that some fraction of them
are trustworthy. At minimum you need a correct majority, that is, N>=2f+1.
In this case you can just take the median sample: since you have f+1
samples greater than or equal to the median and f+1 samples less than or
equal to it, you have it bounded on each side by at least one correct
sample and therefore it can be considered correct. Alternatively, you can
use the Schiff-Dolev-Mizrahi-Schapira Chronos algorithm. This will give you
better results when, for non-adversarial reasons, there's dispersion among
correct clocks: you'll get tighter synchronization among sets of clients
that all use the same sources. However, Chronos requires N>=3f+1.

On Mon, May 10, 2021 at 12:18 PM Doug Arnold <[email-masked]>
wrote:

> Many of the applications of PTP I know of require time transfer accuracy
> better than half the RTT.  This is achieved using a variety of mechanisms,
> including:
>
>    - On-path support
>    - High message rates + lucky packet filters
>    - Synchronous Ethernet
>    - Networks with lightly loaded switches
>    - Preemptive switches
>    - Asymmetry calibration
>    - Multiple PTP domains with different paths to devices needing time
>    - Multiple sources of time, that is PTP, plus other non-PTP time
>    transfer mechanisms in a redundant system
>
>
>
> A switch in the middle could mount a delay attack, which is of course
> immune to cryptography, but the risk could be reduced by non-cryptographic
> defenses such as time source, or network path redundancy.
>
>
>
> NTS4PTP could help against malicious agents which have gained access to
> the network and start sending bogus PTP messages, for example impersonating
> the Grandmaster.
>
>
>
> Doug
>
>
>
>
>
>
>
>
>
>
>
> *From: *Daniel Franke <[email-masked]>
> *Date: *Monday, May 10, 2021 at 11:21 AM
> *To: *Doug Arnold <[email-masked]>
> *Cc: *Miroslav Lichvar <[email-masked]>, NTP WG <[email-masked]>
> *Subject: *Re: [Ntp] A simpler way to secure PTP
>

---

From: Heiko Gerstung <[email-masked]>
Date: Tue, 11 May 2021 09:14:55 +0200

Thanks Daniel, this is a reasonable approach for every application that requires a sync accuracy level which can be achieved with NTS4NTP, but there are quite a number of applications out there which require more than what NTP can provide. PTP is different from NTP on multiple levels and offers a number of features that you do not find in NTP, for example higher packet rates to increase the number of samples you feed into your statistics. It also offers hardware timestamping in the network infrastructure components, i.e. switches and routers, which can improve your sync performance dramatically. In combination with hardware timestamping it will reduce the time error introduced by the network stacks of client and server and the queueing/delay variation part quite a lot. 

I totally agree that using NTP to secure PTP is a reasonable approach, as Doug pointed out this has already been implemented years ago. See https://ieeexplore.ieee.org/document/6948697 for a description of such an approach applied in the financial industry around 2014. 

However, especially unicast PTP is a great traffic amplification tool, maybe one of the biggest traffic amplification machines of all times. And I also believe that it would be great to (re)use the general concepts of NTS to secure the other popular time transfer protocol out there. 

I do not see a valid reason not to introduce a standardized way to improve security for this protocol, this will allow to utilize some of the features of (unicast) PTP in networks that currently should not use it. And it will improve security in networks where users need security mechanisms for their critical services and protocols in addition to the ones already in place to protect lower layers of the network. 

Best 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 Daniel Franke <[email-masked]>
Datum: Samstag, 8. Mai 2021 um 22:53
An: NTP WG <[email-masked]>
Betreff: [Ntp] A simpler way to secure PTP

  DTAI = TAI - UTC offset

  t_raw + theta + DTAI

  hrtt = (t_4 - t_1)/2

  rdel = packet root delay

 

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

---

From: Joachim Fabini <[email-masked]>
Date: Tue, 11 May 2021 09:59:10 +0200

On 5/10/21 7:05 PM, [email-masked] wrote:
> @Doug: Daniel is correct; you can apply all kinds of magic, but 
> ultimately, your hard, 100% certain guarantees are going to be at best 
> "half of RTT" for two-way time transfer and "none at all" for one-way 
> transfer.

"At best" is too little. 100% certain guarantees (for two-way time sync) 
apply for *RTT* - and definitely *not* for half of RTT. The link 
symmetry assumption is one of the weakest point of today's network time 
synchronization protocols that malicious actors can exploit.

By knowing physical link properties (delay, capacity) one can restrict 
the RTT bound and decrease the limits. However, attackers could - in 
theory and practice - exploit this assumption, too (for instance by 
inserting new (faster-than)-light-speed paths).

If anyone is interested: theoretical aspects (and practical 
consequences) of securing time sync protocols against malicious actors 
can be found in an older paper (https://arxiv.org/pdf/1705.10669.pdf) 
and in parts of the subsequent PhD thesis 
(https://www.annessi.net/data/2019-Annessi_thesis.pdf).

regards
Joachim

> 
> -----"ntp" <[email-masked] <mailto:[email-masked]>> schrieb: 
> -----
> An: "Daniel Franke" <[email-masked] <mailto:[email-masked]>>
> Von: "Doug Arnold"
> Gesendet von: "ntp"
> Datum: 10.05.2021 18:19
> Kopie: "Miroslav Lichvar" <[email-masked] 
> <mailto:[email-masked]>>, "NTP WG" <[email-masked] <mailto:[email-masked]>>
> better than half the RTT.  This is achieved using a variety of 
> mechanisms, including:
> 
>   * On-path support
> 
>   * Multiple sources of time, that is PTP, plus other non-PTP time
> immune to cryptography, but the risk could be reduced by 
> non-cryptographic defenses such as time source, or network path redundancy.
> 
> the network and start sending bogus PTP messages, for example 
> impersonating the Grandmaster.
> 
> Doug
> 
> *From: *Daniel Franke <[email-masked] <mailto:[email-masked]>>
> *To: *Doug Arnold <[email-masked] 
> <mailto:[email-masked]>>
> *Cc: *Miroslav Lichvar <[email-masked] 
> <mailto:[email-masked]>>, NTP WG <[email-masked] <mailto:[email-masked]>>
> On Mon, May 10, 2021 at 10:43 AM Doug Arnold 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     timing errors that are less than the expected difference between PTP
>     and NTP.
> 
> neglect the probability of worst-case outcomes. The worst-case outcome 
> for any unicast protocol is going to be at least half the measured RTT, 
> and for a broadcast protocol the worst case is unbounded. As I've 
> mentioned before, you can improve this a little bit if you know a lower 
> bound on the physical distance `d` between the client and server, in 
> which case you can shrink each of your bounds by `d/c` where `c` is the 
> speed of light, but this still won't get you anywhere near the kind of 
> precision you have in mind. If worst-case, let alone typical-case, 
> NTS4NTP behavior is going to break your application in critical ways, 
> then you MUST have a physically-secure link to your time source. If you 
> have an adversary on your communication path, you're just screwed and 
> cryptography can't save you.
> 
> [email-masked] <mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/ntp>
> 

-- 
---------------------------------------
Dr. Joachim Fabini
Senior Scientist
Institute of Telecommunications
TU Wien
Gusshausstrasse 25/E389
A-1040 Vienna, Austria
Tel: +43 1 58801-38813
mailto: [email-masked]
---------------------------------------

---

From: Heiko Gerstung <[email-masked]>
Date: Tue, 11 May 2021 10:07:57 +0200

Daniel, with hardware timestamping in the end nodes you can improve the delay measurement considerably. With hardware timestamping in the network infrastructure, e.g. using TCs, you can improve this even further. These mechanisms are not available to NTP nodes. Applying lucky packet filters at a packet rate of 128 packets/s will improve your calculated RTT by using only 1% of the RTT measurements. There is quite a lot you can do to improve accuracy over a network link that you cannot currently do with NTP. Due to all the above mentioned measures, the precision with which PTP can measure the RTT is typically orders of magnitudes higher than with NTP resulting in a much better “worst outcome”. 

As Doug already mentioned, there are quite a lot of PTP applications in the field which require better than 1us accuracy, and even more that require better than 10us accuracy. I do agree that, in a perfect network with (more or less) static delays and end nodes with low latency network stack implementations, you can achieve the same level of accuracy with NTP that you achieve with PTP, but there are many networks and applications out there with not-so-perfect conditions. I am sure we all do not want to get into a PTP vs NTP discussion here, there are just a lot of applications that require/use PTP and I believe it is a good idea to improve security for it. 

And, to me a network time security approach is not limited to a protection against time manipulation. It should also add protection against abusing the protocol to carry out amplification attacks and disrupt the protocol in any possible way. Yes, if you have a man-in-the-middle being able to simply drop your packets to deny synchronization to your end nodes, you are screwed. But at least your end nodes immediately notice that they do not receive any packets anymore. You can also carry out a delay attack and do a lot of other nasty things. However, protecting the protocol against some malicious attacker being able to inject arbitrary packets into the network is still a desirable goal IMHO.

Best Regards,

   Heiko

-- 

Heiko Gerstung 

Managing Director 

Lange Wand 9 

Email: 

Web: 

Connect via LinkedIn: 

 

Von: ntp <[email-masked]> im Auftrag von Daniel Franke <[email-masked]>
Datum: Montag, 10. Mai 2021 um 17:22
An: Doug Arnold <[email-masked]>
Cc: Miroslav Lichvar <[email-masked]>, NTP WG <[email-masked]>
Betreff: Re: [Ntp] A simpler way to secure PTP

---

From: Heiko Gerstung <[email-masked]>
Date: Tue, 11 May 2021 10:14:55 +0200

Joachim,

thanks for the provided document references. Both are focusing on multicast operation of NTP and PTP, is that correct? At least that is what I understood from the introduction paragraphs of both papers. 

Regards,
  Heiko

-- 
Heiko Gerstung 
Managing Director 

 
Email: 

Connect via LinkedIn: 

Am 11.05.21, 09:59 schrieb "ntp im Auftrag von Joachim Fabini" <[email-masked] im Auftrag von [email-masked]>:

    regards
    Joachim

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 11 May 2021 10:24:19 +0200

On Tue, May 11, 2021 at 09:14:55AM +0200, Heiko Gerstung wrote:
>PTP is different from NTP on multiple levels and offers a number of features that you do not find in NTP, for example higher packet rates to increase the number of samples you feed into your statistics.

Isn't this the other way around? The maximum rate of delay requests is
limited by the TX HW timestamping rate. The few PTP appliances I saw
supported only a very small number of clients. This can exploited for
a DoS attack. The same applies to NTP using HW timestamps+xleave, but
at least it can fall back to SW timestamps and clients should handle
that well.

> It also offers hardware timestamping in the network infrastructure components, i.e. switches and routers, which can improve your sync performance dramatically.

Would you expect the network devices to gain support for the new
security protocol quickly, or is it more likely the leaf clocks would
need to bypass them and send their secured requests to new designated
clocks (avoiding the benefits of the hardware support)?

> However, especially unicast PTP is a great traffic amplification tool, maybe one of the biggest traffic amplification machines of all times. And I also believe that it would be great to (re)use the…

Yes, the near infinite amplification factor of the unicast PTP mode is
a major concern, but I don't see what can be reused from NTS to fix
that. NTS in NTP avoids amplification by the protocol design, not by a
security mechanism.

-- 
Miroslav Lichvar

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 11 May 2021 10:38:58 +0200

On Tue, May 11, 2021 at 09:59:10AM +0200, Joachim Fabini wrote:
> apply for *RTT* - and definitely *not* for half of RTT. The link symmetry
> assumption is one of the weakest point of today's network time

I don't agree. Because we compensate for half the RTT, the maximum
error is reduced to half the RTT. Without the compensation for
half the RTT I would agree.

Assume the real time it takes between peers is 1 ms and that there
are no other sources of errors. If there is an artificial
additional delay of 998 ms in the reply direction, we measure an
RTT of 1000 ms.

We will then assume that it took 500 ms instead of 999 ms to
arrive, and add 500 ms instead of 999 ms to the received time
as our estimate of the time. So we have an error of 499 ms.
I see no way to get an error that is larger than half the RTT
(ignoring other sources of errors.)

Note that this requires a packet in each direction with
enough meta data to be able to calculate an RTT. If you
don't have a RTT, you don't have a maximum bound.

Kurt

---

From: Joachim Fabini <[email-masked]>
Date: Tue, 11 May 2021 10:42:10 +0200

Heiko,

the focus of the thesis was on improving secure multicast communication 
performance (or finding alternatives).
However, chapter 10 of the thesis focuses on the unicast case, including 
a successful attack on a commercially available system (NTP two-way time 
sync "protected" by an IPsec tunnel over public Internet) that exploits 
this property. This was a helpful "lessons learned" session.

regards Joachim

---

From: Heiko Gerstung <[email-masked]>
Date: Tue, 11 May 2021 10:42:40 +0200

Am 11.05.21, 10:24 schrieb "Miroslav Lichvar" <[email-masked]>:

>    at least it can fall back to SW timestamps and clients should handle

Our products can support 2,048 unicast PTP clients at 128 pkts/s for both sync and delay responses, i.e. you end up with roughly 500k TX timestamps on each of the Gigabit Ethernet ports of our devices (up to 10 ports in a 3U chassis). I'd say you did not see the most powerful appliances out there ;-)  ..

>    clocks (avoiding the benefits of the hardware support)?

Well, it will take some time for sure, but if there is no standard, no hardware vendor would be willing to add this to their feature list. 

  >  that. NTS in NTP avoids amplification by the protocol design, not by a

Our draft reuses the NTS-KE phase of NTS4NTP for the key exchange. It uses the integrated PTP security mechanism and adds multiple protection mechanisms to PTP. See the "Security Considerations" part of the draft.

Regards,
   Heiko

    -- 
    Miroslav Lichvar

---

From: [email-masked]
Date: Tue, 11 May 2021 10:48:44 +0200

I don't think I expressed this clearly enough:
Your 100%* guarantee (the 100% kinda still needs an asterisk there) with a two-way exchange is going to be that the measurement you make of your time offset is wrong by at most half of your RTT (where RTT = the sum of the two messages' flight times).

It's about an upper bound to the error you make in your calculation.

The maximum of half of RTT would be taken if one message was delivered instantaneously and the other accounted for all of your RTT, so in reality, you at least know that it's really less than that (and, as Daniel said, you can do a few things more if you account for not exceeding lightspeed and a known lower bound to your physical distance).

With a one-way exchange, the issue is that your possible error is unbounded in one direction (basically because you have no way of asserting that the message is fresh).

See also https://ieeexplore.ieee.org/document/8357814, or my dissertation.

Best regards!

* The asterisk would account for frequency differences in addition to time offsets.

An: <[email-masked]>, "Doug Arnold" <doug.arnold=[email-masked]>
Von: "Joachim Fabini"
Gesendet von: "ntp"
Datum: 11.05.2021 09:59
Kopie: "Miroslav Lichvar" <[email-masked]>, "NTP WG" <[email-masked]>, "Daniel Franke" <[email-masked]>
Betreff: Re: [Ntp] Antwort: Re: A simpler way to secure PTP

regards
Joachim

---

From: Joachim Fabini <[email-masked]>
Date: Tue, 11 May 2021 11:50:16 +0200

> additional delay of 998 ms in the reply direction, we measure an

I guess my concept of error differs - for me it's the slave's 
uncertainty interval. The half RTT error can happen in both directions.

Assume that the slave sends the request at local time ts0 and receives 
the server response at local time ts1=ts0+1000ms, slave-measured RTT is 
1000ms. The master inserted its local timestamp tm into the message. 
We're ignoring local drift/skew.

Theoretical link delay asymmetry for <forwardLink;reverseLink> can range 
anyhwere from <0,1000> to <1000,0>. The only guaranteed bounds for the 
slave is that abs(ts0) < abs(tm) < abs(ts1) (where - an uncertainty 
interval of one full RTT. Unless physical link properties and 
constraints are known, any other assumption is probabilistic.

br Joachim

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 11 May 2021 11:55:41 +0200

On Tue, May 11, 2021 at 11:50:16AM +0200, Joachim Fabini wrote:
> I guess my concept of error differs - for me it's the slave's uncertainty
> interval. The half RTT error can happen in both directions.
> 
> Assume that the slave sends the request at local time ts0 and receives the
> server response at local time ts1=ts0+1000ms, slave-measured RTT is 1000ms.
> The master inserted its local timestamp tm into the message. We're ignoring
> local drift/skew.
> 
> anyhwere from <0,1000> to <1000,0>. The only guaranteed bounds for the slave
> is that abs(ts0) < abs(tm) < abs(ts1) (where - an uncertainty interval of
> one full RTT. Unless physical link properties and constraints are known, any
> other assumption is probabilistic.

What we do to reduce the error, is add 500 ms to tm, and then have an
error from -500 ms to +500 ms. Without adding that 500 ms, the
error is from +0 to +1000 ms.

Kurt

---

From: Joachim Fabini <[email-masked]>
Date: Tue, 11 May 2021 12:56:08 +0200

On 5/11/21 10:48 AM, [email-masked] wrote:
> Your 100%* guarantee (the 100% kinda still needs an asterisk there) with 
> a two-way exchange is going to be that the measurement you make of your 
> time offset is wrong by at most half of your RTT (where RTT = the sum of 
> the two messages' flight times).
> The maximum of half of RTT would be taken if one message was delivered 
> instantaneously and the other accounted for all of your RTT, so in 
> reality, you at least know that it's really less than that (and, as 
> Daniel said, you can do a few things more if you account for not 
> exceeding lightspeed and a known lower bound to your physical distance).

My earlier posting to the ntp group (reply to Kurt's email) seems to be 
delayed. It's about how we define "error" (I read the discussion after 
having a discussion on uncertainty intervals, so was to some extent 
biased...)
If it is about "the maximum deviation of my guessed offset from a 
reference clock" then I'm with you, it's (+-)1/2 RTT. If it is about the 
uncertainty interval it's a RTT. Apologies for the confusion.

Btw, perhaps it's worth to include a dedicated definition of error or 
define an alternative unique name in one of the future docs. I briefly 
skimmed over NTPv4 and NTS and error is used (in the meaning used by 
you) but (imo - did not do an exhaustive search) not defined.
> With a one-way exchange, the issue is that your possible error is 
> unbounded in one direction (basically because you have no way of 
> asserting that the message is fresh).

Full agree.

best regards
Joachim

> See also https://ieeexplore.ieee.org/document/8357814, 
> <https://ieeexplore.ieee.org/document/8357814,> or my dissertation.
> 
> 
> Best regards!
> 
> An: <[email-masked] <mailto:[email-masked]>>, "Doug 
> Arnold" <doug.arnold=[email-masked] 
> <mailto:doug.arnold=[email-masked]>>
> Von: "Joachim Fabini"
> Gesendet von: "ntp"
> Datum: 11.05.2021 09:59
> <mailto:[email-masked]>>, "NTP WG" <[email-masked] 
> <mailto:[email-masked]>>, "Daniel Franke" <[email-masked] 
> <mailto:[email-masked]>>
> On 5/10/21 7:05 PM, [email-masked] 
> <mailto:[email-masked]> wrote:
> can be found in an older paper (https://arxiv.org/pdf/1705.10669.pdf 
> <https://arxiv.org/pdf/1705.10669.pdf>)
> (https://www.annessi.net/data/2019-Annessi_thesis.pdf 
> <https://www.annessi.net/data/2019-Annessi_thesis.pdf>).
> 
> regards
> Joachim
> 
> 
>  >
>  > -----"ntp" <[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>> schrieb:
>  > -----
>  > An: "Daniel Franke" <[email-masked] 
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>>
>  > Von: "Doug Arnold"
>  > Gesendet von: "ntp"
>  > Datum: 10.05.2021 18:19
> <mailto:[email-masked]>
>  > <mailto:[email-masked] <mailto:[email-masked]>>>, "NTP WG" 
> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>>
>  > *From: *Daniel Franke <[email-masked] 
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>>
> <mailto:[email-masked]>
>  > <mailto:[email-masked] 
> <mailto:[email-masked]>>>
>  > *Cc: *Miroslav Lichvar <[email-masked] <mailto:[email-masked]>
>  > <mailto:[email-masked] <mailto:[email-masked]>>>, NTP WG 
> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>>
>  > <[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] 
> <mailto:[email-masked]>>> wrote:
>  >
>  > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>
>  > <https://www.ietf.org/mailman/listinfo/ntp 
> <https://www.ietf.org/mailman/listinfo/ntp>>
>  >
> mailto: [email-masked] <mailto:[email-masked]>

---

From: [email-masked]
Date: Tue, 11 May 2021 13:24:15 +0200

Yeah, your point about max error versus (un)certainty interval makes total sense.
Thanks for clearing it up.

-----"Joachim Fabini" <[email-masked]> schrieb: -----

An: <[email-masked]>
Von: "Joachim Fabini" <[email-masked]>
Datum: 11.05.2021 12:56
Kopie: "Doug Arnold" <doug.arnold=[email-masked]>, "Miroslav Lichvar" <[email-masked]>, "NTP WG" <[email-masked]>, "Daniel Franke" <[email-masked]>
Betreff: Re: Antwort: Re: [Ntp] Antwort: Re: A simpler way to secure PTP

Full agree.

best regards
Joachim

>  > @Doug: Daniel is correct; you can apply all kinds of magic, but
>  > ultimately, your hard, 100% certain guarantees are going to be at best
>  > "half of RTT" for two-way time transfer and "none at all" for one-way
>  > transfer.
>
>  >
>  > -----"ntp" <[email-masked] <mailto:[email-masked]>
>  > -----
>  > An: "Daniel Franke" <[email-masked]
>  > Von: "Doug Arnold"
>  > Gesendet von: "ntp"
>  > Datum: 10.05.2021 18:19
>  > Kopie: "Miroslav Lichvar" <[email-masked]
>  > <mailto:[email-masked] <mailto:[email-masked]>>>, "NTP WG"
>  > Betreff: Re: [Ntp] A simpler way to secure PTP
>  >
>  > Many of the applications of PTP I know of require time transfer accuracy
>  > better than half the RTT.  This is achieved using a variety of
>  > mechanisms, including:
>  >
>  >   * On-path support
>  >
>  >   * High message rates + lucky packet filters
>  >
>  >   * Synchronous Ethernet
>  >
>  >   * Networks with lightly loaded switches
>  >
>  >   * Preemptive switches
>  >
>  >   * Asymmetry calibration
>  >
>  >   * Multiple PTP domains with different paths to devices needing time
>  >
>  >   * Multiple sources of time, that is PTP, plus other non-PTP time
>  >     transfer mechanisms in a redundant system
>  >
>  > A switch in the middle could mount a delay attack, which is of course
>  > immune to cryptography, but the risk could be reduced by
>  > non-cryptographic defenses such as time source, or network path
> redundancy.
>  >
>  > NTS4PTP could help against malicious agents which have gained access to
>  > the network and start sending bogus PTP messages, for example
>  > impersonating the Grandmaster.
>  >
>  > Doug
>  >
>  > *From: *Daniel Franke <[email-masked]
>  > *Date: *Monday, May 10, 2021 at 11:21 AM
>  > *To: *Doug Arnold <[email-masked]
>  > <mailto:[email-masked]
>  > *Cc: *Miroslav Lichvar <[email-masked] <mailto:[email-masked]>
>  > <mailto:[email-masked] <mailto:[email-masked]>>>, NTP WG
>  > *Subject: *Re: [Ntp] A simpler way to secure PTP
>  >
>  > On Mon, May 10, 2021 at 10:43 AM Doug Arnold
>  > <[email-masked] <mailto:[email-masked]>
>  >
>  >     I have heard of people actually doing this in the field as a sanity
>  >     check.
>  >
>  >     However, some applications that use PTP can be broken by introducing
>  >     timing errors that are less than the expected difference between PTP
>  >     and NTP.
>  >
>  > You cannot solve this with cryptography. An adversarial network is, by
>  > definition, one where you can't rely on statistical behavior and can't
>  > neglect the probability of worst-case outcomes. The worst-case outcome
>  > for any unicast protocol is going to be at least half the measured RTT,
>  > and for a broadcast protocol the worst case is unbounded. As I've
>  > mentioned before, you can improve this a little bit if you know a lower
>  > bound on the physical distance `d` between the client and server, in
>  > which case you can shrink each of your bounds by `d/c` where `c` is the
>  > speed of light, but this still won't get you anywhere near the kind of
>  > precision you have in mind. If worst-case, let alone typical-case,
>  > NTS4NTP behavior is going to break your application in critical ways,
>  > then you MUST have a physically-secure link to your time source. If you
>  > have an adversary on your communication path, you're just screwed and
>  > cryptography can't save you.
>  >
>  > _______________________________________________
>  > ntp mailing list
>  > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>  > https://www.ietf.org/mailman/listinfo/ntp
>  > <https://www.ietf.org/mailman/listinfo/ntp
>  >
>  > _______________________________________________
>  > ntp mailing list
>  > [email-masked] <mailto:[email-masked]>
>  > https://www.ietf.org/mailman/listinfo/ntp
>  >

---

From: Daniel Franke <[email-masked]>
Date: Tue, 11 May 2021 15:39:27 -0400

On Tue, May 11, 2021 at 3:14 AM Heiko Gerstung <[email-masked]>
wrote:

> However, especially unicast PTP is a great traffic amplification tool,
> maybe one of the biggest traffic amplification machines of all times. And I
> also believe that it would be great to (re)use the general concepts of NTS
> to secure the other popular time transfer protocol out there.
>

Amplification is definitely worth fixing, but ISTM this should be
orthogonal to the NTS effort. You don't need message authentication for
that, you just need the client to prove (and maybe occasionally re-prove)
that it's able to receive packets at a particular IP address. There may be
some crypto involved in doing so (a la TCP SYN cookies), but it doesn't
have to be related to NTS crypto, and servers shouldn't have to require all
their clients to support NTS just to prevent themselves from being
exploited for amplification.

---

From: Heiko Gerstung <[email-masked]>
Date: Wed, 12 May 2021 07:14:48 +0200

Hi Daniel,

that’s why we use the integrated security mechanism for unicast PTP and just use the NTS-KE protocol to exchange the required keys for that. Due to the fact that the two protocols NTP and PTP work in a completely different way, there is not more that can be reused. I agree we could find another way to exchange keys and it doesn’t have to be NTS. But why not using it, now that it is there? 

Regards,

  Heiko

-- 

Heiko Gerstung 

Managing Director 

Lange Wand 9 

Email: 

Web: 

Connect via LinkedIn: 

 

Von: ntp <[email-masked]> im Auftrag von Daniel Franke <[email-masked]>
Datum: Dienstag, 11. Mai 2021 um 21:40
An: Heiko Gerstung <[email-masked]>
Cc: NTP WG <[email-masked]>
Betreff: Re: [Ntp] A simpler way to secure PTP

On Tue, May 11, 2021 at 3:14 AM Heiko Gerstung <[email-masked]> wrote:

Amplification is definitely worth fixing, but ISTM this should be orthogonal to the NTS effort. You don't need message authentication for that, you just need the client to prove (and maybe occasionally re-prove) that it's able to receive packets at a particular IP address. There may be some crypto involved in doing so (a la TCP SYN cookies), but it doesn't have to be related to NTS crypto, and servers shouldn't have to require all their clients to support NTS just to prevent themselves from being exploited for amplification.

---

From: Daniel Franke <[email-masked]>
Date: Wed, 12 May 2021 01:44:00 -0400

On Wed, May 12, 2021, 01:14 Heiko Gerstung <[email-masked]>
wrote:

> that’s why we use the integrated security mechanism for unicast PTP and
> just use the NTS-KE protocol to exchange the required keys for that. Due to
> the fact that the two protocols NTP and PTP work in a completely different
> way, there is not more that can be reused. I agree we could find another
> way to exchange keys and it doesn’t have to be NTS. But why not using it,
> now that it is there?
>
Return-routability checking (what I referred to in my previous message as
SYN-cookie-like schemes but I like the terminology of
https://datatracker.ietf.org/doc/html/draft-tschofenig-tls-dtls-rrc-01)
doesn't require key exchange at all. The only keys involved are held by the
server and no other party. The client just echoes back the opaque blobs
that the server sends it.

---

From: Doug Arnold <[email-masked]>
Date: Wed, 12 May 2021 17:19:06 +0000

Both equipment designers and network operators have asked if we can specify an automated key management mechanism that they already have rather than make them implement a new one.

Doug

From: ntp <[email-masked]> on behalf of Heiko Gerstung <heiko.gerstung=[email-masked]>
Date: Wednesday, May 12, 2021 at 1:15 AM
To: Daniel Franke <[email-masked]>
Cc: NTP WG <[email-masked]>
Subject: Re: [Ntp] A simpler way to secure PTP
Hi Daniel,

Regards,
  Heiko

--
Heiko Gerstung
Managing Director

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

Connect via LinkedIn:

On Tue, May 11, 2021 at 3:14 AM Heiko Gerstung <[email-masked]<mailto:[email-masked]>> wrote:
However, especially unicast PTP is a great traffic amplification tool, maybe one of the biggest traffic amplification machines of all times. And I also believe that it would be great to (re)use the general concepts of NTS to secure the other popular time transfer protocol out there.

---

From: Danny Mayer <[email-masked]>
Date: Wed, 12 May 2021 13:23:58 -0400

Can you provide examples of automated key management solutions that they 
already have so we can see how they could possibly be aligned with NTS?

Danny

On 5/12/21 1:19 PM, Doug Arnold wrote:
>
> Both equipment designers and network operators have asked if we can 
> specify an automated key management mechanism that they already have 
> rather than make them implement a new one.
>
> Doug
>
> *From: *ntp <[email-masked]> on behalf of Heiko Gerstung 
> <heiko.gerstung=[email-masked]>
> *Date: *Wednesday, May 12, 2021 at 1:15 AM
> *To: *Daniel Franke <[email-masked]>
> *Cc: *NTP WG <[email-masked]>
> that’s why we use the integrated security mechanism for unicast PTP 
> and just use the NTS-KE protocol to exchange the required keys for 
> that. Due to the fact that the two protocols NTP and PTP work in a 
> completely different way, there is not more that can be reused. I 
> agree we could find another way to exchange keys and it doesn’t have 
> to be NTS. But why not using it, now that it is there?
>
> Regards,
>
>   Heiko
>
>
> -- 
>
> Heiko Gerstung
>
> Managing Director
>
> [email-masked] <mailto:[email-masked]>
>
> Web:
>
> Deutsch https://www.meinberg.de <https://www.meinberg.de>
>
> English https://www.meinbergglobal.com <https://www.meinbergglobal.com>
>
> https://blog.meinbergglobal.com <https://blog.meinbergglobal.com>
>
> Connect via LinkedIn:
>
> <https://www.linkedin.com/in/heikogerstung>
>
> *Von: *ntp <[email-masked]> im Auftrag von Daniel Franke 
> <[email-masked]>
> *Datum: *Dienstag, 11. Mai 2021 um 21:40
> *An: *Heiko Gerstung <[email-masked]>
> *Cc: *NTP WG <[email-masked]>
> *Betreff: *Re: [Ntp] A simpler way to secure PTP
>
> On Tue, May 11, 2021 at 3:14 AM Heiko Gerstung 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     However, especially unicast PTP is a great traffic amplification
>     tool, maybe one of the biggest traffic amplification machines of
>     all times. And I also believe that it would be great to (re)use
>     the general concepts of NTS to secure the other popular time
>     transfer protocol out there.
>
> orthogonal to the NTS effort. You don't need message authentication 
> for that, you just need the client to prove (and maybe occasionally 
> re-prove) that it's able to receive packets at a particular IP 
> address. There may be some crypto involved in doing so (a la TCP SYN 
> cookies), but it doesn't have to be related to NTS crypto, and servers 
> shouldn't have to require all their clients to support NTS just to 
> prevent themselves from being exploited for amplification.
>
> _______________________________________________ ntp mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/ntp
>
>

---

From: Doug Arnold <[email-masked]>
Date: Wed, 12 May 2021 17:55:33 +0000

One example is NTS, since most networks that include PTP also include NTP.

I think that the important part is the underlying mechanism for establishing a secure channel for key distribution.  That is where most of the complexity is.  Nearly everyone implements TLS, at least to facilitate https.

Some implement IPsec.  For example the power industry uses GDOI key management, which is built on IPsec.

Doug

From: Danny Mayer <[email-masked]>
Date: Wednesday, May 12, 2021 at 1:24 PM
To: Doug Arnold <[email-masked]>, Heiko Gerstung <[email-masked]>, Daniel Franke <[email-masked]>
Cc: NTP WG <[email-masked]>
Subject: Re: [Ntp] A simpler way to secure PTP

Can you provide examples of automated key management solutions that they already have so we can see how they could possibly be aligned with NTS?

Danny

Doug

From: ntp <[email-masked]><mailto:[email-masked]> on behalf of Heiko Gerstung <heiko.gerstung=[email-masked]><mailto:heiko.gerstung=[email-masked]>
Date: Wednesday, May 12, 2021 at 1:15 AM
To: Daniel Franke <[email-masked]><mailto:[email-masked]>
Cc: NTP WG <[email-masked]><mailto:[email-masked]>
Subject: Re: [Ntp] A simpler way to secure PTP
Hi Daniel,

Regards,
  Heiko

--
Heiko Gerstung
Managing Director

Email:

Connect via LinkedIn:

Von: ntp <[email-masked]><mailto:[email-masked]> im Auftrag von Daniel Franke <[email-masked]><mailto:[email-masked]>
Datum: Dienstag, 11. Mai 2021 um 21:40
An: Heiko Gerstung <[email-masked]><mailto:[email-masked]>
Cc: NTP WG <[email-masked]><mailto:[email-masked]>
Betreff: Re: [Ntp] A simpler way to secure PTP

Amplification is definitely worth fixing, but ISTM this should be orthogonal to the NTS effort. You don't need message authentication for that, you just need the client to prove (and maybe occasionally re-prove) that it's able to receive packets at a particular IP address. There may be some crypto involved in doing so (a la TCP SYN cookies), but it doesn't have to be related to NTS crypto, and servers shouldn't have to require all their clients to support NTS just to prevent themselves from being exploited for amplification.
_______________________________________________ ntp mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/ntp

ntp mailing list

[email-masked]<mailto:[email-masked]>