Date: Thu, 9 Sep 1999 23:15:43 +1000 (EST) From: Darren Reed <avalon@coombs.anu.edu.au> To: stas@sonet.crimea.ua (Stas Kisel) Cc: avalon@coombs.anu.edu.au, stas@sonet.crimea.ua, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: mbuf shortage situations Message-ID: <199909091315.XAA05192@cheops.anu.edu.au> In-Reply-To: <199909090945.NAA18133@sonet.crimea.ua> from "Stas Kisel" at Sep 9, 99 01:45:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Stas Kisel, sie said: > > > From: Darren Reed <avalon@coombs.anu.edu.au> > > > The problem with this is the BSD TCP/IP implementation ACK's (or at least > > attempts to ACK) data as soon as it is received and it is a big no-no to > > discard queued data that has already been ACK'd. > > Probably it is not self-evident why we HAVE to drop this connection. > > It is evil connection. Good applications do read data from their sockets, > and evil ones do not. And ever if it is good, but silly or busy > application, good clients do not send so much data that application > can not process it. Am I wrong, there are any examples? So what if someone manages to crash a program due to a DOS attack ? An easy one that comes to mind is syslogd. It's often stuck in disk-wait and can easily be targetted with a large number of packets. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909091315.XAA05192>