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

Miroslav Lichvar <mlichvar@redhat.com> Mon, 07 June 2021 08:45 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 3954A3A3CE9 for <ntp@ietfa.amsl.com>; Mon, 7 Jun 2021 01:45:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level:
X-Spam-Status: No, score=-2.796 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 2EEHwrZmEqUQ for <ntp@ietfa.amsl.com>; Mon, 7 Jun 2021 01:45:04 -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 80FE43A3CE4 for <ntp@ietf.org>; Mon, 7 Jun 2021 01:45:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623055502; 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=vIpy4oHpusxbusEoOpo/yxfyp61aVd13Wd/56zDlcmk=; b=V/pivfuBvfJJyC3+K3A5WbQ6CxT/Gi2yH1Radk338rC4vUgoBoz+YEzH+ArXWiFZcjv9Ur 3pToW4uQ8gJ1O9jg9FqXrhnuS/DaWxr2CgSGxVoDD3VinhUoSo8vrxcqJSunQ7UHrq0Hi5 0deS0xs5IQqJ855mdfNIjpX6siszwVQ=
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-kmswWwwhOt-RvX2brVXefw-1; Mon, 07 Jun 2021 04:45:01 -0400
X-MC-Unique: kmswWwwhOt-RvX2brVXefw-1
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3AC17800D55; Mon, 7 Jun 2021 08:44:59 +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 6C8E55D9DC; Mon, 7 Jun 2021 08:44:58 +0000 (UTC)
Date: Mon, 7 Jun 2021 10:44:56 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Doug Arnold <doug.arnold=40meinberg-usa.com@dmarc.ietf.org>
Cc: Heiko Gerstung <heiko.gerstung=40meinberg.de@dmarc.ietf.org>, "ntp@ietf.org" <ntp@ietf.org>
Message-ID: <YL3ciGhXI3hnI8zr@localhost>
References: <YLYheZYTSflAdlrF@localhost> <CEB3F4AA-E318-4540-BD6C-4437E3F5F58A@meinberg.de> <YLY3f2/5k1Hjebf7@localhost> <7167BC2B-1889-4DF5-AF7C-BAAAB3586841@meinberg.de> <YLZVS4jwGOnMIk6g@localhost> <24DF9BF2-3072-4152-80D6-9F10D53A59AF@meinberg.de> <YLeFyqZp6bZY9nY9@localhost> <B5F7602A-B084-4B21-9EB2-D25AB030E1EA@meinberg.de> <YLiFXYPBOCIsCHDq@localhost> <AM7PR02MB57652059FC2F56AB15D7D9ADCF3B9@AM7PR02MB5765.eurprd02.prod.outlook.com>
MIME-Version: 1.0
In-Reply-To: <AM7PR02MB57652059FC2F56AB15D7D9ADCF3B9@AM7PR02MB5765.eurprd02.prod.outlook.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
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/DvmWYRHjxEyOtSdgYPzWOczsUDk>
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: Mon, 07 Jun 2021 08:45:08 -0000

On Fri, Jun 04, 2021 at 05:08:24PM +0000, Doug Arnold wrote:
> Miroslav identified three issues that are under discussion:
> - Does it make sense for PTP to have a public-key based
>   authentication?
> 
> A big weakness of PTP is server impersonation.  So PTP needs a security mechanism that requires that a PTP node get authenticated before it can get keys.  Also the feedback I get from both equipment manufacturers and network operators is: no new key management mechanism.  So PTP security should be based on something already in common usage, such as TLS, or IPsec.

IPsec is mentioned in IEEE1588, so I guess it is already used to
secure PTP, at least on hardware that doesn't have timestamping
limited to PTP packets.

> - Does it make sense to reuse something from NTS4NTP?
> 
> All of the commercial time server companies make appliances that do both PTP and NTP.  So the more they can have in common the better.  Most customers that have PTP running, also have NTP running at the same time.  So it will be helpful for network operators to learn about the security if it is similar, even if it just the terminology, and concepts in the standard.

For a vendor selling primary time servers it makes sense to support
everything there is to support, but their number is normally much
smaller than the number of secondary servers and clients. A network
operator might want to limit the number of protocols used. If the
network can support PTP (with boundary clocks or transparent clocks),
it makes sense to use secured PTP. If it cannot support PTP, it's
better to use NTP.

-- 
Miroslav Lichvar