Re: [Ntp] A simpler way to secure PTP
Daniel Franke <dfoxfranke@gmail.com> Sun, 09 May 2021 01:11 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 AF4583A0BF0 for <ntp@ietfa.amsl.com>; Sat, 8 May 2021 18:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.196
X-Spam-Level:
X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 UprzVhWAa7_I for <ntp@ietfa.amsl.com>; Sat, 8 May 2021 18:11:12 -0700 (PDT)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 ED5593A0BEE for <ntp@ietf.org>; Sat, 8 May 2021 18:11:06 -0700 (PDT)
Received: by mail-pg1-x52e.google.com with SMTP id m37so10781067pgb.8 for <ntp@ietf.org>; Sat, 08 May 2021 18:11:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ol8Sh9QisSjxWf9z+mGEtpa/5fWJMkZzXH2AtIYQN44=; b=ekPs5rzsL2TgNtRmh7P8RccAlul1Cq0LLTMmdxsmzVRzTMAeIo5sRd3XdB7alTp3+E cR5IAA5YOf2CpMmkLplY3KKZ+pjQWdz03UNNIpYonZ0szb+ScMgeSSJ9LfebKoRfiMPI e/dakpp31nqEcn6rnZXn6KF3jSdi2CYL+gn/9lcF6HEDZvURIv9wOtZfufZWO2XrLO11 9dAhzkIxq/V7/wH7wGtei4Lfh4pZyiJZMpfBXJauKtmmQb/u+wfZ035vDAmfKb3FalaN FWmLCuGVUWIzaxZJxYEJmMikRLDIquRErIWHhm01BUdM8ZrkNRmt42eYjMWiActQfXlI qZZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ol8Sh9QisSjxWf9z+mGEtpa/5fWJMkZzXH2AtIYQN44=; b=TJW2wx0dgXwLy8zWO/uD+4H4se5Ipr7l5X/BAq2L0X0qG8fleVn1zVPP98VmgWvktN WP6Zc/KexoO3tCZEJfSFbAyBBIHL4dy4kOUoJNUuz+QkGirRrFkCMFCweI+f7o5jl+pF Pu8c5jOPhCRjiS65VCEmJdFD89jVE7vOLxQoUkqN9DnOsc6BOLdUiN1fysIPFByJC92a vZXom+mo+RVforHBUl6n3+iPeoYi/eECrcVcIpzfLCiEjfMXSI2hVAUj5//XT4C4qj3H zKZOyVxqZtA0LZi1X1Su7GyPt5CqV/A8zeu9FCNHOF/fz7eH+F3VHEDmoEXq28bL3/Ss 9Ibw==
X-Gm-Message-State: AOAM531oa4OzSiRBDW+kO+JgilXZHThbBVb+4izK0BQHKuHSotm7EDe/ jWR3PJzX3bKruC0MDAnHto765K2WvEl3T7rE/M4=
X-Google-Smtp-Source: ABdhPJycNr0PMHuuqkLG+FNrekrLQ6M+2dLjXwz48brS755HrGmAczH7ianw7V5AyozWaKlOmI2BbhI5ZtTmH2uLro0=
X-Received: by 2002:aa7:82ce:0:b029:242:deb4:9442 with SMTP id f14-20020aa782ce0000b0290242deb49442mr18406695pfn.73.1620522665362; Sat, 08 May 2021 18:11:05 -0700 (PDT)
MIME-Version: 1.0
References: <CAJm83bCpio5WwigY6nc9Y0Gt_XSdjUV=sHUz04dOQ0zELPwZxw@mail.gmail.com> <7414ff6a71f8476d816997cb183064b2@ostfalia.de>
In-Reply-To: <7414ff6a71f8476d816997cb183064b2@ostfalia.de>
From: Daniel Franke <dfoxfranke@gmail.com>
Date: Sat, 08 May 2021 21:10:54 -0400
Message-ID: <CAJm83bCXh8e=TXVvM+vYBxSLtXZuSm2059Csoy3PfF+snBT7zg@mail.gmail.com>
To: Martin Langer <mart.langer@ostfalia.de>
Cc: NTP WG <ntp@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d1ca5605c1db55f4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/tJbZAJApmUqkVBdMMOgM6g7tWuY>
Subject: Re: [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: Sun, 09 May 2021 01:11:17 -0000
This sort of denial-of-service attack is outside the scope of what NTS is meant to prevent. More potent attacks are already possible at protocol layers lower than anything we can control. You can DoS your local network segment with ARP poisoning, and of course if you control any router on the communication path then you can just drop the traffic altogether. If an *off-path* adversary can DoS you just through blind packet spoofing then that's more troubling, but on the sort of closed networks that PTP is designed for, I think this can always be satisfactorily mitigated by the reverse-path filtering that most routers do automatically and by default. (If a random box on the other side of the Internet can spoof your PTP grandmaster's IP address and that spoofed packet can make it all the way to your endpoint systems rather than getting dropped at your firewall, fix your network). The guarantee that my design is intended to provide is that no attacker, not even one with a privileged network position, can manipulate your clock outside the narrow bounds that NTS-secured NTP establishes. I don't think the attacks you're describing violate that. On Sat, May 8, 2021 at 7:30 PM Langer, Martin <mart.langer@ostfalia.de> wrote: > Hello Daniel, > > That's an interesting thought and reminds me of a similar approach that > Kristof and I had > for securing TESLA for NTP. But I think the problem goes a bit deeper. > ...at least for PTP > unicast. As far as I know, connections could be "reactivated" or cancelled > by replay attacks. > Possibly other attacks could also be carried out by packet manipulation. > ...but I need to > think this through further. ;) > > > have a nice day > > -martin- > > ------------------- > Martin Langer, M.Eng. > Ostfalia Hochschule für angewandte Wissenschaften > - Hochschule Braunschweig/Wolfenbüttel > University of Applied Sciences > > Labor Datentechnik, Labor Design Digitaler Systeme > Fakultät Elektrotechnik > Salzdahlumer Straße 46/48 > 38302 Wolfenbüttel > Germany > > Tel.: +49 5331 939 43370 > Web: https://www.ostfalia.de/cms/de/pws/bermbach/mitarbeiter/martin-langer > > ------------------------------ > *Von:* ntp <ntp-bounces@ietf.org> im Auftrag von Daniel Franke < > dfoxfranke@gmail.com> > *Gesendet:* Samstag, 8. Mai 2021 22:53:06 > *An:* NTP WG > *Betreff:* [Ntp] A simpler way to secure PTP > > 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