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

Miroslav Lichvar <> Tue, 01 June 2021 12:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73B9B3A14FB for <>; Tue, 1 Jun 2021 05:01:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.795
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mlXv8NwcpAI0 for <>; Tue, 1 Jun 2021 05:01:18 -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 472E63A14F6 for <>; Tue, 1 Jun 2021 05:01:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20190719; t=1622548876; 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=mLGensSXYU/Wd4IwciJKYl7A9amNvqGslBIkHA/i1wE=; b=Zn1nVO79Zd7D6raNYNgeoYIZkXwnu2FwHWEAvKbC5ceDCsldjB1pB+Vch//7AdxlgiNqIo BhOqRM8L9KIT0NAOjx2wXx8OrFqiSZpNG8Xm3fA/h2dhSCsKAx7HZ9VRxXdZSZPEx2z1xj f9+GAfJQ3AkSspd2sNuGpxt+0390izc=
Received: from ( []) (Using TLS) by with ESMTP id us-mta-139-xQ8PvYkGO5qrtt7zEwF2Pg-1; Tue, 01 Jun 2021 08:01:14 -0400
X-MC-Unique: xQ8PvYkGO5qrtt7zEwF2Pg-1
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 362CB107ACF3; Tue, 1 Jun 2021 12:01:00 +0000 (UTC)
Received: from localhost ( []) by (Postfix) with ESMTPS id 896CD100164C; Tue, 1 Jun 2021 12:00:59 +0000 (UTC)
Date: Tue, 1 Jun 2021 14:00:57 +0200
From: Miroslav Lichvar <>
To: Heiko Gerstung <>
Cc: "" <>
Message-ID: <YLYheZYTSflAdlrF@localhost>
References: <> <YLYCLIEA4/unB6/5@localhost> <>
MIME-Version: 1.0
In-Reply-To: <>
X-Scanned-By: MIMEDefang 2.84 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 12:01:21 -0000

On Tue, Jun 01, 2021 at 01:14:57PM +0200, Heiko Gerstung wrote:
> First of all: manually distributing symmetric keys is something that is already foreseen and possible with PTP, using the integrated security as described in IEEE1588. However, this does not address the potential amplification and replay attacks as described in the draft. Plus, a manual distribution of symmetric keys is only feasible until a certain number of clients. Keys have to be refreshed in a certain interval to avoid that someone not trustworthy found a way to obtain the keys, and distribution requires to establish a secure way of distributing the keys. 

Great. Please add that to the draft.

> Second point: why not using IPsec or MACsec? Here the problem is the hardware timestamping mechanism. A PTP timestamping engine typically sits in the PHY or the MAC of the network chip or, in 2-step implementations, very often between those two. The timestamper looks out for PTP event messages passing by and it takes a timestamp when it detected a packet

As you probably know, not all NICs do that. Some can provide a
timestamp with each received frame at no cost except that extra bit of
data that needs to be received over PCIe etc. My understanding is that
this is the trend for future as there are other applications, not
related to synchronization of clocks, that need accurately timestamped

> > 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?
> Transparent clocks are a nightmare from a security standpoint and they are typically not used in those networks that are using unicast PTP. Additionally, although the concept of transparent clocks has been introduced in IEEE1588-2008, I do not know any commercially available router or switch that supports acting as a unicast PTP transparent clock. 

The network devices don't need to have the keys if the correction
field is excluded from the ICV calculation (as allowed by the PTP
spec). The security impact is not that too different from a delay
attack. If you don't want to support that, that's ok, but it needs to
be explained in the draft.

> > 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.
> It still would not address the amplification attack scenario and keeps the door wide open for abusing unicast PTP for replay based amplification DDoS scenarios. It would be simpler, but with our more complex approach we can address those security problems, too. 

Can you please elaborate? My (limited) understanding of DTLS is that
it would address the attacks. It has a 48-bit sequence number to
protect against replays and client authentication comes from TLS.

Miroslav Lichvar