[sr-dev] Proposal: New Dialog Module Design

[Iñaki Baz Castillo]

2010/3/20 Timo Reimann <Timo.Reimann at 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.

-- 
Iñaki Baz Castillo
<ibc at aliax.net>