Subject: [Ntp] Last Call: <draft-ietf-ntp-bcp-07.txt> (Network Time Protocol Best Current Practices) to Best Current Practice

From: The IESG <[email-masked]>
Date: Mon, 24 Sep 2018 10:07:07 -0700

The IESG has received a request from the Network Time Protocol WG (ntp) to
consider the following document: - 'Network Time Protocol Best Current
Practices'
  <draft-ietf-ntp-bcp-07.txt> as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2018-10-08. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

   NTP Version 4 (NTPv4) has been widely used since its publication as
   RFC 5905 [RFC5905].  This documentation is a collection of Best
   Practices from across the NTP community.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ntp-bcp/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ntp-bcp/ballot/

No IPR declarations have been submitted directly on this I-D.

The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc1305: Network Time Protocol (Version 3) Specification, Implementation and Analysis (Draft Standard - Legacy stream)
    rfc5905: Network Time Protocol Version 4: Protocol and Algorithms Specification (Proposed Standard - IETF stream)
    rfc7384: Security Requirements of Time Protocols in Packet Switched Networks (Informational - IETF stream)
    rfc7094: Architectural Considerations of IP Anycast (Informational - IAB stream)

---

From: Steven Sommars <[email-masked]>
Date: Tue, 25 Sep 2018 19:46:38 -0500

Some comments on draft-ietf-ntp-bcp-07:

Section 2, paragraph 1, refers to "best way to detect ..."  Please reword
to remove "best".  [High reliability might also utilize traceable time,
authenticated time exchanges, local stratum ones, etc.]

Section 4.1, typo:  combing -> combining

Section 4.1.  The first section in this section asserts that all NTP
implementation perform intersection, clustering, and combining.
According to https://chrony.tuxfamily.org/comparison.html, Chrony does not
do clustering.
Suggest changing to "... sophisticated algorithms such as intersection,
clustering and combining".

Section 4.1, next to last paragraph.  Change "During the leap second of
June of 2015, " to "For several hours before and after the June 2015 leap
second,"

Section 4.2. Comment.  It may be difficult to put this into practice if the
stratum 1 servers reside in other organizations

Section 4.3,  Most NTP servers (90%+ in my tests) block remote mode 6
messages.
Important NTP implementations (e.g., chrony) do not implement the mode 6
commands.
Please mention these limitations of mode 6.

Section 4.4   The paragraph mentioning ntp-4.2.8p6 and ntp.keys is too
implementation specific.  Please remove it.

Section 4.6, nit   "ntp server" -> "NTP server"

Section 4.6.1   There are traps aplenty when leap smearing is in effect.
E.g., how does a client determine whether an upstream source is, or is not
smeared?
The best current practice for leap smearing is to not use it.

section 6.1,   The protections should be done by the individual client
software(e.g., ntpd) not by the host.

On Mon, Sep 24, 2018 at 12:11 PM The IESG <[email-masked]> wrote:

>     rfc1305: Network Time Protocol (Version 3) Specification,
> Implementation and Analysis (Draft Standard - Legacy stream)
>     rfc5905: Network Time Protocol Version 4: Protocol and Algorithms
> Specification (Proposed Standard - IETF stream)
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 26 Sep 2018 08:14:51 +0200

>>> Steven Sommars <[email-masked]> schrieb am 26.09.2018 um 02:46 in
Nachricht
> clustering and combining".

Maybe use "all conforming NTP implementations", so chrony would be non-conforming. I think the clustering algorithm is part of the NTP specification.

> Important NTP implementations (e.g., chrony) do not implement the mode 6

I don't know whether crony is "important". Maybe it's "common".

> software(e.g., ntpd) not by the host.

As I did not receive any comments on my change proposals from August, I'm attaching them to this message again...

Regards,
Ulrich

>>     rfc7094: Architectural Considerations of IP Anycast (Informational -

Subject: Antw: [Ntp] I-D Action: draft-ietf-ntp-bcp-07.txt
From: "Ulrich Windl" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Date: Sat, 25 Aug 2018 23:29:57 +0200

Hi!

Sorry for the late reply, but I have change proposal regarding the headings and ordering (not to talk about actual contents now). At the moment there is:
1.  Introduction
1.1.  Requirements Language
2.  Keeping NTP up to date
3.  General Network Security Best Practices
4.  NTP Configuration Best Practices
5.  NTP Security Mechanisms
6.  NTP Security Best Practices
7.  NTP in Embedded Devices
8.  NTP over Anycast
9.  Acknowledgements

[...]

I would put 2. to 8. into a single big section named "Recommendations".

Then I'd put 2. at the beginning of 3. (possibly making a 3.1, i.e. 2.1.1 if the new "2." is "Recommendations and 2.1 is "General Network...".
(Alternatively it could be put at the beginning of the existing 6.)
I'd put 5 as a sub-item of 6.
Maybe rename 7 to "Special Configurations", putting the old 7. as sub-item.
I feel that 8. would fit inside the old 4 as sub-item.

Regards,
Ulrich
>>> <[email-masked]> 31.07.18 21.18 Uhr >>>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Time Protocol WG of the IETF.

        Title           : Network Time Protocol Best Current Practices
        Authors         : Denis Reilly
                          Harlan Stenn
                          Dieter Sibold
	Filename        : draft-ietf-ntp-bcp-07.txt
	Pages           : 23
	Date            : 2018-07-31

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ntp-bcp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ntp-bcp-07
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-bcp-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-bcp-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Subject: Antw: [Ntp] I-D Action: draft-ietf-ntp-bcp-07.txt
From: "Ulrich Windl" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Date: Sun, 26 Aug 2018 00:42:00 +0200

Hi!

Another remark on "The NTP Control Messages responses are much larger than the
   corresponding queries.  Thus, they can be abused in high-bandwidth
   DDoS attacks.  To provide protection for such abuse NTP server
   operators should deploy ingress filtering BCP 38 [RFC2827].": If I understood it correctly, the ingress filtering has to be done by the attacker's ISP (where the bad packet enters the net). At the destination you possibly cannot do ingress filtering unless you want to disallow any packets outside the current subnet or the company's nets. If I misunderstood the advice, others may do as well, so please elaborate what operators should actually do.

On "If a system is a broadcast client and its syslog shows that it is
   receiving "early" time messages from its server, that is an
   indication that somebody may be forging packets from a broadcast
   server.":
Maybe elaborate on use of authentication for broadcast clients: Should use of (strong) authentication keys be recommended?

On "If a system is using broadcast mode and is running ntp-4.2.8p6 or
   later, use the 4th field of the ntp.keys file to specify the IPs of
   machines that are allowed to serve time to the group.":
I think it's too specific: Why not state "If your NTP client (it's describing a client, right?) allows to filter valid time sources, please use it (for eaxmple ntp-4.2.8p6 allows to put valid IP... in the 4th field of ..."

Maybe rename "Using Pool Servers" to "Selecting Servers to use", because it's more general than just pool servers.
I would prefix the paragraph starting with "The NTP pool project is a group ..." with a general explanation that some NTP software is able to process a DNS response for a server name containing multiple IP addresses of different servers to pick some of those servers as time sources. THEN proceed explaining the NTP pool server project. Maybe also emphasize that "ingress filtering should not block pool servers" if they are intended to be used.

I would combine these two paragraphs: "If you are a vendor who wishes to provide time service to your
   customers or clients, consider joining the pool and providing a
   "vendor zone" through the pool project." and "If you would like to contribute a server with a static IP address and
   a permanent Internet connection to the pool, please consult the
   instructions at http://www.pool.ntp.org/en/join.html [3] .".

You could add "up to twice a year" at the end of: "UTC is kept in agreement with the astronomical time UT1 [4] to within
   +/- 0.9 seconds by the insertion (or possibly a deletion) of a leap
   second."

I would change "and the protocol has the
capability to broadcast leap second information" to "and the protocol has the
capability to broadcast and process leap second information".

Change "Note well that NTPv4 allows a maximum poll
interval of 17, or 131,072 seconds, which is longer than a day." to "Note well that NTPv4's longest polling interval exceeds one day and thus a leap second announcement may be missed."

Change "keys have to be exchanged securely by external
   means." to "keys have to be exchanged securely by external
   means, and they have to be protected from disclosure."

I would swap the two sentences "NTP does not provide a mechanism to automatically
   refresh the applied keys.  It is therefore recommended that the
   participants periodically agree on a fresh key.". (Its recommended to refresh keys periodically, but (unfortunately) NTP dies not assist you in doing so (excpet from "readkeys").

On "Some implementations store the key in clear text.": Which do not?

I would re-word "An NTP client establishes a protected association by appending the
   key to the server statement in its configuration file." as "Authentication is requested by the client by specifying a key and adding a valid MAC to the request. This happens when a key number is specified with the server configuration (value and type of the key are read from a secret key file)."

I'd replace "Autokey was designed in 2003 to provide a means for clients to
   authenticate servers." with "Autokey was designed in 2003 to provide automatic key selection and updates for clients to
   authenticate servers."

The sentence "As such, access control should be used to limit the exposure of this
   information to inappropriate third parties." is quite confusing, because when a server serves a client, it will provide such information. Despite from updating the software, the operator can do little about that.

On "Prevent the NTP daemon from taking time steps that set the clock
      to a time earlier than the compile date of the NTP daemon.": This would be a recommendation to an implementer, right? The operator cannot do much about it, I guess.

Before the paragraph on "Kiss-o'-Death (KoD)" the concept should be explained in one sentence. (Like "KoD is a mechanism for a server to tell a client to stop polling it (that fast).)
And: The heading "KISS Packets" should be "Kiss-of-Death Packets". Generally I would remove some of the details that describe the implementation and are not related to actual recommendations.

In 6.6 explain that a passive peer receives time messages from a server that has not been configured at the client.

For 7. maybe note that embedded devices sometimes do not have a battery-buffered clock, so using NTP successfully to set the time may be critical for proper operation.

Maybe add: "Avoid devices that use a fixed built-in configuration for NTP" (meaning: YOu cannot configure its servers or security).

Maybe also differ between embedded clients and embedded servers...

For 8.: Maybe clarify the difference between "manycast", "anycast" and "multicast" (not to talk abut broadcast).

Regards,
Ulrich

>>> <[email-masked]> 31.07.18 21.18 Uhr >>>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Time Protocol WG of the IETF.

        Title           : Network Time Protocol Best Current Practices
        Authors         : Denis Reilly
                          Harlan Stenn
                          Dieter Sibold
    Filename        : draft-ietf-ntp-bcp-07.txt
    Pages           : 23
    Date            : 2018-07-31

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ntp-bcp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ntp-bcp-07
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-bcp-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-bcp-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/