[Serusers] Loose routing question

Jan Janak jan at iptel.org
Thu May 19 13:49:14 CEST 2005


On 02-05-2005 19:00, Michael Ulitskiy wrote:
> Hello,
> 
> I'm trying to comprehend loose routing concept and I have
> a question that concerns me.
> As far as I understand loose routing says that if there're Route
> headers in a message it should be forwarded according to the URIs
> set in Route headers. 
> I thought that this is true only within a dialog, but RFC3261 (part 16.6) says:
> "Requests establishing a dialog may contain a preloaded Route header field."
> Also SER manual says: " the failure not to include loose routing in your scripts 
> may lead to infinite loops. Make sure that you include the following script 
> fragment immediately after request sanity checks" and provide the following
> piece of code:
> if (loose_route()) {
>         t_relay();
>         break;
> };
> 
> which as far as I understand unconditionally forwards message if Route header
> is present.
> So I'm wondering what about security? 

  Your concerns are correct. Loose routing and especially pre-loaded
  route sets can become security issue. Moreover, when loose routing is
  being used, then the SIP message can be forwarded to the URI from the
  2nd Route header field -- but all security-related check in SER
  usually check the Request-URI (which is the contact of the remote
  party in this case).

  You should put all the access control checks also before
  t_relay in the loose_route condition.  This will ensure that the
  caller has permissions to place calls to the URI in the Request-URI,
  nothing less nothing more.

  This is not yet enough (as you corrently point out in the text below)
  and because it is not possible to check the real IP and port of the
  next hop after all changes have been done by SER (and it is complex
  becuase it can involve DNS queries to resolve SRV/A records), you would 
  need to deploy some screening on the gateway side too.

  The gateway should check if the request is coming from the IP and port
  of the trusted proxy server and in addition to that it should verify
  that the Request-URI contains the IP (not hostname) and port that belongs 
  to the gateway. The Request-URI test is important because an attacker could
  create a fake DNS record that will resolve to the IP of your gateway
  and this way he could bypass access control checks on the proxy. If
  the request-uri of the message contains the IP of the gateway then you
  know that the proxy server did all the access control checks because
  it knew it was forwarding to the gateway. Requests containing another
  IP or any hostname in the Request-URI should be rejected by the
  gateway.

  If the gateway does not support such screening then you could put
  another SER instance with very simple configuration (that would just
  perform the checks, no loose routing) in front of it. The simpler the
  better in this case.

  Some people on the list also suggested putting a "magic cookie" into
  the Request-URI which will only be known to the SIP Proxy and gateway.
  The proxy server would only put the cookie into the Request-URI if it
  successfuly performed all the security checks and if it knows that it
  is forwarding to the gateway. The gateway would reject any request
  that does not contain the magic cookie.

     Jan.

> If I follow this guidelines how I would
> shield my PSTN gateway if anyone can construct message and 
> pre-load it with URI of my gateway and all my proxies must honor it.
> For example I have a PSTN gateway on ip address 10.1.1.5 and proxy
> on 10.1.1.10 that supposed to interface outside world.
>
> So I guess if someone construct a message like this:
> 
> INVITE sip:12345 at somewhere.com SIP/2.0
> ...
> Route: <sip:12345 at 10.1.1.5;lr>
> 
> my proxy will forward it to PSTN gateway and it will make outbound call.
> 
> Is this true? Please enlighten me on this.
> Thank you,
> 
> Michael
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers




More information about the sr-users mailing list