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

Miroslav Lichvar <> Tue, 01 June 2021 09:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B5D8F3A0E91 for <>; Tue, 1 Jun 2021 02:47:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.495
X-Spam-Status: No, score=-3.495 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fHNBB1bnnqpS for <>; Tue, 1 Jun 2021 02:47:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 52B0B3A0E93 for <>; Tue, 1 Jun 2021 02:47:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20190719; t=1622540851; 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=WMEBGPceuadXMAZeIpoo2466CbtycgXQ9BlmZjZM60M=; b=AgUVRf9L5y4XINhPIgajva8+Z+iAUGGIm++nhjIIxhdBBHf6Ji2JHdmCDHsaiDEBf6iYlb 5IR7Zxmf0sN+jbh/7i3GxstxErSH/Xi20w1d8fejSCcLj5VJHqcJhGnTVTpyqp//dRcwsg 1vl5KoM33ibdHL1PwM0ne5gKUqmkfjQ=
Received: from ( []) (Using TLS) by with ESMTP id us-mta-18-dPPWSfaCPHu01T-9-dPWSg-1; Tue, 01 Jun 2021 05:47:28 -0400
X-MC-Unique: dPPWSfaCPHu01T-9-dPWSg-1
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DF3B2107ACC7; Tue, 1 Jun 2021 09:47:26 +0000 (UTC)
Received: from localhost ( []) by (Postfix) with ESMTPS id 338FA5D9D0; Tue, 1 Jun 2021 09:47:25 +0000 (UTC)
Date: Tue, 1 Jun 2021 11:47:24 +0200
From: Miroslav Lichvar <>
To: Heiko Gerstung <>
Cc: "" <>
Message-ID: <YLYCLIEA4/unB6/5@localhost>
References: <>
MIME-Version: 1.0
In-Reply-To: <>
X-Scanned-By: MIMEDefang 2.79 on
Authentication-Results:; auth=pass smtp.auth=CUSA124A263
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Archived-At: <>
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Jun 2021 09:47:39 -0000

On Wed, May 26, 2021 at 10:31:22AM +0200, Heiko Gerstung wrote:
> I just submitted the latest revision of our NTS for Unicast PTP draft (-02) which you can find here:

Here are my thoughts.

I'm missing some background of the draft. What is the issue of the
solutions described in IEEE1588, like authentication with manually
distributed symmetric keys and security mechanisms implemented at
lower layers like MACsec and IPsec, that this draft is supposed to

In NTP, NTS is mainly about scaling to large numbers of clients and
privacy. None of that applies to the PTP unicast mode. Due to the
infinite amplification factor and susceptibility to DoS attacks
clients have to be authorized, so I think even the need of public-key
crypto should be explained. Is it supposed to make management of PTP
in a network easier or more secure by distributing certificates
instead of symmetric keys?

I'm missing some description on whether/how this is supposed to work
with transparent clocks. In the IEEE1588 terms, is the correction
field considered mutable?

As you already have to keep a client-specific state, I'd say an
obvious question is why not use an existing application payload
security protocol like DTLS? The draft would basically turn into
"Exchange PTP messages over DTLS on ports X and Y".

If you needed to support transparent clocks and/or keep compatibility
with some existing hardware than can timestamp only specific messages
on the standard PTP event port, you could use DTLS only for general
messages and add a single TLV to get the key needed for authentication
of event messages. I think that would still be easier to implement
(using an existing DTLS implementation) and have a much simpler
specification than what you are currently proposing.

As for that issue with detecting delay attacks that Daniel brought up,
I think that might be better to have its own draft as it applies to
all PTP modes and all security mechanisms, even those at lower layers,
if the existing documents (e.g. IEEE1588 and RFC 7384) are not

Miroslav Lichvar