Subject: [Ntp] Alissa Cooper's Discuss on draft-ietf-ntp-bcp-10: (with DISCUSS and COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Tue, 18 Dec 2018 12:23:22 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-ntp-bcp-10: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

RFC 2119 and RFC 8174 need to be normative references.

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

Section 2.1:

s/BCP 38 [RFC2827] was approved/BCP 38 [RFC2827] was published/ (presumably the
approval was not the seminal thing)

"It is RECOMMENDED that large corporate networks (and ISP's of any size)
implement ingress and egress filtering."

I'm not really sure what the parentheses are meant to imply here. If this is a
normative recommendation for both ISPs and large corporate networks, why
doesn't it say "ISPs and large corporate networks"?

Section 3.2:

"If time sources do not generally agree, find out the cause and either
   correct the problems or stop using defective servers."

It seems odd to frame this as a directive, especially in a paragraph where the
subject is made explicit ("operators"). I think this would make more sense if
it said "operators should find out" or "operators ought to find out."

Section 3.3:

Please fix the sentence highlighted by the Gen-ART reviewer.

Section 3.4:

"To provide protection for such abuse NTP server
   operators on large networks SHOULD deploy ingress filtering in
   accordance with BCP 38 [RFC2827]."

Why is this recommendation limited to large networks, whereas the normative
recommendation to do ingress and egress filtering in Section 2.1 applies to
ISPs of any size?

Section 3.6:

I agree with the Gen-ART reviewer that the use of "you" is inappropriate here
and should be replaced by a noun (e.g., "operators").

Section 4.1:

"Therefore, for each association, keys SHOULD be exchanged securely by external
   means, and they SHOULD be protected from disclosure."

I recognize that this is outside the bounds of the protocol, but if this
document is a BCP that is going to make these normative recommendations for
what they're worth, shouldn't they be MUSTs? If not, what are the exceptional
cases where the exchange of these keys shouldn't be secure and confidential?

Section 4.2:

Same question as Section 4.1.

Section 5:

Same comment as Section 3.2. The subject to which the directive is being given
should be named.

Section 5.2:

"It is likely to become the default behavior in other
       systems as they migrate legacy init scripts to process
       supervisors such as systemd."

For posterity it may be better to say, "At the time of this writing, it appears
likely to ..."

"Operators SHOULD be aware that when operating with the above two
   conditions, the panic threshold offers no protection from attacks."

I don't think it's appropriate to use normative language about being aware.

Section 6.1:

"Vendors of embedded devices MUST pay attention to the current state
   of protocol security issues and bugs in their chosen implementation."

Same comment as 5.2, it's inappropriate to normatively require paying attention.

Section 6.2.1:

"For more information, visit ..."

Same comment as 3.2 and 5 -- this sentence needs a subject.

---

From: Denis Reilly <[email-masked]>
Date: Wed, 19 Dec 2018 20:32:49 +0000

Sorry for the confusion, we'll make RFC 2119 and RFC 8174 normative on the next revision.

Other responses are inline. Thank you for you review, Alissa.

Best Regards,

--
Denis Reilly  |  Technical Lead  |  [email-masked]  (585)321-5837

-----Original Message-----
From: Alissa Cooper <[email-masked]> 
Sent: Tuesday, December 18, 2018 3:23 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; Karen O'Donoghue <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Alissa Cooper's Discuss on draft-ietf-ntp-bcp-10: (with DISCUSS and COMMENT)

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

Section 2.1:

s/BCP 38 [RFC2827] was approved/BCP 38 [RFC2827] was published/ (presumably the approval was not the seminal thing)

--DPR: We agree, we'll change it.

"It is RECOMMENDED that large corporate networks (and ISP's of any size) implement ingress and egress filtering."

I'm not really sure what the parentheses are meant to imply here. If this is a normative recommendation for both ISPs and large corporate networks, why doesn't it say "ISPs and large corporate networks"?

--DPR: We had a discussion at one point whether small ISP’s needed to apply it, hence the language. I like your suggestion and will use it.

Section 3.2:

It seems odd to frame this as a directive, especially in a paragraph where the subject is made explicit ("operators"). I think this would make more sense if it said "operators should find out" or "operators ought to find out."

--DPR: Will change to “operators are encouraged to find out why”

Section 3.3:

--DPR: will change
"If the time on your network has to be correct close to 100% of the time, then even if you using a satellite-based system, operators need to plan for those rare  instances when the system is unavailable (or wrong!).

To
Depending on the application requirements, operators may need to consider backup scenarios in the rare circumstance when the satellite system is faulty or unavailable.

Section 3.4:

Why is this recommendation limited to large networks, whereas the normative recommendation to do ingress and egress filtering in Section 2.1 applies to ISPs of any size?

--DPR: Simply because we are using the works “networks” here more broadly than ISP’s. We considered ISP’s to be large networks by definition. We can use the same language here as in Section 2.1: ISPs and large corporate networks.

Section 3.6:

I agree with the Gen-ART reviewer that the use of "you" is inappropriate here and should be replaced by a noun (e.g., "operators").

--DPR: We’re revisiting the text generally one more time to clarify these, you will see the changes in the next revision.

Section 4.1:

I recognize that this is outside the bounds of the protocol, but if this document is a BCP that is going to make these normative recommendations for what they're worth, shouldn't they be MUSTs? If not, what are the exceptional cases where the exchange of these keys shouldn't be secure and confidential?

Section 4.2:

--DPR: We did discuss this, and decided that since there is no formally defined approach to share these keys outside the protocol, that it's unreasonable to make this a MUST. 

Section 5:

Same comment as Section 3.2. The subject to which the directive is being given should be named.

--DPR: change to “Contact the maintainers of the relevant implementation for more information.”

Section 5.2:

For posterity it may be better to say, "At the time of this writing, it appears likely to ..."

--DPR: We agree.

-- DPR: we will change this to "Operators need to be aware".

Section 6.1:

--DPR: Will change to "are advised to"

Section 6.2.1:

--DPR: Will change to "Details are available at"

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