[Ntp] A simpler way to secure PTP
Daniel Franke <dfoxfranke@gmail.com> Sat, 08 May 2021 20:53 UTC
Return-Path: <dfoxfranke@gmail.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658E13A1229 for <ntp@ietfa.amsl.com>; Sat, 8 May 2021 13:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ElpUILzvNM8 for <ntp@ietfa.amsl.com>; Sat, 8 May 2021 13:53:19 -0700 (PDT)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708593A1228 for <ntp@ietf.org>; Sat, 8 May 2021 13:53:19 -0700 (PDT)
Received: by mail-pl1-x629.google.com with SMTP id v13so7269109ple.9 for <ntp@ietf.org>; Sat, 08 May 2021 13:53:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=mlgLCDNBEnCjk+aAGus6b2fySzlN6Okvcrt25im7fKs=; b=MQ+QldxjOpdG+9iHSruRLmv1cMTqjzZaP+0mhrXCzo+Ir8Ls1uDlpb+XxHasOY5hoj oiWbSeLqq1yYO6o2ScguFwkPIvlysnYIqPnCD9w+8ISjyasfqQD9Fwqu0hoyrRORxp7t EGXZkEIwYZzspcmLN/DPt1D+ZwY84S6shP2jmbWNEQ1ThT4bCtTzKaLBthpJPRZXRCRj w2Ng/AC3y2mwN7rmYjQFUMNZYoO2HEoZnNzkKW4PN7wyyaBxtBhWa/e1eMiwZCc0Kaot 4yNW+5+Vk7b16zv5wkcxtkOFBUCGScHs0DAH4/5kR677BWA3iZwyK3Sbn+IvMeGKQaVJ MQzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mlgLCDNBEnCjk+aAGus6b2fySzlN6Okvcrt25im7fKs=; b=MP5+Chfb6sDcWmt0LtOtEppAIffnSsSiNaYYspQvP23wKxoicaqUxF1WxuF3OGaJAE BtW4WwNXGa5jde7AEQwBA71ekaM2z2pNb6A5sxbm79dhQTVmHmGwfiYN2WxODUA/OnFV g20IoshdLSqhtMkXJa+oGNg8BpApBWdBjQ2KmOtAJ6KT9mqlX6iM5sTBa7YITNlsciG9 fY2pQ0dnVbn4MU7BHvING7fxRIi7ejMYrLnWQYotM8jNNxc7/v4u2nUVr5ve8aLHc15O nG5imkZqArn5YAKwBpMwdruK0geel0LFKizOMpjYvC9hV1nodmDahrfjZsOdPo0f5Q2+ WDQg==
X-Gm-Message-State: AOAM533S9D84AEef0rEW6/jCKyB91jZjuz2nRFmuhuyqaVgKOj3Pas6J EUVeRaMufwp0JKkw4iSKeVtq8VNlXrKNV1k9UzN/Y9x+n2BQHQ==
X-Google-Smtp-Source: ABdhPJxqLjwANP8ZyBhZDnNjZY2jKcz5o3QQRCjBKxdBHj4EXDzyxhHGiAPpit3ViCoElgftjGRo767W2tAhqtP/Mtg=
X-Received: by 2002:a17:90a:a581:: with SMTP id b1mr18127082pjq.53.1620507197814; Sat, 08 May 2021 13:53:17 -0700 (PDT)
MIME-Version: 1.0
From: Daniel Franke <dfoxfranke@gmail.com>
Date: Sat, 08 May 2021 16:53:06 -0400
Message-ID: <CAJm83bCpio5WwigY6nc9Y0Gt_XSdjUV=sHUz04dOQ0zELPwZxw@mail.gmail.com>
To: NTP WG <ntp@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e1b9bc05c1d7bb61"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/-gQcQH915bf7NFTCjJ8LfVe8aa4>
Subject: [Ntp] A simpler way to secure PTP
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: Sat, 08 May 2021 20:53:23 -0000
As an alternative to Martin's and Heiko's drafts, I'd like to propose a simpler approach to securing PTP. It is compatible with all PTP features, supports the same threat model as NTS-secured NTP, introduces zero jitter, and can be implemented entirely on the client side without the knowledge or cooperation of the rest of the PTP infrastructure. The trick is: run NTS-secured NTP and regular, unauthenticated PTP side-by-side. Do not use the NTP responses to set the clock; instead, use them only to establish maximum error bounds on the current time, and then clamp all PTP messages to within those bounds. The client's on-wire interaction with the NTP server is the same as it is in normal NTS-secured NTP, but the way it processes the server's responses is different. The client maintains an estimate `theta` of the offset between a local, unadjusted monotonic clock `t_raw` (implemented e.g. by CLOCK_MONOTONIC_RAW on linux) and the server's realtime clock, along with a continuously-changing error term `lamdba`. Upon receiving an authentic response from an NTP server, let: t_1 = origin timestamp captured from t_raw. t_2 = packet receive timestamp t_3 = packet transmit timestamp t_4 = destination timestamp captured from t_raw. theta = ((t_2 - t_1) + (t_3 - t_4))/2 DTAI = TAI - UTC offset giving a current estimated TAI time of t_raw + theta + DTAI For computing error bounds, let hrtt = (t_4 - t_1)/2 rdel = packet root delay r_1 = local clock precision r_2 = packet clock precision PHI = some appropriate upper bound on our local clock's drift rate and then our error term is plus-or-minus hrtt + rdel/2 + r_1 + r_2 + PHI*(t_raw - t_1) Only the single best clock sample, from a given NTP server, i.e. the one that gives the tightest error bounds, need be retained. Other things being equal, newer samples will be preferable to older ones because the PHI*(t_raw - t_1) term will be smaller, but sometimes this may be negated by other terms such as hrtt being larger. A client may gain resiliency by using multiple NTS-secured NTP servers. In this case for N servers it lets f=floor((N-1)/2), then discards the f lowest lower bounds and the f highest upper bounds, and then treats anything inside any of the remaining bounds as plausible. Any PTP message whose time (after applying the usual link-delay correction) is plausible according to these bounds is processed as usual. Any PTP message whose time is not plausible is first clamped to the nearest bound and then processed as usual. And that's all there is to it!
- [Ntp] A simpler way to secure PTP Daniel Franke
- Re: [Ntp] A simpler way to secure PTP Langer, Martin
- Re: [Ntp] A simpler way to secure PTP Daniel Franke
- Re: [Ntp] A simpler way to secure PTP Miroslav Lichvar
- Re: [Ntp] A simpler way to secure PTP Doug Arnold
- Re: [Ntp] A simpler way to secure PTP Daniel Franke
- Re: [Ntp] A simpler way to secure PTP Doug Arnold
- Re: [Ntp] A simpler way to secure PTP Langer, Martin
- [Ntp] Antwort: Re: A simpler way to secure PTP kristof.teichel
- Re: [Ntp] A simpler way to secure PTP Daniel Franke
- Re: [Ntp] A simpler way to secure PTP Heiko Gerstung
- Re: [Ntp] Antwort: Re: A simpler way to secure PTP Joachim Fabini
- Re: [Ntp] A simpler way to secure PTP Heiko Gerstung
- Re: [Ntp] Antwort: Re: A simpler way to secure PTP Heiko Gerstung
- Re: [Ntp] A simpler way to secure PTP Miroslav Lichvar
- Re: [Ntp] Antwort: Re: A simpler way to secure PTP Kurt Roeckx
- Re: [Ntp] Antwort: Re: A simpler way to secure PTP Joachim Fabini
- Re: [Ntp] A simpler way to secure PTP Heiko Gerstung
- [Ntp] Antwort: Re: Antwort: Re: A simpler way to … kristof.teichel
- Re: [Ntp] Antwort: Re: A simpler way to secure PTP Joachim Fabini
- Re: [Ntp] Antwort: Re: A simpler way to secure PTP Kurt Roeckx
- Re: [Ntp] Antwort: Re: Antwort: Re: A simpler way… Joachim Fabini
- [Ntp] Antwort: Re: Antwort: Re: Antwort: Re: A si… kristof.teichel
- Re: [Ntp] A simpler way to secure PTP Daniel Franke
- Re: [Ntp] A simpler way to secure PTP Heiko Gerstung
- Re: [Ntp] A simpler way to secure PTP Daniel Franke
- Re: [Ntp] A simpler way to secure PTP Doug Arnold
- Re: [Ntp] A simpler way to secure PTP Danny Mayer
- Re: [Ntp] A simpler way to secure PTP Doug Arnold