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

On Mon, Nov 19, 2007 at 08:58:26AM -0600, Ted Lemon wrote:
> There's no reason why this option should use FQDNs while the other fifty
> use IP addresses, and there are a number of good reasons not to send
> FQDNs, the first and most obvious of which is that they take up more
> space in the packet, and space in the packet is very limited.

There is a concern of which I am aware among the NTP users community
concerning a recent catastrophic event which I think I am reading
in the subtext of this thread.  Lets find out.

A SOHO router manufacturer latched onto the IPv4 address (not the
domain name) of a particular open-to-the-public NTP clock.  The
IPv4 address was hard-coded into their firmware.

Upon the release of this product, said clock was slowly subjected to
what grew into an Entire-Internet scale distributed DDOS.

The operator responsible for the NTP device at said IPv4 address was
not willing nor capable of continuing to supply free bandwidth and
hardened NTP servers to meet this SOHO router manufacturer's global
clocking needs, certainly not free of charge, and ultimately had to
readdress his clock.  I seem to recall he was actually sued by the
SOHO router manufacturer, because all their SOHO routers suddenly
started spitting errors and misbehaving when this free service was
withheld, but my memory is beyond its limits at this point.

So it is possible that the community may strongly desire an otherwise
unusual number of intermediaries between /etc/ntp.conf and the IPv4
addresses they determine.

DHCP is an excellent solution, because it is likely that this SOHO
router was in fact obtaining its own IP address via DHCPv4, so if
it also received its clock via DHCPv4 rather than being hard-
coded, there would never have been a problem to solve.

IPv4 addresses via DHCP are possibly a worse solution, however,
because if it does deliver fixed IPv4 addresses to clients, then a NAT
box acting as a home gateway is a greater operational danger than the
above; imagine if this SOHO router manufacturer had decided to deliver
the fixed IPv4 address they had selected via DHCPv4 to all its
NAT-side clients, in all homes its clones resided, worldwide.

So if the DHCP protocol field required RFC1035 syntax, an IPv4 address
becomes an illegal configuration format, and that may be a desirable
outcome to a segment of the operational community that is concerned
with the historic stickyness of their IPv4 addresses, and the tendency
to get sued for publishing one.

I do not make a judgement at this time, but I would like to caution
the NTP community that additional intermediaries will not necessarily
correct bad behaviour.  In example, putting your clock's location in
DNS resolution into A/AAAA records does not mean a SOHO router
manufacturer can not / will not resolve those addresses and then
hard-code them into products.

I would also like to suggest that some of these concerns may be
mitigated by tracking Ralph Drom's recent 'container option' draft,
wherein a SOHO router may dynamically receive from an 'upstream'
DHCPv6 server the configuration values it should give 'downstream'
DHCPv6 clients.

I'm not aware of an equivalent for DHCPv4 however.

So cautioned, I personally leave it up to the NTP community to
prove to us exactly to what extent it is genuinely useful to have
such intermediaries as DNS (or even DHCP, even if I consider that
a given) involved.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins