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

Heiko Gerstung <> Tue, 01 June 2021 12:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0F533A169D for <>; Tue, 1 Jun 2021 05:48:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JjaIURMoxzJ5 for <>; Tue, 1 Jun 2021 05:48:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB94F3A16D8 for <>; Tue, 1 Jun 2021 05:48:37 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id E5F3D71C0B07; Tue, 1 Jun 2021 14:48:34 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1622551714; 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=+53e3nNnoCDV0h/+9X2JGPElHp0AUV91SMTRWJoiOxk=; b=nQidzmdxmIdL2Bj0DAIlvkz74b9alP3jPqFN9ghIBnwF+GhLNF3HnURDYfIAtNI6XOsuCA +tWlxkZp9VBJ3Ylw37Le5IFrJrdf+tCvri1X6Pjvv4KjpLePz9qD4PrEXdWiv2yavhS346 fkvpfKpdUxWGoiQ7xjkN4JyaWaDuDDm8ZP4MwQZtDJtVrYy/WzvWaJa84YEGyMvScaDuij ylZaWY+N4zql1FKT3bcv39vvuieq1xN2UGBn5U1vFYGP5kX7tW8vComOkEyPlC7kNqJTPT BRpACQRtHICOLTmdd0wAQ9EHPV+6cP0akW1l11DbFp8tGmYJTjas4K8fOjuL0A==
Received: from ( []) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Tue, 1 Jun 2021 14:48:34 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.49.21050901
Date: Tue, 1 Jun 2021 14:48:32 +0200
Message-ID: <>
Thread-Topic: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
References: <> <YLYCLIEA4/unB6/5@localhost> <> <YLYheZYTSflAdlrF@localhost>
In-Reply-To: <YLYheZYTSflAdlrF@localhost>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+MTY2Mzc3M2Q1NjU3YjNiNw==
From: Heiko Gerstung <>
To: Miroslav Lichvar <>
Cc: "" <>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----F03107F40CCAB1377ED7D9C825369AD8"
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:48:44 -0000

> Am 01.06.21, 14:01 schrieb "Miroslav Lichvar" <>om>:
> On Tue, Jun 01, 2021 at 01:14:57PM +0200, Heiko Gerstung wrote:
>> First of all: manually distributing symmetric keys is something that is al
>> ready foreseen and possible with PTP, using the integrated security as described
>> in IEEE1588. However, this does not address the potential amplification and rep
>> lay 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 refresh
>> ed in a certain interval to avoid that someone not trustworthy found a way to ob
>> tain the keys, and distribution requires to establish a secure way of distributi
>> ng the keys.
> Great. Please add that to the draft.
I will. 

>> Second point: why not using IPsec or MACsec? Here the problem is the hardw
>> are 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 t
>> akes 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
> packets.

I agree that this is a trend. SO_TIMESTAMP showed us the way on a software level here. However, changing silicon takes time and requires a huge commitment from the NIC manufacturers. I know how long it took to get HW timestamping support for PTP into at least most of the more famous NIC silicon and I will not hold my breath regarding this. 

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

Yes, as I said I would leave protecting the correction field (i.e. supporting TCs) out of the draft, except for a short paragraph documenting this and give a reason why. Happy to add that to the draft and re-submit.

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

I understood that you want to use DTLS to exchange the symmetric keys used to calculate the ICV of the unencrypted event messages. This unfortunately does not address the replay/amplification vulnerability of the unicast negotiation protocol itself, it just protects against replaying the DTLS messages. I most probably know much less about DTLS than you, Miroslav. For example, I do not know whether this requires asymmetric cryptography in every message or just at the beginning in the handshake. However, I am pretty sure that DTLS can be used to securely exchange the symmetric keys instead of using TLS in the NTS-KE phase. 

As I tried to explain earlier, our intention with this draft was to stay close to NTS4NTP to enable implementors to re-use code and allow users to combine the required infrastructure for NTS4NTP and NTS4UPTP. I fully agree that other protocols and security mechanisms would do the trick as well, but I believe that the name "Network Time Security" indicates that it has a good chance of being a better fit for securing a network time sync protocol. And, according to our research and our experience regarding network time synchronization, we came to the conclusion that this is the case for unicast PTP. 

We believe that our draft provides a solution to most of the security challenges for unicast PTP. It protects against packet manipulation from on-path and off-path adversaries. It supports authentication, identification, integrity and consistency, does not affect performance at all and is fully compatible with IEEE1588-2019 and its defined integrated security protocol. I am very sure we overlooked something or missed a point or we might have a flaw in one or more of our concepts and I would really like the WG and its members with all the security-expertise-firepower to review the draft and find those points in order to address them properly. If someone wants to create a proposal based on DTLS instead of NTS, I am happy to review it and compare it against our document.  If it turns out to be more efficient to implement and operate or is somehow more beneficial to implementors and end users, I am more than happy to support WG adoption of it and work on it. 

Best Regards,

Heiko Gerstung 
Managing Director 
MEINBERG® Funkuhren GmbH & Co. KG 
Lange Wand 9 
D-31812 Bad Pyrmont, Germany 
Phone: +49 (0)5281 9309-404 
Fax: +49 (0)5281 9309-9404 
Amtsgericht Hannover 17HRA 100322 
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 
Do not miss our Time Synchronization Blog:
Connect via LinkedIn: