Open Letter to D-Link about their NTP vandalism

Two concrete technical suggestions to mitigate the volunteered NTP server's
usage issues at the DIX:

(1) Have someone else anycast the DIX block, and NAT the incoming NTP requests
to another NTP stratum-1 server (eg pool address(es)).

Or a much better idea:

(2) Renumber into a new /24, which is announced only at the DIX with no-export,
so that only DIX members are able to reach the server - as was the intended
usage of this NTP server in the first place.

(The announcment can be made by anyone at the DIX, it is not strictly necessary
that the NTP server be the announcer of the /24. And in fact, it need not be
a /24, as the server should be the only occupant of the block - but it should
not be covered by any globally visible aggregate, at least not one contiguous
to the connectivity at the DIX.)

As to the liability issue, it is easy enough to envision that someone,
somewhere, is relying on time results from NTP for a life-or-death application,
like a medical device, and is innocently an impacted third party in this.

Sending bad NTP values could in theory be responsible for killing someone's
scratch monkey...

All these messages for a device that:

- probably uses ntp for internal log cacheing
- is a home/SOHO device
- a box that can't be chimed
- has ntp on the wan port only

http://support.dlink.com/faq/view.asp?prod_id=1228&question=DI-604%20/%20DI-524_revD%20/%20DI-524_revE%20/%20DI-614+%20/%20DI-624%20/%20DI-754%20/%20DI-764%20/%20DI-774%20/%20DI-614+_revB%20/%20DI-604_revE%20/%20DI-774_revB%20/%20Di-784%20/%20DI-514

http://www.support.dlink.com/faq/view.asp?prod_id=1983&question=configure+ntp

I wonder who DNS servers they embedded.

-M<

Date: Tue, 11 Apr 2006 23:47:11 -0400
From: Brian Dickson

As to the liability issue, it is easy enough to envision that
someone, somewhere, is relying on time results from NTP for a
life-or-death application, like a medical device, and is innocently
an impacted third party in this.

If I had a life-or-death application depending on NTP, I'd do what I've
already suggested: Use GPS and multiple stratum-1 servers, and clip
adjustment delta magnitude. I might also listen for a heartbeat (no pun
intended) saying "device agrees with NTP server", then raise an error if
that condition failed.

Sending bad NTP values could in theory be responsible for killing
someone's scratch monkey...

I can only hope that my life is never entrusted to a device that, at the
suggestion of a lone NTP server, would adjust the clock by 42 years.
IANAL, nor do I play one on TV, but such a setup would seem grossly
negligent.

Automated devices fail. Pretending otherwise is foolish. But you _did_
say "scratch monkey". :slight_smile:

Eddy