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