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

Heiko Gerstung <heiko.gerstung@meinberg.de> Tue, 01 June 2021 09:28 UTC

Return-Path: <heiko.gerstung@meinberg.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DFB3A0DC6 for <ntp@ietfa.amsl.com>; Tue, 1 Jun 2021 02:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=meinberg.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wG3m7LNgTvJB for <ntp@ietfa.amsl.com>; Tue, 1 Jun 2021 02:28:35 -0700 (PDT)
Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27ED33A0DCB for <ntp@ietf.org>; Tue, 1 Jun 2021 02:28:34 -0700 (PDT)
Received: from seppmail.py.meinberg.de (unknown [193.158.22.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id 4FA0571C0D82; Tue, 1 Jun 2021 11:28:32 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=dkim; t=1622539712; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8dDnC5sevfSDOrLC+5alO3zgejgWw+UetbFS003YzAI=; b=Cg+cK30x9b30OQVPea2WVaFg6QKpUFzhqWeGxEcy9/RLKipzikKx2Yn90HAsuBOSs796fm bW63Hwtf6h7IiSTfOhiwiINbRJ3ok0WD0c9FSIPvmpvFGQnIUhLiMyYQuzYtCeddtOCIG+ +6rSn3HROHeHBlX7btKpCzVAESu+zCJ23cNrJwX8WyjJ29vTh6CkW6K9rtgqUuAdijcc/C tB3BMNW34l6Hge/SpHsgjE08uKE3kU5hrRTvPpMwKLfRlZD5y9dLtOJUyMyPRLNIOOxezA tNHKbfhsnrKy0jjRoI4XM2LDvkztgQ+/2k/LhjXsNBNl6xsge9vNopAPkLzokg==
Received: from srv-kerioconnect.py.meinberg.de (srv-kerioconnect.py.meinberg.de [172.16.3.65]) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by seppmail.py.meinberg.de (Postfix) with ESMTPS; Tue, 1 Jun 2021 11:28:31 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.49.21050901
Date: Tue, 1 Jun 2021 11:28:29 +0200
Message-ID: <1B276A19-C8BC-488A-B999-5066146403EB@meinberg.de>
Thread-Topic: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
References: <5F0AB4A8-30FB-4EE4-904C-BCC2CDFCA552@meinberg.de> <CAJm83bA=uQb05KMtUJN_qk0J65eaa1Av5OBatrN4mAk3dPC11Q@mail.gmail.com> <D1556106-7B75-48B2-962C-BEDF035DDA26@meinberg.de> <CAJm83bDhGyd-au6+h0U0jaLVLSkiKY_pKDQCcLiSY09dPP5qAQ@mail.gmail.com> <024470C1-E225-4FF8-AFD0-FD6A6CEF48CB@meinberg.de> <CAJm83bDOc+84AV__CnpMHoRHTDftKAgMhS52jhTPkG-g-ZUzag@mail.gmail.com> <A15ACFA0-B9E1-4F60-B76B-7C2A9146F5D7@meinberg.de> <CAJm83bB5M74-Xfgr53-5iCfmeeRC-wV8a+16UK8-D5VgNR8_5Q@mail.gmail.com>
In-Reply-To: <CAJm83bB5M74-Xfgr53-5iCfmeeRC-wV8a+16UK8-D5VgNR8_5Q@mail.gmail.com>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+MTY2Mzc3M2Q1NjU3YjNiNw==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: Daniel Franke <dfoxfranke@gmail.com>
Cc: "ntp@ietf.org" <ntp@ietf.org>, Doug Arnold <doug.arnold@meinberg-usa.com>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----0DAC1A470844CE734ADAFC32039045C1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/9uUr7Ovps_GQpgiKO9y8OoPfGe0>
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Jun 2021 09:28:42 -0000

> Am 28.05.21, 15:26 schrieb "ntp im Auftrag von Daniel Franke" <ntp-bounces@ietf.
> org im Auftrag von dfoxfranke@gmail.com>gt;:
> 
> On Fri, May 28, 2021 at 3:33 AM Heiko Gerstung
> <heiko.gerstung@meinberg.de> 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: 
heiko.gerstung@meinberg.de
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