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

From: [email-masked]
Date: Tue, 2 Oct 2018 11:15:40 +0200

"ntp" <[email-masked]> schrieb am 26.09.2018 08:14:51:

> Von: "Ulrich Windl" <[email-masked]>
> An: "Steven Sommars" <[email-masked]>, "draft-ietf-ntp-
> [email-masked]" <[email-masked]>, "[email-masked]" 
> <[email-masked]>, "[email-masked]" <[email-masked]>
> Datum: 26.09.2018 08:15
> Betreff: [Ntp] Antw: Re: Last Call: <draft-ietf-ntp-bcp-07.txt> 
> (Network Time Protocol Best Current Practices) to Best Current Practice
> Gesendet von: "ntp" <[email-masked]>
> 
> >>> Steven Sommars <[email-masked]> schrieb am 26.09.2018
> um 02:46 in
> Nachricht
> <CAD4huA7BSOwcaH_TqOvRvDBDQXVwrJHhCunvsk=[email-masked]>:
> > 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".
> 
> Maybe use "all conforming NTP implementations", so chrony would be 
> non-conforming. I think the clustering algorithm is part of the NTP 
> specification.
> 

The clustering algorithm is specified in 5905. However, as far as I know
the requirements language does not require an implementation to use this 
algorithm. 

> > 
> > 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.
> 
> I don't know whether crony is "important". Maybe it's "common".
> 
> > 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.
> > 
> 
> As I did not receive any comments on my change proposals from 
> August, I'm attaching them to this message again...
> 
> Regards,
> Ulrich
> 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > On Mon, Sep 24, 2018 at 12:11 PM The IESG <[email-masked]> 
wrote:
> > 
> >>
> >> 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)
> >>
> >>
> >>
> >> _______________________________________________
> >> ntp mailing list
> >> [email-masked] 
> >> https://www.ietf.org/mailman/listinfo/ntp 
> >>
> 
> 
> 
> ----- Nachricht von "Ulrich Windl" <[email-masked]
> regensburg.de> auf Sat, 25 Aug 2018 23:29:57 +0200 -----
> 
> An:
> 
> <[email-masked]>
> 
> Kopie:
> 
> <[email-masked]>
> 
> Betreff:
> 
> Antw: [Ntp] I-D Action: draft-ietf-ntp-bcp-07.txt
> 
> 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:
>    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 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/
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
> 
> ----- Nachricht von "Ulrich Windl" <[email-masked]
> regensburg.de> auf Sun, 26 Aug 2018 00:42:00 +0200 -----
> 
> An:
> 
> <[email-masked]>
> 
> Kopie:
> 
> <[email-masked]>
> 
> Betreff:
> 
> Antw: [Ntp] I-D Action: draft-ietf-ntp-bcp-07.txt
> 
> 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:
>    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 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/
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 02 Oct 2018 11:43:26 +0200

>>> <[email-masked]> schrieb am 02.10.2018 um 11:15 in Nachricht
<[email-masked]>:
> "ntp" <ntp‑[email-masked]> schrieb am 26.09.2018 08:14:51:
> 
>> Von: "Ulrich Windl" <[email-masked]‑regensburg.de>
>> An: "Steven Sommars" <[email-masked]>, "draft‑ietf‑ntp‑
>> [email-masked]" <draft‑ietf‑ntp‑[email-masked]>, "[email-masked]" 
>> <[email-masked]>, "ntp‑[email-masked]" <ntp‑[email-masked]>
>> Datum: 26.09.2018 08:15
>> Betreff: [Ntp] Antw: Re: Last Call: <draft‑ietf‑ntp‑bcp‑07.txt> 
>> Gesendet von: "ntp" <ntp‑[email-masked]>
>> 
>> > Some comments on draft‑ietf‑ntp‑bcp‑07:
>> > 
>> > Section 4.1, typo:  combing ‑> combining
>> > 
>> non‑conforming. I think the clustering algorithm is part of the NTP 
>> specification.
>> 
> 

Hello!

It's an interesting point: Traditionally the RFCs for NTP described what was
implemented more than demanding what should. In RFC 1303 you read "However, it
is important to observe that not all time servers or clients in an NTP
synchronization subnet must implement these algorithms.", while RFC 5905 states
"   All servers and clients who are fully NTPv4-compliant MUST implement the
entire suite of algorithms described in this document.".

Browsing the latter RFC, I noticed there are several lower-case "must"s that
should be uper case IMHO, BTW...

Regards,
Ulrich

>> > Section 4.4   The paragraph mentioning ntp‑4.2.8p6 and ntp.keys is too
>> > Section 4.6, nit   "ntp server" ‑> "NTP server"
>> > 
>> > On Mon, Sep 24, 2018 at 12:11 PM The IESG <iesg‑[email-masked]> 
> wrote:
>> > 
>> >>
>> >> consider the following document: ‑ 'Network Time Protocol Best 
> Current
>> >> Practices'
>> >>   <draft‑ietf‑ntp‑bcp‑07.txt> as Best Current Practice
>> >>
>> >> [email-masked] mailing lists by 2018‑10‑08. Exceptionally, comments 
> may be
>> >> https://datatracker.ietf.org/doc/draft‑ietf‑ntp‑bcp/ 
>> >>
>> >> https://datatracker.ietf.org/doc/draft‑ietf‑ntp‑bcp/ballot/ 
>> >>
>> >>
>> >> No IPR declarations have been submitted directly on this I‑D.
>> >>
>> >>
>> >> Implementation and Analysis (Draft Standard ‑ Legacy stream)
>> >> Specification (Proposed Standard ‑ IETF stream)
>> >> Networks (Informational ‑ IETF stream)
> (Informational ‑
>> ‑‑‑‑‑ Nachricht von "Ulrich Windl" <[email-masked]‑ 
>> regensburg.de> auf Sat, 25 Aug 2018 23:29:57 +0200 ‑‑‑‑‑
>> 
>> An:
>> 
>> <i‑d‑[email-masked]>
>> 
>> Kopie:
>> 
>> <[email-masked]>
>> 
>> Betreff:
>> 
>> Antw: [Ntp] I‑D Action: draft‑ietf‑ntp‑bcp‑07.txt
>> 
>> Hi!
>> 
>> I'd put 5 as a sub‑item of 6.
> sub‑item.
>> I feel that 8. would fit inside the old 4 as sub‑item.
>> 
>> Regards,
>> Ulrich
>> >>> <internet‑[email-masked]> 31.07.18 21.18 Uhr >>>
>> 
>> A New Internet‑Draft is available from the on‑line Internet‑Drafts 
>> directories.
>>    Filename        : draft‑ietf‑ntp‑bcp‑07.txt
>>    Pages           : 23
>>    Date            : 2018‑07‑31
>> 
>> Abstract:
>> https://datatracker.ietf.org/doc/draft‑ietf‑ntp‑bcp/ 
>> 
>> https://tools.ietf.org/html/draft‑ietf‑ntp‑bcp‑07 
>> https://datatracker.ietf.org/doc/html/draft‑ietf‑ntp‑bcp‑07 
>> 
>> https://www.ietf.org/rfcdiff?url2=draft‑ietf‑ntp‑bcp‑07 
>> 
>> 
>> Internet‑Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet‑drafts/ 
>> 
>> ‑‑‑‑‑ Nachricht von "Ulrich Windl" <[email-masked]‑ 
>> regensburg.de> auf Sun, 26 Aug 2018 00:42:00 +0200 ‑‑‑‑‑
>> 
>> An:
>> 
>> <i‑d‑[email-masked]>
>> 
>> Kopie:
>> 
>> <[email-masked]>
>> 
>> Betreff:
>> 
>> Antw: [Ntp] I‑D Action: draft‑ietf‑ntp‑bcp‑07.txt
>> 
>> Hi!
>> 
>>    corresponding queries.  Thus, they can be abused in high‑bandwidth
>> On "If a system is using broadcast mode and is running ntp‑4.2.8p6 or
>> please use it (for eaxmple ntp‑4.2.8p6 allows to put valid IP... in 
>> the 4th field of ..."
>> 
>>    +/‑ 0.9 seconds by the insertion (or possibly a deletion) of a leap
>>    second."
>> 
>> I would re‑word "An NTP client establishes a protected association 
>> by appending the
>> Before the paragraph on "Kiss‑o'‑Death (KoD)" the concept should be 
>> And: The heading "KISS Packets" should be "Kiss‑of‑Death Packets". 
>> battery‑buffered clock, so using NTP successfully to set the time 
>> Maybe add: "Avoid devices that use a fixed built‑in configuration 
>> >>> <internet‑[email-masked]> 31.07.18 21.18 Uhr >>>
>> 
>> A New Internet‑Draft is available from the on‑line Internet‑Drafts 
>> directories.
>>     Filename        : draft‑ietf‑ntp‑bcp‑07.txt
>>     Pages           : 23
>>     Date            : 2018‑07‑31
>> 
>> Abstract:
>> https://datatracker.ietf.org/doc/draft‑ietf‑ntp‑bcp/ 
>> 
>> https://tools.ietf.org/html/draft‑ietf‑ntp‑bcp‑07 
>> https://datatracker.ietf.org/doc/html/draft‑ietf‑ntp‑bcp‑07 
>> 
>> https://www.ietf.org/rfcdiff?url2=draft‑ietf‑ntp‑bcp‑07 
>> 
>> 
>> Internet‑Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet‑drafts/ 
>>

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 3 Oct 2018 11:09:58 +0200

> entire suite of algorithms described in this document.".

The same paragraph also has: "Alternative algorithms MAY be used, but
their output MUST be identical to the algorithms described in this
specification."

So, in order for an implementation to be "fully NTPv4-compliant", it
not only needs to implement a clock filter, selection, cluster,
combine, and clock discipline algoritms, they must give exactly the
same results as the algorithms described in the RFC.

That's a very strong requirement. I'd be curious to know if such an
implementation actually exists.

-- 
Miroslav Lichvar

---

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 3 Oct 2018 14:38:06 +0000

Folks,

Just a quick note as I know the editor of this document is unavailable at the moment… Thanks for the review of this document. We will be working on a response over the course of the next couple of weeks and will respond on the ntp mailing list. 

Karen 

> On Sep 26, 2018, at 4:54 PM, Joe Touch <[email-masked]> wrote:
> 
> Hi, all,
> 
> I agree with Tom’s review below. The text is too colloquial and imprecise - especially for describing advice that involves a level of precision itself.
> 
> Many of the recommendations lack rationale - e.g., simply choosing 4 time servers isn’t sufficient to help ensure reliable, accurate results unless they are chosen to reduce the number of shared “ancestor” servers. 
> 
> Even many of the words used need work, e.g., “since” is temporal (not rationale - which should use “because”), and the error is especially problematic in a document describing time. Time itself is referred to as if having a single definition, where the security concerns used as rationale often depends on the use of a single, common, *absolute* shared time scale, not simply “time” (which could also refer to relative time).
> 
> The section on leap smearing fails to underscore the key issue - that NTP is intended to provide a UTC time scale, and leap smeared-time is NOT UTC time, which then undermines the ability to compare NTP time values in a single time scale - which then can impact security protocols, financial transactions, etc. The issue is more than whether public servers should smear; the issue is whether smearing defeats the very definition of NTP as a protocol. BCP should indicate that smearing MUST NOT be used in an NTP server using the assigned NTP port number, period. Frankly, it was a mistake that its support was ever added to the NTP codebase. The only alternative would be for NTP to be extended to report “smeared time” as a *distinct* time scale, which it currently does not. The issue if multiple time scales is discussed in a draft I have been working on, FWIW (draft-touch-time).
> 
> This is just a short list of the failures of this document, where Tom lists others below.
> 
> I do think it would be useful to have a BCP for NTP, but I am not clear that this draft is more than a good reason to start that process. I worry whether using it as a starting point can evolve to the level that we should expect from a BCP.
> 
> Joe
> 
> 
>> On Sep 26, 2018, at 2:57 AM, tom petch <[email-masked]> wrote:
>> 
>> This I-D leaves me uncertain.  Should it be an RFC?  Does it qualify for
>> BCP status?  I think 'maybe' and 'no' respectively
>> 
>> There are a number of detailed glitches - see below - but the overall
>> style is of more concern to me where BCP status is concerned. Statements
>> such as:
>> - the answer is obvious
>> - they agree well enough
>> - Use your NTP implementation's remote monitoring capabilities to
>>  quickly identify servers which are out of sync
>> - the MAC may always be based on an MD5 hash
>> - Readers are encouraged to adopt its mechanisms.
>> - Contact the maintainers of your  implementation for more information.
>> - access control should be used to limit the exposure of this
>> information to inappropriate third parties
>> - A much better approach might be
>> - If, against long-standing recommendation,
>> - Readers of this BCP already understand
>> - Readers are encouraged to check the status of the draft,
>> 
>> some of which I think misleading, none of which I expect to see in a
>> BCP.  Most of it is too vague for me; section 6 stands out as being more
>> of what I would expect to see in a BCP.
>> 
>> Also, it is symptomatic, for me, that the 'Requirements Language' is out
>> of
>> date, lacking reference to RFC8174, and yet I see a lot of lower case
>> words, such as 'recommended', along with some upper case.
>> 
>> Likewise, the I-D starts with
>> 'Many network security mechanisms rely on time'
>> so security is a key part, if not the point, of the I-D yet I find
>> Security Considerations weak.  Section 5 references RFC7384,
>> 'profound threat analysis for time synchronization protocols '.  Yes,
>> but it is ironic that that RFC, detailed, thorough, useful, is only
>> Informational; and it is not mentioned in this, the section on Security
>> Considerations. This section  does not point to threats
>> and mitigations from the body of the I-D, rather it seems to weaken the
>> whole I-D with somewhat vague statements.
>> 
>> Picking up on some details,
>> 
>> Abstract
>> RFC 5905 [RFC5905].
>> looks like a reference which is not ok for an Abstract which needs to be
>> plain text.
>> 
>> out of date no RFC8174
>> 3.1
>> BCP38 Info page [1] .
>> I did not immediately recognise [1] as a reference to a URL.
>> 
>> 4
>> compilied in Section Appendix A.
>> compiled?
>> 
>> 4.1
>> opposed to an SNTP implementation
>> expansion would be helpful
>> 
>> this section in general lacks any detail of 'how'.  What is agreement,
>> between two
>> sources?  How do I converge three sources?  I look to a BCP for advice
>> on such matters.
>> 
>> 4.2
>> There is a general principle behind this that I would like to see
>> stated, namely to ensure that multiple sources are really independent.
>> I learnt this when I read about Apollo moon shots, but have seen it
>> ignored many times since.  You have to work hard to track back to the
>> details of the technology in use to find out if there is really more
>> than one code base, or chip set, or... in use.  Where security
>> depends on such matters, you really need to do that to ensure you have
>> independence. Appendix A suggests that there is but one code base.
>> 
>> 4.4
>> its syslog shows
>> Is this a recommendation to use the 'syslog' protocol as opposed to
>> YANG:-)  Elsewhere, you use system logs which I think better.
>> 
>> I think too that there is a general point that is missing that these
>> systems
>> need error logging, need (remote) monitoring, else ... well, what is the
>> threat?  what is the mitigation?
>> 
>> broadcast client
>> sounds like a client that broadcasts rather than one that receives
>> broadcasts.
>> 
>> 4.6
>> GNSS
>> I would like expanded on first use
>> 
>> IERS
>> ditto
>> 
>> 4.6.1
>> using a leap-smear can cause your reported time to be "legally
>> indefensible
>> sounds like a SHOULD NOT if this is a BCP
>> 
>> 5
>> /A profound threat analysis for time synchronization protocols are
>> given/
>> A profound threat analysis for time synchronization protocols is given/
>> 
>> 5.1
>> the MAC may always be based on an MD5 hash,
>> MD5 is regarded as too weak in many contexts; does that apply here?
>> 
>> Generally, is there any difference between IPv4 and IPv6 here?  IP
>> addresses are
>> often mentioned but no mention of different versions.  RFC4786, e.g., is
>> explicit that it covers both.
>> 
>> Appendix A
>> 
>> /specific to various implementation of RFC 5905./
>> specific to various implementations of RFC 5905./
>> except that the advice seems to be specific to ntpd and not
>> apply to any other implementation
>> 
>> A.1.2
>> /mode 7 /Mode 7 /
>> 
>> /BY default/by default/ ?
>> 
>> 
>> Tom Petch
>> 
>> ----- Original Message -----
>> From: "The IESG" <[email-masked]>
>> To: "IETF-Announce" <[email-masked]>
>> Cc: <[email-masked]>; <[email-masked]>;
>> <[email-masked]>; <[email-masked]>
>> Sent: Monday, September 24, 2018 6:07 PM
>> 
>> => The IESG has received a request from the Network Time Protocol WG
>> (ntp) to
>>> consider the following document: - 'Network Time Protocol Best Current
>>> Practices'
>>> [email-masked] mailing lists by 2018-10-08. Exceptionally, comments may
>> be
>> Switched Networks (Informational - IETF stream)
>> (Informational - IAB stream)
>> 
>

---

From: Denis Reilly <[email-masked]>
Date: Sat, 27 Oct 2018 17:53:14 +0000

Hello, Steven.

Sorry for the belated reply, but please see our responses inline. Changes have already been made to the version in the GIT repository at https://github.com/denisreilly/ntp-bcp . (Unfortunately, the changes did not make the cutoff date to be published before the next IETF, but will be uploaded to datatracker soon.)

Best Regards,

--
Denis Reilly  |  Technical Lead  |  [email-masked]<mailto:[email-masked]>  (585)321-5837<tel:(585)%20321-5837>

From: Steven Sommars <[email-masked]>
Sent: Tuesday, September 25, 2018 8:47 PM
To: [email-masked]; [email-masked]; [email-masked]; Karen O'Donoghue <[email-masked]>
Subject: Re: [Ntp] Last Call: <draft-ietf-ntp-bcp-07.txt> (Network Time Protocol Best Current Practices) to Best Current Practice

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.]
DR: Yes, we agree and have changed the wording to “Important ways … are”

DR: Agreed, will fix

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

DR: RFC5905 does document all these algorithms, and specify that they must all be implemented. However, different implementors may have a different point of view about how necessary those algorithms really are, and perhaps this will be a topic for the next version of NTP when we get there. For now, the authors do not want to change the language, but rather we will specify that “An NTP implementation that is compliant with RFC5905” will do this, to make it clearer where the requirement comes from.

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,"
DR: Agreed, will fix.

Section 4.2. Comment.  It may be difficult to put this into practice if the stratum 1 servers reside in other organizations
DR: Yes, it may be difficult, but we think it is necessary. We’ve added some language that says that it is ultimately up to the operators to ensure that their sources are sufficiently independent.

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.
DR: We generally agree, but ee feel that the text is specific in saying that "some" NTP implementation use these messages, and that we state why they are not fit for use everywhere.
To make the point clearer, we will explicitly state that public-facing NTP servers should block Mode 6 queries from outside their organization.

Section 4.4   The paragraph mentioning ntp-4.2.8p6 and ntp.keys is too implementation specific.  Please remove it.
DR: We agree, it was already moved to the appendix and never removed here.

DR: Agree

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.
DR: Not everyone agrees that leap smearing should not be used, but we are specific in saying it should now be used on public servers, where operators expect UTC.
We will also add some language noting that there is currently no standardized way to detect that a server may be leap-smearing.

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

DR: The intention of the text here is that "hosts" means "ntp clients and/or servers" in general. Text will be updated accordingly.

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

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]<mailto:[email-masked]> mailing lists by 2018-10-08. Exceptionally, comments may be
sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

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)

_______________________________________________
ntp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ntp

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

---

From: Denis Reilly <[email-masked]>
Date: Wed, 31 Oct 2018 19:54:23 +0000

Hello, Tom! We appreciate your comments. Responses are in-line.

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

-----Original Message-----
From: tom petch <[email-masked]> 
Sent: Wednesday, September 26, 2018 5:57 AM
To: ietf <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Last Call: <draft-ietf-ntp-bcp-07.txt> (Network Time Protocol Best Current Practices) to Best Current Practice

This I-D leaves me uncertain.  Should it be an RFC?  Does it qualify for BCP status?  I think 'maybe' and 'no' respectively

There are a number of detailed glitches - see below - but the overall style is of more concern to me where BCP status is concerned. Statements such as:
- the answer is obvious
- they agree well enough
- access control should be used to limit the exposure of this information to inappropriate third parties

some of which I think misleading, none of which I expect to see in a BCP.  Most of it is too vague for me; section 6 stands out as being more of what I would expect to see in a BCP.

DR: We are always looking for areas to improve the language and make it more like "what people expect" to have in a BCP. We are trying to balance the specific recommendations that we know we can make with the "best practices" that may only apply in certain situations.

Also, it is symptomatic, for me, that the 'Requirements Language' is out of date, lacking reference to RFC8174, and yet I see a lot of lower case words, such as 'recommended', along with some upper case.

DR: That is my mistake, with this being the first time with a document in the IETF. I will add the latest requirements language and we will take a fresh look at the requirements language.

Likewise, the I-D starts with
'Many network security mechanisms rely on time'
so security is a key part, if not the point, of the I-D yet I find Security Considerations weak.  Section 5 references RFC7384, 'profound threat analysis for time synchronization protocols '.  Yes, but it is ironic that that RFC, detailed, thorough, useful, is only Informational; and it is not mentioned in this, the section on Security Considerations. This section  does not point to threats and mitigations from the body of the I-D, rather it seems to weaken the whole I-D with somewhat vague statements.

DR: We can mention the RFC7384 directly in the Security Considerations section.  I'd be interested in your ideas about how to make the Security Considerations stronger without simply restating what is in the body of the text.

Abstract
RFC 5905 [RFC5905].
looks like a reference which is not ok for an Abstract which needs to be plain text.

DR: We agree, we will reword the abstract to eliminate the reference.

DR: We will update the boilerplate text (as well as review the text and make sure we are using the proper key words where we man to!)

3.1
BCP38 Info page [1] .

DR: We will change to "More information is available at the BCP38 Info Web page" to make clear that it is a URL.

4

DR: Yes, we are fixing this typo.

4.1

DR: The real intent here was to describe how implementations of RFC 5905 would behave, so we've replaced this text with "An NTP implementation that is compliant with RFC 5905".

this section in general lacks any detail of 'how'.  What is agreement, between two sources?  How do I converge three sources?  I look to a BCP for advice on such matters.

DR: The "how" is defined in RFC 5905. The operator has to decide how many time sources he/she is using.

4.2
There is a general principle behind this that I would like to see stated, namely to ensure that multiple sources are really independent.
I learnt this when I read about Apollo moon shots, but have seen it ignored many times since.  You have to work hard to track back to the details of the technology in use to find out if there is really more than one code base, or chip set, or... in use.  Where security depends on such matters, you really need to do that to ensure you have independence. Appendix A suggests that there is but one code base.

DR: Agree. Change "diversity of sources" to "diversity of sources with independent implementations".

After "may have the same bugs", add "Even devices from different vendors may not be truly independent if they share common elements." 
Then, we can strike "regardless of whether ... different vendors", because that will be redundant.

Denis likes that last line in the comment. After "application software bugs", we will add 
"When having the correct time is of critical importance, it's ultimately up to operators to ensure that their sources are sufficiently independent."

4.4
its syslog shows

DR: We agree, we'll change to "system logs" globally

I think too that there is a general point that is missing that these systems need error logging, need (remote) monitoring, else ... well, what is the threat?  what is the mitigation?

DR:  We do go into more specifics on particular threats and mitigations in other sections. Would you like that referenced here?

broadcast client
sounds like a client that broadcasts rather than one that receives broadcasts.

DR: We can change that to "client in broadcast mode"

4.6
GNSS

IERS
Ditto

DR: agreed

4.6.1
using a leap-smear can cause your reported time to be "legally indefensible sounds like a SHOULD NOT if this is a BCP

DR: Some users simply don't care if their time is traceable; they care more that all the machines on their network have the same time. We feel "SHOULD NOT" is too strong in this case, and the current language reflects properly that operators who wish to use leap-smearing should be aware of the implications.

5
/A profound threat analysis for time synchronization protocols are given/ A profound threat analysis for time synchronization protocols is given/

DR: Agree

5.1

DR: MD5 is in the process of being deprecated, but many implementations still support it, so it is appropriate to mention here. But we will clarify the situation, as well as include a reference to draft-ietf-ntp-mac , which replaces MD5 with AES-CMAC.

Generally, is there any difference between IPv4 and IPv6 here?  IP addresses are often mentioned but no mention of different versions.  RFC4786, e.g., is explicit that it covers both.

DR: We can clarify (particularly in the Anycast section) that the recommendations cover both. 

Appendix A

/specific to various implementation of RFC 5905./ specific to various implementations of RFC 5905./ except that the advice seems to be specific to ntpd and not apply to any other implementation

DR: We did originally make a broad call on the NTP mailing list for information from any of the available implementations, but we only received content specific to ntpd. Since there are no other implementations currently with appendixes, we will refactor to make Appendix A devoted solely to the NTF implementation. In the event this BCP is updated with information from different implementations, they can have their own appendix.

A.1.2
/mode 7 /Mode 7 /

DR: Agree!

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, September 24, 2018 6:07 PM

final
be
beginning of