[SR-Users] Stateful vs. stateless replies from script
Alex Balashov
abalashov at evaristesys.com
Thu Oct 7 11:11:35 CEST 2010
On 10/07/2010 04:57 AM, Jiri Kuthan wrote:
> The problem is that "somewhat increased" can be A LOT. transaction
> context is in order of kilobytes and creating transaction context
> on every single request can exhaust memory very very quickly.
> It is not just about evil attacks but also about resilience against
> different sorts of misconfigurations which flood the server with
> traffic. Which happens.
Thanks to you and Marius for taking the time to formulate thorough
replies. I read them with interest!
Is the problem you mention above not mitigated to some extent by the
fact that a transaction is not created until either t_newtran() or
t_relay() is called? For example:
route {
...
if(is_method("INVITE")) {
...
if(!check_from()) {
xlog("L_ERR", "[...] From URI user part does not "
"match authorisation username!\n");
send_reply("403", "Forbidden");
exit;
}
...
if(!t_relay())
sl_reply_error();
}
As far as I know, the 403 Forbidden above would go out statelessly, right?
So, I assume that the misconfigurations and memory exhaust
vulnerabilities under discussion are -- if it is INVITEs we are
talking about -- ones in which the request is relayed and the negative
replies come end-to-end from upstream, right? But in that case, by
virtue of having called t_relay(), the reply is already processed
statefully.
Now, of course, there are other types of request handling where a
transaction is implicitly created, but am I correct in my
interpretation of INVITE handling vis-a-vis transaction creation above?
Thanks,
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
More information about the sr-users
mailing list