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
- [Ntp] Shorter NTS packets? Miroslav Lichvar
- Re: [Ntp] Shorter NTS packets? Langer, Martin
- Re: [Ntp] Shorter NTS packets? Miroslav Lichvar
- Re: [Ntp] Shorter NTS packets? Daniel Franke
- Re: [Ntp] Shorter NTS packets? Miroslav Lichvar
- Re: [Ntp] Shorter NTS packets? Hal Murray
- Re: [Ntp] Shorter NTS packets? James Browning
- Re: [Ntp] Shorter NTS packets? Miroslav Lichvar