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.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
