Open Letter to D-Link about their NTP vandalism

Date: Tue, 11 Apr 2006 14:29:02 -0400 (EDT)
From: "Michael Froomkin - U.Miami School of Law" <froomkin@law.miami.edu>
Cc: nanog@nanog.org`
Subject: Re: Open Letter to D-Link about their NTP vandalism

>
> It's legal to have broken NTP server in ANY country, and it's legal in most
> (by number) countries to send counter-attack (except USA as usual, where
> lawyers want to get their money and so do not allow people to self-defence).
>

<law professor> I'd really suggest that readers confirm this claim (that
intentional sending of false data with a malicious purpose is perfectly
acceptable) with a local lawyer before trying it at home or at work.</law
>

I'll suggest that there are several presumptions in that 'claim' that are
not fully supported by the facts of the matter, as previously described.

1) _Who_says_ it is 'false data'? *Who*knows* what that machines is 'supposed'
to provide TO WHOM? (The _published_ functionality is to provide time service
to queries from a specific address-range. This does *not* place any limits on
the 'expected behavior' when queried from _outside_ of that specific address-
range.)

2) *Who*says* there is 'malicious intent' involved? I'm going to be
travelling 'off network'(with the 'network' being defined as the one where
I have published that I'm providing time-server services to), and I happen
to have a recurring need for 32-bit units of a specifically transformed out-
put of a local hardware-based "/dev/random". So, I put up a server to deliver
that data when requested. For reasons of 'convenience' in my programming,
I choose to format the queries/responses like a particular 'well known'
protocol, and run it on the port associated with that well-known protocol.
Do I have any responsibility to 'announce' that I'm doing something like
that, for 'private' use?

*Am*I*responsible* if 'somebody else', _without_checking_with_me, and
=without=asking=my=permission=, queries that machine, and "assumes" that
the data that they get back is, in fact, from that 'well known' protocol?

In point of fact, if the server in question were located in the United States,
there is a colorable argument that can be advanced that the queries originating
from outside the address-space for which the owner declared he intended to
provide a specified service, constitute a violation of 18 USC 1030 (a) (2) (C).
(<http://www.law.cornell.edu/uscode/18/1030.html>, for those who need it :slight_smile:

Note that that section applies _regardless_ of the 'truthfulness'/'accuracy'
of the data returned.

I submit that;
1) If the query originator is 'entitled' to make assumptions about what the

2) It would seem that the server operator is *equally* 'entitled' to make
    assumptions about what the query means, and
3) to respond in a manner consistent with _his_ understanding of what the
    query originater 'wanted'.

If the query originator fails to 'get what he wanted', due to his failure
to communicate _in_advance_ with the server operator, *WHO* is to blame?

Now, if the sever operator publishes that he will provide a certain type of
date, in reqponse to a certain type of query, and someone sends that type
of query, you do (potentially) have the elements the elements of a contract,
and the server operator might be commiting a civil tort *if* the server
returns 'something unexpected'.

I also bet that the claim of widespread acceptability would fail badly if
we weigh countries by population. Or even connectivity.

Not to mention the fact that your packets might stray across borders
sometimes.

There's a _whole_nuther_ can of of worms, as regards "who is responsible"
when a device is totally passive until 'directed' to act by an outside
party. Is the one that is 'responsible' the one who configured the 'possible'
actions of the device, or the one who issued the command to perform one
of those actions? Does it matter if, through not bothering to investigate
adequately, the command issued does _not_ do what the issuer intended?

* bonomi@mail.r-bonomi.com (Robert Bonomi) [Tue 11 Apr 2006, 22:00 CEST]:

I'll suggest that there are several presumptions in that 'claim' that are not fully supported by the facts of the matter, as previously described.

Please don't suggest anything of the kind. This is not the North American International Law Posturing Group.

Your legal opinion is appreciated, but it's off-topic for this list.

  -- Niels.

1) _Who_says_ it is 'false data'? *Who*knows* what that machines is 'supposed'
to provide TO WHOM?

I think if you are handing another machine an NTP packet that's intentionally
set several months off just to get them to shut up, you *know* the answer
to "is it false data".

I submit that;
1) If the query originator is 'entitled' to make assumptions about what the

2) It would seem that the server operator is *equally* 'entitled' to make
   assumptions about what the query means, and
3) to respond in a manner consistent with _his_ understanding of what the
   query originater 'wanted'.

If the query originator fails to 'get what he wanted', due to his failure
to communicate _in_advance_ with the server operator, *WHO* is to blame?

I suppose pointing out that the Internet works because providers *cooperate*
and *agree on protocols* would be pointless....

Yeap ... cooperate... Which DLink is not doing.

    All legal discussion end the same way... a dead end.

    Half are scared by lawyer and the other have enought intestinal fortitude to put them in there place.

    (At the bottom of the sea hopefully)

Date: Tue, 11 Apr 2006 16:30:11 -0400
From: Valdis.Kletnieks

I suppose pointing out that the Internet works because providers
*cooperate* and *agree on protocols* would be pointless....

To a certain [limited] extent, anyway, as countless NANOG-L threads prove time and again. Of course, it's hard to view D-Link as "cooperative" in this instance.

AS112-style NTP service, anyone? That would be cooperative and possibly even useful.

Eddy

[I just happened to see this, browsing at high speed, so please
forgive me, if I'm out of context.]

eddy+public+spam@noc.everquick.net:

AS112-style NTP service, anyone? That would be cooperative and
possibly even useful.

That is actually not necessarily such a good idea.

With the current AS112 stuff, we only provide DNS reverse service for
network for which there should essentially be no queries. Hence,
replying with "doesn't exist" is kind of OK. Should an anycast
instance go rouge and give false answers, that is still within the
bounds of "acceptable", since the query shouldn't be there in the
first place.

If you create a disparate anycast system of NTP server, you run into a
security issue, since many security protocols have "accurate time" as
an important parameter, and a rouge anycast NTP server could create
substantial amounts of harm from security and other standpoints by
giving out incorrect time.

Nope, you want your NTP to come from an appropriate source ...
preferrably with signatures.

        Cheers,
          /Liman

Date: Wed, 12 Apr 2006 01:10:09 +0200
From: Lars-Johan Liman

[I just happened to see this, browsing at high speed, so please
forgive me, if I'm out of context.]

I was primarily referring to taking the load away from DIX. :slight_smile:
However, as long as you raise a few points...

If you create a disparate anycast system of NTP server, you run into a
security issue, since many security protocols have "accurate time" as
an important parameter, and a rouge anycast NTP server could create
substantial amounts of harm from security and other standpoints by
giving out incorrect time.

A rogue server can cause trouble regardless of whether it's anycasted
[by design]. The "blast radius" might be smaller (which can complicate
troubleshooting but helps contain damage). Of course, more systems
means more chance for failure.

Furthermore, "unicast by design" does nothing to prevent a rogue route
from changing that. Panix was just a recent victim of this.

Nope, you want your NTP to come from an appropriate source ...
preferrably with signatures.

Time to query multiple NTP sources, utilize GPS, and limit time
adjustment deltas.

I'll concede that multi-provider anycast presents an obvious problem for
sharing the key with "only the good guys". However, I think all the
little D-Link critters can live with unsigned stratum-9 answers by
default.

Eddy

2) *Who*says* there is 'malicious intent' involved? I'm going to be
travelling 'off network'(with the 'network' being defined as the one where
I have published that I'm providing time-server services to), and I happen
to have a recurring need for 32-bit units of a specifically
transformed out-
put of a local hardware-based "/dev/random". So, I put up a
server to deliver
that data when requested. For reasons of 'convenience' in my programming,
I choose to format the queries/responses like a particular 'well known'
protocol, and run it on the port associated with that well-known protocol.
Do I have any responsibility to 'announce' that I'm doing something like
that, for 'private' use?

  I don't understand how you can think that a hypothetical where we don't
know what the intent is constitutes a response to a situation where we do
know exactly what the intent is. I hope your argument is not "if you can lie
and get away with it, then it's okay". That doesn't sound like a good
business model to me.

again, denying service (assuming there's no explicit contract to provide
it) is unquestionably safe. i was responding to the proposal that the

wrong

time be deliberately returned. you'd be betting that nobody would notice
or that it would cost nobody money -- which isn't a safe bet, since

someone

can always find ways to allege that your intentional actions cost them

money.

(as opposed to your deliberate inaction, as in the case of denying

service.)

  The problem is this case is that there is no perfect way to deny service.
If bums are trampling your garden to take food out of your garbage, you can
lock the garbage can, but you can't poison the food. The problem becomes
when the locked garbage can is a problem for the garbage collectors.

  I don't think anything short of legal action against D-Link is likely to
solve this. I'd love to be proben wrong.

  DS

If everyone on NANOG were to send a boycott email ("Our company, Acme
Internet Carrier of Oshkosh, will no longer be using Dlink equipment due
to yada yada yada") and send it to the Investor Relations email addresses
listed at:
http://www.corpasia.net/taiwan/2332/irwebsite/index.php?secid=22&version=e&mod=ircontacts
Then Dlink would have to sit up and notice and fix the problem (especially
once the quarterly sales numbers shows an unexplained 10% sales dip
starting in May 2006).

And best of all - no lawyers needed. Boycotting someone or something is
legal.

-Hank

a message of 27 lines which said:

AS112-style NTP service, anyone? That would be cooperative and
possibly even useful.

It already exists (Security warning: do not use it on strategic
machine, there is no warranty that these servers are trustful):

http://www.pool.ntp.org/

Active server count on 2006-04-12
Africa 1
Asia 24
Europe 368
North America 223
Oceania 26
South America 7
Global 582
All Pool Servers 653

The pool.ntp.org project is a big virtual cluster of timeservers striving to provide reliable easy to use NTP service for millions of clients without putting a strain on the big popular timeservers.

Adrian von Bidder created this project after a discussion about resource consumption on the big timeservers, with the idea that for everyday use a DNS round robin would be good enough, and would allow spreading the load over many servers. The disadvantage is, of course, that you may occasionally get a bad server and that you usually won't get the server closest to you. The workarounds for this is respectively to make sure you configure at least three servers in your ntp.conf and to use the country zones (for example 0.us.pool.ntp.org) rather than the global zone (for example 0.pool.ntp.org). Read more on using the pool.

The pool is now enormously popular, being used by at least hundreds of thousands and maybe even millions of systems around the world.

The pool project is now being maintained by Ask Bj�rn Hansen and a great group of contributors on the mailing lists.

pool.ntp.org

Tony.

Apr 12 06:27:29 multid[360]: dns: 0.europe.pool.ntp.org: query
Apr 12 06:27:30 multid[360]: dns: 0.europe.pool.ntp.org: 82.71.9.63 ttl=79 from 192.168.180.1.
Apr 12 06:27:30 multid[360]: sending SNTP request to server 0.europe.pool.ntp.org (82.71.9.63)
Apr 12 06:27:30 multid[360]: The NTP time is 12.4.2006 04:27:29.150000 UTC
Apr 12 06:27:30 multid[360]: system time is 1.007000 seconds ahead
Apr 12 06:27:30 multid[360]: adjusting time backward 1.007000 seconds

Seems to do that every 8 hours.

I could not find a config file. Compiled into "/sbin/multid" ?

I guess similar devices like the maudit D-Link are much the same. Only that
multid deamon seems to be AVM specific. If that NTP thing is from the non
disclosed und unGPLed TI source then best forget about it. Replace it by some
wellknown software that is known not to be nasty.

Another router that is not compatible and not especially a good router -
has an html interface where you can put it your favourite NTP server.

I still wonder why I cannot configure the NTP server but at least it is not
as nasty as the D-Link.

Peter

Stephane Bortzmeyer wrote:

Just for curiousity, you can change it. /etc/hosts is a link

/etc/hosts -> ../var/tmp/hosts

you can edit but you cannot permanently save it.

cat /etc/hosts

127.0.0.1 localhost
192.168.178.1 fritz.box
217.10.79.8 0.europe.pool.ntp.org ntp.sipgate.de

Now I dont bother pool.ntp.org but ask my sip provider.
That trick might work for the D-Link too.

Of course 0.europe.pool.ntp.org is alright but that
ntp server D-Link has is not.

You have to insert the hostname plus ip into /var/tmp/hosts
or the box will ask DNS.

Cheers
Peter and Karin

Peter Dambier wrote:

Sorry for the noise again.

Yes, you can edit /etc/hosts

No, the box does not care.

Neither voipd nor multid care for it

Apr 13 05:25:17 voipd[402]: >>> Request: SUBSCRIBE sip:1887188@sipgate.de
Apr 13 05:25:17 voipd[402]: dns: _sip._udp.sipgate.de: query
Apr 13 05:25:17 voipd[402]: dns: _sip._udp.sipgate.de: "0 0 5060 sipgate.de" ttl=584 from 192.168.180.1.
Apr 13 05:25:17 voipd[402]: dns: sipgate.de: query
Apr 13 05:25:17 voipd[402]: dns: sipgate.de: 217.10.79.9 ttl=4786 from 192.168.180.1.
Apr 13 05:25:18 voipd[402]: <<< Status: 200 OK

Apr 13 02:27:25 multid[360]: dns: 0.europe.pool.ntp.org: query
Apr 13 02:27:25 multid[360]: dns: 0.europe.pool.ntp.org: 85.214.32.50 ttl=1619 from 192.168.180.1.
Apr 13 02:27:25 multid[360]: sending SNTP request to server 0.europe.pool.ntp.org (85.214.32.50)
Apr 13 02:27:25 multid[360]: The NTP time is 13.4.2006 00:27:24.133000 UTC
Apr 13 02:27:25 multid[360]: system time is 1.020000 seconds ahead
Apr 13 02:27:25 multid[360]: adjusting time backward 1.020000 seconds

Regards,
Peter and Karin

Peter Dambier wrote: