Re: [Ntp] NTP over PTP

Miroslav Lichvar <mlichvar@redhat.com> Mon, 28 June 2021 13:46 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 E8F313A0771 for <ntp@ietfa.amsl.com>; Mon, 28 Jun 2021 06:46:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.996
X-Spam-Level:
X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, 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 muvNU8BLUerq for <ntp@ietfa.amsl.com>; Mon, 28 Jun 2021 06:45:58 -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 864433A0770 for <ntp@ietf.org>; Mon, 28 Jun 2021 06:45:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1624887957; 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=XaTwLOKq8EV83h2ifwunLFSKk5ZJDCw0qSRwq7gHgeU=; b=Cw2RtaqhwiO699FHcF7KEH5p6MVwTekWZEcgLROcgOtasaznV1+wO7QBlDSdhmXMFtMTpo We46EmBw5Z1WvIJbcxad2GTqbXc0l0p7vC79L5cAAcKFyF+HDkOagRw7PtLJIsBuYrGC/a sJhnmLlvbAZOT4ItFI6yNdVn2QD8Q34=
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-539-GcoX1xNnPI-9ozHigkI-wA-1; Mon, 28 Jun 2021 09:45:55 -0400
X-MC-Unique: GcoX1xNnPI-9ozHigkI-wA-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 2E38C100C66E; Mon, 28 Jun 2021 13:45:54 +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 87C18797C9; Mon, 28 Jun 2021 13:45:53 +0000 (UTC)
Date: Mon, 28 Jun 2021 15:45:51 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Heiko Gerstung <heiko.gerstung@meinberg.de>
Cc: "ntp@ietf.org" <ntp@ietf.org>
Message-ID: <YNnSj8eXSyJ89Hwv@localhost>
References: <YNRtXhduDjU4/0T9@localhost> <36AAC858-BFED-40CE-A7F7-8C49C7E6782C@meinberg.de>
MIME-Version: 1.0
In-Reply-To: <36AAC858-BFED-40CE-A7F7-8C49C7E6782C@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/IvxBs_xfOgf-zTq6HLlj3DeZP7U>
Subject: Re: [Ntp] NTP over PTP
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <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, 28 Jun 2021 13:46:01 -0000

On Fri, Jun 25, 2021 at 03:00:25PM +0200, Heiko Gerstung wrote:
> If I follow your argument that unicast PTP is like the NTP control mode then yes, both mode 6 and unicast PTP are not secured against replay and amplification attacks. The NTS4UPTP draft is exactly addressing this for unicast PTP and provides the required protection. I outlined in the draft that the proposed approach achieves most of the stated objectives/goals of NTS4NTP, which is well secured (we certainly agree on that). 

If I understand it correctly, your draft is addressing the
amplification issue by requiring client authentication. That's
probably the best one can do, but it doesn't make it comparable to NTP
or NTS4NTP. The operator will still have to trust the clients to not
abuse their credentials and also trust them to not get compromised.
That's nothing like NTS4NTP where you can run a public server without
any worry about someone exploiting your server for amplification.

> In the interim meeting I believe there have been multiple participants that agreed that 
> a) PTP should be secured (it is worth it)

At least for the normal non-unicast mode, I agree.

The unicast mode seems to be intended for networks with partial
on-path hardware support, where requirements on accuracy are less
strict, and I think this might already be better supported by NTP.

> Arguing that the two drafts on the table might just need TLS instead of NTS-KE is something I cannot understand, too. PTP already has a security mechanism that is standardized and, with some extensions (provided by the submitted drafts), can be used to significantly enhance security of the protocol. What is needed is a key exchange mechanism and some additional features to close the security holes (i.e. no protection for the source IP address) - again, exactly what the two drafts provide. 

Ok, but to me it seems it would be simpler if you have skipped NTS-KE
and went with TLS directly. Anyway, for adopting the document that
shouldn't matter.

> Regarding "NTP over PTP": trying to trick the hardware timestamping engines of a large variety of vendors into timestamping a PTP packet is bound to fail IMHO. There is no standard for how these timestamping engines work, some may even look at sizes of packets (they should not do that, as PTP messages can theoretically carry TLVs, but sometimes hardware vendors take shortcuts). Some implementations will forward packets to a management CPU when the forwarding plane detects a PTP frame. The CPU will not recognize that this is NTP and will probably throw away the packet. Again, most likely not the right way to do it, but alas ... 

If there is some hardware that can timestamp only fixed-length PTP
messages with no TLVs, then that will not work with any form of
NTS4UPTP either, right? There has to be some TLV to authenticate the
message and the hardware needs to accept that.

The same applies to one-step clocks. If implemented in silicon, that
will not work in any case.

-- 
Miroslav Lichvar