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

Jiri Kuthan jiri at iptel.org
Thu Oct 7 10:57:42 CEST 2010


On 10/7/10 10:42 AM, Alex Balashov wrote:
> Now that K v3.1.0 provides send_reply(), what is the preferred ideology about whether to send stateful or stateless negative error replies?
>
> I mean in general, not in specific cases like digest authentication in the new 'auth' module, where, according to the docs, a transaction and stateful replies
> are required in order for enhanced nonce replay protection.

That's a fair point -- transaction processing could be used as "nonce memory" to
mitigate replay attacks. For that however transaction processing would have to be
in script earlier before anything else (sending a positive reply, doing anything
that's subject to authentication), and the nonce verification would have to be bound
to transaction id. Otherwise a replay attack could occur just with a different
transaction id, so that TM would not filter it out.

One could see it as a trade-off between a bit better replay-attack resilience and
a bit higher vulnerability to memory exhaustion. Both kind attacks are possibly
either way, so it is not a really either-or type of choice.

>
> The traditional wisdom in past bodies of scripts and knowledge in the public realm has been, in my interpretation, that stateless replies are acceptable for
> final negative responses from script[1]. After all, a reply like "404 Not Found" from the proxy is basically fire-and-forget; why devote additional
> transactional memory to it while the transaction hold-down timer expires? We do not care if we receive an ACK, nor want anything further to do with this branch.

Yes, that has been the purpose.

>
> On the other hand, there is a point of view out there that mixing stateless and stateful replies is not good, despite the somewhat increased overhead and
> resource usage associated with making all replies stateful.

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.

>This perspective emphasises that if the proxy is fundamentally operating in a stateful manner, it
> should do so with respect to all messages, rather than allowing a large category of replies to slip under the radar of TM and have possibly inconsistent results.
>
> For now, I have changed my code to use send_reply() in all cases where sl_send_reply() was used in the past; it seems easier to let Kamailio/SR make the
> decision. However, in practice, most requests will result in the creation of a transaction, so it is like replacing sl_send_reply() with t_reply() in the
> majority of cases.
>
> Am I missing anything? Any salient considerations I missed?


I think the argumentation is perfectly right, it is just the operational
trade-offs to be made.

>
> I am curious as to the consensus about the best practice here from the vantage point of the developers.

I'm personally most worried about memory exhaustion, but that's
really my choice which I would not advertise as generally applicable/best/whatsoever.
Eventually that's why we haven't cemented one way or other.

-jiri

>
> Thanks,
>
> -- Alex
>
> [1] Except in FAILURE-ROUTEs, from which only stateful replies may
> be issued.
>



More information about the sr-users mailing list