Re: [Ntp] A simpler way to secure PTP

Danny Mayer <mayer@pdmconsulting.net> Wed, 12 May 2021 17:24 UTC

Return-Path: <mayer@pdmconsulting.net>
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 0B7843A11CA for <ntp@ietfa.amsl.com>; Wed, 12 May 2021 10:24:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 k5b4szeXDs6q for <ntp@ietfa.amsl.com>; Wed, 12 May 2021 10:24:07 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64EEF3A11CD for <ntp@ietf.org>; Wed, 12 May 2021 10:24:02 -0700 (PDT)
Received: from newusers-MBP.fios-router.home (pool-108-26-179-179.bstnma.fios.verizon.net [108.26.179.179]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4FgM8b4JhQzMNTC; Wed, 12 May 2021 17:23:59 +0000 (UTC)
To: Doug Arnold <doug.arnold=40meinberg-usa.com@dmarc.ietf.org>, Heiko Gerstung <heiko.gerstung=40meinberg.de@dmarc.ietf.org>, Daniel Franke <dfoxfranke@gmail.com>
Cc: NTP WG <ntp@ietf.org>
References: <CAJm83bCpio5WwigY6nc9Y0Gt_XSdjUV=sHUz04dOQ0zELPwZxw@mail.gmail.com> <886DDD0D-AB9A-43A1-999B-FC296D680434@meinberg.de> <CAJm83bDKrecB0d=hTZDkCiS2xnFyOHJf+Apcxkg6TnvFbdB0nA@mail.gmail.com> <54DCB402-CB39-4714-8BE6-7F491B11B0DD@meinberg.de> <AM7PR02MB5765E22D8048797F72E894BECF529@AM7PR02MB5765.eurprd02.prod.outlook.com>
From: Danny Mayer <mayer@pdmconsulting.net>
Message-ID: <a5f9976f-5c0b-d0e2-3aba-71cb1744ebe6@pdmconsulting.net>
Date: Wed, 12 May 2021 13:23:58 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <AM7PR02MB5765E22D8048797F72E894BECF529@AM7PR02MB5765.eurprd02.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------D8861C4C6E8EE815F7344F20"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/X3VXM5leNplBzM0CNVXXmPaYQhs>
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: Wed, 12 May 2021 17:24:12 -0000

Can you provide examples of automated key management solutions that they 
already have so we can see how they could possibly be aligned with NTS?

Danny

On 5/12/21 1:19 PM, Doug Arnold wrote:
>
> Both equipment designers and network operators have asked if we can 
> specify an automated key management mechanism that they already have 
> rather than make them implement a new one.
>
> Doug
>
> *From: *ntp <ntp-bounces@ietf.org> on behalf of Heiko Gerstung 
> <heiko.gerstung=40meinberg.de@dmarc.ietf.org>
> *Date: *Wednesday, May 12, 2021 at 1:15 AM
> *To: *Daniel Franke <dfoxfranke@gmail.com>
> *Cc: *NTP WG <ntp@ietf.org>
> *Subject: *Re: [Ntp] A simpler way to secure PTP
>
> Hi Daniel,
>
> that’s why we use the integrated security mechanism for unicast PTP 
> and just use the NTS-KE protocol to exchange the required keys for 
> that. Due to the fact that the two protocols NTP and PTP work in a 
> completely different way, there is not more that can be reused. I 
> agree we could find another way to exchange keys and it doesn’t have 
> to be NTS. But why not using it, now that it is there?
>
> 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 <mailto:heiko.gerstung@meinberg.de>
>
> Web:
>
> Deutsch https://www.meinberg.de <https://www.meinberg.de>
>
> English https://www.meinbergglobal.com <https://www.meinbergglobal.com>
>
> Do not miss our Time Synchronization Blog:
>
> https://blog.meinbergglobal.com <https://blog.meinbergglobal.com>
>
> Connect via LinkedIn:
>
> https://www.linkedin.com/in/heikogerstung 
> <https://www.linkedin.com/in/heikogerstung>
>
> *Von: *ntp <ntp-bounces@ietf.org> im Auftrag von Daniel Franke 
> <dfoxfranke@gmail.com>
> *Datum: *Dienstag, 11. Mai 2021 um 21:40
> *An: *Heiko Gerstung <heiko.gerstung@meinberg.de>
> *Cc: *NTP WG <ntp@ietf.org>
> *Betreff: *Re: [Ntp] A simpler way to secure PTP
>
> On Tue, May 11, 2021 at 3:14 AM Heiko Gerstung 
> <heiko.gerstung@meinberg.de <mailto:heiko.gerstung@meinberg.de>> wrote:
>
>     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.
>
> Amplification is definitely worth fixing, but ISTM this should be 
> orthogonal to the NTS effort. You don't need message authentication 
> for that, you just need the client to prove (and maybe occasionally 
> re-prove) that it's able to receive packets at a particular IP 
> address. There may be some crypto involved in doing so (a la TCP SYN 
> cookies), but it doesn't have to be related to NTS crypto, and servers 
> shouldn't have to require all their clients to support NTS just to 
> prevent themselves from being exploited for amplification.
>
> _______________________________________________ ntp mailing list 
> ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp
>
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp