Re: [Ntp] Ben Campbell's No Objection on draft-ietf-ntp-bcp-10: (with COMMENT)

[Denis Reilly <[e-mail]>]

Hello, Ben! Thanks for the review. I've posted a new version of the draft which incorporate the feedback from the review.

Please see responses in-line:

--
Denis Reilly  |  Technical Lead  |  [e-mail]  [phone]

-----Original Message-----
From: Ben Campbell <[e-mail]> 
Sent: Wednesday, December 19, 2018 6:39 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; Karen O'Donoghue <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Ben Campbell's No Objection on draft-ietf-ntp-bcp-10: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-ntp-bcp-10: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ntp-bcp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi, thanks for this work. I'm balloting "no objection", but have a few
comments/questions:

*** Substantive Comments ***

General observation: I was surprised to find that that a lot of the recommendations here don't seem especially specific to NTP. (E.g. keeping implementations up to date.) But I don't suppose that's really an problem, so I don't expect action here.

--


§2.1, last paragraph: "It is RECOMMENDED that large corporate networks (and ISP’s of any size) implement ingress and egress filtering."

Is that a new normative requirement, or an existing requirement from BCP38? If the latter, please consider using description language rather than normative keywords.

Response:
BCP38 / RFC 2827 doesn't use any normative language, so  it's a new normative recommendation from this BCP.

--


§3.3: This section recommends that operators choose time servers with different implementations/technology. Are time sources expected to publicize that sort of information?

Response:
We're calling attention to the fact that having a diversity of timing sources is not as simple as having two boxes from the same vendor. If you are using time sources that are not under your direct control, it can be hard to obtain this information, but perhaps operators would have better luck with servers within their own organizations.

--


§3.4: Am I correct to assume that "control messages" and "mode 6 messages" are the same thing? Please use consistent terminology.

Response:
We'll choose "NTP Control Messages".

--

§3.6:
- First Paragraph: "Users who want to
synchronize their computers SHOULD only synchronize to servers that they have permission to use."
Why not MUST?

Response:
We originally made this SHOULD because we felt that many users don't really have control over which servers they use, and so we couldn't realistically make the guidance that strong. But in response to another comment, we changed this text to "Network operators and advanced users", so with that narrower focus now MUST is more appropriate.

We also changed the similar guidance in the section on embedded devices to MUST.

--

- 2nd paragraph: Is the NTP Pool stabile enough for a plug like this in an RFC?
Remember, RFCs live "forever". (see also §6.2.1)

Response: 
It's been around for quite a while and the members of the working group think it's stable enough to include.

--

§3.7: "Note well that NTPv4’s longest polling interval exceeds one day and thus a leap second announcement may be missed."
Is that okay? Is there any action recommended due to this?

Response:
Changed to read:
When implementing this recommendation, 
operators should ensure that clients are not configured to use polling intervals
greater than 24 hours, so the leap second notification is not missed

--

§3.7.1, last paragraph: How does a client know if the server does leap second smearing?

Response: 
There is no standard way to detect this at this time. Someone has to ask the server administrator.

--

§4.1:
- "Therefore, for each association, keys SHOULD be exchanged securely by external means, and they SHOULD be protected from disclosure." Why not MUST (both times)?

Response:
Several others have brought this up, we're changing these to MUSTs.

--

- "Implementations will soon be available based on AES-128-CMAC [I-D.ietf-ntp-mac], and users are encouraged to use that when it is available."
Is that worth a normative requirement?

Response:
Yes, especially since it seems that draft will emerge first.

--

- "Some implementations store the key in clear text"
Wouldn't the better practice to be not to do that?

Response:
Yes, but we need to address the current state of things.

--

§5.1:
- 3rd paragrap: "A host that is not supposed to act as an NTP server that provides timing information to other hosts MAY additionally log and drop incoming mode 3 timing queries from unexpected sources."

 i don't understand the point. Also, is the upper-case "MAY''intended as  permission to do that?

Response:
we changed this to non-normative in the latest draft. This section is about minimizing information leakage. One way to do this is simply to not respond to packets that it doesn't have to.

--

- last paragraph: "Note well that proper monitoring of an NTP server instance includes checking the time of that NTP server instance." Should there be normative guidance here? (Also, the sentence seems out of place.)

Response:
The normative guidance is at the end now. 
We are pointing out here that while you might want to drop all Mode 3 packets, they do have some use for monitoring within your organization.

--

§6.1: "Vendors of embedded devices MUST pay attention"
Can you recommend something more concrete (and verifiable) than "pay attention"?

Response:
We've made this non-normative in response to another comment.

--

*** Editorial Comments ***

§2.1: "more susceptible to spoofing attacks then other connection-oriented
protocols": s/then/than Also, it seems like "other" is not descriptive here, since UDP is not a connection-oriented protocol.

Response:
We removed the "other" in the latest draft.

--

§3.4:
-  first paragraph: The last sentence will not hold up well to the passage of time. Please consider adding something to the effect of "At the time of this writing..." - Last paragraph: The last sentence seems redundant to the section on BCP38.

Response:
Agree on both points. The last paragraph now directly references the BCP38 section instead of repeating the recommendation.

--

§5.1, 3rd paragraph: It is recommended that operators SHOULD filter mode 3 queries at the edge "recommended that...SHOULD" is redundant. Please consider just saying "Operators SHOULD..."

Response: We Agree.

--

§5.4: Is a KoD packet and a RATE packet the same thing? (Please use consistent
terminology)

Response: 
We discuss both the broader KoD packets here, and the RATE packets which are a primary use of the KoD mechanism. We've made some changes to the text to clarify the distinction between the two.

§11.2: Is there a reason [BCP38INFO] is here and not in the URL references?

Response (From Denis): 
Actually, this was an attempt to fix how that URL is rendered on the HTML view of the document. (See https://tools.ietf.org/html/draft-ietf-ntp-bcp-10 ) 
I guess since this URL has the text "BCP" in it, it doesn't render properly. I will revert it back to a URL reference, but then I will need to get some professional help on this, perhaps from the RFC Editor?


ATTENTION: This email came from an external source.
Do not open attachments or click on links from unknown senders or unexpected emails.