[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