Re: [Ntp] Shorter NTS packets?

Miroslav Lichvar <mlichvar@redhat.com> Mon, 13 December 2021 09:35 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 5F82D3A0F35 for <ntp@ietfa.amsl.com>; Mon, 13 Dec 2021 01:35:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=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 IGo-ebcWSGwM for <ntp@ietfa.amsl.com>; Mon, 13 Dec 2021 01:35:21 -0800 (PST)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.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 1500D3A0F2A for <ntp@ietf.org>; Mon, 13 Dec 2021 01:35:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1639388119; 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=l6Dmbe8X4R8YXi/GO0nB5ERtD9ocWWEk9WiBJMm87lM=; b=jCRMEll8BAJC3cF2OQVis/mGhkeeEdKhGIkT8LCnIx4fSJ+TUg+dCRx6SIPAHJcXvs83aM TGJ7u6t+JP/lBoR5EHJpiU3vDadJmGfqAXox/j8NYzn2kCFHPAwJQnyC3HmkX9GFhADdpe Xss5FGjwNmkkROO7DHfxEoSWDl8STs0=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-79-jrQJFQDIPeGF0QC4mb5Msg-1; Mon, 13 Dec 2021 04:35:17 -0500
X-MC-Unique: jrQJFQDIPeGF0QC4mb5Msg-1
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 90513801AAB; Mon, 13 Dec 2021 09:35:16 +0000 (UTC)
Received: from localhost (unknown [10.43.135.229]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BAEDA61082; Mon, 13 Dec 2021 09:35:15 +0000 (UTC)
Date: Mon, 13 Dec 2021 10:35:14 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Hal Murray <halmurray@sonic.net>
Cc: ntp@ietf.org
Message-ID: <YbcT0usgSQeXzXLN@localhost>
References: <mlichvar@redhat.com> <YbHR69xnXYUR3NY3@localhost> <20211209215746.5385B28C1BF@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
MIME-Version: 1.0
In-Reply-To: <20211209215746.5385B28C1BF@107-137-68-211.lightspeed.sntcca.sbcglobal.net>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
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/97JL-HXco162p9BRJ3Oq0kOvCnc>
Subject: Re: [Ntp] Shorter NTS packets?
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, 13 Dec 2021 09:35:22 -0000

On Thu, Dec 09, 2021 at 01:57:46PM -0800, Hal Murray wrote:
> How much of the problem will shorter packets solve?

In cases where the network blocks all NTP messages of >=204 bytes,
NTS didn't work at all. With shorter messages it should work well
until a packet is dropped for some other reason and the client
requests two or more cookies. When the client runs out of cookies, it
will restart NTS-KE and work again until a packet is dropped.

In cases where the network blocks all NTP messages between 204 and 452
bytes, NTS worked only once every four requests. With shorter messages
it should work well until a packet is dropped. Then it won't get a
response until it requests four or more cookies. Maybe clients could
implement some heuristic to detect this case and go straight from 1 to
4 cookies.

> NTS-KE includes a port number.  Can each server just pick
> a local port?

Yes, that is possible. The problem is that different servers could be
using different ports and the ports might be blocked in a local
firewall, so users would need to ask their admins to unblock them to
get NTS working.

Ideally, there would be only one port other than 123 and NTS-KE
servers would provide both ports to the clients at the same time, so
clients behind restrictive firewalls can still use the port 123 as
before.

The Port Negotiation NTS-KE record can contain only one port, but
it seems there can be multiple records of this type in a single NTS-KE
message. This should be added to the alternative-port draft if there
is a chance it will move forward.

-- 
Miroslav Lichvar