Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

Heiko Gerstung <heiko.gerstung@meinberg.de> Mon, 08 March 2021 12:41 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 C25313A0E30 for <ntp@ietfa.amsl.com>; Mon, 8 Mar 2021 04:41:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 Uh9jo0oVkTz0 for <ntp@ietfa.amsl.com>; Mon, 8 Mar 2021 04:41:45 -0800 (PST)
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 1C08A3A0E31 for <ntp@ietf.org>; Mon, 8 Mar 2021 04:41:45 -0800 (PST)
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 81DD371C0EFB; Mon, 8 Mar 2021 13:41:42 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=dkim; t=1615207302; 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=HKzA6cn0QryQag8U9IpKqKdQ2u13eLlFFaX10/1UnzQ=; b=l8oYxU6gKuDmN8l9RAUGADj//QrlcjawXjzkG3NqtyWyAV214sg0Io9aWdzldmyBmnE15V CrffSt3MaRmVueRnFjx9JO62MB5wU5Si0bVFusLGMiBCRKc9gHY7TKEiVQ/2jA/6GDWMGt lHvy67nX2SKXlYhudT1/SZ+DbbtB8d0cPrdGbWt04xfhCQ3g0rWn8C+FRDZltYn+2c4PJR qEeuqb+crZxWty7eAt61bnuYI6oUSTUihxx0Ng4fokF+1F+IrMe0ixkQb/o8WUjop0Sqnw +Bvra+crlW3UnPl4VShIIP4wqGSpSyT9YSWSbgTQpk0n+m1hfdKVVleHsEpHKQ==
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; Mon, 8 Mar 2021 13:41:41 +0100 (CET)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.46.21021202
Date: Mon, 8 Mar 2021 13:41:40 +0100
Message-ID: <6626A848-B90A-4858-8807-833FD74E6A09@meinberg.de>
Thread-Topic: [Ntp] Comments on draft-langer-ntp-nts-for-ptp
References: <CACsn0cnz1GfKUKn6q61qmAbs=VPgTGFZnP=kEeQHk9CUxLACXg@mail.gmail.com> <f51dfb1db7c843ecaf58efac526d30ef@ostfalia.de> <6C614D22-A00E-432E-A65E-9A21F8B4476E@meinberg.de> <YEYHHhIrYv4ZhTkl@localhost>
In-Reply-To: <YEYHHhIrYv4ZhTkl@localhost>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+NmUxZmZlYTJhY2NhZTU2Mg==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: Miroslav Lichvar <mlichvar@redhat.com>
Cc: "Langer, Martin" <mart.langer@ostfalia.de>, Watson Ladd <watsonbladd@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="----61274970B00A9DB594AF4E3A60EB9674"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/TQmMB4rs98XI0KHdYGnb89ocRwY>
Subject: Re: [Ntp] Comments on draft-langer-ntp-nts-for-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: Mon, 08 Mar 2021 12:41:51 -0000

Hi Miroslav,

even if cookies would not be required, I would still want to keep this concept simply because we can re-use the whole NTS4NTP mechanism and do not have to invent yet another protocol etc. 

Plus, you do not need any state for the unicast negotiation itself. It is a short, quick packet exchange between a client and a GM and once it has been completed, the GM does not need to store any data about the client for the next unicast negotiation. When successful, the GM enters the packet transmission phase (which requires state as the GM needs to set up a packet transmission for a slave), but using the cookie concept for the unicast negotiation phase would allow a NTS-KE server to hand out cookies to a NTS/PTP client who could then use them to request packet transmission from a separate list of Unicast GMs. 

These Unicast GMs would not need any per-client information from the NTS-KE server instance as they can verify the cookie to make sure this is a valid and authorized NTS client. And then it can use the keys included in the cookie to secure the packet transmission.

If you look at this from  the viewpoint of NTS4NTS, you can basically have an identical phase 1 and phase 2 in NTS4NTP is the actual NTP req/resp exchange whereas in NTS4PTP this is the Unicast Transmission Request and Grant exchange. Up until this point, both can use the same mechanisms. Now, in PTP you have another phase (phase 3) which can have much higher traffic requirements (e.g. 128 pkt/s for one client) and therefore should only use the symmetric C2S and S2C keys. 

My proposal is to keep NTS identical between NTP and PTP for phases 1 and 2 and solve phase 3, e.g. by using the symmetric keys established/exchanged in phase 1.

If we choose to go for a completely different approach, this will most probably slow down adoption and we should really not call it NTS anymore... ;-) 

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 08.03.21, 12:15 schrieb "Miroslav Lichvar" <mlichvar@redhat.com>:

    On Mon, Mar 08, 2021 at 11:43:29AM +0100, Heiko Gerstung wrote:
    > As far as I can see, up until this point the mechanism can be very similar to NTS4NTP. We most probably need a different cookie format, but the rest should be OK. Once we did 1 + 2, the unicast master will start the PTP packet transmission to the authenticated (via the cookie) PTP client. The client will also start sending Delay Req packets and requires the GM to respond with unicast delay responses. 
    > 
    > During this packet transmission phase I propose to use the S2C to secure the packets from the GM to the client (ANNOUNCE, SYNC, DELAY_RESP) and the C2S key to secure the packets from the NTS/PTP client to the GM (i.e. DELAY_REQ). 

    I don't think it makes sense to use NTS cookies in PTP, even if you
    limit the NTS support to the unicast mode. The main point of the
    cookies is to avoid having client-specific state on the server. That's
    not possible in PTP as announce and sync messages are not responses to
    requests. They are sent at their own interval, which can be different
    from the delay request interval.

    In PTP there has to be some client-specific state and the clients need
    to be authenticated. Very different from NTS-for-NTP.

    -- 
    Miroslav Lichvar