Re: [Partysip-dev] loop detection

[Aymeric Moizard]

Hi fredrik,

Thanks for working on partysip, more below:

On Mon, 2 Sep 2002, Fredrik Thulin wrote:

> Hi
>
> It appears to me that loop detection for a SIP proxy server is very much like
> loop detection for a mail server (something I'm much more familiar with).
> First of all you want to make sure you are not going to send something to
> yourself, and secondly you want to make sure that noone has made up a new
> name for you that you are not aware of (so that noone can add a CNAME for
> 'is.stupid.example.com' to sipserver.su.se and then call me at
> 'address@hidden' instead of any of my real addresses). Third thing
> you want to do is check if there are too many Via: headers in there. I
> haven't read the SIP documentations yet (sorry for speaking up before doing
> my homework, I will as soon as I get the time) but there seems to be
> something called Max-Forwards which I suspect is designed to solve this
> problem.

There is many different task a proxy should do:
 1: check if a loop/spiral exist.
 2: make a difference between a loop (unvalid) and a spiral (valid)
 3: check if the max-forwards has been reached.

In fact, what you are doing is try to avoid creating a loop. This is
good. But you also have some mechanisms that could be used to detect
when they exist. This is more what the rfc speak about. You can
check how loops are detected in rfc3261 (using the "sent-by" and other
values... Note that actually partysip does not use the sent-by
parameter... it should...).

> So I started poking around the partysip code, but I couldn't really
> get it to work so I humbly ask for lights in the dark. It seemed like
> too much work has been done (resources allocated etc) to do the loop
> checking after the DNS resolving, so I tried to add DNS resolving in
> the psp_core_is_responsible_for_this_route() routine.
>
> However, as DNS lookups seems to be done asynchronously by a thread or
> something this loop prevention usually fails the first time because there is
> nothing in the cache.
> How can I make it wait until the answer is available, or do you think it is
> more suitable to do the loop checking later on when evaluating destinations?
> Maybe the latter is better after all...

Well... I got no simple solution by now! My idea is to remove the
stateless module (or at least give the possibility to run partysip
as a stateless or as a statefull module but never both at the same
time: this would allow the creation of transaction at the reception
of message instead of waiting for the first plugins to be called.
Then, it would be easier to "loose" time on another NAME resolution.

Hope this will give you ideas.
Anyway, it would be good to get a fix for the initial issue:
Try to prevent loop detection, at least the ones the administrator
can avoid: eg: give the list of virtual host and not only one and
verify all of them in "psp_core_is_responsible_for_this_route()"!
(also, this would avoid unusefull resolution when we are not in the
case of an attack :)

Aymeric

> Please give me some advise as to where this should go and also how to
> reject a destination.
>
> Attached are three patches,
>
>       * fredrik-partysip-debugging-patch1: more/improved debugging
>       * fredrik-partysip-recvfrom-patch1: use recvfrom() instead of recv() to
>           be able to show the source IP of received datagrams. Maybe there
>           is some other better way to do it - if so, please show me ;)
>       * fredrik-partysip-loop-detection-patch1: my work in progress
>
> do with them as you please.
>
> /Fredrik
>