Re: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts

Miroslav Lichvar <mlichvar@redhat.com> Wed, 28 August 2019 10:37 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 BB422120090 for <ntp@ietfa.amsl.com>; Wed, 28 Aug 2019 03:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 AAFBqaSAjpax for <ntp@ietfa.amsl.com>; Wed, 28 Aug 2019 03:37:57 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20892120088 for <ntp@ietf.org>; Wed, 28 Aug 2019 03:37:57 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8655E102BB3E for <ntp@ietf.org>; Wed, 28 Aug 2019 10:37:56 +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 0B35060A35 for <ntp@ietf.org>; Wed, 28 Aug 2019 10:37:55 +0000 (UTC)
Date: Wed, 28 Aug 2019 12:37:52 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: ntp@ietf.org
Message-ID: <20190828103752.GI24761@localhost>
References: <1B4A56E7-16A6-4767-9268-BCF4BEB9A247@isoc.org> <BCA949D7-7D92-43A9-9766-573559A9FC70@meinberg.de> <5D66392D020000A100033273@gwsmtp.uni-regensburg.de> <8F6BAF5F-CC7B-47B9-90FD-BD20D6ABE845@meinberg.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8F6BAF5F-CC7B-47B9-90FD-BD20D6ABE845@meinberg.de>
User-Agent: Mutt/1.12.0 (2019-05-25)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.64]); Wed, 28 Aug 2019 10:37:56 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/azzeubwHXqN2b26n5Bmb1RNzsd8>
Subject: Re: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Wed, 28 Aug 2019 10:38:00 -0000

On Wed, Aug 28, 2019 at 12:07:53PM +0200, Heiko Gerstung wrote:
> Regarding backwards compatibility of NTPv5: I think it would be no problem to change the NTP packet format if there are requirements we want to meet that can be fulfilled more efficiently with a changed packet header. Any implementation that ignores the version field deserves whatever happens to it and, since a client mode packet contains the version number, an NTP server would most probably have to reply to a v4 client request with a v4 server response anyway. Only if an implementation sends a request with version=5 and then tries to decode the response based on a v4 packet format there will be a problem. And again, implementations doing this should go down in flames anyway IMHO. 

I think a good reason to keep v5 mostly compatible with v4, similarly
to how previous versions were compatible with one another, would be
avoiding extra complexity in both server and client implementations.

My suggestion would be to keep the NTP header 48 octets long and
change only two fields: the refid and reference timestamp. They are
ignored by current servers and most clients. That gives us 12 octets
of contiguous space in the header to work with. That's plenty for the
timescale negotiation and other metadata. Longer fields should be in
extension fields. No MACs allowed.

FWIW, I'm willing to help with the NTPv5 specification if people are
considering to start working on that.

-- 
Miroslav Lichvar