[Ntp] Comments on draft-ietf-ntp-mode-6-cmds-09

Hal Murray <hmurray@megapathdsl.net> Fri, 28 August 2020 19:29 UTC

Return-Path: <hmurray@megapathdsl.net>
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 D72363A0965 for <ntp@ietfa.amsl.com>; Fri, 28 Aug 2020 12:29:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.137
X-Spam-Level: *
X-Spam-Status: No, score=1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HDRS_LCASE=0.1, HELO_DYNAMIC_IPADDR=1.951, PDS_RDNS_DYNAMIC_FP=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ROkYTVmgEQz4 for <ntp@ietfa.amsl.com>; Fri, 28 Aug 2020 12:29:21 -0700 (PDT)
Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id D6E573A0969 for <ntp@ietf.org>; Fri, 28 Aug 2020 12:29:20 -0700 (PDT)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 1AD8840605C; Fri, 28 Aug 2020 12:29:17 -0700 (PDT)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: Brian Haberman <brian@innovationslab.net>
cc: Hal Murray <hmurray@megapathdsl.net>, ntp@ietf.org
From: Hal Murray <hmurray@megapathdsl.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Aug 2020 12:29:17 -0700
Message-Id: <20200828192917.1AD8840605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/K_TF_OjT__RJxMy8sGunSif-6v8>
Subject: [Ntp] Comments on draft-ietf-ntp-mode-6-cmds-09
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: Fri, 28 Aug 2020 19:29:23 -0000

Bottom of page 6: "suggested elsewhere in this document"
I think a section number would help.

Page 5, first paragraph of section 2: "Bit positions marked as 0..."
There aren't any.

Page 5 - packet diagram.  The Authenticator says "96 bits".
That should be 20 or 24 bytes.

I don't know of an up to date reference for NTP shared key authentication.  We 
should at least reference RFC 8573 Message Authentication Code for the Network 
Time Protocol

Do we want to say more?  I think we can come up with something in a few 
paragraphs.  Maybe an appendix?

Page 7: The Authenticator description refers to RFC 1305.  We need something 
better.  See above.

Page 9: "OMEGA", "MSF", and "GEOS"
  Does anybody even know what OMEGA and GEOS were?
  Wikipedia says OMEGA was shut down in 1997.
  Wikipedia says GEOS-3 was shut down in 1979.

MSF is the UK version of WWVB.  I think that should be bumped up to the VLF 
line.
DCF77 is the German equivalent.

Page 13:  The pdf as printed on my printer has several instances of "<169>" 
and "<170>".  I can't figure out what they are trying to tell me.  It looks 
like they might be left/right quotes.

Page 13: There are several references to variables in RFC 5905.  I think 
that's too restrictive.  It doesn't allow for new variables such as counters 
for NTS.  How about something like "such as the ones described in RFC 5905"?

Page 14, Read variables: "and values".  I don't think values make sense when 
reading.  That idea belongs in the next paragraph.

Page 15/16:  Are the details of the nonce relevant?  I think of it as a string 
to be returned.  (I would have called it a cookie rather than a nonce.)

Page 17: Should the discussion of time-shifting attacks mention 
data-minimization?
  https://tools.ietf.org/html/draft-ietf-ntp-data-minimization-04

Page 17, last paragraph.   I think it is common to allow query from the local 
network.  That paragraph hints at it, but doesn't actually say that ntpd (or 
at lease some implementations) has an access control list.

Page 18, top paragraph.  The mode 7 monlist was nuked many years ago and 
replaced by a mode 6 Read MRU(10) that needs a nonce.  Is there a good writeup 
of the monster DDoS event that triggered that change?

Page 20, packet chart: The optional MAC should be 16 or 20 bytes.  This packet 
chart splits the Authentication into KeyID and MAC.  The corresponding chart 
for mode 6 on page 5 lumps them together.  Should we be consistent?

Page 21, MAC: "defined by the version..."  Huh?



-- 
These are my opinions.  I hate spam.