Re: [Ntp] A simpler way to secure PTP

Daniel Franke <> Mon, 10 May 2021 17:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D2173A23FB for <>; Mon, 10 May 2021 10:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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_BLOCKED=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 CmZd3ZgJmqFE for <>; Mon, 10 May 2021 10:09:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 73D7A3A23F6 for <>; Mon, 10 May 2021 10:09:54 -0700 (PDT)
Received: by with SMTP id h14-20020a17090aea8eb02901553e1cc649so10445025pjz.0 for <>; Mon, 10 May 2021 10:09:54 -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=hLMyr9PvLJlT14Rt6iwnXvxhH2O4mvWCMUgTWN8Z184=; b=of2djC24042n7Ds6bb3lsokLFgFj25FfBuoGuA64Ezl/rZJFRhgFTl2p9DGqYOhDev EVBg78ELtPHGeseQRZb1SqI1s3RSbkUoC6CPs+5nG4YOKTnwgt6GFo4zfVDvUx531OEE zelj4tHUAG2JZAjakqYq3FB6OSA5pS1H+MkpLhitjj/X2WHbRdj9Lp6zZLj/Q586tTtw Czi8LRjWyhimhZPzvql4dqdfEjzKBUJ41qLZyBQvycv7FoYeDkgjjvt+h50LbK7cFPZh 9ntZI4mCPaLICdYaSXCGbtKtjGm9kqVWgJiPjXfCqKhwP+pd2L2rm5fQKRDzjxWAmgak jfgw==
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=hLMyr9PvLJlT14Rt6iwnXvxhH2O4mvWCMUgTWN8Z184=; b=aCzdIg8BJzy6Ta5gp8bPwBtknXleYRWX6a02vStQwF0Vkyc7d6mYNrJ9LXA7Z0ERmV q34doRU94ro27QDtK3Pw25dK9TYUY2eANlFAqn+WNNmBNs7Wio3Z/qf+WDIqU/62PXuz EvMXaWsGYd8N8YxouaT937dwnQbao61dw+u5B7QbvlBcbz7FUg/rxpTXX4lpFd1L1hlf xOGwzJMv7hayXHSJF/862MHOp0hNJv8ZeTVodgaZeCSQft6rXMwFUtzNcN3kBoJB2iGB /Dt+yRadyxOITzgBOdCJYouMhqf93wwOajdPZ0vlyuoiD97CK2g8JzPNfIFeWFcA5DzM BeMg==
X-Gm-Message-State: AOAM533HfEODXRJIgkxbpXUlmenM76ewO+L1uCeF0Zo0yXly43EI+hzk 0gHlU/9UplV/iVcvj9XiA+j5ZfHYeMzJtQNV83M=
X-Google-Smtp-Source: ABdhPJwX6OuczKYdHgf5ZqeYU+T8WzQnZJ/QlY1m4E9Q80k+Igj5B1115l2Nb5s6s8GzaZ7868cvGJEG+2SDXU2Cuzw=
X-Received: by 2002:a17:902:9f88:b029:ee:b4e5:64d4 with SMTP id g8-20020a1709029f88b02900eeb4e564d4mr25134734plq.41.1620666591971; Mon, 10 May 2021 10:09:51 -0700 (PDT)
MIME-Version: 1.0
References: <> <YJkrFjnRPJJHz9da@localhost> <> <> <>
In-Reply-To: <>
From: Daniel Franke <>
Date: Mon, 10 May 2021 13:09:40 -0400
Message-ID: <>
To: Doug Arnold <>
Cc: Miroslav Lichvar <>, NTP WG <>
Content-Type: multipart/alternative; boundary="000000000000838d4c05c1fcd8ef"
Archived-At: <>
Subject: Re: [Ntp] A simpler way to secure PTP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 May 2021 17:09:59 -0000

You get the most leverage out of the PTP + NTS4NTP approach in situations
where having as much precision as possible is desirable, but having your
clock be a decade off is far worse than having it be a half-RTT off.
Perhaps your system is running different applications with different levels
of criticality that use the clock in different ways.

You're of course correct that if you have multiple independent links, you
can get a secure result if you're able to assume that some fraction of them
are trustworthy. At minimum you need a correct majority, that is, N>=2f+1.
In this case you can just take the median sample: since you have f+1
samples greater than or equal to the median and f+1 samples less than or
equal to it, you have it bounded on each side by at least one correct
sample and therefore it can be considered correct. Alternatively, you can
use the Schiff-Dolev-Mizrahi-Schapira Chronos algorithm. This will give you
better results when, for non-adversarial reasons, there's dispersion among
correct clocks: you'll get tighter synchronization among sets of clients
that all use the same sources. However, Chronos requires N>=3f+1.

On Mon, May 10, 2021 at 12:18 PM Doug Arnold <>

> Many of the applications of PTP I know of require time transfer accuracy
> better than half the RTT.  This is achieved using a variety of mechanisms,
> including:
>    - On-path support
>    - High message rates + lucky packet filters
>    - Synchronous Ethernet
>    - Networks with lightly loaded switches
>    - Preemptive switches
>    - Asymmetry calibration
>    - Multiple PTP domains with different paths to devices needing time
>    - Multiple sources of time, that is PTP, plus other non-PTP time
>    transfer mechanisms in a redundant system
> A switch in the middle could mount a delay attack, which is of course
> immune to cryptography, but the risk could be reduced by non-cryptographic
> defenses such as time source, or network path redundancy.
> NTS4PTP could help against malicious agents which have gained access to
> the network and start sending bogus PTP messages, for example impersonating
> the Grandmaster.
> Doug
> *From: *Daniel Franke <>
> *Date: *Monday, May 10, 2021 at 11:21 AM
> *To: *Doug Arnold <>
> *Cc: *Miroslav Lichvar <>om>, NTP WG <>
> *Subject: *Re: [Ntp] A simpler way to secure PTP
> On Mon, May 10, 2021 at 10:43 AM Doug Arnold <>
> wrote:
> I have heard of people actually doing this in the field as a sanity check.
> However, some applications that use PTP can be broken by introducing
> timing errors that are less than the expected difference between PTP and
> NTP.
> You cannot solve this with cryptography. An adversarial network is, by
> definition, one where you can't rely on statistical behavior and can't
> neglect the probability of worst-case outcomes. The worst-case outcome for
> any unicast protocol is going to be at least half the measured RTT, and for
> a broadcast protocol the worst case is unbounded. As I've mentioned before,
> you can improve this a little bit if you know a lower bound on the physical
> distance `d` between the client and server, in which case you can shrink
> each of your bounds by `d/c` where `c` is the speed of light, but this
> still won't get you anywhere near the kind of precision you have in mind.
> If worst-case, let alone typical-case, NTS4NTP behavior is going to break
> your application in critical ways, then you MUST have a physically-secure
> link to your time source. If you have an adversary on your communication
> path, you're just screwed and cryptography can't save you.