Re: [Ntp] NTS4UPTP draft

Dieter Sibold <> Wed, 02 June 2021 21:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A09A43A1C61 for <>; Wed, 2 Jun 2021 14:40:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 dzCx926Fs-P2 for <>; Wed, 2 Jun 2021 14:40:54 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DDCF03A1C5C for <>; Wed, 2 Jun 2021 14:40:53 -0700 (PDT)
Received: by with SMTP id h3so2166798wmq.3 for <>; Wed, 02 Jun 2021 14:40:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:embedded-html; bh=uV+iot8E4C0P1NiEQLQ6AEnzNOcbTfT4QSHCPDkw4og=; b=ZtXyf/kKWDLkC1OAVWolr8ztWNlPJoJLh14aDmBOJl1cp4L4kX3qx3ovtHNJgIw9z2 MmaTLChypIK1x8rkCfuXOHwsV6G/iaNgANBhQsv5apHxe7FfFRpIOFNE32GUWbBBw0oj 98XE/F6gC7bOUvl3dXHgz4zdnICVW13BuSgUl3RGq2MC5b5XBLAOX7o8can+xd5zpXU2 t1+32j+fA7xwOB9mVJZAMyrK1gDkewEcA8bbfoMrBkfqu7Ulkw+pM06Sum7RcAkg+u/N PT5YBydPnQa8OxmiK1hdXh5mSSSWTPz5Xv379CYhCyjhIqd1EmboZUWmZKKeMzTkJmr0 QzXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding:embedded-html; bh=uV+iot8E4C0P1NiEQLQ6AEnzNOcbTfT4QSHCPDkw4og=; b=YTBkMvOhUaP15Nd9fD1xBtN6n3hVxThKakO/RRTTlHFRoVJV3D3i/6QLnjWwBu5vTz Jdiz3nli83LS5IUIpvbQX7d1jPl5iRh0V2sFkaFN+soTyU7Qz/mntA+tiK6AllhodgTH Mx90B+/+5ijrq616UzN3MKpgr7KFSeKG5pkXv3Mipq1nrg6+C9N9icoWxGUXLtPkFeKB YvDjfBv8k8qYvoSXYuRZmAzFGNV84b6Zj+cDizKyCre5xfVKKlnb24PToFfRn3YC01fA J/g67x04mwCyhxvWVRN+D3JGLCM1VIfDBcxmtvJPODhFzW2Z+LyeD46BGiwZIf5hqhLg D+Lw==
X-Gm-Message-State: AOAM530oRDKSa1llgxgFK29cgL596mfxAQV6n4YfCRG8yB0nmFKmzo92 aQqsGKmzIM2JYQGLnIGVZgcu8rhEzOg=
X-Google-Smtp-Source: ABdhPJw6C7XrjhB2+nAAzBxnfJUGbw7DBhqyKaH3JfRjBNRmDy2H/ePaFDnaQt8QxKMI30YlGTJMnw==
X-Received: by 2002:a7b:cbc2:: with SMTP id n2mr33929322wmi.69.1622670050898; Wed, 02 Jun 2021 14:40:50 -0700 (PDT)
Received: from [] ( [2003:d1:7f13:5e00:e864:95b5:1986:1e87]) by with ESMTPSA id y22sm4652027wma.36.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Jun 2021 14:40:50 -0700 (PDT)
From: "Dieter Sibold" <>
To: "Heiko Gerstung" <>
Cc: "NTP WG" <>
Date: Wed, 02 Jun 2021 23:40:49 +0200
X-Mailer: MailMate (1.14r5757)
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_72CBD36F-5F6B-4E0E-84D6-3B6E5944A29E_="
Content-Transfer-Encoding: 8bit
Embedded-HTML: [{"plain":[2337, 1925], "uuid":"CAB84320-BDEA-422A-ABC9-CA756BD6DAA0"}]
Archived-At: <>
Subject: Re: [Ntp] NTS4UPTP draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Jun 2021 21:40:59 -0000

WG chair hat off!

I think it is common understanding that communication across the 
internet should be protect by security means. It also is common practice 
to protect LAN based communication since experience taught that it is a 
false sense of security to rely only on security gateways to  protect 
against adversaries.

In the past PTP is applied mainly in local networks but today it is 
going to be applied across Internet connection also. From my point of 
view: it is out of question, that an inherent security approach is 
necessary for PTP. Instead, it is necessary to find good arguments for 
not specifying a PTP specific security protocol. Up to now I didn’t 
heard any convincing argument against a PTP specific security approach. 
Hence, I would argue that the two relevant questions are 1) who shall 
specify this approach  and 2) if the working group will be ready to do 
that, which draft should be the basis for this effort?

Who? Basically there is the P1588 wg of IEEE who is currently in charge 
to update  the PTP spec and the NTP wg of IETF who already did work in 
context of PTP (in fact not really the NTP but the TICTOC wg).
- P1588 wg: the member of this group have a lot of elaborated knowledge 
of PTP but their focus and experience are not in the field of security.
- NTP wg: compared to P1588 this wg has less knowledge of PTP. However 
it has better knowledge regarding security protocols and with IETF’s 
security area much more resources in this area too.

Which draft?
Currently, we have three proposals for an PTP security approach. Two 
drafts, one from Heiko and one from Martin and a sketch form Daniel. The 
drafts from Heiko and Martin apply elements of NTS in order to protect 
PTP messages. Both approaches need to extent NTS in order to meet 
requirements specific to PTP. Heiko’s draft focuses on PTP’s unicast 
mode (which is not to be confused with NTP’s message exchange) whereas 
Martin’s draft is more comprehensive and considers all PTP modes. 
Daniel’s proposes to use NTS secured NTP to protect PTP, which is a 
watchdog like approach (certainly, this is a somewhat simplified 

If the wg will do the effort it has to decide which of these drafts 
shall be considered. One of them, all of them or a combination?


On 2 Jun 2021, at 13:28, Heiko Gerstung wrote:

> So far the feedback regarding our draft is more or less trying to make 
> the point that
> instead of securing the currently unsecure protocol B, users should 
> better change the protocol so that it looks almost like secure 
> protocol A
> try to use parts of protocol B to enhance protocol A
> use protocol A to establish a secure error boundary for protocol B but 
> do not care for all the other possible attack vectors of protocol A.
> Apologies for oversimplifying this, but I believe I explained in 
> detail why none of these three approaches is as good as securing 
> protocol B.
> I read a few times that other WG members are agreeing that PTP needs 
> to be secured. NTS4UPTP is trying to deliver this for the unicast mode 
> of PTP. Given the experience you went through with NTS4NTP I believe 
> it is a sensible approach to divide the job of securing the two 
> different variants of PTP into two drafts. This will enable us to get 
> to a point where we can secure at least unicast PTP a lot faster 
> compared with one big draft that is trying to cover both unicast and 
> multicast. It is clear that you need two different approaches for 
> those two quite different variants and I propose to do this in two 
> drafts instead of one big draft with two parts.
> Regards,
>    Heiko
> -- 
> 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
> Email:
> Web:
> Deutsch
> English
> Do not miss our Time Synchronization Blog:
> Connect via LinkedIn:

> _______________________________________________
> ntp mailing list