Re: [Ntp] A simpler way to secure PTP

Miroslav Lichvar <mlichvar@redhat.com> Mon, 10 May 2021 12:46 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 4A1823A1B86 for <ntp@ietfa.amsl.com>; Mon, 10 May 2021 05:46:25 -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 d7WmPMggJo8Z for <ntp@ietfa.amsl.com>; Mon, 10 May 2021 05:46:22 -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 0A8CD3A1BBF for <ntp@ietf.org>; Mon, 10 May 2021 05:46:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620650781; 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=r5Wa2QuaYr03o8YGGBWcQH2U3eyCJ8x8YBseanrx3Vo=; b=MSbgDj+98jKr9KElK/A4b0f9OU+QWdze1/Uae9yswrkQqzPeZJbTvM5g5VYZmLfg0vBkK0 z8tU5OYJh3VxUXMW2tUX/2eqYfdK2NDpfIdVYkAXdWQrRqOiGNPJI5xNreLaxfAwEOMWb9 /RzR1lZs8UcCq0++4fFkvkCQrjsS87U=
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-241-254o2XhQPmW7_sDldc2vjw-1; Mon, 10 May 2021 08:46:17 -0400
X-MC-Unique: 254o2XhQPmW7_sDldc2vjw-1
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 58AE61922023; Mon, 10 May 2021 12:46:16 +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 B0FDA60CC5; Mon, 10 May 2021 12:46:15 +0000 (UTC)
Date: Mon, 10 May 2021 14:46:14 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Daniel Franke <dfoxfranke@gmail.com>
Cc: NTP WG <ntp@ietf.org>
Message-ID: <YJkrFjnRPJJHz9da@localhost>
References: <CAJm83bCpio5WwigY6nc9Y0Gt_XSdjUV=sHUz04dOQ0zELPwZxw@mail.gmail.com>
MIME-Version: 1.0
In-Reply-To: <CAJm83bCpio5WwigY6nc9Y0Gt_XSdjUV=sHUz04dOQ0zELPwZxw@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
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="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/cHlEE1_td_k5boBT2aKSmWzCY6w>
Subject: Re: [Ntp] A simpler way to secure PTP
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: Mon, 10 May 2021 12:46:33 -0000

On Sat, May 08, 2021 at 04:53:06PM -0400, Daniel Franke wrote:
> The trick is: run NTS-secured NTP and regular, unauthenticated PTP
> side-by-side. Do not use the NTP responses to set the clock; instead, use
> them only to establish maximum error bounds on the current time, and then
> clamp all PTP messages to within those bounds.

Makes sense to me.

In a more general approach, this is already possible with some
existing PTP and NTP implementations like linuxptp and chrony. PTP can
be specified as an untrusted reference clock, which will be used for
synchronization only if it agrees with trusted NTS-secured NTP
source(s). We recommend combining (multiple) PTP and NTP time sources
for better accuracy, resiliency, and security.

-- 
Miroslav Lichvar