Re: [ntpwg] [dhcwg] Network Time Protocol (NTP) OptionsforDHCPv6

Richard Gayraud (rgayraud) wrote:
> Hello All,
> 
> Thank you very much for all your comments about our draft. 
> Benoit and I did not expect such a passionate discussion when we 
> submitted it 3 weeks ago.
> 

Welcome back!

> With this email, I would like to summarize the current 
> situation, objections, issues, and possible solutions. We will 
> try to take into account as much as possible of the remarks and 
> questions. The possibility of an increased risk of catastrophic 
> event will be considered very carefully and will be mitigated.
> 
> First of all, I would like to expose again the motivation for 
> this work (I believe there was some confusion about the 
> rationale for it):
> 
> System administrators like to configure a large number of hosts 
> from a centralized DHCP server. Today, DHCP is a protocol of 
> choice for remote configuration of IP hosts. DHCPv6 is lacking 
> the ability to configure NTP clients. This is our main 
> motivation. So, this work is not intended to address some 
> hypothetical NTP requirement to improve its peer discovery 
> mechanisms. Instead, this work is intended to address a DHCPv6 
> need to include NTP configuration. In other words, we are 
> working in the context of DHCPv6, to make it more comprehensive. 
> One may argue that some other protocol than DHCP might be more 
> suitable for this, but our precise purpose is to extend DHCPv6 
> expressiveness.
> 

There seems to be a general misunderstanding of the differences between
NTP and SNTP and the fact that there's already an RFC for SNTP Options
(RFC4075). NTP and SNTP are really the same protocol and have the same
requirements for provisioning NTP Server addresses. The client needing
information does not need to distinguish between the two cases when
receiving NTP server addresses so why does DHCP?

> This is not a replacement for existing NTP configuration 
> mechanisms. This will simplify the work of system administrators 
> (or ISPs) by allowing global, remote configuration of NTP 
> clients, instead of individual, per-host configuration of the 
> ntpd.conf file. 

In that case we would want DNS names and not IP addresses. If you are
trying to configure an ntpd implementation most of the time you want
names and not addresses otherwise you reduce it's flexibility.

> We try to be implementation agnostic. As someone mentioned, 
> the parameters we selected exist in the reference implementation,
> but they are also clearly defined as part of the NTPv4 
> specification. The relevance of these parameters in DHCP 
> will be discussed. Some of will be removed, some will be added 
> (I encourage people in the NTP WG to propose some other useful 
> parameters). All depends on the level of expressiveness we want 
> to give to DHCP regarding NTP. In any case, all parameters will 
> be optional (in the same way they are in ntpd.conf). Only the 
> server identity will be required (IP address or FQDN depending 
> on the outcome of the discussion about this).

Most of the options mentioned are specialized for unusual situations not
encountered under normal conditions and should not be generally used.

> That being said, I tried to collect all the issues you raised in 
> a sort of 'dashboard' that I will update.
> 	
> 
> Issue #1: DHCPv6 NTP option may trigger some catastrophic event
> ---------------------------------------------------------------
> 
> This is similar to what happened in the past with hardcoded NTP 
> servers IP addresses in SOHO routers. We can imagine that a 
> badly designed SOHO equipment with an embedded DHCP server would 
> advertise a hardcoded address over the SOHO LAN. There has been 
> no consensus yet about the validity of this scenario:
> 
> - Some people think adding the possibility to carry an FQDN 
>   instead of an IP address will solve this,

The issues we see today with these SOHO routers have hardcoded IP
addresses that are in their firmware. They are almost certainly not
getting them from some external source. If they were to get them from
elsewhere that would at least be an improvement.

> - Others think FQDN will not solve the issue but move it to the 
>   DNS system, (though it might reduce the amplitude of the issue 
>   due to the distributed nature of DNS),
> 
> - Others think this is a non-issue as DHCP servers in SOHO 
>   equipments only redistribute information they got from their 
>   client side. Bigger DHCP servers are manually configured. 

Which of course brings up the question of what about smaller DHCP
servers which are probably much more numerous (though that's speculation
on my side).

>   The same problem would happen to DNS servers if SOHO equipments 
>   would contain hardcoded DNS servers addresses. But in the case 
>   of DNS, DHCP have contributed to avoid the issue rather than 
>   amplifying it (please refer to the 2 messages Mark Andrews sent
>   on sunday and monday for details).

DNS lookups from NTP are very infrequent, usually just at startup. New
lookups are likely to happen if the returned IP address does not have a
responding NTP server and the NTP client needs to drop that address.

> Unless we all agree with Mark Andrews that this is a non-issue, 
> we need to fully understand the exact use case involved if this 
> problem can happen, and provide a way to avoid it. Next week 
> discussions might be a good opportunity to clarify this.

Yes, but unfortunately I cannot be in Vancouver.

> => Possible solutions include:
> 
>  - use of FQDN,
> 
>  - add clear statement an NTP server IP address MUST NOT be 
>    hardcoded in a DHCP servers, unless it points to an equipments 
>    operated by the vendor. describe the risk in the document 
>    itself

That's a minimum requirement I think.

>  - mandatory use of FQDN ?

Oddly enough I don't want to be that strict. There are a number of
(S)NTP clients embedded in firmware which may not have a resolver or the
code to call one so we do need to take that into account. Of course this
is counter to the rest of my arguments!

>  - aren't KOD packets part of the solution ? (This draft only 
>    addresses NTPv4 clients with IPv6 connectivity). Maybe we 
>    can enforce support for KOD for clients supporting DHCP NTP 
>    configuration.

No KoD just warns abusive clients. It does nothing to get them to take
action though we can poison the timestamp if we have to. I don't know
how you expect DHCP to be involved here. You certainly cannot even ask a
client if they obey KoD packets.

> Issue #2: Use of FQDN should be allowed for DNS indirection
> -----------------------------------------------------------
> 
> Regardless the outcome of Issue #1, there seems to be some 
> interest in the community to carry either an IP address or an 
> FQDN (ntpd.conf also offers FQDN as a way to specify server 
> identity).
> 
> We could re-define the option syntax to use sub-options. FQDN 
> and Server address being 2 possible sub-options. Other 
> parameters (if suitable) could also be defined as sub-options.
> 
> 
> Issue #3: Irrelevant parameters (maxpoll/minpoll/burst/iburst)
> --------------------------------------------------------------
> 
> When writing the first version of this draft, one of our goals 
> was to allow better control of the tradeoff between NTP clock 
> precision and traffic generated over a LAN. IPv6 has a large 
> address space, and an IPv6 subnet can contain a huge number of 
> hosts. Thus, it may be suitable to reduce the amount of traffic 
> generated by NTP clients. On the other hand, some deployments 
> may require fast and precise clock synchronization. Hence the 
> Maxpoll, Minpoll, Burst and IBurst parameters. Again, these are 
> not mandatory and will rarely be used.
> 
> - some people says you have to be an expert to set these 
>   parameters and these should not be opened.

Use of these options do *not* give you fast and precise clock
synchronization with the exception of iburst which should be the default
setting anyway. It's a common misunderstanding of how NTP works. We
might want to update the reference implementation to make that a
default; it's not the default currently.

> => I do not understand why the workstation users (controlling 
>    their individual ntpd.conf file) would be more skilled to 
>    set these parameters than network administrators (controlling
>    the DHCP server)? 

They most likely would not have any idea how to configure an NTP server.
A network administrator is going to know what NTP servers in the network
can be used or at least the nearest ones externally that allow open
access or permitted access by them. Large networks should have their own
NTP servers and point all of their clients to those rather than using
external NTP servers. Smaller networks should be using the country-
specific pool addresses. Note that the pool (pool.ntp.org and the
country-specific subdomains like uk.pool.ntp.org) is configured to give
out a different set and order of IP addresses to distribute the NTP load
among the pool members so here it is important to use FQDN names. ntp
servers are then strongly encouraged to use the pool in this way.

> If some parameter is questionable in a DHCP option, I think it 
> is also questionable as an ntpd.conf option. Isn't it?

No. Some of the options are for specific issues that need to be
addressed and since ntpd is also used for refclocks those are also a
separate set of options and then there's orphan mode for isolated
networks without access to a refclock somewhere in the network. I'm sure
there are similar options in the DHCP configuration.

What *is* missing is autokey. This is necessary for authenticating the
servers sending NTP packets to the client. This also requires a key file
that needs to be made available OOB. key file distribution is not an
option mentioned in the DHCP option spec being discussed.

> I do remember examples of customers requesting that their NTP 
> clients quickly sync (and acquire time) on startup. If the network 
> administrator wants NTP this kind of behavior, he will set the 
> Burst flag to reach fast NTP convergence. Anything I missed here?

NO! Please do not use Burst as you will be abusing the NTP Servers. The
flag that should be used is iburst and that should be the default anyway
so it doesn't need to be specified at all. Burst should never be used on
a standard network, it's for special situations like occasional dialup
to NIST to fetch the latest NTP information.

> Issue #4: "maxpoll is useless"
> ------------------------------
> 
> Even people who like additional parameters, agree to say that 
> maxpoll is useless (Brian, Dave). Could you explain why this is 
> useless?.

You are pushing queries further out once the client ntp server has
settled down with disciplining the clock. 1024 seconds is usually quite
long enough and certainly does not abuse the servers. Most of the NTP
clock algorithms are built around the default values for normal network
and provide the best and fastest convergence to a given clock frequency
and clock value and it's rare for it to need to be anything else. The
Interplanetary network might need some tweaking for spacecraft on their
way to Mars, Jupiter and Saturn, but they are hardly normal situations!

> Issue #5: "delay is useless"
> ----------------------------
> 
> The delay field serves as a trigger to enable/disable the 
> client volley in multicast mode. Again, I don't understand why 
> this is useless. The goal of this parameter is not to have the 
> DHCP server to measure the network delay. It is simply to allow 
> the network administrator to manually configure a constant delay 
> to compensate for having no volley (please refer to  
> http://www.cis.udel.edu/~mills/ntp/html/confopt.html where the
> 'broadcastdelay' option has a similar purpose). I believe the 
> default 4ms might not be suitable for all network topologies.
> 

The DHCP has no way to measure the delay between the NTP client and the
Multicast NTP server since the delay relationship on the network between
the DHCP server, the NTP Client and the NTP server is unrelated. How
does the DHCP server measure the delay between each NTP client and the
NTP Multicast server? It's better to let the client make the
measurement. In normal operation it does so anyway.

> Issue #6: "multiple instances versus list of addresses"
> -------------------------------------------------------
> 
> The use of multiple instances of the same DHCP option to 
> advertise several NTP servers seems to be somewhat confusing. 
> Depending on the decision made for other issues, we will 
> probably change the syntax of the options (or sub-options if 
> any).
> 
> Having a list of "struct" or "records" is not usual in DHCP and 
> it is not guaranteed that implementations will support it. This 
> is why we opted for the simpler "multiple instances option" as 
> we have some per-server configuration parameters (Key-ID, issue 
> #7, might become another one). Any suggestion for a better 
> syntax allowing a list of "struct" to be carried over DHCPv6 is 
> welcome.

If you are going to send a list just send them one after the other and
say how many you are sending. Note that any options for that list would
normal be the same for every one of them.

> The sub-option syntax would enable easier future evolutions, but 
> it seems difficult to use it to attach per-server parameters like
> Burst or Key-ID (unless we consider the order of sub-options to 
> be relevant, which is a bit weird, isn't it?).
> 
No burst or iburst please. See above.

> Issue #7: Key ID
> ----------------
> 
> Some people suggest it might be useful to carry a Key ID with 
> each server name/address. There is no opposition to this I 
> believe.
> 
> 	
> Issue #8: Carrying an URL for a config file
> -------------------------------------------
> 
> This has been suggested a few times, but has 2 major drawbacks:
> 
>  - It requires the client to be ftp/tftp/http-enabled (a lot 
>    of complexity on the client),
>    
>  - It would be implementation dependant,
> 

If each client where running a different implementation this is almost
certainly true.

> If sub-options are used in the DHCP message, we will certainly 
> have the same level of flexibility. 
> 
> ----
> 
> Please tell me if I made any mistakes, I would like to converge 
> on a comprehensive list of issues.
> 

There are two additional issues that you should think about:

1) RFC4075 already exists as a separate option for SNTP clients and
that's not really necessary. This draft should look at consolidating
these two sets of options especially as DHCP has no way of knowing
whether or not the client is running NTP or SNTP and wouldn't be sending
different information anyway. Let the client figure out what it can use.
So you should obsolete RFC4075 with this draft. You could reuse the
option numbers perhaps.

2) Send an NTP timestamp
The reason for doing this is that some hardware (and even some systems!)
don't have a TOY so they have no idea what time or date it is when they
boot up. So when they get their DHCP settings have an NTP timestamp to
get the machine at least close to the correct time would be very useful
to those systems.

Comments?

Danny

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg