Control Messages Protocol for Use with Network Time Protocol Version 4
draft-ietf-ntp-mode-6-cmds-11
Discuss
Yes
Erik Kline
No Objection
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
Note: This ballot was opened for revision 09 and is now closed.
Erik Kline
Yes
Murray Kucherawy
(was Discuss)
No Objection
Comment
(2020-12-10 for -10)
Sent
Thanks for resolving the document status confusion. I found the same typos Roman did. A quick pass with a spell checker might speed things through the RFC Editor slightly.
Roman Danyliw
No Objection
Comment
(2020-08-25 for -09)
Sent
** Section 4. Can “Whitespace (ASCII) non-printing format effectors)” be specified more precisely? ** Section 6. Per “… the host can use a whitelist to explicitly list IP addresses …”, consider s/whitelist/allow-list/ ** References -- Section 1.2. Add an information reference for ntpdc -- Section 6. Add an informative reference for ntpd ** Editorial Nits -- Global. Typo. s/developement/development/ -- Section 2. Typo. s/Conains/Contains/ -- Section 2. Per “… this contains the authenticator information defined in Appendix C of RFC 1305”, please make RFC1305 a reference. -- Section 4. Typo. s/managment/management/ -- Section 6. Typo. s/atacks/attacks/ -- Appendix A. Typo. s/reponse/response/ -- Appendix A. Editorial. s/more then one packet/more than one packet/
Éric Vyncke
No Objection
Comment
(2020-08-21 for -09)
Sent
Thank you for the work put into this document. First, I must admit that this is the first time I see an IETF stream informational document for the specification of a control protocol used by an obsoleted RFC 1305. This document is much easier to read than the appendix B of RFC 1305 and the author takes care to write that this spec is not mandatory to implement but I really wonder why this document exists ? Moreover the abstract says "The goal of this document is to provide a current, but historic, " so why not publishing this document as 'historic' rather than 'informal' (datatracker seems to allow this modification). Please find below a couple of non-blocking COMMENTs (and I would appreciate a reply to each of my COMMENTs) and some NITs. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 1.1 -- Suggest to replace 'IP' by 'IPv4' in 'IP hosts are not required to reassemble datagrams larger than 576' + add some text that this document applies the same limitation to IPv6. -- Section 2 -- Possibly linked to my lack of understanding of the purpose of this document, but, if applicable only to NTPv3, then should the Version number clearly specified to be 3 ? -- Section 3.2 -- Suggest to add 'bit' after 'Peer Status' in the table headings to make it clear. -- Section 4 -- It will probably be useful to expand 'MRU' at first use. In the "Read ordered list (11):" it is not clear how the entries are ordered in the case of "ifstats" is it per local address ? Are IPv4 addresses before IPv6 addresses ? -- Appendix A -- Is there a reason why the mode 7 is in the appendix and not in the main body ? == NITS == -- Section 2 -- s/Conains/Contains/ -- Section 4 -- Should there be a comma in 'seven characters "ifstats" the associated' before 'the associated' ?
Benjamin Kaduk Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2022-03-22)
Sent for earlier
[updating version to which ballot position applies, since the -11 does not seem to have addressed the core topics. Furthermore, a 20- or 24-**bit** authenticator will have its own problems to cover, though 20- or 24-**byte** authenticators would be more reasonable.] There seems to be an internal inconsistency regarding the format of the data payload: at the start of Section 4 we see that "When present, the data field contains a list of identifiers or assignments in the form <<identifier>>[=<<value>>],<<identifier>>[=<<value>>],... where <<identifier>> is the ASCII name of a system or peer variable specified in RFC 5905 and <<value>> is expressed as a decimal, hexadecimal or string constant in the syntax of the C programming language", but later on we see that the Read Status reply "contains a list of binary-coded pairs <<association identifier>> <<status word>>, one for each currently defined association. The "binary-coded" (with, apparently, implicit length) seems at odds with the ASCII key/value assignment pairs. The description of the Configure(8) command as "The command data is parsed and applied as if supplied in the daemon configuration file" lacks any reference to what that format is or how one might know what format the peer expects. This does not seem sufficiently specified so as to admit interoperable implementation. The description of the Read MRU(10) command also seems underspecified. What name=value pairs affect the selection of records (and how)? Is there a particular name used with name=value pair for the returned nonce, or how is the returned nonce framed? If it's implementation-specific, say so. The only currently specified authentication scheme for these commands appears to be DES-CBC-MAC, from Appendix C of RFC 1305. (RFC 5905 suggests that existing implementations, however, use a different keyed-MD5 scheme that is similarly flawed.) As a CBC-MAC, this mechanism is subject to an extension attack, allowing an attacker to observe an existing valid packet and construct a forged packet with valid MAC by appending additional data at the end. This, therefore, fails to actually provide the key property of authentication. There are additional fundamental issues with the NTP authentication format (independently of the DES-CBC-MAC scheme), which may not quite rise to DISCUSS-level, and accordingly are listed in the COMMENT section.
Alissa Cooper Former IESG member
No Objection
No Objection
(for -09)
Not sent
Alvaro Retana Former IESG member
No Objection
No Objection
(for -09)
Not sent
Barry Leiba Former IESG member
No Objection
No Objection
(2020-08-26 for -09)
Sent
I support Murray’s DISCUSS. To add to the discussion: It’s not clear to me why either a Historic or an Informational RFC is needed, to repeat information that is in an Obsolete RFC. It would be one thing if these were for current implementation, but the draft is clear that they’re not. Then why isn’t it sufficient that they are documented in 1305? Why does there need to be a non-Obsolete RFC that has them?
Deborah Brungard Former IESG member
No Objection
No Objection
(for -09)
Not sent
Martin Duke Former IESG member
No Objection
No Objection
(2020-08-26 for -09)
Sent
I support Murray’s DISCUSS. With a document of this type, I am not sure if all of these type codes and bit settings should be IANA registries or not. Sec 4 references Fig. 2 but I think you mean Fig. 1. In sec 6, please replace “whitelist” with “allowlist” or other equivalent term.
Martin Vigoureux Former IESG member
No Objection
No Objection
(2020-08-27 for -09)
Not sent
I have noticed a number of additions but also changes compared to 1305, for example regarding the code points * Operation Code * System Event Code, * Peer Selection, * Peer Event Code, * Clock Status/Clock Code. I have read: The goal of this document is to provide a current, but historic, description of the control messages as described in RFC 1305 and any additional commands implemented in NTP. Which I interpret as 1305 being the main constituant of this document, plus some additional elements of specifications. Therefore, finding new stuff compared to 1305 isn't totally surprising but still, it is not clear to me where do the additions come from, and what explains the changes compared to 1305.