[Ntp] Handling of future versions in historic implementations

Miroslav Lichvar <mlichvar@redhat.com> Thu, 22 September 2022 15:25 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 ABAABC1522CA for <ntp@ietfa.amsl.com>; Thu, 22 Sep 2022 08:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.676
X-Spam-Level:
X-Spam-Status: No, score=-7.676 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HR15n2hBI4fN for <ntp@ietfa.amsl.com>; Thu, 22 Sep 2022 08:25:13 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AADFCC1524D3 for <ntp@ietf.org>; Thu, 22 Sep 2022 08:25:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663860311; 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=7IZUrjDpPZ2jziWNwZmmaGWagHBTUlYrknu/bTytza4=; b=CXki4j61LmE84JpVV5U2BIIEE9hz5V6pwM7UdnbhZgI7Mr/9QnN+H+g9FQ+pU9v/SySoFR Y0VR1S/AoY/c23EAqltDc2DG3NLnIGSSGHHeM/rnlecPPNPsOiNrZgEz7S2gD/YR1rPSou LNnIf/raweL5WclP/+u6ldFCwqIzGJ0=
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-593-SUnR_N_EMJ-GLkiyOSdECw-1; Thu, 22 Sep 2022 11:25:10 -0400
X-MC-Unique: SUnR_N_EMJ-GLkiyOSdECw-1
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2004A3C11045 for <ntp@ietf.org>; Thu, 22 Sep 2022 15:25:10 +0000 (UTC)
Received: from localhost (unknown [10.43.135.229]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BD4D140C6EC2 for <ntp@ietf.org>; Thu, 22 Sep 2022 15:25:09 +0000 (UTC)
Date: Thu, 22 Sep 2022 17:25:08 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: ntp@ietf.org
Message-ID: <Yyx+VOkuFCAuBBYb@localhost>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2
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/c2tCFnMQcvqXyqK_2NpUuTNCvr8>
Subject: [Ntp] Handling of future versions in historic implementations
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: Thu, 22 Sep 2022 15:25:17 -0000

I did a bit of archeology to see how the older NTP implementations
handled future versions, now that there are some concerns about NTPv5
making incompatible changes.

>From what I understand, NTPv0 was implemented by David Mills in assembly
for the Fuzzball router. I found a disk image that contains some text
related to NTP, but I didn't find an easy way to disassemble it and
even if I did I'd probably not understand it well enough to find the
instructions working with the reserved fiel which become the version
field in later specifications. If anyone would like to try that,
please let me know.

The NTPv1 implementation (ntpd) was written by Louis A. Mamakos and Mike
Petry in C. In the code I found (from May 1989) in the main() function
there is:

	if ((pkt->status & VERSIONMASK) != NTPVERSION_1)
		continue;

	receive(dst, pkt, &tv, i);

That is, future versions were ignored.

The NTPv2 implementation seems to be a new implementation written from
scratch by Dennis Fergusson. This is the origin of "xntpd". In the code
that is available on www.eecis.udel.edu (from Nov 1989) there is:

	if (PKT_VERSION(pkt->li_vn_mode) == NTP_VERSION) {
		sys_newversionpkt++;
	} else if (PKT_VERSION(pkt->li_vn_mode) == NTP_OLDVERSION) {
		sys_oldversionpkt++;
	} else {
		sys_unknownversion++;
		return;
	}

Again, future versions were ignored.

The NTPv3 implementation was based on the NTPv2 xntpd and the NTPv3
support was implemented by Lars H. Mathiesen (according to the
COPYRIGHT file). In the code (from June 1994) there is:

	if (PKT_VERSION(pkt->li_vn_mode) >= NTP_VERSION) {
		sys_newversionpkt++;
	} else if (PKT_VERSION(pkt->li_vn_mode) >= NTP_OLDVERSION) {
		sys_oldversionpkt++;
	} else {
		sys_unknownversion++;
		return;
	}

This seems to be intentionally handling future versions as compatible
with NTPv3.

The NTPv4 support was implemented in xntpd by David Mills and it was
renamed to ntpd. In the current version of the code there is:

	if (hisversion == NTP_VERSION) {
		sys_newversion++;		/* new version */
	} else if (   !(restrict_mask & RES_VERSION)
		   && hisversion >= NTP_OLDVERSION) {
		sys_oldversion++;		/* previous version */
	} else {
		DPRINTF(2, ("receive: drop: RES_VERSION\n"));
		sys_badlength++;
		return;				/* old version */
	}

The future versions are accepted as "previous version". This might
seem like a bug, but from what we have heard on this list recently,
it was intended.

So, it seems this idea of future versions being compatible with older
versions started with NTPv3, but for some reason it wasn't specified
in RFC 1305 or RFC 5905.

-- 
Miroslav Lichvar