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/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
