[SR-Users] Stateful vs. stateless replies from script
Andrei Pelinescu-Onciul
andrei at iptel.org
Thu Oct 7 12:16:09 CEST 2010
On Oct 07, 2010 at 10:57, Jiri Kuthan <jiri at iptel.org> wrote:
> 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.
There's a bit of a misunderstanding here. Stateful mode when using
nounce_count or one-time-nonces is required to avoid challenging a
possible retransmission (and not to enhance protection).
Consider the one-time-nonce example: each nonce is allowed only once, if
seen more then once the message will be challenged.
Now consider an authenticated message that is retransmitted: the first
message will pass authentication, but it's retransmission will fail =>
the retransmission will be challenged. This can cause problems when the
UA gets back an OK reply and a challenge reply for the same message
(theoretically it should work if they arrive in order, but in
practice...).
tm is used only to make sure retransmission are identified an not
challenged again.
[...]
In rest I agree with Jiri: I would use sl_send_reply() wherever I could
to send negative replies. The biggest problem right now is memory
consumption and not creating transactions helps a lot (one has to
remember that even a replied transaction is kept in memory for at least
5s and that is ignoring negative replies to INVITE when tm has to wait
for the ACK first).
OTOH if you start ser/sr/kamailio with 10Gb of RAM, you don't have more
then 1000-3000 cps and you are in a controlled environment (no DOS,
crazy device floods a.s.o), then it doesn't matter.
Andrei
More information about the sr-users
mailing list