Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 9 Sep 1999 18:47:49 +0400 (MSD)
From:      Stas Kisel <stas@sonet.crimea.ua>
To:        avalon@coombs.anu.edu.au, stas@sonet.crimea.ua
Cc:        freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG
Subject:   Re: mbuf shortage situations
Message-ID:  <199909091447.SAA24055@sonet.crimea.ua>
In-Reply-To: <199909091315.XAA05192@cheops.anu.edu.au>

next in thread | previous in thread | raw e-mail | index | archive | help
> From avalon@cheops.anu.edu.au Thu Sep  9 16:17:27 1999

> > Probably it is not self-evident why we HAVE to drop this connection.
>
> 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.

1. If ever syslog used (or will use) TCP, it should drop the connection
which is logging data too quickly.
OS shouldn't kill process, only drop connection. So no crash.
More examples?

2. udp_drain() may either drop all packets or intellectually select
"offending" socket and try to avoid deletion of "right" packets and
simplifying spoofing. RFC allows 1st way, but 2-nd can improve OS.

3. Another idea. Apart from the *_drain() method. Probably I ever will
try to implement it somedays (quite low probability, though).
Set TCP window in a packets according to really available kernel
memory. Available memory should be distributed non-uniformly
between maximum number of sockets. So 1-st socket has window=
=64k-still_not_read_data, and 1024-th has window=MIN_WINDOW-
-still_not_read_data. 
MIN_WINDOW should be determined for max efficiency. About 2k.
Distribution can not be linear - it isapproximately like min(NORM*1/x,64k).
Exactly it can be determined via functional equation. Something like
\integral_0^maxsockets{dist(x)dx}=kernel_memory and several
conditions. (sorry for my poor TeX).

In a case of attack new sockets will be created with a very small
window - about 2k.

Please blame me as much as possible - probably I have missed some significant
detail.
Probably all this math suxx and the best is a "stair" function -
somebody already works on lowering TCP window, if I didn't mistaken.


--
Stas Kisel. UNIX, security, C, TCP/IP, Web. UNIX - the best adventure game
http://www.tekmetrics.com/transcript.shtml?pid=20053 http://www.crimea.edu
+380(652)510222,230238 ; stas@crimea.edu stas@sonet.crimea.ua ; 2:460/54.4



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909091447.SAA24055>