<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: [sr-dev] Proposal: New Dialog Module Design</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>>> (1) Under "dialog_out table", the following is stated:<BR>
>><BR>
>> "A response arrives to the proxy and TM modules invokes the Dialog module<BR>
>> callback for the previously generated dialog.<BR>
>><BR>
>> *Such callback ignores the response if its Call-ID or From-tag doesn't match<BR>
>> the entry in dialog_in table with same hash_id*[...]"<BR>
>><BR>
>> I do not think the module has to check whether the response's Call-ID and<BR>
>> From-tag match the entry in the dialog_in table because a mismatch should<BR>
>> never happen: When the tm callback to dlg_reply() was registered in<BR>
>> dlg_onreq(), the hash ID of the very dialog created during dlg_onreq() was<BR>
>> passed as argument to tm's registration function. And since the tm module<BR>
>> makes sure that you cannot receive a response-based callback for a different<BR>
>> transaction than the one the registration was carried out from, the dialog<BR>
>> that the response-triggered callback will point to must be the right one.<BR>
><BR>
> At transaction layer just the branch and CSeq is inspected in order to<BR>
> match response with its corresponding client transaction. So the<BR>
> following could occur (due to a spoofed reply):<BR>
><BR>
> ### Request sent from proxy to Bob:<BR>
> INVITE sip:bob@example.org SIP/2.0<BR>
> Via: SIP/2.0/UDP 1.2.3.4;branch=aaaaaaaa<BR>
> From: sip:alice@example.org;tag=1111<BR>
> Call-ID: 11111111<BR>
> CSeq: 1 INVITE<BR>
><BR>
> ### Spoofed response frmo Bob (matches the transaction but not the dialog):<BR>
> SIP/2.0 180 Ringing<BR>
> Via: SIP/2.0/UDP 1.2.3.4;branch=aaaaaaaa<BR>
> From: sip:alice@example.org;tag=2222<BR>
> Call-ID: 22222222<BR>
> CSeq: 1 INVITE<BR>
><BR>
> So in this case, the fact that TM matches the response against an<BR>
> existing client transaction doesn't mean that the response is valid<BR>
> according to dialog rules so such values (From tag and Call-ID) should<BR>
> be matched by the Dialog module.<BR>
><BR>
> Do you agree? or do I miss something yet?<BR>
<BR>
I agree about the possibility of message forgery (which I simply did not<BR>
have in mind), and that another check on the Call-ID and From-tag will<BR>
avoid illegitimate tinkering with the dialog state.<BR>
<BR>
Generally, I don't know whether we should look at the security issue at<BR>
all here. I'm not much of a SIP security guy though, so off the top of my<BR>
head I wouldn't know if there are other, more effective measures to<BR>
counter "attacks" against the dialog state. If not, the check looks<BR>
reasonable (and quite easy to implement). If there are, or if From-tag<BR>
spoofing is just the tip of the eisberg and we need a more suitable<BR>
security mechanism anyway, such a one should be sought.<BR>
<BR>
<BR>
>> (2) The "Spiral" example only shows one possible implementation with two<BR>
>> dialog states created for an effectively single dialog. However, during the<BR>
>> thread on the mailing list that started off the re-design proposal, we<BR>
>> discussed another approach where a single dialog state is maintained for<BR>
>> spirals only (denoted "dialog continuation" by myself).<BR>
>><BR>
>> Is there a reason why this approach isn't taken into consideration on the<BR>
>> wiki page? If it's just a matter of time and effort, I'd be glad to add some<BR>
>> text and another example in order to let people comment on this further.<BR>
>> Like I said before, I really consider having dialog callback users deal with<BR>
>> module deficits the worse choice if a better option is available.<BR>
><BR>
> It's just a proposal, of course comments and suggestions are more than<BR>
> welcome :)<BR>
<BR>
OK -- just wondered if some new facts invalidated the single-dialog approach<BR>
by now. Glad to hear that's not the case. :)<BR>
<BR>
I will extend the wiki page on that issue as soon as I find some spare time.<BR>
<BR>
<BR>
> Could you please point me to your suggestion about "dialog continuation"?<BR>
> However, if we want a new spiral not no create a new dialog then it<BR>
> would be easily feasible just by adding a constrain when creating a<BR>
> dialog upon receipt of an INVITE:<BR>
><BR>
> "If there is already an entry in dialog_in table with same From-tag<BR>
> and Call-ID then the new INVITE is part of a spiral and no new dialog<BR>
> is created for it".<BR>
<BR>
Yeah, that's exactly what I had in mind (and, in fact, what I have<BR>
prototype-implemented already in Kamailio 1.5). Implemention-wise, I needed<BR>
to extend dlg_onreq() and two or three helper functions slightly.<BR>
<BR>
By the way, the look-up in the dialog hash table based on From-tag and<BR>
Call-ID, and skipping of a new dialog creation is just what I call<BR>
"dialog continuation". It's a pretty fancy word for a rather simple thing,<BR>
but for completeness, I mentioned it first in the very first post of<BR>
the "Improving the dialog module" thread:<BR>
<BR>
<A HREF="http://lists.sip-router.org/pipermail/sr-dev/2010-March/006378.html">http://lists.sip-router.org/pipermail/sr-dev/2010-March/006378.html</A><BR>
(under "Solutions", (1))<BR>
<BR>
<BR>
Cheers,<BR>
<BR>
--Timo</FONT>
</P>
</BODY>
</HTML>