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

Daniel Franke <> Tue, 01 June 2021 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D36CC3A2474 for <>; Tue, 1 Jun 2021 12:27:38 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 khA9itbiXzh6 for <>; Tue, 1 Jun 2021 12:27:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5D6EF3A2472 for <>; Tue, 1 Jun 2021 12:27:37 -0700 (PDT)
Received: by with SMTP id x73so277935pfc.8 for <>; Tue, 01 Jun 2021 12:27:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1uG3HDmTsepnfb6Qe8Lg3YhOy/r+tCvq7OMP9muJPGg=; b=hpwE6PsPVsWmTCb/OMiVV/+1RXNSKf/S+pPmCPlJsOC6USpoeBr24+Ged/V/wXSnzR zqcNEZT/bbZy11TU0eUyvSwgq6kIXBO7cLaOJputoTKGcOcOIrcR8oEppaY6QVwINXm8 xzh+LlIWFKfsoykXTTTPlYaSfvafqL3IyMLtsLhle6Qdoa0z5B/n8PE2SssGXPujD6Gq bPtLPw81KIDL/J5Pc3rbhOJ5YY6Hs6LXcrNqrFzcUqW2ALRtIvCtY5FQCEw98gWT7aOf 73/6tVnX7gDkPhB/WrRfvPFEpxDF74SK5cdnUD1qCu3i7kZJkR9i/SqNlYjhJjotb6ui DSbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1uG3HDmTsepnfb6Qe8Lg3YhOy/r+tCvq7OMP9muJPGg=; b=RcCb9Kx5+eg6c3R96qrDRACvgThjMjXCl0XW7vy4nohqJEdBC2CaWFMZL8z2coKmTC VHTqMMwxBLjyvUFIbmdOWPTfphVF8syfR8lHuiOoB4cxOqzvbzjnASBYNpgxQDiy9Q8m wL7ZUNeSxLIG8d++0fIO/qFnOX5pz8UnTsrGBwZ2+KgpCVCCwpMHYsj9mVbCwB+BoJQE AvuOxkxkzYkVmEmnq+qiT/MsVWwinBbUIujYnkWNdeu9QhnRtVffHCUhOroanHAiUEFA BBqoFP7KExrwsuO62GWIO/D34gpE9hDqRAM7h+iCqME97LhbEhUjgqbTNZ1B+3S3QRj/ VbUw==
X-Gm-Message-State: AOAM5314C/9G/G2ZBBayIc8rHig7/L/CgHGVm5L1650LUDf54P2erVmg q5OwxAyvOyoMTYpSnHr4qJZ9FwJgyI4p2RxtMtVoXRSu
X-Google-Smtp-Source: ABdhPJz6vkBIVxyhZR9Vt5uiRe/Rg25yTu8lgEp9kY7DOYD3LCne1gPHJLPhbBE1+8XNP45jzulrTV+QC5qE4PdV8NI=
X-Received: by 2002:a63:bc19:: with SMTP id q25mr29745069pge.211.1622575656274; Tue, 01 Jun 2021 12:27:36 -0700 (PDT)
MIME-Version: 1.0
References: <> <YLYCLIEA4/unB6/5@localhost> <> <YLYheZYTSflAdlrF@localhost> <> <YLY3f2/5k1Hjebf7@localhost>
In-Reply-To: <YLY3f2/5k1Hjebf7@localhost>
From: Daniel Franke <>
Date: Tue, 1 Jun 2021 15:27:25 -0400
Message-ID: <>
To: Miroslav Lichvar <>
Cc: Heiko Gerstung <>, "" <>
Content-Type: text/plain; charset="UTF-8"
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 19:27:39 -0000

On Tue, Jun 1, 2021 at 9:35 AM Miroslav Lichvar <> wrote:
> Ok, if you need as much of NTS4NTP as possible and at the same time
> keep accuracy provided by hardware timestamping as is supported in
> current hardware, I think the solution is simple: NTS4NTP over PTP.
> You can wrap NTP messages in a PTP event message to get hardware
> timestamps and keep all the benefits of NTS4NTP. It seems your plan is
> to provide NTS4NTP in any case. Do you see any disadvantages?

All these long and similar initialisms for the various PTP security
proposals are getting unmanageable, so I'm going to create some new

* I'm going to start calling my proposal NSCoPE, for NTP Securely
Constraining PTP Errors.

* I'm going to call Miroslav's proposal PEN, for PTP-Encapsulated NTP.

* I'll keep using NTS4NTP for RFC 8915, NTS4UPTP for the
Gerstung-Rohde-Arnold draft, and NTS4PTP for the Langer-Bermbach

I agree with Miroslav that PEN likely requires a lot less development
effort than NTS4UPTP does, but it still requires changes to both the
server and the client, unlike NSCoPE which can be implemented
unilaterally on the client. There's a tremendous gulf between changing
one line of code on the server and changing zero. A one-line change
requires a full-blown standards-track effort involving multiple
standards bodies, interop testing between vendors, and lots of network
infrastructure that needs upgrading, even if the upgrade is just a
firmware patch. If only client-side changes are needed, none of this
coordination is required.

Maybe a better way to think of PEN is not as a security layer for PTP,
but rather as a way to improve the typical-case precision of NTP by
adding hardware timestamps. It strikes me as a better alternative to
interleaved mode, one which avoids the need for server state or for
sending follow-up packets. It's hardly PTP at all; the fact that
responses come back framed as PTP event messages is just a hack to get
existing hardware to cooperate. The fact that the NTP messages can use
NTS is pretty much incidental. You can do PEN with unauthenticated NTP
messages too and (as long as you're not under attack) get all the same
benefit to precision.