[Serusers] uri==myself check and record_route()

Maxim Sobolev sobomax at portaone.com
Thu Oct 23 12:46:13 CEST 2003


Jan Janak wrote:

> On 22-10 22:36, Maxim Sobolev wrote:
> 
>>> That is correct. Mid-dialog requests (like BYE) must not be processed
>>> in the if (uri==myself) section, you just need to relay them.
>>>
>>> The problem in your config file is that you reject anything that
>>> doesn't match (uri==myself), you should just t_relay such messages
>>> (yes I know it creates open relay).
>>>
>>> Determining what should be relayed and what not in this case is
>>> another story (since you probably doesn't want to be open relay).
>>> (Digest authentication doesn't help here much).
>>
>>That the problem I am trying to solve. Having my system working as an 
>>open relay is the idea that thrives me a lot. :-(
> 
> 
>   We discussed this some time ago, part of it is already
>   implemented, Juha started to implement another part, but I don't know
>   what is the current state.
> 
>   Here is a description:
> 
>   Before forwarding a mid-dialog request, a proxy would like to check
>   that the dialog has been established using the proxy. To be able to do
>   that, a piece information has to be inserted into INVITE message that
>   can later help to identify the dialog. The only place in the SIP
>   message where this can be done is Record-Route header field (because
>   you can make sure that the the contents of the header field will be
>   present in all subsequent requests).
> 
>   The proxy will mark the dialog by inserting ftag parameter into it's
>   Record-Route header field, the ftag parameter will contain From tag.
> 
>   Later, when a mid-dialog request (for example BYE) comes, the proxy
>   will do the following:
> 
>   - First it checks if From contains a domain the proxy is responsible
>     for and if so, it will simply generate digest challenge and that's
>     it. If the user is able to generate proper digest reply than he
>     belongs to our domain and his requests will be forwarded.
> 
>   - If From doesn't contain a domain the proxy is responsible from then
>     we can't use digest authentication--the sender wouldn't be able to
>     generate proper reply.
> 
>     In this case the proxy compares To tag with ftag parameter value
>     from it's Route header field. If they are same then the dialog was
>     established using the proxy and we are done -- we can relay the
>     request.
> 
>   
>   The algorithm will also work with messages which do not establish a
>   dialog like MESSAGE or OPTIONS because such message will have domain
>   of our proxy either in From (we challenge) or in the Request-URI
>   (processed automatically).
> 
>   Current implementation status is that the ftag part has already been
>   implemented and Juha recently sent a message that he is working on a
>   function that can do the comparison with To tag.
> 
>   The approach as described here won't prevent malicious users from
>   using your proxy as a relay because they can forge the Route header
>   field including ftag parameter, but it will prevent users that have
>   "misconfigured" their user agents from using you as outbound proxy.

Great!

>   To prevent also malicious users, some kind of cryptographic protection
>   of the Route header field would be needed. 
>   
>   This cryptographic protection is already implemented, but I have it in
>   form of a patch and I haven't enough time yet to integrate and test
>   it.

It should be relatively easy to do it - upon startup SER can generate 
some random string and then, when INVITE arrives, calculate one-way hash 
using this value and some other parameters that must persist during the 
dialog - e.g. Call-Id, From tag etc, then inserting it as a parameter 
into the Record-Route field. Then we can always check is the mid-dialog 
request should be serviced by us.

-Maxim




More information about the sr-users mailing list