20 Mar
2010
20 Mar
'10
2:36 p.m.
2010/3/20 Timo Reimann <Timo.Reimann(a)1und1.de>de>:
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.
Great!
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. 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. 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(a)aliax.net>