[SR-Users] Stateful vs. stateless replies from script

[Jiri Kuthan]

inline

On 10/7/10 11:11 AM, Alex Balashov wrote:
> 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?

yes


>
> 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?

I was refering to all other checks you may want to do before you establish
transaction context and forward. Particularly if you do authenticate. Generally
the "default" way of scripting was based on the assumption "don't establish
transaction/forward until it is clear you want to forward".

>  But in that case, by virtue of having called t_relay(), the reply is already
> processed statefully.

Yes, but I was making a point to a different case. Again -- I think the question
is "when does the script writer choose that a request is good enough to be processed".
Before all sort of tests the writer chooses to deploy are positive, stateless
reply seems safer to me.

>
> 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?

Yes. Until you do some t_command, there is no transaction contet. Once you do,
there is. The point is really in the script that incorporates some request
filtering policy -- what is good enough to spend memory on...

-jiri


>
> Thanks,
>