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

Miroslav Lichvar <mlichvar@redhat.com> Wed, 28 August 2019 11:15 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 25ACF120105 for <ntp@ietfa.amsl.com>; Wed, 28 Aug 2019 04:15:03 -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 or7Fze8cRaQk for <ntp@ietfa.amsl.com>; Wed, 28 Aug 2019 04:15:02 -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 305A7120100 for <ntp@ietf.org>; Wed, 28 Aug 2019 04:15:02 -0700 (PDT)
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 mx1.redhat.com (Postfix) with ESMTPS id DC0CB7EB89 for <ntp@ietf.org>; Wed, 28 Aug 2019 11:15:01 +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 6006360C80 for <ntp@ietf.org>; Wed, 28 Aug 2019 11:15:01 +0000 (UTC)
Date: Wed, 28 Aug 2019 13:14:58 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: ntp@ietf.org
Message-ID: <20190828111458.GJ24761@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> <20190828103752.GI24761@localhost> <3f4b55ca-02d9-a470-229b-40860866efbf@nwtime.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3f4b55ca-02d9-a470-229b-40860866efbf@nwtime.org>
User-Agent: Mutt/1.12.0 (2019-05-25)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.71]); Wed, 28 Aug 2019 11:15:01 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/wsxIdm4Ke6fN0iojSIe7uFtkt6w>
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 11:15:03 -0000

On Wed, Aug 28, 2019 at 03:42:15AM -0700, Harlan Stenn wrote:
> On 8/28/2019 3:37 AM, Miroslav Lichvar wrote:
> > My suggestion would be to keep the NTP header 48 octets long and
> > change only two fields: the refid and reference timestamp. They are
> 
> If you change the refid field how will you effect degree 1 loop detection?

Hopefully with something better than the current refid field based on
(hashes of) addresses. Something like your suggested-refid proposal,
except the extension field would contain both the ID of the server
(randomly generated) and the ID of the its reference.

This could fit into the space of the NTPv4 refid and reference
timestamp, but it would take 64 of those 96 bits and I'm not sure if
32 bits is enough for the other new stuff.

> > 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.
> 
> I assume you meant "No >legacy< MACs allowed."

Right.

-- 
Miroslav Lichvar