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

Miroslav Lichvar <mlichvar@redhat.com> Tue, 01 June 2021 15:42 UTC

Return-Path: <mlichvar@redhat.com>
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 6351F3A1C7E for <ntp@ietfa.amsl.com>; Tue, 1 Jun 2021 08:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.496
X-Spam-Level:
X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
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 4snhYSknt65Y for <ntp@ietfa.amsl.com>; Tue, 1 Jun 2021 08:42:09 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (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 3C42B3A1C7C for <ntp@ietf.org>; Tue, 1 Jun 2021 08:42:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622562128; 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=xjQXVpgIRuZYDnbbKPqNlzGZQJOuyyOm/8U71mp0kAw=; b=AS6FE5DpCi2T9ZGQnaT0LvCQgnrLRTON9Oet/2AFRSSUuxSH4FfA+sN3cfBMmo6KwQvi1z l20zeOUGcVOnVPVEIIO5LI2MAig5FbuKB+tDFeMtf+7bMdbybNfJIh530wr5x8j5sxucYu DcDxyX0Qt7ne87nhsS40Q77Lz8rlnkw=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-425-M5NnGHB4OZG82sYoZotBvg-1; Tue, 01 Jun 2021 11:42:06 -0400
X-MC-Unique: M5NnGHB4OZG82sYoZotBvg-1
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A154D6972A; Tue, 1 Jun 2021 15:42:05 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 04E3D78632; Tue, 1 Jun 2021 15:42:04 +0000 (UTC)
Date: Tue, 1 Jun 2021 17:42:03 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Heiko Gerstung <heiko.gerstung=40meinberg.de@dmarc.ietf.org>
Cc: "ntp@ietf.org" <ntp@ietf.org>
Message-ID: <YLZVS4jwGOnMIk6g@localhost>
References: <7F9B8D13-BC90-4E15-9BDF-81714DF0F0C6@meinberg.de> <YLYCLIEA4/unB6/5@localhost> <1DAA3605-CC04-46DE-8CFC-975BED7D4160@meinberg.de> <YLYheZYTSflAdlrF@localhost> <CEB3F4AA-E318-4540-BD6C-4437E3F5F58A@meinberg.de> <YLY3f2/5k1Hjebf7@localhost> <7167BC2B-1889-4DF5-AF7C-BAAAB3586841@meinberg.de>
MIME-Version: 1.0
In-Reply-To: <7167BC2B-1889-4DF5-AF7C-BAAAB3586841@meinberg.de>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlichvar@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/9Mc3ZOA-aR5ugcQR_rDHV9ZJRxk>
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: Tue, 01 Jun 2021 15:42:13 -0000

On Tue, Jun 01, 2021 at 04:18:09PM +0200, Heiko Gerstung wrote:
> > Am 01.06.21, 15:35 schrieb "Miroslav Lichvar" <mlichvar@redhat.com>om>:
> > The idea is that DTLS protects everything except the sync and delay
> > request messages. The unicast negotiation would be protected, of
> > course.
> 
> OK, that is something you have to describe in detail. 

The PTP general port (320) would move to a new port, which would be
protected by DTLS. The client would open a DTLS session with the
server on that port and use it for all messages normally transmitted
on the general port. The key needed for authentication of event
messages could be generated by the client and provided to the server
in a new TLV together with the request-unicast-transmission TLV. The
server would use the key to authenticate sync messages for the client
and verify ICV in its delay requests. Just the first thing that came
to my mind. I'm sure it could be improved.

> > You can wrap NTP messages in a PTP event message to get hardware
> > timestamps and keep all the benefits of NTS4NTP. It seems your plan is
> > to provide NTS4NTP in any case. Do you see any disadvantages?
> 
> Yes, because unicast PTP does not work in the same way as NTP. NTP is based on a request/response exchange while unicast PTP is not. I would certainly be possible to put NTP4NTS messages into PTP, but that would have the same drawback that I see with Daniel's proposal to use NTP4NTS to secure the time error of PTP: you need to setup an NTS4NTP infrastructure and basically run two sync protocols plus one security/key exchange protocol in parallel. NTS4UPTP only requires you to run one sync protocol and a key exchange protocol. 

If you used only NTP4NTS over PTP, you would still have only one sync
protocol. Just the transport is different. That's a couple lines of
code.

> I would also not be happy with the efficiency, because an NTS4NTP packet probably has some redundant or unnecessary information in it that is not required when I run unicast PTP. And, the other way around, adding a full "dummy" PTP packet header to enable using the hw timestamping engine to hardware timestamp my NTS4NTP packets is a waste of bandwidth and CPU cycles. 

If you compare the PTP header to the NTS uniq ID and cookie, I don't
think it's so bad.

> Such a NTS4NTP protocol also does not address the other advantage that unicast PTP has over NTP: higher packet rates. You can change that too, of course. In the end you created a third time sync protocol which to me looks more like a Frankenstein monster version of NTP/PTP and is a completely different beast. It will be neither compliant to NTP, nor PTP.

I'm not sure I follow here. You can send NTP requests at any rate you
like. That doesn't require a new protocol. The poll field is a signed
8-bit integer if you had a server that actually looked in the content
of the field.

Yes, server performance might be worse due to the need to decode and
encode a cookie with each request, but that's a price you need to pay
if you want all the benefits of NTS4NTP. I'd expect in most cases the
HW-timestamping to be the bottleneck. If not, you could use
AES-GCM-SIV instead of AES-SIV-CMAC for cookie encryption to get a
better performance.

> It may work and add more accuracy to NTP4NTS, but has nothing to do with PTP. And yes, you can argue that nobody needs PTP anymore in that case, but I am not sure it will be a pleasant discussion.

Right. :)

-- 
Miroslav Lichvar