[dhcwg] Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6

[Danny Mayer <[e-mail]>]

[This is a resend since the dhcpwg SMTP list server rejected my email
for no obvious reason]

Benoit Lourdelet (blourdel) wrote:
> Hello, 
> 
> We have just submitted a new draft proposing an NTP option for DHCPv6. 
> 
> The goal of this draft is to standardize automatic configuration of
> NTPv4 (IPv6) clients over DHCPv6.
> We think there is currently no satisfactory solution for configuring
> NTPv4 clients from a centralized DHCPv6 server.
> 
> We'd be very happy to hear feedback about the draft, and I'm planning to
> ask that it becomes a WG draft eventually.
> 
> Here's a url:
> 
>  
> http://www.ietf.org/internet-drafts/draft-gayraud-dhcpv6-ntp-opt-00.txt

I reviewed this draft, even though I'm in the middle of reviewing the
autokey draft, and I find it misconceived.

1) The draft seems geared to only the reference implementation of NTP
rather than being implementation agnostic. There is also reference to
SNTP which the reference implementation is not and in any case SNTP
implementations are likely to have different terms and requirements for
configuration.

2) The server must never be specified as an IP address but always as a
DNS name. If you wish to use only IPv6 there are options to do so. It is
easy to configure a DNS server for the specific purpose if it is local
to the site. We have had too many incidents of hardcoded addresses which
cause major incorrect usage of ntp servers not to mention clients that
continue to try and use the same server months and even years after it
has stopped being an NTP server. The only time you might use an IPv6
address here is if the address is site-local or link-local. A future
enhancement to the reference implementation will requery the DNS for new
address information in the case of failure of responses from the
configured NTP server and will allow easy migration of NTP services.
This also ignores the pool option now available in the development NTP
reference code.

3) The additional fields that you specify should *never* be set unless
you understand exactly what you are doing. We always recommend the use
of iburst (and not i-burst BTW) so it's not necessary to specify this.
The use of burst contradicts the last sentence of the last paragraph of
Section 2.1. The use of minpoll and maxpoll is similarly bad for exactly
the same reasons. You need to have very special reasons to set these to
anything other than the default.

4) There is no autokey option even though the Section 6 discusses
security considerations which seem to be for DHCPv6 only without any
consideration whatsoever for NTP. These packet options provide a
convenient way of distributing autokey keys to the clients but it is not
 an option under this draft

5) The multicast option similarly has flaws. The only practical values
are FF02::101 and FF05::101 which are reserved for NTP usage unless you
are planning to use other ones. The delay however is position-dependent
on the wire and a DHCPv6 server is never going to know what that delay
is likely to be so there is no way for it to determine what to set it to.

6) I have not read either RFC 3315 or RFC4075 but section 6 Security
Considerations totally ignores NTP and other time issues. If you are
provisioning NTP on the client you *cannot* use any authentication
mechanism that assumes that the time on the client has any valid value.
Furthermore there is nothing to prevent the client receiving invalid NTP
configuration options. If DHCPv6 itself is using time-dependent
authentication mechanisms it is flawed, possibly fatally so since the
client will not have the correct time in the first place. I see no way
to fix this nor how to prevent a rogue system sending its own packets
and having them accepted as valid.

I'm going to stop here but I recommend that this draft does not proceed
and needs to be totally rewritten.

Danny


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg