>> (1) Under "dialog_out table", the following is stated:
>>
>> "A response arrives to the proxy and TM modules invokes the Dialog module
>> callback for the previously generated dialog.
>>
>> *Such callback ignores the response if its Call-ID or From-tag doesn't match
>> the entry in dialog_in table with same hash_id*[...]"
>>
>> I do not think the module has to check whether the response's Call-ID and
>> From-tag match the entry in the dialog_in table because a mismatch should
>> never happen: When the tm callback to dlg_reply() was registered in
>> dlg_onreq(), the hash ID of the very dialog created during dlg_onreq() was
>> passed as argument to tm's registration function. And since the tm module
>> makes sure that you cannot receive a response-based callback for a different
>> transaction than the one the registration was carried out from, the dialog
>> that the response-triggered callback will point to must be the right one.
>
> At transaction layer just the branch and CSeq is inspected in order to
> match response with its corresponding client transaction. So the
> following could occur (due to a spoofed reply):
>
> ### Request sent from proxy to Bob:
> INVITE sip:bob@example.org SIP/2.0
> Via: SIP/2.0/UDP 1.2.3.4;branch=aaaaaaaa
> From: sip:alice@example.org;tag=1111
> Call-ID: 11111111
> CSeq: 1 INVITE
>
> ### Spoofed response frmo Bob (matches the transaction but not the dialog):
> SIP/2.0 180 Ringing
> Via: SIP/2.0/UDP 1.2.3.4;branch=aaaaaaaa
> From: sip:alice@example.org;tag=2222
> Call-ID: 22222222
> CSeq: 1 INVITE
>
> 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.


>> (2) The "Spiral" example only shows one possible implementation with two
>> dialog states created for an effectively single dialog. However, during the
>> thread on the mailing list that started off the re-design proposal, we
>> discussed another approach where a single dialog state is maintained for
>> spirals only (denoted "dialog continuation" by myself).
>>
>> Is there a reason why this approach isn't taken into consideration on the
>> wiki page? If it's just a matter of time and effort, I'd be glad to add some
>> text and another example in order to let people comment on this further.
>> Like I said before, I really consider having dialog callback users deal with
>> module deficits the worse choice if a better option is available.
>
> It's just a proposal, of course comments and suggestions are more than
> welcome :)

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.


> 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))


Cheers,

--Timo