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,