[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