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

[Daniel Franke <[e-mail]>]

On Fri, May 28, 2021 at 3:33 AM Heiko Gerstung
<[e-mail]> wrote:
> sorry for top-posting, I try to summarize your arguments in this discussion (and please correct me if I misunderstood something):
>
> You object adopting the draft that my colleagues and I submitted because:
> 1) you expect that working on this will require a lot of work for a lot of people
> 2) you think that using NTS4NTP in combination with Unicast PTP can provide a solution to the problems we want to solve with NTS4UPTP
> 3) you think that 2) is true because PTP could not guarantee a higher level of time accuracy in any network, mainly due to the fact that you consider RTT as the limiting factor and because there is no way to defend RTT against a MITM that is capable of delaying packets
> 4) you assume that because of 3) any user with a requirement that can only be fulfilled with PTP has to physically secure their network anyway to be protected against delay attacks and therefore there is no point in securing unicast PTP against any other security threats and types of attacks
>
> 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.

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:

1. Are there goals beyond protecting the integrity of time
synchronization that NTS4UPTP can serve but hybrid NTS4NTP/PTP can't?

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?

Question 1 is what I already raised upthread when I mentioned
anti-amplification, protecting management functions, etc.

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