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

Heiko Gerstung <heiko.gerstung@meinberg.de> Fri, 28 May 2021 07:34 UTC

Return-Path: <heiko.gerstung@meinberg.de>
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 E0D553A1E9B for <ntp@ietfa.amsl.com>; Fri, 28 May 2021 00:34:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 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, RCVD_IN_DNSWL_MED=-2.3, 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=meinberg.de
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 wZsUGQ9NUm9a for <ntp@ietfa.amsl.com>; Fri, 28 May 2021 00:34:01 -0700 (PDT)
Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767E63A1E98 for <ntp@ietf.org>; Fri, 28 May 2021 00:34:00 -0700 (PDT)
Received: from seppmail.py.meinberg.de (unknown [193.158.22.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id 2AF5B71C01B7; Fri, 28 May 2021 09:33:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=dkim; t=1622187237; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2oZTtskaFf4eZRJG8hVJPzZj80HMjhzKvhuEBQkj7bE=; b=hUVmvHLXrLy22H2RJ//9uNs1Ua8VAjxYvnNpzPYRcdZhnFVoOXAWtdWG6E7cRosOrFi8tc hYg0Zh+ko9DURd3XrU51aatoIbOsUD3p9EIuIGpHUOpdPS0bBuLZGp5xWdERorKbxb4aWA 4AgdYEK8l/5GGT1lCVKmVk/AYD/2FUmSVZhtjw2khVVakFWJSS8Fu772tL5aGfiU3+uCpG u6Ny8JLVeMClG/R9+sGSEowlJEuD+ooy5Q/W4LHfCtB+kwgufge2SgJwGNIvb/S3Mf7N5I e4qQJgyPHSMhXKjz8QRBHBwa2K226BcRmMPV4FdyMKym3+avZCqmwg8ppvgVdg==
Received: from srv-kerioconnect.py.meinberg.de (srv-kerioconnect.py.meinberg.de [172.16.3.65]) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by seppmail.py.meinberg.de (Postfix) with ESMTPS; Fri, 28 May 2021 09:33:56 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.49.21050901
Date: Fri, 28 May 2021 09:33:55 +0200
Message-ID: <A15ACFA0-B9E1-4F60-B76B-7C2A9146F5D7@meinberg.de>
Thread-Topic: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
References: <5F0AB4A8-30FB-4EE4-904C-BCC2CDFCA552@meinberg.de> <CAJm83bA=uQb05KMtUJN_qk0J65eaa1Av5OBatrN4mAk3dPC11Q@mail.gmail.com> <D1556106-7B75-48B2-962C-BEDF035DDA26@meinberg.de> <CAJm83bDhGyd-au6+h0U0jaLVLSkiKY_pKDQCcLiSY09dPP5qAQ@mail.gmail.com> <024470C1-E225-4FF8-AFD0-FD6A6CEF48CB@meinberg.de> <CAJm83bDOc+84AV__CnpMHoRHTDftKAgMhS52jhTPkG-g-ZUzag@mail.gmail.com>
In-Reply-To: <CAJm83bDOc+84AV__CnpMHoRHTDftKAgMhS52jhTPkG-g-ZUzag@mail.gmail.com>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+MTY2Mzc3M2Q1NjU3YjNiNw==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: Daniel Franke <dfoxfranke@gmail.com>
Cc: "ntp@ietf.org" <ntp@ietf.org>, Doug Arnold <doug.arnold@meinberg-usa.com>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----86CF693F3053CF0C9939061FE52FFC43"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/zk3bIt9oHIEiU45hfG-pAYzPdWw>
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
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: Fri, 28 May 2021 07:34:07 -0000

Hi Daniel,

sorry for top-posting, I try to summarize your arguments in this discussion (and please correct me if I misunderstood something):

You object adopting the draft that my colleagues and I submitted because:
1) you expect that working on this will require a lot of work for a lot of people
2) you think that using NTS4NTP in combination with Unicast PTP can provide a solution to the problems we want to solve with NTS4UPTP
3) you think that 2) is true because PTP could not guarantee a higher level of time accuracy in any network, mainly due to the fact that you consider RTT as the limiting factor and because there is no way to defend RTT against a MITM that is capable of delaying packets
4) you assume that because of 3) any user with a requirement that can only be fulfilled with PTP has to physically secure their network anyway to be protected against delay attacks and therefore there is no point in securing unicast PTP against any other security threats and types of attacks

Is that correct? Did I miss something?

Best Regards,
  Heiko


-- 
Heiko Gerstung 
Managing Director 
 
MEINBERG® Funkuhren GmbH & Co. KG 
Lange Wand 9 
D-31812 Bad Pyrmont, Germany 
Phone: +49 (0)5281 9309-404 
Fax: +49 (0)5281 9309-9404 
 
Amtsgericht Hannover 17HRA 100322 
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 
 
Email: 
heiko.gerstung@meinberg.de
Web: 
Deutsch https://www.meinberg.de
English https://www.meinbergglobal.com
 
Do not miss our Time Synchronization Blog: 
https://blog.meinbergglobal.com
 
Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung
 
 

Am 27.05.21, 18:44 schrieb "ntp im Auftrag von Daniel Franke" <ntp-bounces@ietf.org im Auftrag von dfoxfranke@gmail.com>gt;:

    On Thu, May 27, 2021 at 11:13 AM Heiko Gerstung
    <heiko.gerstung@meinberg.de> wrote:
    > I tried to explain that there is a RTT computation taking place, the client simply uses both sync and delay_req/resp messages for this. Maybe Doug can explain this to you in a better way.
    > There is a RTT calculation, and a PTP client uses RTT/2 as a correction for the incoming sync messages.

    I'm pretty sure I already understand. In the case of both NTP and PTP,
    you have a calculation like

    theta = ((t2-t1) + (t3-t4))/2

    In NTP, there's just one exchange that gives you all four timestamps.
    In PTP, you use DELAY_REQ/DELAY_RESP just for t2 and t1, and then you
    get t3 and t4 from the SYNC message.
    Trying to do without the SYNC message would give you bad results,
    because there's no hardware timestamp on DELAY_RESP to give you t3, so
    you'd be forced to treat t3 as equal to t2 or t2 plus some assumed
    processing delay.

    And then your maximum error bounds are ±((t4-t1) - (t3-t2))/2. Err,
    okay, I guess that still works out when you do it with separate
    messages? (t4-t1) will be big, but so will (t3-t2) so they'll cancel
    each other. But by "works out" I still mean "works out to ±half-RTT".
    It is not possible to improve on this.

    > I try again to explain what I believe you are missing here. Any application that requires sync has a minimum requirement for synchronization, i.e. any time error greater than this limit is going to affect the application, in most cases it completely avoids that the application can be used anymore. In some cases it degrades the application to a point where financial damages are negatively impacting the owner/operator of that application. And in some cases it can cause physical harm to human beings (think of a power grid protection system which cannot continue to work without very tight synchronization and therefore might trip a circuit breaker as a precaution, creating a blackout for hundreds or thousands of households in the process). For those applications, there is no reduced sync performance under "adversarial conditions", the synchronization solution either delivers the required minimum accuracy or not. Most if not all applications that use PTP require a sync performance of a microsecond or less, that is the reason why they deployed PTP and not NTP.  NTP accuracy is not good enough for these people and therefore it does not help at all to introduce a concept which considers a degraded sync performance under adversarial conditions.

    People who have these kinds of requirements *must* physically secure
    the network links they use for time synchronization. NTS cannot
    provide anything that will help them. My proposal won't do what they
    need, and neither will yours. I know you have customers clamouring for
    a solution and that you want to give them one, but it is simply. not.
    possible.

    > OK, you just changed your principal reason why you object to adopting the draft after it seems I convinced you that the initial reasons why you object adoption of the draft do not exist. I am a little bit at a loss here, because I do not know if I can convince you *at all* to support adoption. But anyway, this is too important and I will keep trying ;-) ...

    Yes, at first my biggest objection was "this won't work". You've now
    offered some clarifications and accepted some corrections that would
    allow it to work about as well as my alternative, but still not nearly
    as well as you claim it will and not nearly well enough to satisfy the
    use cases you've described in the previous quote. And so different
    objections rise to the top.

    > I am puzzled that your main reason is that you believe this is a lot of work for a lot of people. Three people with a lot of experience in both NTP and PTP already put a lot of work into this draft and tried to reuse as many parts as possible from NTS4NTP to minimize the required work. These three people are willing to continue to work on this draft, and I am sure that others will join. If you personally do not think it is worthwhile, I fully accept that. But I believe you should not speak for others. In addition to that, your new principal reason to object the adoption can be applied to every new standard, especially when it is timing related. For example, you could ahve applied the same reason to NTS4NTP when it first came up as a topic.

    Your proposal reuses some parts of NTS4NTP but still involves a lot of
    new work, probably including building new silicon. Mine reuses all of
    them. NTS4NTP was a lot of work for a lot of benefit, and part of that
    benefit is that it gives us a nearly-trivial way to also secure PTP.
    Sure, "this is a lot of work for little benefit" is an argument that
    can be deployed against any new standard, but sometimes it's true and
    sometimes it isn't!

    > Nope. There is nothing available *TODAY* that comes even close. You are comparing apples and oranges. The draft offers the same level of protection against cybersecurity threats that are covered by NTS4NTP. It does so by maintaining the full accuracy level of PTP, i.e. sub microsecond time synchronization. An NTP/PTP combo can only protect your time to the accuracy level of NTP. It is not an alternative to what we propose with this draft.

    NTS4UPTP does *not* maintain sub-microsecond precision under
    adversarial conditions. You are making an impossible claim. I can't
    yet tell you exactly where your error in reasoning is, because you
    haven't specified the client behavior in enough detail to give me a
    stationary target to pick apart. If you'd care to explain exhaustively
    what checks and calculations you expect the client to perform, and
    what better-than-half-RTT bounds you claim to be achieving, I'll
    happily reciprocate with an equally detailed protocol trace that
    illustrates how an adversary can mount a delay attack in order to feed
    the client time that passes your checks but falls outside your
    asserted bounds.

    > > If you want to change my mind about this, I suggest you try convincing
    > > me that PTP has functions that are auxiliary to time synchronization
    > > that still need securing. Can an attacker do harm to an unsecured PTP
    > > deployment in ways other than just desynchronizing clocks? DDoS
    > > amplification is one example, but that can be solved in a much
    > > lighter-weight fashion requiring little or no cryptography.
    >
    > I doubt that this is possible with unicast PTP. I kindly ask you to explain how you want to achieve that without a major redesign of the protocol, at which point it would not be PTP anymore.

    That's easy. You just need to require the client to prove that it's
    actually able to receive traffic at its claimed address before you
    send any significant traffic in that direction. You can do this by
    sending the client a random or pseudorandom token that it's required
    to echo back before you'll send it anything else, and periodically
    repeating this challenge to prove that it's still there. You can do
    this with no cryptography at all, or with just a little bit by having
    the token be a MAC over the client's network address and a timestamp,
    computing using a key known only to the server. The advantage of
    constructing it this way is that the server doesn't have to hold any
    state related to the client until it has already passed the challenge,
    because it can recompute the challenge token rather than having to
    store it.

    _______________________________________________
    ntp mailing list
    ntp@ietf.org
    https://www.ietf.org/mailman/listinfo/ntp