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

[Jan Janak]

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.

  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.