Re: [Int-dir] Intdir early review of draft-ietf-ntp-bcp-06

[[e-mail]]

Resending because of typo in int-ads list. Sorry.

-------------------------------------
Dr. Dieter Sibold
Physikalisch-Technische Bundesanstalt
Q.42 - Zeitverteilung mittels IP
QM-Verantwortlicher der Stelle IT
Bundesallee 100 
D-38116 Braunschweig
Tel:    [phone]
E-Mail: [e-mail]


[e-mail] wrote: -----
To: "神明達哉" <[e-mail]>
From: [e-mail]
Date: 06/30/2018 15:07
Cc: "<[e-mail]>" <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: Intdir early review of draft-ietf-ntp-bcp-06

Hello Tatuya,

I'm writing not as WG chair but as one of the editors of this draft. Thanks very much for the review of the draft draft-ietf-ntp-bcp. Please find our answers to your comments below.

Dieter Sibold





-----"神明達哉" <[e-mail]> wrote: -----

>To: "<[e-mail]>" <[e-mail]>, [e-mail]
>From: "神明達哉" <[e-mail]>
>Date: 06/15/2018 22:22
>Cc: [e-mail], [e-mail]
>Subject: Intdir early review of draft-ietf-ntp-bcp-06
>
>I am an assigned INT directorate reviewer for
><draft-ietf-ntp-bcp-06>. These
>comments were written primarily for the benefit of the Internet Area
>Directors. Document editors and shepherd(s) should treat these
>comments just like they would treat comments from any other IETF
>contributors and resolve them along with any other Last Call comments
>that have been received. For more details on the INT Directorate, see
>https://datatracker.ietf.org/group/intdir/about/ .
>
>Based on my review, the document IS NOT ready to go to IETF Last Call
>and therefore CANNOT be forwarded to the IESG. See the next
>paragraph
>for my rationale. That said, I don't know the history or past
>discussions on this document, so my points may simply be a rehash of
>previous discussions in the WG for which the WG reached a different
>consensus. If so, I wouldn't challenge that consensus and my
>recommendation can be "it IS ready and CAN be forwarded to the IESG".
>As a technical document I found it generally well-written and useful
>(although I have to note that I'm not an NTP expert and it's quite
>possible that I overlook something very primitive).
>
>I have the following DISCUSS/ABSTAIN level issue:
>
> This draft heavily relies on the behavior and features of a
> particular implementation developed by ntp.org. It seemed to me to
> be quite awkward for an IETF document, especially for a BCP RFC.
> Personally, I would generally expect a BCP to provide generic,
> implementation-independent information. Some
> implementation-specific information such as how to configure ntpd
>to
> meet particular recommendations would be a nice addition, but I
> would like it to be clearly separated from the main content, either
> as a different section or as an appendix.
>
This issue has been risen in the WG right after the IETF 98 meeting.  At that time consensus has been achieved to focus on ntp.org's implementation (ntpd). The intention of this document is to assist operators to provide well-designed NTP services. This was motivated by the large DDoS amplification attacks between 2013 and 2015 in which especially the ntpd-specific monlist command was abused as amplification vector. With this in mind, we added ntpd specific content to the document to provide best practice guidance for a secure ntpd configuration. Also, most of the contributions we received for this document were written with ntpd in mind. Having said that we also acknowledge your argument and therefore we intend to follow your suggestion to move valuable implementation specific content into  a different section or an appendix.


>The following are other issues I found with this document that SHOULD
>be corrected before publication:
>
>- On a related point to the above DISCUSS level issue, it's
> confusing to me that this draft is sometimes ambiguous about
>whether
> it talks about an implementation-dependent feature or about a
> general protocol/operational topic. For example, Section 4.2
>refers
> to NTP 'mode 6' and 'mode 7'. It was not clear to me whether these
> modes mean the same as described in RFC 5905. According to Figure
>1
> of the RFC mode 6 means 'broadcast client' and mode 7 isn't
>defined;
> Figure 10 says mode 6 means 'NTP control message' and mode 7 means
> 'reserved'. So this may be 'mode 6' in this draft refers to Figure
> 10 of the RFC while 'mode 7' refers to a implementation-specific
> feature of ntpd. These may be too obvious for readers already
> familiar with NTP, but it was quite confusing for someone without
> much background of the protocol and implementation, like me.
> Although a technical document could require some level of
> prerequisites, I think this draft could be more reader friendly and
> be clearer about the general and implementation-specific
>discussions
> (this comment would still apply regardless of how we resolve the
> 'DISCUSS-level' issue).
>
As pointed out above, we intend to improve the document by  separating implementation specific content from the protocol specific content. Regarding Sec, 4.3., we will redraft this section and emphasize that this section considers the NTP control messages. Mode 7 related content is implementation specific and will be moved to an different section or an appendix.


>- Section 3.1 seems a bit awkward to me. It doesn't talk about how
> it's relevant to NTP, while talking about quite a lot of details of
> BCP 38. It would fit in the entire draft context better if it
> discusses the implication of BCP 38 for NTP (such as UDP-based
> protocols are more susceptible to address spoofing attacks). I
> would also consider making the section more concise, just referring
> to BCP 38 instead of discussing many details of it.
>

We will add language that explains BCP 38's relevance to NTP, especially in the context of DDoS. Also, we will shorten this section as you suggested.


>The following are minor issues (typos, misspelling, minor text
>improvements) with the document:
>
>- Section 5.3: s/in in/in/
> this effort was at draft #10, and in in the 'final call' process.

Thanks.

>
>- Section 6.1:
>
> [...] To minimize
> information leakage, leaf-node hosts should drop all incoming NTP
> packets except mode 4 response packets that come from unknown
> sources.
>
> On a first read this sentence didn't make sense to me. I guess the
> intent was:
>
> To minimize information leakage, leaf-node hosts should drop:
> - all incoming NTP packets that come from unknown sources
> - unless they are mode 4 response packets
>
> But the original sentence could also read:
>
> To minimize information leakage, leaf-node hosts should drop:
> - all incoming NTP packets
> - unless they are mode 4 response packets that come from unknown
> sources
>
> Perhaps this one is clearer and less ambiguous?
>
> [...] To minimize
> information leakage, leaf-node hosts should drop all incoming NTP
> packets that come from unknown sources except mode 4 response
> packets.
>

This sentense is indeed wrong. Thanks for pointing out. It should read:
[...] To minimize information leakage, leaf-node hosts should drop all incoming NTP packets except mode 4 response packets that come from known sources.

>--
>JINMEI, Tatuya