[sr-dev] improving the dialog module

Klaus Darilion klaus.mailinglists at pernau.at
Wed Mar 17 18:30:47 CET 2010



Am 17.03.2010 18:18, schrieb Iñaki Baz Castillo:
> 2010/3/17 Klaus Darilion<klaus.mailinglists at pernau.at>:
>
>>> But that is not a spoofed reply, instead it's just a 100% valid reply
>>> with a different To-tag. It could occur if the called is a proxy which
>>> performs serial forking (so after some seconds our proxy receives
>>> responses with a new To-tag, i.e. the remote voicemail server).
>>
>> Let's call it a malicious reply. I was talking about a false from-tag, not
>> to-tag. Thus, tm will accept the 200 ok and terminate the transaction (if it
>> is implemented RFC conform). If dialog module checks from-tag it probably
>> will ignore the reply.
>
> You are rigth, sorry, I understood "To-tag".
> Well, from the proxy point of view the transaction must end (even if
>  From tag doesn't match the dialog data), as the transaction layer is
> not dialog aware.
>
> But of course the dialog module would ignore the response as From-tag
> doesn't match, and that's the expected behavior (the UAC wouuld also
> ignore such response).

I checked dialog code: it is safe. Dialog does not have to check 
callid/tags as the dialog is already identified via the tm-callback (at 
least of out-of-dialog transactions).

Thus, a malicious response can not be used to bring tm/dialog out of 
synchronization.


>> Anyway, I guess dialog module is only good as helper module but shouldn't be
>> used as a reliable module (e.g. for security, accounting ...)
>
> That's the question. Theorically dialog module is just a helper, but
> looking at OpenSIPS there are several modules offering functionality
> based on dialog module... so... It's like "it's not a secure/robust
> module but I don't care".

I think it is OK for things like NAT traversal as an attacker can just 
stop its NAT traversal.

But for example it is unreliable for accounting. E.g. a malicious BYE 
request with manipulated RURI (sip:foo.bar instead of 
sip:00431234 at ip.address.of.gw) will stop the dialog, but never reach the 
gateway.

regards
klaus



More information about the sr-dev mailing list