Subject: Re: [Ntp] Murray Kucherawy's Discuss on draft-ietf-ntp-mode-6-cmds-09: (with DISCUSS and COMMENT)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 Sep 2020 21:20:51 -0700

On Fri, Aug 28, 2020 at 11:02 AM Hal Murray <[email-masked]> wrote:

> I think what happened is that most of the reviewing was done while we were
> thinking Historic and we didn't go back and review things again with a
> fresh
> outlook after changing from Historic to Informational.  (I'm as guilty as
> anybody for not noticing that sooner.)
>
> Who is going to read the final document?  What is the goal?  I think the
> important next step is to get the abstract and introduction to line up
> with
> Informational.
> [...]
>

My impression from the telechat where the IESG discussed this is (and my
IESG friends are free to correct me if I'm mis-remembering) is that we
could be talked into either status, so long as the text in the document was
less ambiguous and is also consistently aligned with whatever the WG
chooses.

Some text was proposed up-thread (by Brian, I believe) that seemed like a
step in the right direction to me.  Eric also thought it was an improvement.

I'll send some detailed comments in another message.

Did you send those?  After a cursory look I didn't see anything on this
particular topic.

-MSK

---

From: Hal Murray <[email-masked]>
Date: Tue, 01 Sep 2020 23:16:36 -0700

> Did you send those?  After a cursory look I didn't see anything on this

There are a lot of people/lists on this header.  My comments were WG level 
details so in at attempt to reduce clutter, I only sent it to Brian (editor) 
and the NTP WG.

What are the policy/preferences for things like this?

---------

Subject: Comments on draft-ietf-ntp-mode-6-cmds-09
From: Hal Murray <[email-masked]>
Date: Fri, 28 Aug 2020 12:29:17 -0700
To: Brian Haberman <[email-masked]>
Cc: Hal Murray <[email-masked]>, [email-masked]

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.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 2 Sep 2020 20:24:35 -0700

> > Did you send those?  After a cursory look I didn't see anything on this

Apologies, I thought you meant you had detailed comments about the document
status discussion, and I wanted to make sure I hadn't missed something.

-MSK

---

From: Watson Ladd <[email-masked]>
Date: Fri, 4 Sep 2020 10:16:59 -0400

On Thu, Aug 27, 2020 at 7:25 AM Hal Murray <[email-masked]> wrote:
>
> What do the DNS folks to to avoid DDoS reflection amplification and/or
what do
> the people who filter NTP packets do with DNS packets?

What *should* be done is to ensure the response is no bigger than the
query, or if there is a multiplier that it is small.

Sincerely,
Watson Ladd

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 7 Sep 2020 12:43:48 +0530

Hi WG,

I support adoption. Some comments, nits, and queries to improve the I-D -

* Regarding updating RFC 5905
Please update the metadata to "Updates: 5905 (if approved)" - you
should only put the RFC number.
Please state it clearly in the abstract what text in RFC 5905 is being
updated. This should also be spelled out clearly in the body.

* Document Structure
Please add the following sections
~ Security Consideration
~ Table of Contents

* IANA
Please tell the registry name. I assume it as per RFC 6335, then would
need to provide -
   Service Name:
   Transport Protocol:
   Assignee:
   Contact:
   Description:
   Reference:
   Port Number:

* Nits
~ Can you add the description of modes in parenthesis on the first
use, you do that later in section 2.
~ Update requirement language to include RFC 8174
~ Section 2 "Both NTP requests and responses MAY be sent from the
port."; can you alternative port to avoid confusion?
~ Please add a reference for NTS

* Query
~ You state that autokey is not expected to be used, but what happens if it is?
~ There are instances of SHOULD in the text (see paragraphs 4 and 5 in
section 2), but I am not sure in which conditions that behavior is not
expected, maybe you could be clear about them, or do they need to be
MUST?

Thanks!
Dhruv

On Thu, Aug 27, 2020 at 8:01 AM Karen O'Donoghue <[email-masked]> wrote:
>
> Folks,
>
> This email starts a two week Call for Adoption on:
> https://datatracker.ietf.org/doc/draft-mlichvar-ntp-alternative-port/
>
> Please reply to the mailing list (keeping the subject line intact) regarding your position on adopting this document into the working group. Please provide any comments on the document itself as well.
>
> Regards,
> Karen
>
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 10 Sep 2020 17:26:53 +0200

> I support adoption. Some comments, nits, and queries to improve the I-D -

Thanks for your detailed comments and suggestions. I'll try to fix
them in the next version of the draft.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 16 Sep 2020 16:53:27 +0200

> I support adoption. Some comments, nits, and queries to improve the I-D -

Again, thanks for the comments. A new version of the draft is here:

https://www.ietf.org/id/draft-mlichvar-ntp-alternative-port-02.txt

> updated. This should also be spelled out clearly in the body.

I've described the new text as an addition to the section 9.1 of RFC
5905. It doesn't seem like a very good fit to me, but I couldn't find
a better place. Suggestions are welcome.

> ~ Please add a reference for NTS

There already was a reference for NTS. Did you mean it should be
moved, or was it something else?

> ~ You state that autokey is not expected to be used, but what happens if it is?

If a server has Autokey enabled, it must not respond to Autokey
requests on the alternative port. That should follow from the
specified restrictions.

> expected, maybe you could be clear about them, or do they need to be

I'm not quite sure which SHOULDs you find unclear. Some of them are
meant to prevent existing implementations from breaking the new
specification and the rest is just meant to be a recommendation,
allowing different algorithms to be implemented for selecting and
switching between the ports.

-- 
Miroslav Lichvar

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 17 Sep 2020 11:18:37 +0530

Hi Miroslav,

> a better place. Suggestions are welcome.

What you added looks good to me.

> moved, or was it something else?

I missed that reference in section 1. Just expand NTS there and we are
good to go.

> requests on the alternative port. That should follow from the

Do you see value in adding some text? The mention on auto-key in the
introduction with just -

   The first group of modes typically does not allow any traffic
   amplification, i.e. the response is not larger than the request.  An
   exception is Autokey specified in RFC 5906 [RFC5906].  Autokey is
   rarely supported on public NTP servers.

gives the impression that auto-key is not used, and no information on
what happens if it is.

> switching between the ports.

I understand.

I am wondering if it is better to differentiate between older
implementation that does not support ALTPORT with new ones that do.
And, perhaps say things like - "An NTP server that supports ALTPORT
MUST receive requests in the client mode on both the PORT (123) and
ALTPORT (TBD) ports."  A case of an NTP server that does not support
ALTPORT is already covered by the existing text in RFC 5905.

Thanks!
Dhruv