23 Oct
2003
23 Oct
'03
1:55 a.m.
On 22-10 22:36, Maxim Sobolev wrote:
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.
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.
Jan.
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. :-(