Date: Tue, 1 Dec 1998 10:30:44 -0600 From: Karl Denninger <karl@Denninger.Net> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, Matthew Dillon <dillon@apollo.backplane.com> Cc: John Saunders <john.saunders@scitec.com.au>, freebsd-current@FreeBSD.ORG Subject: Re: RE: D.O.S. attack protection enhancements commit (ICMP_BANDLIM) Message-ID: <19981201103044.A55812@Denninger.Net> In-Reply-To: <199812011619.LAA04055@khavrinen.lcs.mit.edu>; from Garrett Wollman on Tue, Dec 01, 1998 at 11:19:58AM -0500 References: <005b01be1cf6$e6368da0$6cb611cb@saruman.scitec.com.au> <199812010708.XAA03688@apollo.backplane.com> <199812011619.LAA04055@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 01, 1998 at 11:19:58AM -0500, Garrett Wollman wrote: > <<On Mon, 30 Nov 1998 23:08:50 -0800 (PST), Matthew Dillon <dillon@apollo.backplane.com> said: > > > As far as I can tell, it starves the mbuf pool and/or outgoing > > packet queues. > > More likely, this is a case of receive livelock -- the machine spends > all of its time in interrupt mode servicing hardware interrupts and > never makes it back down to soft IPL so that the network code can run > and actually process the packets. Jeff Mogul at DEC Palo Alto wrote a > paper about this a few years back. The right way to fix it is to > actively schedule network service, so that packets are dropped in > hardware when the machine is overloaded. > > You can check net.inet.ip.intr_queue_drops to see whether this is in > fact happening. Possibly. But the situation that Matt is talking about happens QUICKLY, and frequently leads to a hard-lock of the machine. I know what he's talking about, because I've seen it at MCSNet. I've NEVER been able to get a good traceback on what's going on - it happens too quickly. I suspect, however, that it is in fact a DOS attack sourced from the outside. > > thrown away. Furthermore, if the reply is to a non-existant > > IP on the local LAN, the ICMP replies get buffered while > > the machine tries to ARP the destination. > > We should rate-limit ARPs, but don't. Makes sense. > > If not, the xmit > > traffic goes to the switch which starts collisioning-out packets > > when the router beyond the switch saturates. > > I'm sorry, I can't parse this. > > > 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. > > -GAWollman 20kpps of ICMP traffic?! Surely you jest! -- -- Karl Denninger (karl@denninger.net) http://www.mcs.net/~karl I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. 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?19981201103044.A55812>