[19485] in bugtraq
Re: /N grouped concurrency limits for network services
daemon@ATHENA.MIT.EDU (Solar Designer)
Mon Mar 5 17:44:29 2001
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID: <20010305223902.A3942@openwall.com>
Date: Mon, 5 Mar 2001 22:39:02 +0300
Reply-To: Solar Designer <solar@OPENWALL.COM>
From: Solar Designer <solar@OPENWALL.COM>
X-To: Dan Kaminsky <dankamin@cisco.com>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <00e501c0a3db$42a7c370$0300040a@na.cisco.com>; from
dankamin@cisco.com on Sat, Mar 03, 2001 at 04:12:46AM -0800
On Sat, Mar 03, 2001 at 04:12:46AM -0800, Dan Kaminsky wrote:
> > There's no memory consumption problem with implementing this feature
> > like the Bugtraq post implied.
>
> Sure there is. To cover the ground of a single /16 ACL, 256 /24 ACLs are
> required. To cover 256 /16's, 65536 /24's are required. More memory will
> be needed for the latter than the former.
I've got several e-mails like this, so I am CC'ing the list on this
reply now.
Different people have different kinds of concurrency and/or rate
limiting in mind when talking about this. Obviously, I was talking
about what I think is reasonable to implement.
Concurrency limiting doesn't run into any memory consumption problem.
The server only needs to maintain information about active sessions.
A reasonable combination of concurrency and rate limiting per source
address, such as what popa3d uses in standalone mode, is similar to
simple concurrency limiting with the difference that the definition
of "active" sessions is changed to include those which were recently
closed. This implies that only accepted connections cause a "slot"
to be allocated. Since a single source address (or netblock) could
cause up to a fixed number of slots to be allocated by keeping the
connections open, it doesn't hurt (security-wise) to also leave the
slots allocated for recently-closed connections. The table of what
is considered an "active" session may be of a fixed size, -- it only
needs to match the server capacity.
Of course, other combinations of concurrency and rate limiting are
possible.
Implementing per-source rate limiting alone and doing so at a lower
layer may run into (solvable) memory consumption problems.
--
/sd
