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

From: 神明達哉 <[email-masked]>
Date: Fri, 15 Jun 2018 13:12:57 -0700

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.

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

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

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.

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

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Fri, 15 Jun 2018 13:15:23 -0700

(sorry, there was a typo for the int-ads alias, resnding with fixing the error).

---

From: [email-masked]
Date: Sat, 30 Jun 2018 14:58:56 +0200

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

-----"神明達哉" <[email-masked]> wrote: -----

>To: "<[email-masked]>" <[email-masked]>, [email-masked]
>From: "神明達哉" <[email-masked]>
>Date: 06/15/2018 22:22
>Cc: [email-masked], [email-masked]
>Subject: Intdir early review of draft-ietf-ntp-bcp-06
>
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.

> (this comment would still apply regardless of how we resolve the
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.

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

> this effort was at draft #10, and in in the 'final call' process.

Thanks.

> packets that come from unknown sources except mode 4 response

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.

---

From: [email-masked]
Date: Sat, 30 Jun 2018 15:39:22 +0200

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:    +49-531-592-84 20
E-Mail: [email-masked]

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

Hello Tatuya,

Dieter Sibold

Thanks.