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

Miroslav Lichvar <mlichvar@redhat.com> Thu, 27 May 2021 15:16 UTC

Return-Path: <mlichvar@redhat.com>
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 BFCA53A135D for <ntp@ietfa.amsl.com>; Thu, 27 May 2021 08:16:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Level:
X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
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 P9ah55bPNaiz for <ntp@ietfa.amsl.com>; Thu, 27 May 2021 08:16:28 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB4BA3A1369 for <ntp@ietf.org>; Thu, 27 May 2021 08:15:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622128552; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jUu6dZ3fiT0QLMynedctKevM8Cgjz8KF+kmqjH6KWZA=; b=H0Dp1zcKtdqhOjQi11CcfPpnXIfAduqRenWwEpdNLmK0UgtktRfSGNKFPrLAAxXDlsV8H8 tSZo0ardiYYa4rJhThM7gn4k65TtTlXl5kOI6plI9BW81tz7nz7qK1QQLVk15Yi7iYPnRx qd0TyGD6z5j4l1lpIE7MDHh/1xunRRI=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-3-phCFin2gO2Ggl3wyVmLJTg-1; Thu, 27 May 2021 11:15:50 -0400
X-MC-Unique: phCFin2gO2Ggl3wyVmLJTg-1
Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B7379107ACCA; Thu, 27 May 2021 15:15:48 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A353019C66; Thu, 27 May 2021 15:15:46 +0000 (UTC)
Date: Thu, 27 May 2021 17:15:45 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Daniel Franke <dfoxfranke@gmail.com>
Cc: Heiko Gerstung <heiko.gerstung@meinberg.de>, "ntp@ietf.org" <ntp@ietf.org>
Message-ID: <YK+3obGkBjSf5Azb@localhost>
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>
MIME-Version: 1.0
In-Reply-To: <CAJm83bDhGyd-au6+h0U0jaLVLSkiKY_pKDQCcLiSY09dPP5qAQ@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlichvar@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/oWY4XuBLTsxoxB-JuAiyFvzpd40>
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:16:31 -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. 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.

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

-- 
Miroslav Lichvar