Subject: Re: [Ntp] Antw: I-D Action: draft-ietf-ntp-bcp-07.txt

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 05 Nov 2018 08:14:12 +0100

>>> Denis Reilly <[email-masked]> schrieb am 31.10.2018 um 19:23 in
Nachricht
<[email-masked].
om>:
> Hello, Ulrich! We did see this note of yours from August, but didn't address

> it at the time. I am in the process of answering all the NTP BCP feedback. 
> Please see our answers inline below.

Hi!

I'll comment inline as well.

[...]
> 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."
> 
> DR: We don't think that change is necessary. 

If you think of some administrator that is not too deep into NTP and leap
seconds, I think this information would be helpful, e.g. there's little sense
downloading the leapinfo file daily or weekly (not even monthly).

> 
> 
> 
> 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".
> 
> DR: I personally think that the way to view this is that the protocol will 
> broadcast the leap second information, and the clients receiving the
protocol 
> messages would process the information. So I don't think the change is 
> necessary.

Aslong as the whole RFC is named "Network time protocol" and it is describing
much more than the packet exchanges, I think it is justified to claim that NTP
(the "P" in the name) is able to (actually MUST) 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."
> 
> DR: Agreed
> 
> 
> 
> 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."
> 
> DR: Agreed
> 
> 
> 
> 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").
> 
> DR: Personally I like how that language flows a bit better, we changed to:
> "It is recommended that participants agree to refresh keys periodically. 
> However, NTP does not provide a mechanism to assist in doing so."
> 
> 
> On "Some implementations store the key in clear text.": Which do not?
> DR: I don't know of any, but we can't guarantee that future implementation 
> won't. In any case, we don't think the text needs to change.

Maybe rephrase like "For any implementation that stores key in clear text
(where "clear text" means not stongly encrypted)..." (Recently I had some
software where the vendor had claimed the password is stored in encrypted form,
when is actually was just BASE64 encoded...)

> 
> 
> 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."
> 
> DR: Dieter recommends "Autokey was specified in 2010 to provide automated 
> key management and authentication of NTP 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.
> 
> DR: I see now, we will reword to match language that was changed for the 
> "control messages" section:
> "As such, mechanisms outside of the NTP protocol, such as Access Control 
> Lists, should be used to limit the exposure of this information to allowed
IP 
> addresses, and keep it from remote attackers not on the list.
> 
> 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.
> 
> DR: We will clarify this for implementors.
> 
> 
> 
> 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.
> 
> DR: We feel that the introductory sentence "The "Kiss‑o'‑Death" (KoD) packet

> is a rate limiting mechanism where a server can tell a misbehaving client to

> "back off" its query rate." is a clear enough explanation. But we agree that

> the heading can be changed.
> 
> 
> 
> In 6.6 explain that a passive peer receives time messages from a server that

> has not been configured at the client.
> 
> DR: Can you explain this further? We don't see how it fits here.

OK.

> 
> 
> 
> 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.
> 
> DR: Excellent point, thanks!
> 
> 
> 
> 
> 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...
> 
> DR: We feel this advice can be difficult for some of these new small IoT 
> devices, we prefer to put the onus on vendors to be responsible.

Wasn't that some Linksys routers polling some NIST server like mad? If the
NIST would block such requests, and you couldn't  configure a different server,
you'll have a problem not getting the correct time. It was a scenario like that
I had in mind...

> 
> 
> 
> 
> For 8.: Maybe clarify the difference between "manycast", "anycast" and 
> "multicast" (not to talk abut broadcast).
> 
> DR: We feel that Manycast and Multicast are already covered in RFC 5905.

Yes, but do you really think any operator that reads the recommendations did
read the NTP specification in detail? Or what the intended audience different?
I think anybody that knows all the bits from RFC 5905 and its precursors does
not really need these recommendations.

Regards,
Ulrich

> 
> Regards,
> Ulrich
> 
> 
>>>> <internet‑[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

---

From: "Dieter Sibold" <[email-masked]>
Date: Mon, 05 Nov 2018 16:06:32 +0700

> not really need these recommendations.

The BCP provides information not contained in RFC 5905. People may learn 
this information from other sources but they can learn it from the BCP 
also. Therefore, I don’t think that pointing the reader to RFC 5905 
for the difference between many cast, anycast and multicast renders the 
BCP to be useless.

Dieter