Date: Wed, 2 Dec 1998 13:58:43 +1100 From: "John Saunders" <john.saunders@scitec.com.au> To: "Garrett Wollman" <wollman@khavrinen.lcs.mit.edu>, "Matthew Dillon" <dillon@apollo.backplane.com> Cc: <freebsd-current@FreeBSD.ORG> Subject: RE: RE: D.O.S. attack protection enhancements commit (ICMP_BANDLIM) Message-ID: <002401be1d9f$ac2c1bd0$6cb611cb@saruman.scitec.com.au> In-Reply-To: <199812011619.LAA04055@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett Wollman <wollman@lcs.mit.edu> wrote:
> Matthew Dillon <dillon@apollo.backplane.com> wrote:
> > It's a real problem. When you are receiving a 20Kpps
> > attack you do not want to be transmitting 20Kpps in ICMP
> > replies to a possibly spoofed address.
>
> Then again, when you are receiving 20kpps of legitimate traffic, you
> still want to behave correctly.
I think Matt's (cleaned up) patch should go ahead as the idea
is sound. It's never normal to have 20Kpps ICMP traffic
(famous last words :-) in even the largest networks today.
The talk about stability is really an interesting aside from
the patch itself and outside of Matt's scope.
Additions to the patch I would like to see are a nice sysctl
variable to set the rate limit, with setting it to 0
effectively disabling the limit (although I'll be enabling
it personally). Particular care should be taken to see that
if rate limiting is disabled then the extra execution
overhead is minimal.
<back to interesting stability discussion>
However if what we are saying is that under 20Kpps ICMP
traffic FreeBSD wedges, what happens under 20Kpps of
perfectly valid UDP or TCP traffic? We probably won't see
high packet rate TCP traffic because you need 240Mbps
bandwidth to generate 20Kpps with a 1500 byte MTU. However
high UDP packet rates are possible and will get worse as
services like VoIP become more mainstream.
If the problem is mbuf starvation shouldn't the network layer
simply pause until resources become available? Anything not
network related should continue as normal.
If the problem is CPU starvation from excessive network
interrupts, the network driver layer should throttle itself
back somehow. This is a difficult task to do elegantly and
most commercial drivers I have worked on or seen take a
pragmatic approach.
The ARP rate limit seems interesting. Possibly an exponential
backoff algorithm for ARP requests, with queued packet dumping
could be implemented. The way I see it if no ARP response is
available after a few seconds we can become _really_ aggressive
about dumping queued packets.
Cheers.
-- . +-------------------------------------------------------+
,--_|\ | John Saunders mailto:John.Saunders@scitec.com.au |
/ Oz \ | SCITEC LIMITED Phone +61294289563 Fax +61294289933 |
\_,--\_/ | "By the time you make ends meet, they move the ends." |
v +-------------------------------------------------------+
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002401be1d9f$ac2c1bd0$6cb611cb>