[Ntp] NTP over PTP

Miroslav Lichvar <mlichvar@redhat.com> Thu, 24 June 2021 11:32 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 679853A0A55 for <ntp@ietfa.amsl.com>; Thu, 24 Jun 2021 04:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.295
X-Spam-Level:
X-Spam-Status: No, score=-2.295 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 (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 2ce51ygg2u42 for <ntp@ietfa.amsl.com>; Thu, 24 Jun 2021 04:32:52 -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 C3F153A1957 for <ntp@ietf.org>; Thu, 24 Jun 2021 04:32:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1624534371; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=wcYau+IrDNq+lkcvIefRZLhxmB7IO/3lUrHOUzbgDXQ=; b=OBXnEJDJJhJ5j2Xr/CoAIGaZ+BLX81rLHpdg8LYm1Zz+SIMkiZNDgkoR/VOGk5oWwZ8WgG LMgJXVFTBcLLCIANaZ5nZZSV4lQdb/HqitUzLuuiVCFnxcaQAtWtthwtthOWbrjEK3oT2E B5H7QIvu5ckt8ibSLIVgfdnLTEIwJ50=
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-273-Y14GvhObPBacNVE6aoANOg-1; Thu, 24 Jun 2021 07:32:49 -0400
X-MC-Unique: Y14GvhObPBacNVE6aoANOg-1
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 33C94192AB6D for <ntp@ietf.org>; Thu, 24 Jun 2021 11:32:48 +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 B1AB15D9F0 for <ntp@ietf.org>; Thu, 24 Jun 2021 11:32:47 +0000 (UTC)
Date: Thu, 24 Jun 2021 13:32:46 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: ntp@ietf.org
Message-ID: <YNRtXhduDjU4/0T9@localhost>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
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/CJtvXdNlgF_uWrTypnPRtT86F_Q>
Subject: [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: Thu, 24 Jun 2021 11:32:58 -0000

The NTP WG was asked to secure the PTP unicast mode considering it has
experience with securing NTP. The problem is that the PTP unicast mode
is very different from the NTP client/server mode, the only mode which
I think we can claim to be well secured (by symmetric key and NTS).
The closest thing to the PTP unicast mode would be the NTP control
mode (6), which is not secured (e.g. against replay attacks).

I suspect there is nothing here to be reused to secure the unicast
PTP. There might be some practical advantages of sharing NTS-KE with
NTP, but I don't see any security benefits. The two drafts that were
discussed here just need TLS and might actually be simpler if they
used it directly.

With this WG still having NTP in its name, there is the uncomfortable
question that has to be asked. Why can't you just use the NTP
client/server mode instead of the PTP unicast mode?

A point was made that there is still a lot of hardware that supports
only plain PTP. It doesn't support PTP secured by IPSec, MACSec, DTLS,
etc, either. This was apparently one of the reasons for writing the
NTS4UPTP draft.

That has a simple solution. Use PTP as a transport for NTP messages.
The hardware doesn't care what is inside as long as it can recognize
the PTP header to trigger the timestamping.

I submit this idea as a (very short) draft:
https://datatracker.ietf.org/doc/html/draft-mlichvar-ntp-over-ptp-00

I understand some people won't like this as an answer to the question
of securing the unicast PTP. It would be useful in other cases too.

But is it worth trying to invent a PTP-specific solution to secure its
unicast mode, when the result cannot possibly be as good as what NTP
already has?

As I understand it, the unicast mode of PTP was invented mainly for
some of the telco profiles, which for the most part seem to emulate
NTP. What exactly was missing in NTP when those profiles were written?
IIRC someone mentioned it was discussed with the NTP WG at the time,
but I don't have any references.

-- 
Miroslav Lichvar