bad DCC traffic from e-corp.net

] From: Dave Lugo <dlugo@etherboy.com>

] > What countermeasures are appropriate?
]
] Until e-corp.net at minimum responds, I'd think that a firewalling
] that host would be an appropriate reponse.

I thought of that, but adding routing blackholes on the public servers
I control would not help the others and might harm them by shifting
the traffic to them.


> From: Paul Vixie <paul@vix.com>

> ...
> on the F and C root name servers, we use freebsd "ipfw" to limit each
> ingress flow to 100Kbits/sec.  this seems to cause bad actors to slow
> down, since they are in lockstep to our replies.

> ...
> you might consider something very similar in the dcc server code, since
> not every dcc server will be running on freebsd or otherwise have this
> kind of rate limiting built into its kernel.

dccd maintains rate limits for each recent client IP address as well
as for all anonymous clients taken together.  However, those limits
are compile-time parameters.  Until now, the pressure has been to
increase the limits for anonymous clients.  An additional bug is that
NOPs do not count against those limits.

Besides making DCCD_RL_SUB, DCCD_RL_FREE, and DCCD_RL_ALL_FREE
(see the installation instructions in the source, such as
in http://www.rhyolite.com/anti-spam/dcc/dcc-tree/INSTALL.html)
run-time parameters and counting NOPs, I wonder if I shouldn't count
each NOP as 10 or 20 real operations.  NOPs are much cheaper to handle,
but they should also happen only once hour or two per client.


I must confess I'm irked with the source of that PC code.  Not only
would this not be the first time his efforts have been noticeable in
bad ways at the public servers, but he is apparently not running DCC
servers for his customers.  Judging from the previous incidents, I
suspect he has never run a DCC server.  I'm in favor of commercial
software, including selling BSD-style licensed code (provided copyrights
are maintained).  Most of the uses of the DCC can be seen as selling
code that was obtained for free (e.g. at ISPs).  However, selling such
code with other people's network bandwidth and CPU cycles crosses the
line.


Vernon Schryver    vjs@rhyolite.com