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

[David L. Mills]

David,

The true story of the U. Wisconsiin incident, along with others at NIST 
and USNO, is in: Mills, D.L., J. Levine, R. Schmidt and D. Plonka. 
Coping with overload on the Network Time Protocol public servers. Proc. 
Precision Time and Time Interval (PTTI) Applications and Planning 
Meeting (Washington DC, December 2004), 5-16. The paper is also on the 
web: www.eecis.udel.edu/~mills/papers.html.

So far as I know, Netgear had no plans to sue U. Wisconsin or the ISP. 
However, my very strong advice to U. Wisconsin was to sue Netgear. The 
incidents are what prompted the in-your-face practices in the latest 
SNTP RFC, as well as the traffic grooming and Kiss-o'Death response in 
recent NTP distributions.

I don't know what the argument is about with respect to IPV4 and NAT. I 
would assume best practice would be for the firewall to run NTP and 
provide its nonroutable IPv4 address behind the firewall. In principle, 
it could hand out a routable IPv4 (or IPv6) address of an outside server 
and translate only the return address. Frankly, I would rather the SOHO 
do broadcast, rather than be stung by a raft of clients.

Dave

David W. Hankins wrote:

> 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.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg