3 May
2005
3 May
'05
2 a.m.
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
19 May
19 May
2:49 p.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6:38 p.m.
On Thursday 19 May 2005 07:49 am, Jan Janak wrote:
On 02-05-2005 19:00, Michael Ulitskiy wrote:
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
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
27 May
27 May
10:12 a.m.
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
10:11 a.m.
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(a)tutpro.com>
To: "Jan Janak" <jan(a)iptel.org>
Cc: <serusers(a)lists.iptel.org>rg>; "Michael Ulitskiy"
<mulitskiy(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
10:44 a.m.
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
29 May
29 May
11:04 a.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers 
7 Jun
7 Jun
12:08 p.m.
Juha Heinanen wrote:
Jan Janak writes:
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
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.
12:58 p.m.
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
3 p.m.
Juha Heinanen wrote:
Klaus Darilion writes:
Oh yes! I'm a little shortsighted and only consider my setups :-)
regards,
klaus
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.
7114
days inactive
7150
days old
9 comments
7 participants
participants (7)
-
Francesco Bottà -
Greger V. Teigre -
Jan Janak -
Juha Heinanen -
Klaus Darilion -
Michael Ulitskiy -
Michael Ulitskiy