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

>>> Hal Murray <hmurray@megapathdsl.net> schrieb am 28.08.2020 um 21:29 in
Nachricht <20200828192917.1AD8840605C@ip-64-139-1-69.sjc.megapath.net>:

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

Definitely!

> 
> 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?

Yes ;-)

>   Wikipedia says OMEGA was shut down in 1997.
>   Wikipedia says GEOS‑3 was shut down in 1979.

But the ports for echo and discard are still reserved, right? ;-)
> 
> MSF is the UK version of WWVB.  I think that should be bumped up to the VLF

> line.
> DCF77 is the German equivalent.

I think we should keep the names, but not assume everybody knows what they
mean. Add some short explanation, maybe.

> 
> 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.

I guess typographical quotes. Actually I found it (with some background
knowlege): Dave was using Ventura Publisher. I found an old reference manual:
In Appendix E-4 (page 348) ist lists character codes 169 and 170 as quotes "66"
(&ldquo;) and "99" (&rdquo;), respectively.

> 
> 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 

Does it explain the attack? I feel: No...

> 
> 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?

Wouldn't it be enough to explain that the request size is N bytes, while the
response from a server (say with C clients or servers) would be M bytes?

> 
> 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.
> 
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp 