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

Miroslav Lichvar <mlichvar@redhat.com> Mon, 02 September 2019 11:19 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 2E09E120103 for <ntp@ietfa.amsl.com>; Mon, 2 Sep 2019 04:19:30 -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 oRpQMDTiAerE for <ntp@ietfa.amsl.com>; Mon, 2 Sep 2019 04:19:27 -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 68416120073 for <ntp@ietf.org>; Mon, 2 Sep 2019 04:19:27 -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 79E7318C4260; Mon, 2 Sep 2019 11:19:26 +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 AE587610C6; Mon, 2 Sep 2019 11:19:25 +0000 (UTC)
Date: Mon, 02 Sep 2019 13:19:21 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Karen O'Donoghue <odonoghue@isoc.org>
Cc: "ntp@ietf.org" <ntp@ietf.org>
Message-ID: <20190902111921.GD15024@localhost>
References: <1B4A56E7-16A6-4767-9268-BCF4BEB9A247@isoc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1B4A56E7-16A6-4767-9268-BCF4BEB9A247@isoc.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.62]); Mon, 02 Sep 2019 11:19:26 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/iyfTEmTxtYaMIpCBqnt7oJoB4Hc>
Subject: Re: [Ntp] 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: Mon, 02 Sep 2019 11:19:30 -0000

On Wed, Aug 28, 2019 at 03:37:03AM +0000, Karen O'Donoghue wrote:
> 1.  Network Time Protocol Extended Information Extension Field
> https://datatracker.ietf.org/doc/draft-stenn-ntp-extended-information/

I don't support adopting this draft. There are currently only two
pieces of information specified: the TAI offset and the interleaved
flag. The former would be better supported by the Daniel's
leap-seconds draft and the latter is unnecessary (as the draft notes).

> 2.  Network Time Protocol I-Do Extension Field
> https://datatracker.ietf.org/doc/draft-stenn-ntp-i-do/

I support adoption of this draft. I don't think this belongs to NTS-KE
or NTPv5 header as others have suggested. It might be possible to
determine the support by sending a request with a given extension
field and see if the server responds correctly, but with the I-Do
field that should scale better and also allow the requests and
responses to have a symmetric length.

> 3.  Network Time Protocol MAC/Last Extension Fields
> https://datatracker.ietf.org/doc/draft-stenn-ntp-mac-last-ef/

I don't support adoption of this draft. It doesn't seem to make
parsing of NTPv4 packets easier or allow them to contain shorter
extension fields.

> 4.  Network Time Protocol Suggested REFID Extension Field
> https://datatracker.ietf.org/doc/draft-stenn-ntp-suggest-refid/

I don't support adoption of this draft as it currently stands. I think
we do need a better reference ID, but it should be separate from the
refid field in the NTPv4 header. We need an ID that's independent from
IP addresses (e.g. randomly generated) and we need to detect
higher-degree loops. If the draft could be reworked in that direction,
I'd support its adoption. I don't think it should be specific to
NTPv5. It will most likely need an extension field and that can work
in both NTPv4 and NTPv5.

-- 
Miroslav Lichvar