2010/3/20 Timo Reimann Timo.Reimann@1und1.de:
So in this case, the fact that TM matches the response against an existing client transaction doesn't mean that the response is valid according to dialog rules so such values (From tag and Call-ID) should be matched by the Dialog module.
Do you agree? or do I miss something yet?
I agree about the possibility of message forgery (which I simply did not have in mind), and that another check on the Call-ID and From-tag will avoid illegitimate tinkering with the dialog state.
If the UAC receives such spoofed response (wrong From-tag/Call-ID) I think it would ignore it. So if Dialog module doesn't do the same we would end with a dialog (in dialog_out) which in fact doesn't exist in the UAC. This is whay I think such check should be done.
Generally, I don't know whether we should look at the security issue at all here. I'm not much of a SIP security guy though, so off the top of my head I wouldn't know if there are other, more effective measures to counter "attacks" against the dialog state. If not, the check looks reasonable (and quite easy to implement). If there are, or if From-tag spoofing is just the tip of the eisberg and we need a more suitable security mechanism anyway, such a one should be sought.
Matching From-tag and Call-ID seems enough reasonable for me. However there could be other security issues realted to dialog, difficult to handle/check at proxy level (as a proxy is, by definition, not dialog-aware).
Anyhow, Dialog module should be just a helper, nothing related to accounting (IMHO).
OK -- just wondered if some new facts invalidated the single-dialog approach by now. Glad to hear that's not the case. :)
I will extend the wiki page on that issue as soon as I find some spare time.
I think it would be better if the wiki page contains a single proposal, without offering choices as these choices could be discussed here (I could be wrong, of course).
What I mean is that, if the unique dialog approach (when spiral occurs) is definitely better than the multiple dialogs approach, then let's modify it in the wiki :)
The question would be, is there somebody who prefers the spiral multiple dialogs approach? why?
Could you please point me to your suggestion about "dialog continuation"? However, if we want a new spiral not no create a new dialog then it would be easily feasible just by adding a constrain when creating a dialog upon receipt of an INVITE:
"If there is already an entry in dialog_in table with same From-tag and Call-ID then the new INVITE is part of a spiral and no new dialog is created for it".
Yeah, that's exactly what I had in mind (and, in fact, what I have prototype-implemented already in Kamailio 1.5). Implemention-wise, I needed to extend dlg_onreq() and two or three helper functions slightly.
Great!
By the way, the look-up in the dialog hash table based on From-tag and Call-ID, and skipping of a new dialog creation is just what I call "dialog continuation". It's a pretty fancy word for a rather simple thing, but for completeness, I mentioned it first in the very first post of the "Improving the dialog module" thread:
http://lists.sip-router.org/pipermail/sr-dev/2010-March/006378.html (under "Solutions", (1))
Ops, so long time ago that I forgot :)
Thanks a lot.