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,