Re: [Ntp] A simpler way to secure PTP

Heiko Gerstung <heiko.gerstung@meinberg.de> Tue, 11 May 2021 08:42 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 57B753A08FA for <ntp@ietfa.amsl.com>; Tue, 11 May 2021 01:42:48 -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, 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=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 gwO3vWi_97M2 for <ntp@ietfa.amsl.com>; Tue, 11 May 2021 01:42:43 -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 116C43A08F9 for <ntp@ietf.org>; Tue, 11 May 2021 01:42:43 -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 83C0071C0E8B; Tue, 11 May 2021 10:42:41 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=dkim; t=1620722561; 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=apsuSC96D8oi44ikfke8m/nNBxrrEh37R6cBb6N+/o4=; b=MjiEGcQx/DZPZVsBszYYfyCGQhc1LBnaNzQ7OQhy3xrwZ7bXnMMRM6Gc9BNXOjuj3nySux VxCThvVJLlPSg5eJexmk9i+8d0OyTOvXJPC+lWPtTR965BJtHGtsGrB0/jJ3/8S4PrL+5y BqS2eDCU4clhZNz/BjeQ62JfWW4L8NOaUjvQ6ZMUfKmL0Xo8GLpQXmlEljLbhpc07pwz+Q Hu7BOfVrC3H9ktpwt2FyaCzDVrsFz7TLDGAknB3/jGWdOfDp4y6p9i/lkOwlEIgy3ymXRg IuS2B7U7eR7PoR67t12zJ/W5+Faz7nnMczARBrNqfOn77mZfqJ/H+0ulGFjSGQ==
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; Tue, 11 May 2021 10:42:40 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.48.21041102
Date: Tue, 11 May 2021 10:42:40 +0200
Message-ID: <826BF504-52D8-4657-BD90-01A119111A1A@meinberg.de>
Thread-Topic: [Ntp] A simpler way to secure PTP
References: <CAJm83bCpio5WwigY6nc9Y0Gt_XSdjUV=sHUz04dOQ0zELPwZxw@mail.gmail.com> <886DDD0D-AB9A-43A1-999B-FC296D680434@meinberg.de> <YJo/M6TdqqrmrVyP@localhost>
In-Reply-To: <YJo/M6TdqqrmrVyP@localhost>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+NmY2YTczNjlmZDI4MmRiNQ==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: Miroslav Lichvar <mlichvar@redhat.com>
Cc: Daniel Franke <dfoxfranke@gmail.com>, NTP WG <ntp@ietf.org>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----1CA0835E646174AF04C1A87597865BDE"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/9X7sdsi-4uSQuDQf_0cX1t2e-nw>
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: Tue, 11 May 2021 08:42:48 -0000

 

Am 11.05.21, 10:24 schrieb "Miroslav Lichvar" <mlichvar@redhat.com>om>:

    On Tue, May 11, 2021 at 09:14:55AM +0200, Heiko Gerstung wrote:
   > >PTP is different from NTP on multiple levels and offers a number of features that you do not find in NTP, for example higher packet rates to increase the number of samples you feed into your statistics.

>    Isn't this the other way around? The maximum rate of delay requests is
>    limited by the TX HW timestamping rate. The few PTP appliances I saw
>    supported only a very small number of clients. This can exploited for
>    a DoS attack. The same applies to NTP using HW timestamps+xleave, but
>    at least it can fall back to SW timestamps and clients should handle
>    that well.

Our products can support 2,048 unicast PTP clients at 128 pkts/s for both sync and delay responses, i.e. you end up with roughly 500k TX timestamps on each of the Gigabit Ethernet ports of our devices (up to 10 ports in a 3U chassis). I'd say you did not see the most powerful appliances out there ;-)  ..

   > > It also offers hardware timestamping in the network infrastructure components, i.e. switches and routers, which can improve your sync performance dramatically.

>    Would you expect the network devices to gain support for the new
>    security protocol quickly, or is it more likely the leaf clocks would
>    need to bypass them and send their secured requests to new designated
>    clocks (avoiding the benefits of the hardware support)?

Well, it will take some time for sure, but if there is no standard, no hardware vendor would be willing to add this to their feature list. 

>    > However, especially unicast PTP is a great traffic amplification tool, maybe one of the biggest traffic amplification machines of all times. And I also believe that it would be great to (re)use the general concepts of NTS to secure the other popular time transfer protocol out there. 

  >  Yes, the near infinite amplification factor of the unicast PTP mode is
  >  a major concern, but I don't see what can be reused from NTS to fix
  >  that. NTS in NTP avoids amplification by the protocol design, not by a
  >  security mechanism.

Our draft reuses the NTS-KE phase of NTS4NTP for the key exchange. It uses the integrated PTP security mechanism and adds multiple protection mechanisms to PTP. See the "Security Considerations" part of the draft.

Regards,
   Heiko


    -- 
    Miroslav Lichvar