Re: [Ntp] Quick review of WGLC for status change for draft-ietf-ntp-update-registries

Miroslav Lichvar <mlichvar@redhat.com> Mon, 08 August 2022 12:39 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 3D8F2C13CCDA for <ntp@ietfa.amsl.com>; Mon, 8 Aug 2022 05:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.688
X-Spam-Level:
X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.582, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4FOoZMvm0hO for <ntp@ietfa.amsl.com>; Mon, 8 Aug 2022 05:39:13 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.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 BB478C15C537 for <ntp@ietf.org>; Mon, 8 Aug 2022 05:39:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1659962352; 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=QwR96eTtSyVIFC/pH6+aCuqkJ+GDPoeWJCtAyxZGpfw=; b=hYjJzUTUnRlqIRs4JvpPZ2xvKPOynveDZvhB3fQ97mGGD1EwkRF8oa6kUlqFLaBFXVCj+P 7MRSEnUeK8k7LBFSs8o6c5E9aeEYmVvJMYALrRssg64ZitMM9s4ZWI2zL7xUjxZ2W7kGdi uVohmjbRuf3sdarFDwqnNJaB6rWknbM=
Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-360-pA-CrSWZMNue5pW_QD86Nw-1; Mon, 08 Aug 2022 08:39:11 -0400
X-MC-Unique: pA-CrSWZMNue5pW_QD86Nw-1
Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 00D6E3801F52; Mon, 8 Aug 2022 12:39:11 +0000 (UTC)
Received: from localhost (unknown [10.43.135.229]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 84D5A492CA2; Mon, 8 Aug 2022 12:39:10 +0000 (UTC)
Date: Mon, 08 Aug 2022 14:39:09 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Harlan Stenn <stenn@nwtime.org>
Cc: ntp@ietf.org
Message-ID: <YvED7T5R0UsRWbv3@localhost>
References: <PH0PR06MB7061FA7A5B338D262B3A2963C2999@PH0PR06MB7061.namprd06.prod.outlook.com> <6a187a2f-9883-2fb5-1f51-1593591ddebb@nwtime.org> <PH0PR06MB706126984E4442EF32F8242AC2999@PH0PR06MB7061.namprd06.prod.outlook.com> <da155c84-2c70-2e3b-59eb-03e380806cf2@nwtime.org> <PH0PR06MB70611F2331D8255F7E2B6604C2999@PH0PR06MB7061.namprd06.prod.outlook.com> <0b4c7efa-3977-b588-0974-33b6a9437e52@nwtime.org> <YvDWC27qKnODlD52@localhost> <0b57b7db-772e-f5e6-e6a0-a433673f3d77@nwtime.org>
MIME-Version: 1.0
In-Reply-To: <0b57b7db-772e-f5e6-e6a0-a433673f3d77@nwtime.org>
X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9
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/qdXEE2atTK2qRnMUsH56f7W6LPk>
Subject: Re: [Ntp] Quick review of WGLC for status change for draft-ietf-ntp-update-registries
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
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, 08 Aug 2022 12:39:16 -0000

On Mon, Aug 08, 2022 at 03:35:40AM -0700, Harlan Stenn wrote:
> While re-reading to find my answer, I note 4.3 says that Field Types from
> 0xF000 through 0XFFFF are reserved for experimentation and development.
> 
> This makes no sense to me.
> 
> If this experimental/development work is done "privately" then nobody cares
> what value is used.

It avoids conflicts with properly specified extension fields. With an
experimental extension field the user is responsible to enable it only
if the server is known to support it.

> Next, if this experimental/development work gets turned into a Standard,
> then implementations will likely need to support both the Standard and the
> experimental versions.  That's needless code bloat.

No, if it's documented as an experimental feature, it can be dropped
or changed at any time.

One use case is testing of some NTPv5 features. We can't use NTPv5 as
it doesn't exist yet, but we can use an experimental NTPv4 extension
field that contain the new NTPv5 fields.

> I'll also point out that, as noted in draft-stenn-ntp-extension fields, a
> number of 0xFxFF values are being used for the I-DO extension field
> proposal, as documented in draft-stenn-ntp-i-do.

The draft expired long time ago. If you decide to resubmit it, I'm
sure you can change it to another value.

But I don't think the I-DO EF is a good solution to the issue with
ambiguous parsing. It assumes the server doesn't change since the
support was negotiated. NTP is (mostly) stateless. The client cannot
be sure it's talking to the same server from which it received the
last response. A server can be changed, upgraded, or redirected in
network.

> Also, as I'm more carefully reading the proposal, I find it curious that you
> are are not objecting to its citing of 5906. I recall that you have
> explicitly ignored that document when writing chrony, at least around the
> numeric range of keyIDs, because 5906 was "informational" and not listed as
> an optional Standard.

chrony does not support Autokey. It doesn't care that keys with some
specific IDs are generated automatically. It cannot authenticate as an
Autokey server and will not accept a response from an Autokey server.

> > The Checksum Complement EF (0x2005) is present in the table 1, but it
> > is incorrectly described as "Reserved for historic reasons". That
> > should be changed to refer to RFC 7821. Only the Autokey-related
> > entries should be "Reserved for historic reasons".
> 
> I do not believe there is *any* reason that the V1 EF format values
> (assuming that is what the "Reserved for historic reasons" is referring to)
> cannot be used by the current/V2 handlers.

V1 and V2 is specific to Autokey. There is a specification which
nobody follows. There is an implementation that uses unspecified
values. The table is trying to cover all values. I don't think it
matters which one is marked as "reserved for historic reasons". What
is important is that nothing else will be using them. We already had a
collision with one of the NTS extension fields. That must be
prevented.

-- 
Miroslav Lichvar