Network Time Protocol Best Current Practices
draft-ietf-ntp-bcp-13

Thank you for writing this - I found it a helpful, interesting and pleasant read. 

I do have a few comments - these are just comments, feel free to ignore, etc. 

Firstly, thanks for mentioning BCP-38 -- it feels like you are tilting at windmills here, but I appreciate your optimism :-)

'NTF' should be expanded on first use. 

I don't have any test to suggest, but "For several hours before and after the June 2015 leap second, several operators implemented leap smearing while others did not, ..." sounds like, in June 2015 a whole bunch of operators sat down at their workstations and wrote code to implement leap smearing (the word  "implemented" makes this less than clear). Perhaps "performed leap smearing" would be clearer? 

Section 4.1.  Pre-Shared Key Approach
"The MD5 hash is now considered to be too weak." -- too weak for what? (I agree, but you seem to be missing words).

Much of the test of the document seems to be "motherhood and apple pie" type advice (e.g: "Users should keep up to date on any known attacks on their selected implementation, and deploy updates containing security fixes as soon as practical."), but this is a BCP, this doesn't seem unreasonable :-)

Thanks to everyone who worked on this document! It's well-written and easy to
understand. I offer a handful of editorial suggestions below.

---------------------------------------------------------------------------

§1:

>  This document also contains information for protocol implementors who
>  want to develop their own RFC 5905 compliant implementations.

Nit: "RFC-5909-compliant" or "[RFC5909]-compliant".

---------------------------------------------------------------------------

§2.1:

>  UDP-based protocols such as NTP are generally more
>  susceptible to spoofing attacks then other connection-oriented
>  protocols.

Nit: "...than..."

The use of "other" implies that NTP is a connection-oriented protocol, which
doesn't match my understanding. I think you want to simply remove "other".

---------------------------------------------------------------------------

§3:

>  This section provides Best Practices for NTP configuration and
>  operation.  Best Practices that are specific to the NTF
>  implementation are compiled in Appendix A.

Please expand "NTF" on first use.

---------------------------------------------------------------------------

§4.2:

Maybe cite RFC 5906 here?

---------------------------------------------------------------------------

§5.2:

Some of the mitigations in here seem specific to one implementation of an NTP
daemon (e.g., reference to "minsane" and "minclock" parameters and to the
"ntp.conf" file). As the remainder of the advice in the document to this point
appears to be generic, I propose that these practices either be described in an
implementation-neutral way; or, if that is not possible, moved to Appendix A.

---------------------------------------------------------------------------

§7:

>  With anycast, a single IP address is assigned to multiple interfaces,
>  and routers direct packets to the closest active interface.

This is kind of a confusing use of the word "interface" -- a simple reading of
this sentence is that you have a single server with, say, multiple network
cards, and the router is deciding which of those cards to send a packet to.
If I didn't already know the meaning of "anycast," this description would
leave me scratching my head.  Perhaps use the term "node" or "server" instead.

---------------------------------------------------------------------------

§7:

>  As
>  anycast servers may arbitrarily enter and leave the network, the
>  server a particular client is connected to may change.

It might be worth noting in the document that these changes can happen due to
factors other than NTP servers coming online and offline, such as changes in
routing tables.  In more extreme cases -- e.g., flapping routes --  this could
result in clients switching between two different servers rapidly.

---------------------------------------------------------------------------

§A.7:

>  (This is easy to do
>  because the origin timestamp on broadcast mode packets is not
>  validated by the client.  By contrast, client/server and symmetric
>  modes do require origin timestamp validation, making it more
>  difficult to spoof packets [CCR16].

Nit: This is missing a closing parenthesis.

Thanks for addressing my DISCUSS. Previous 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.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thank you for addressing my Discuss points!