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

[Denis Reilly <[e-mail]>]

Hello,

We kept the ntpd-specific information in Section 4 on purpose, because although the security issues that were found applied to the protocol in general, all of the relevant papers that were cited were based on the ntpd implementation, so we felt it would be harder to separate this content. We did modify some text here to make it less implementation-specific, and we added some text advising users to contact the maintainers of their implementation to find out how to mitigate these issues in their implementations.

Thank you for your review. I will be uploading the (pre) 07 version to the Datatracker soon, and I will work with the WG chairs to figure out the next steps.

Best Regards,


--
Denis Reilly  |  Lead Engineer  |  [e-mail]  [phone]

-----Original Message-----
From: 神明達哉 <[e-mail]> 
Sent: Wednesday, July 25, 2018 7:31 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; <[e-mail]> <[e-mail]>
Subject: Re: [Int-dir] Intdir early review of draft-ietf-ntp-bcp-06

At Tue, 17 Jul 2018 19:40:24 +0200,
[e-mail] wrote:

> in our reply from June 30 we described the measures we intended to 
> take in order to address your concerns you expressed in your review 
> from Jun 15  of draft-ietf-ntp-bcp-06. In the meantime we added your 
> proposed changes to a new version of the draft. This version is not 
> yet uploaded to the datatracker but accesssible under 
> https://github.com/denisreilly/ntp-bcp/blob/master/draft-ietf-ntp-bcp-
> 07.xml We would very much appreciate if you could review the changes. 
> Please let us know if we addressed your concerns appropriately.

I've just re-reviewed the (pre) 07 version.  It generally looks pretty good to me, addressing my comments.  Regarding separating implementation ('ntpd') specific topics, I've noticed there are still a few places in the main text that refer to 'ntpd'

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

- Section 4.6.1
   Clients that are connected to leap smearing servers MUST NOT apply
   the "standard" NTP leap second handling.  So if they are using ntpd,
   these clients must never have a leap second file loaded, and the
   smearing servers must never advertise to clients that a leap second
   is pending.

- Section 5.1: 'the server statement' sounds like ntpd specific.
   An NTP client establishes a protected association by appending the
   key to the server statement in its configuration file.  Note that the
   NTP process has to trust the applied key.

- Various places in Section 6

You may want to move these to the appendix, but I don't argue these are a DISCUSS-level issue, and I'd leave the decision to you.

--
JINMEI, Tatuya