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? 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@somewhere.com SIP/2.0 ... Route: sip:12345@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
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@somewhere.com SIP/2.0 ... Route: sip:12345@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On Thursday 19 May 2005 07:49 am, Jan Janak wrote:
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.
Thanks Jan and everyone else who replied. I got it. Just wanted to point out again that I believe it would be to everyone best to make it more clear in documentation.
Michael
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@somewhere.com SIP/2.0 ... Route: sip:12345@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Jan Janak writes:
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.
just to let people know, cisco ios gws do NOT check host part of request-uri belongs to itself and thus happily process any invite they receive. as far as i know, there is currently no way to configure such a check in ios gws.
-- juha
if helps, you can set with a bind interface command (loopback) only for signalling and another only for RTP (IOS T Train feature set) and then apply an ACL for trusted Proxys...indeeed, the check for the R-URI I think doesnt't exist anymore...
Regards,
verbal ----- Original Message ----- From: "Juha Heinanen" jh@tutpro.com To: "Jan Janak" jan@iptel.org Cc: serusers@lists.iptel.org; "Michael Ulitskiy" mulitskiy@acedsl.com Sent: Friday, May 27, 2005 9:12 AM Subject: Re: [Serusers] Loose routing question
Jan Janak writes:
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.
just to let people know, cisco ios gws do NOT check host part of request-uri belongs to itself and thus happily process any invite they receive. as far as i know, there is currently no way to configure such a check in ios gws.
-- juha
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Francesco Bottà writes:
if helps, you can set with a bind interface command (loopback) only for signalling and another only for RTP (IOS T Train feature set) and then apply an ACL for trusted Proxys...indeeed, the check for the R-URI I think doesnt't exist anymore...
as jan explained, how does it help if trusted proxy doesn't know that invite to host foo.bar actually goes to the gw?
-- juha
Thanks, Juha! I wasn't aware of that. g-)
Juha Heinanen wrote:
Jan Janak writes:
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.
just to let people know, cisco ios gws do NOT check host part of request-uri belongs to itself and thus happily process any invite they receive. as far as i know, there is currently no way to configure such a check in ios gws.
-- juha
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Juha Heinanen wrote:
Jan Janak writes:
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.
just to let people know, cisco ios gws do NOT check host part of request-uri belongs to itself and thus happily process any invite they receive. as far as i know, there is currently no way to configure such a check in ios gws.
Thus you should not allow loose_routing for out-of-dialog requests. Even if a customer bypasses your PSTN routing logic by using a sip uri with a domain which resolves to the IP address of the gateway, you can bill the call as the user was authenticated.
regards, klaus
Klaus Darilion writes:
Thus you should not allow loose_routing for out-of-dialog requests.
yes, if you have no other means to prevent unauthorized use of your gw.
Even if a customer bypasses your PSTN routing logic by using a sip uri with a domain which resolves to the IP address of the gateway, you can bill the call as the user was authenticated.
yes, if the user has subscribed to pstn service.
-- juha
Juha Heinanen wrote:
Klaus Darilion writes:
Thus you should not allow loose_routing for out-of-dialog requests.
yes, if you have no other means to prevent unauthorized use of your gw.
Even if a customer bypasses your PSTN routing logic by using a sip uri with a domain which resolves to the IP address of the gateway, you can bill the call as the user was authenticated.
yes, if the user has subscribed to pstn service.
Oh yes! I'm a little shortsighted and only consider my setups :-)
regards, klaus
-
Francesco Bottà -
Greger V. Teigre -
Jan Janak -
Juha Heinanen -
Klaus Darilion -
Michael Ulitskiy -
Michael Ulitskiy