[Ntp] NSCoPE

kristof.teichel@ptb.de Thu, 03 June 2021 12:49 UTC

Return-Path: <kristof.teichel@ptb.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4D8023A0EF2 for <ntp@ietfa.amsl.com>; Thu, 3 Jun 2021 05:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.419
X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, 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=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id oJlDnGgzW65o for <ntp@ietfa.amsl.com>; Thu, 3 Jun 2021 05:49:41 -0700 (PDT)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD1B3A0EED for <ntp@ietf.org>; Thu, 3 Jun 2021 05:49:40 -0700 (PDT)
Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de []) by mx1.bs.ptb.de with ESMTP id 153CncMS024798-153CncMU024798 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 3 Jun 2021 14:49:38 +0200
Received: from lotus.bs.ptb.de (lotus.bs.ptb.de []) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id D08B3B785ED; Thu, 3 Jun 2021 14:49:36 +0200 (CEST)
MIME-Version: 1.0
Importance: Normal
X-Priority: 3 (Normal)
In-Reply-To: <CAJm83bBrEx85KMuJ4k6vJrX7HQ9mwgdbwexYbsO8b7OwkOx-Gg@mail.gmail.com>
References: <CAJm83bBrEx85KMuJ4k6vJrX7HQ9mwgdbwexYbsO8b7OwkOx-Gg@mail.gmail.com>, <OF7448B63E.194846B7-ONC12586E7.00725D69-C12586E7.00725D6A@ptb.de>
From: kristof.teichel@ptb.de
To: "Daniel Franke" <dfoxfranke@gmail.com>
Cc: "NTP WG" <ntp@ietf.org>
Date: Thu, 3 Jun 2021 14:49:34 +0200
Message-ID: <OFD9C5E43C.2C2E90FC-ONC12586E9.0044DDCC-C12586E9.004674F3@ptb.de>
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/9s4ogLH00zadSqkd8OBe5VHEUKE>
Subject: [Ntp] NSCoPE
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jun 2021 12:49:47 -0000

I've had some time to contemplate this

>> I'm just not sure that it is worth the effort to focus on NTS+PTP specifically and market that as a security solution for PTP... but that gut feeling could definitely be off.
>> It just feels to me like it might be more interesting and fruitful (long-term) to make this into a generically applicable thing; I would be willing and able to contribute serious amounts of work to such an effort.

>You're correct, the general approach of using an imprecise, secure
time source to clamp a precise, insecure one can be applied to many
combinations of the two. But the details of how to commensurate the
two timescales and compute intervals of plausibility would be
different so I'd rather just focus on one particular combination and
note the broader applicability in passing.

The more I think about it, the more I'm convinced that for this to be (and stay, medium or even long-term) relevant, it would be of interest to mention and ideally cover GNSS applications.
Specifically the pairs GPS Chimera + NTS and Galileo OS-NMA + NTS have already gotten some attention.
- https://arxiv.org/pdf/1710.05798.pdf" target="_blank" rel="noopener noreferrer nofollow">https://arxiv.org/pdf/1710.05798.pdf
- my doctoral thesis
 (I can supply you with pre-prints, if you're interested.)

On the other hand, with PTP it seems to me that it could get its own solid two-way solution, and then it would get both the points for accuracy and those for security guarantees.
At that point, NSCoPE would be irrelevant for PTP altogether.

This is not going to happen anytime soon with GNSS systems, or radio systems.
How much harder do you think it would be to formulate the concept generically, with the assumption that you have an NTS measurement plus another measurement with higher potential accuracy and potentially in a different timescale, and argue the PTP application more as a practical illustration (and perhaps the candidate for a first implementation in software)?

I would definitely have an easier time convincing my higher-ups to let me invest time and effort into this if it were arguable that GNSS was covered.

P.S.: the "P" in "NSCoPE" would have to be re-designated to "precision-measurement" or something... but that part seems manageable.