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

Heiko Gerstung <heiko.gerstung@meinberg.de> Thu, 27 May 2021 15:31 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 457A13A1349 for <ntp@ietfa.amsl.com>; Thu, 27 May 2021 08:31:48 -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 yqJF7zSWXroW for <ntp@ietfa.amsl.com>; Thu, 27 May 2021 08:31:43 -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 5AE233A1352 for <ntp@ietf.org>; Thu, 27 May 2021 08:31:42 -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 E489571C06FB; Thu, 27 May 2021 17:31:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=dkim; t=1622129500; 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=EA3xsd3hbLj9XVTc5Ub1DuEslQrjnHfJR0UT47a9a1M=; b=FW5Rzv9cNKtTuqbBcN0n5i6C+EkZDJh2knUxbStKGOYASQHHfg1LBE5158+wsHaiZxUP8M xy7P1msoIwt1xo0Iju77jNAH71UT38xVgZ9HOj6geCwZtrBdDJP4yVxdomD0kVXXyAKBC+ /EkNdDZhfuv67FvHEfQYnrTFgQjCw+FvuS84hQ8OIwkNPokogzMnkJYl6dEswwuRs1/4i3 5hsuyNm6/OyPgtYH9JXM9y3y0K8Tqy0NQ8NFT5oNeQc3AcTply4t2uQODR2Oqoa/899sa1 aCSeSVtGLBUJJHo06J5CeC7wBloWTG67EYUDVuXdRIui42D/opGSmGfNZ9aq5A==
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; Thu, 27 May 2021 17:31:40 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.49.21050901
Date: Thu, 27 May 2021 17:31:39 +0200
Message-ID: <FDD7A2E9-74FE-4E8C-88AB-1399869D5F3F@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> <YK+3obGkBjSf5Azb@localhost>
In-Reply-To: <YK+3obGkBjSf5Azb@localhost>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+MTY2Mzc3M2Q1NjU3YjNiNw==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: Miroslav Lichvar <mlichvar@redhat.com>, Daniel Franke <dfoxfranke@gmail.com>
Cc: "ntp@ietf.org" <ntp@ietf.org>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----694B1D8081B771AD11F73FE1F0B5EA31"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/S2JnzOx6t5m1FJnp70H8xewEqVE>
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: Thu, 27 May 2021 15:31:48 -0000

> On Thu, May 27, 2021 at 09:19:32AM -0400, Daniel Franke wrote:
>> Under adversarial conditions, the potential error of my approach is
>> ±half-RTT, ± some other miscellaneous error terms that don't amount to
>> much by comparison. Without the fixes I've suggested, the potential
>> error of your approach is unbounded. With these fixes, it again
>> becomes the same as mine.
> 
> In a network that has a full hardware PTP support, but not NTP
> support, the delay measured by PTP would be smaller than NTP. Whether
> that allows a MITM attacker to do more interesting things, I'm not
> sure. 

It will most probably allow an attacker to disrupt or degrade the sync service required for a critical application that relies on PTP and its accuracy. 

> I think they can always simply stop forwarding the traffic and
> let the clocks drift away on their own, even if they don't bother to
> mess with their frequency by shifting delays in opposite directions.

I agree, there is nothing you can put into a protocol that can protect against a MITM dropping traffic or delaying it to a point where the delay(-asymmetry) has a negative impact on the application. That did not stop the WG to work on NTS4NTP. It is an attack scenario that cannot be mitigated on this level, but at least clients would notice that sync packets are not coming through, and as Daniel explained, they can also spot an increased RTT and could send alarms etc. 

>> If you want to change my mind about this, I suggest you try convincing
>> me that PTP has functions that are auxiliary to time synchronization
>> that still need securing. Can an attacker do harm to an unsecured PTP
>> deployment in ways other than just desynchronizing clocks?
> 
> There is quite a lot of data in the announce message used for various
> purposes, which might have an impact further down the synchronization
> chain. For example a wrong TAI-UTC offset wouldn't do anything to a
> boundary clock keeping time in TAI, but it would have an impact on
> leaf clients converting to UTC.

That is correct, this is why the draft protects announce messages just like it protects sync and delay req/resp messsages. Any modification of a PTP packet in transmit by an attacker has the potential to cause harm and could degrade the sync service that is vital for a critical application like a power grid, a telecommunications network or an air traffic radar system. 

I therefore kindly ask you and the other WG members to support adoption of the draft. The team of authors is willing to put all the resources into finalizing the draft in the shortest possible timeframe. 

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