Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

From: Heiko Gerstung <[email-masked]>
Date: Tue, 1 Jun 2021 11:28:29 +0200

> Am 28.05.21, 15:26 schrieb "ntp im Auftrag von Daniel Franke" <ntp-bounces@ietf.
> org im Auftrag von [email-masked]>:
> 
> On Fri, May 28, 2021 at 3:33 AM Heiko Gerstung
> <[email-masked]> wrote:
>> [...]
>> Is that correct? Did I miss something?
> 
> You have the gist of it, but there's a nit about (2) and an important
> bit of nuance about (4).

> On (2), the hybrid NTS4NTP/PTP solution isn't limited to unicast PTP.
> It works just as well with broadcast/multicast. Of course the NTS4NTP
> part still has to be unicast NTP.

Understood. I actually believe that for multicast PTP (there is no broadcast PTP) this might be a better fit than for unicast, simply because multicast PTP does not implement the negotiation and contract based approach of unicast PTP and is used more often in smaller, private networks. Multicast PTP does not require the PTP server to be stateful in regards to a client either. It is, in fact, a quite different protocol to some regard. Multicast PTP is not an alternative in a lot of applications and networks, including but not limited to the Internet.

> On (4): "security threats and types of attacks" is kind of vague. I'd
> rather think of this in terms of goals and adversary powers, and this
> leads to two questions that I'm open to being persuaded on:
Excuse my vagueness here, I did not want to repeat all the scenarios and details that we described in our draft here ;-) ..

Talking with our users I found it always easier to explain why a protocol is doing this or that when an actual and real-world attack scenario is given as a background. It is of course important to explain the goals and the potential adversary powers in addition to that, because you ultimately will not be able to provide a complete list of all possible attack scenarios (and/or you may not want to do that either, after all the bad guys should have to come up with new ideas on their own). 

> 1. Are there goals beyond protecting the integrity of time
> synchronization that NTS4UPTP can serve but hybrid NTS4NTP/PTP can't?
Very easy: with your proposal you cannot protect someone abusing unicast PTP as a ginormous amplification machine. Plus, for multicast PTP you will not be able to protect the BMCA, i.e. any attacker can seriously disrupt PTP synchronization in general for all devices in a multicast domain and easily DoS the whole PTP sync service of your network. 

The answer to your question therefore is: yes, an important goal is to avoid that anyone can abuse the sync protocol to carry out attacks against the network and its participants. Not protecting PTP not only means that I cannot rely on being able to use PTP at all (and why should I not revert back to only use NTP in this case). It also allows to abuse it to carry out attacks that have nothing to do with time sync.

> 2. Are there any interesting classes of adversary weaker than the
> standard MitM adversary, from whom NTP4UPTP can provide stronger
> protection than hybrid NTS4NTP /PTP can?
Yes. You can inject packets to carry out replay attacks or amplification attacks with the goal of disrupting any node in the network, even a node that is not interested in time sync and may not even participate in it. 

> Question 1 is what I already raised upthread when I mentioned
> anti-amplification, protecting management functions, etc.
I probably misunderstood your question back then, because you asked about functions that PTP has that are auxiliary to time synchronization and also whether an attacker can do harm to an unsecured PTP deployment in ways other than just desynchronizing clocks. I assumed you were only looking at PTP as a protocol and it did not occur to me that the obvious reason of avoiding that someone abuses PTP to flood an arbitrary number of IP addresses with a large number of unwanted IPv4 messages would not be a good enough reason.

> Question 2 is something I raised in the original thread about hybrid
> NTS4NTP/PTP. Any attacker who is on-path or adjacent to one of the
> endpoints can set itself up as a MitM and therefore conduct delay
> attacks. Off-path attackers, on the other hand, can't read or modify
> legitimate traffic but may be able to inject packets with spoofed
> source addresses. With hybrid NTS4NTP/PTP, such an adversary can
> potentially do just as much damage as a MitM can, injecting SYNC
> messages that fall just inside the window of plausibility and inducing
> a half-RTT error. 

Well no, such an attacker can easily distrupt any service or node on the network, just like an MitM can, but without having to gain access to a central part of the network infrastructure first. The Internet is a great example, trying to get into the network route between a client and a server is most probably pretty hard and requires some effort. Sending one forged packet to the server can be carried out by anyone with a computer and an Internet connection. The same, to some extent, applies to a private but large (e.g. nationwide or global) network of a telecom carrier or power grid operator. 

> With NTS4UPTP, such packets could be rejected
> because the attacker wouldn't be able to forge the MAC tag; an
> off-path attacker isn't capable of moving us from the "normal" case of
> sub-microsecond precision to the "adversarial" case of half-RTT
> precision. However, I don't find this argument compelling enough,
> because in realistic PTP deployments. the problem of off-path
> attackers should already be adequately mitigated by firewalls. Your
> network is very broken if an outside attacker can spoof your PTP
> server's network address and have that spoofed packet make it all the
> way to clients rather than being dropped at your router. You couldn't
> rely on firewalls this way if you were running PTP over the open
> internet, but that's not how people use PTP.
Some people actually do that. And, as Marius already stated, considering a firewall to be the ultimate protection against bad guys is something that my users and I would not agree with. After all, you hopefully use ssh and https in your internal networks, although they are behind a firewall. 

And, a firewall will not help you if an attacker replays a unicast packet with a forged source IP address that is allowed to pass the firewall. Even with a firewall in place I could still cancel the contract of any PTP unicast client by sending a request to cancel the transmission every second. From anywhere on this planet. And there is nothing you could do against this except changing the IP address of the PTP client and adjusting your firewall settings. Not very practical and not very secure.

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

---

From: Heiko Gerstung <[email-masked]>
Date: Tue, 1 Jun 2021 12:27:26 +0200

> Von: ntp <[email-masked]> im Auftrag von <[email-masked]>

> Datum: Montag, 31. Mai 2021 um 17:28

> An: Kai Heine <[email-masked]>, NTP WG <[email-masked]>

> As someone who is also involved in the security subcommittee of the 1588 WG, I f

> eel that it might be important to clarify the following:

> PTP has a method of transporting authentication tags in a TLV field, specified i

> n the current standard version.

> What is "missing" is a key management scheme that enables the use of those secur

> ity TLVs (there are some, but I feel that one based on NTS' methods would be rea

> lly nice to have).

And I would like to add that unicast PTP has no means of protection against someone sending a negotiation request (or cancel) packet with a forged IP address, as the TLV you refer to does not protect the transport header which, in turn, is used by the unicast PTP server to determine the IP address of the requesting client. 

> So far, AFAIK, Heiko's draft is the only document that has actually been propose

> d here.

Martin and Rainer also submitted a draft, well before ours, back in February. You can find it here:

https://datatracker.ietf.org/doc/draft-langer-ntp-nts-for-ptp/

Unlike our draft it also covers multicast PTP and is introducing more significant additions to the NTS-KE phase. It is 69 pages in sizes and a very comprehensive and detailed document, and I definitely believe it is worth discussing it in the WG as well. One motivation for creating NTS4UPTP was that we believe that it is more practical to stay closer to NTS4NTP by reusing as much of the NTS-KE phase as possible, given the differences of NTP and unicast PTP. Plus, securing a multicast protocol requires even more effort IMHO than unicast, after all there was a good reason why NTS4NTP does not cover multicast/broadcast modes of NTP. By focusing on unicast, I am confident that we can get to a standard a lot faster, and I would like to find a way to secure both multicast NTP and PTP in an additional step in the future. 

> I'm sorry, but I haven't read it closely enough to judge its technical merits.

I really would like to start discussing the draft on a technical basis, that is why I would like to see it being adopted by the WG.

> Until then, I believe I support adoption of Heiko's draft (except if there is a

> good argument to be made that we need to look at all candidates first and then c

> hoose one?).

That is a question I would have, too. 

> The approach certainly seems to have enough merit for at least a WG-wide discuss

> ion.

> I also feel that I would like to hear more people's opinions, especially more wh

> o don't have a candidate of their own in this race.

Yes please. And, tbh, I do not really consider this a race or a competition. I would prefer to put all proposals on the table and find a way to combine them and/or divide them into two or more documents which address a separate set of problems/challenges and in the end are complementing each other. 

Regards,

  Heiko

-- 

Heiko Gerstung 

Managing Director 

Lange Wand 9 

Email: 

Web: 

Connect via LinkedIn: