3 May
2005
3 May
'05
1:10 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
3 May
3 May
1:43 a.m.
Currently (in rel_0_9_) the "loose_route()" function will NOT match a
message unless SER has some stateful information regarding that
transaction in memory (my assumption has been that the information is
created when the "record_route()" or "record_route_preset()"
functions
are used and is referenced by "loose_route()" according to the
"tag=..."
header field inside the "Route:" header), so simply adding a "Route:
..." header into the sip message will not be loose_routed.
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? 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 May
6 May
11:20 a.m.
reticent wrote:
Currently (in rel_0_9_) the "loose_route()"
function will NOT match a
message unless SER has some stateful information regarding that
transaction in memory (my assumption has been that the information is
created when the "record_route()" or "record_route_preset()"
functions
are used and is referenced by "loose_route()" according to the
"tag=..."
header field inside the "Route:" header), so simply adding a "Route:
..." header into the sip message will not be loose_routed.
Could a Developer please ACK / non-ACK this that Ser suddenly turned
call stateful?
Regards,
Martin
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? 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
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
1:49 p.m.
New subject: [Serdev] Re: [Serusers] Loose routing question
No, it is not call stateful. I still keep all the messages regarding
loose_route on my todo list for review, because there were many of them
and I am not sure where does the confusion come from. I'll get back to
it.
Jan.
On 06-05-2005 11:20, Martin Koenig wrote:
reticent wrote:
Currently (in rel_0_9_) the
"loose_route()" function will NOT match a
message unless SER has some stateful information regarding that
transaction in memory (my assumption has been that the information is
created when the "record_route()" or "record_route_preset()"
functions
are used and is referenced by "loose_route()" according to the
"tag=..."
header field inside the "Route:" header), so simply adding a "Route:
..." header into the sip message will not be loose_routed.
Could a Developer please ACK / non-ACK this that Ser suddenly turned
call stateful?
Regards,
Martin
Michael Ulitskiy wrote:
_______________________________________________
Serdev mailing list
serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev 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
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7:35 p.m.
Whoops, sorry for the confusion
Guess i don't know as much about SER as i thought i did =P
tavis
Martin Koenig wrote:
reticent wrote:
Currently (in rel_0_9_) the
"loose_route()" function will NOT match a
message unless SER has some stateful information regarding that
transaction in memory (my assumption has been that the information is
created when the "record_route()" or "record_route_preset()"
functions
are used and is referenced by "loose_route()" according to the
"tag=..."
header field inside the "Route:" header), so simply adding a "Route:
..." header into the sip message will not be loose_routed.
Could a Developer please ACK / non-ACK this that Ser suddenly turned
call stateful?
Regards,
Martin
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? 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
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
9:14 a.m.
Yes, this is indeed a great problem. It is not easy to authenticate
loose_route processed messages. e.g. the following example:
a(a)a.com calls b(a)b.com. b forwards the request to c(a)c.com. Now, proxy c
should check if messages are allowed to be loose_routed. But the To: and
From: headers only include the domains a and b, never c. This,
authenticating the calls is not possible.
For all loose_routed reuqest, I check if there is a to-tag present. If
yes -> relay the request. Faked to-tag will be detected by the gateway
and should be rejected: cisco does :-), AFAIK asterisk does not :-(
If there is not tog-tag, I will reject the request.
This solution is fine aslong as you are not using asterisk as gateway.
regards,
klaus
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? 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
11:04 a.m.
Juha Heinanen wrote:
Klaus Darilion writes:
What would be a normal (out-of-dialog) check?
regards,
klaus
shorty, I'm doing this:
if (loose_route) {
if to-tag {
# in-dialog, faked messages must
# be handled by next hop
t_relay
} else {
# somebody tries to route via my proxy
if method==CANCEL {
# that's fine
t_relay()
} else {
# don't use my proxy to relay
sl_send_reply(...)
}
}
}
If there is not tog-tag, I will reject the
request.
what is the benefit of rejecting the request instead of calling
loose_route() and then doing your normal (out-of-dialog) checks to the
request?
3:56 p.m.
Juha Heinanen wrote:
Klaus Darilion writes:
I do not check them, as this always caused problems in forwarding
sceanrios. Consider the following example.
A: sip:a@a.com
B: sip:klaus@iptel.org
C: sip:klaus@enum.at
I made a permanent location entry in proxy B (iptel.org) to forward all
my calls to my primary SIP account (klaus(a)enum.at).
A calls B and C will pick up the call. Now, C puts the call on hold. The
reINVITE will be loose_route processed from C, B, and A.
The INVITE looks like:
INVITE ...
From: sip:klaus@iptel.org
To: sip:a@a.com
Thus, although the client is registered to C, C can not authenticate the
INVITE as the domain enum.at does not appear in From: or To:
Proxy B (iptel.org) may request authentication from my client (as From:
conatins iptel.org). But my stupid SIP phone can not authenticate
against iptel while registered to enum.at
Thus, I do not authenticate loose_route requests. I just check if it is
in-dialog. Thus, bad requests can handled by the other SIP client. I
don't like my setup, but I'm not aware how to overcome the presented
problem. Any hints?
regards,
klaus
What would be a normal (out-of-dialog) check?
the same checks you do for initial requests that don't have Route
header, i.e., check if domain of request uri is local, authenticate
caller if local, etc.
-- juha
4:13 p.m.
Klaus Darilion writes:
Thus, although the client is registered to C, C can
not authenticate the
INVITE as the domain enum.at does not appear in From: or To:
Proxy B (iptel.org) may request authentication from my client (as From:
conatins iptel.org). But my stupid SIP phone can not authenticate
against iptel while registered to enum.at
klaus,
i guess you misunderstood me. my original question was this:
If there is not tog-tag, I will reject the request.
what is the benefit of rejecting the request instead of calling
loose_route() and then doing your normal (out-of-dialog) checks to the
request?
i never suggested that you should try to authenticate in-dialog requests
(which do have to-tag). what i questioned is why you would reject an
INITIAL request, just because it includes a Route header, and you still
haven't answered THAT question.
-- juha
4 May
4 May
10:25 a.m.
Juha Heinanen wrote:
i never suggested that you should try to authenticate
in-dialog requests
(which do have to-tag). what i questioned is why you would reject an
INITIAL request, just because it includes a Route header, and you still
haven't answered THAT question.
OK, got the point. The answer is simple: it's easier to deny things than
to think about potential risks and how to authenticate calls. I can't
think about a scenario where a user needs to send a request via my
proxy. This sounds like using the proxy as smart-relay and there is no
need for that.
Of course I could allow it loose_route out-of dialog requests and apply
proper authentication logic, but what do I lose if I simply prohibit
such requests?
regards,
klaus
10:44 a.m.
Hi Juha!
Out of curiosity, how do you handle out-of dialog requests with a
pre-set route? If I would allow them, I would handle it this way:
if (loose_route) {
if to-tag {
# in-dialog, faked messages must
# be handled by next hop
t_relay
break;
}
# out-of dialog request
if method==CANCEL {
# that's fine
t_relay()
break;
}
# check if it is a local user
if is_from_local {
if proxy_authorize {
t_relay
} else {
proxy_challenge
}
break;
}
# don't use my proxy to relay
sl_send_reply("403","Relaying not allowed")
break;
}
Juha Heinanen wrote:
Klaus Darilion writes:
Thus, although the client is registered to C, C
can not authenticate the
INVITE as the domain enum.at does not appear in From: or To:
Proxy B (iptel.org) may request authentication from my client (as From:
conatins iptel.org). But my stupid SIP phone can not authenticate
against iptel while registered to enum.at
klaus,
i guess you misunderstood me. my original question was this:
If there is not tog-tag, I will reject the
request.
what is the benefit of rejecting the request instead of calling
loose_route() and then doing your normal (out-of-dialog) checks to the
request?
i never suggested that you should try to authenticate in-dialog requests
(which do have to-tag). what i questioned is why you would reject an
INITIAL request, just because it includes a Route header, and you still
haven't answered THAT question.
-- juha
1:44 p.m.
Klaus Darilion writes:
Out of curiosity, how do you handle out-of dialog
requests with a
pre-set route? If I would allow them, I would handle it this way:
something like that, but of course you would need to allow also requests
to your local users from foreign users (unless you have a walled garden).
-- juha
5:06 p.m.
Juha Heinanen wrote:
Klaus Darilion writes:
ACK. But still I see no reason why an incoming call for example will use
a pre-route set?
regards,
klaus
Out of curiosity, how do you handle out-of dialog
requests with a
pre-set route? If I would allow them, I would handle it this way:
something like that, but of course you would need to allow also requests
to your local users from foreign users (unless you have a walled garden).
5 May
5 May
11:11 p.m.
On 04-05-2005 17:06, Klaus Darilion wrote:
Juha Heinanen wrote:
From RFC3261:
When a provider wishes to configure a UA with an outbound proxy,
it is RECOMMENDED that this be done by providing it with a
pre-existing route set with a single URI, that of the outbound proxy.
And the reason why:
This ensures that outbound proxies that do not add Record-Route
header field values will drop out of the path of subsequent
requests. It allows endpoints that cannot resolve the first Route
URI to delegate that task to an outbound proxy.
This is what the spec says. Most likely it won't work this way because
most implementation would use the outbound proxy for all messages, but
that's another story.
Jan.
Klaus Darilion writes:
ACK. But still I see no reason why an incoming call for example will use
a pre-route set? Out of curiosity, how do you handle out-of dialog
requests with a
pre-set route? If I would allow them, I would handle it this way:
something like that, but of course you would need to allow also requests
to your local users from foreign users (unless you have a walled garden).
9 May
9 May
12:56 p.m.
Jan Janak wrote:
On 04-05-2005 17:06, Klaus Darilion wrote:
That's the point. But as I do not want people to use my proxy as
outboundproxy I do not allow loose_routing of out-of-dialog requests.
regards
klaus
Juha Heinanen wrote:
From RFC3261:
When a provider wishes to configure a UA with an outbound proxy,
it is RECOMMENDED that this be done by providing it with a
pre-existing route set with a single URI, that of the outbound proxy.
And the reason why:
This ensures that outbound proxies that do not add Record-Route
header field values will drop out of the path of subsequent
requests. It allows endpoints that cannot resolve the first Route
URI to delegate that task to an outbound proxy.
This is what the spec says. Most likely it won't work this way because
most implementation would use the outbound proxy for all messages, but
that's another story. Klaus Darilion writes:
ACK. But still I see no reason why an incoming call for example will use
a pre-route set? Out of curiosity, how do you handle out-of dialog
requests with a
pre-set route? If I would allow them, I would handle it this way:
something like that, but of course you would need to allow also requests
to your local users from foreign users (unless you have a walled garden).
6 May
6 May
12:11 p.m.
Hello,
from my experience, the following setup works securely for a proxy that
wants to be:
a) NOT an outbound proxy
b) RFC3261 compilant loose router
if (loose_route() && has_totag() && method != "REGISTER") {
t_relay();
}
IMHO, it doesn't make much sense to make the same machine a outbound
proxy and local registrar, because you will most likely run into NAT
problems. One needs direct signaling between user and proxy.
Regards,
Martin
Klaus Darilion wrote:
Juha Heinanen wrote:
Klaus Darilion writes:
ACK. But still I see no reason why an incoming call for example will
use a pre-route set?
regards,
klaus
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers Out of curiosity, how do you handle out-of dialog
requests with a
pre-set route? If I would allow them, I would handle it this way:
something like that, but of course you would need to allow also requests
to your local users from foreign users (unless you have a walled
garden). 
3 May
3 May
10:20 p.m.
Thanks everyone for replies.
It's a little clearer now :)
Don't you think it should be mentioned in documentation that
loose routed messages shouldn't be just blindly forwarded?
I find this part of the docs quite confusing.
Michael
On Monday 02 May 2005 07:10 pm, 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? 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
10:38 p.m.
Thanks everyone for replies.
It's a little clearer now :)
Don't you think it should be mentioned in documentation that
loose routed messages shouldn't be just blindly forwarded?
I find this part of the docs quite confusing.
Michael
On Monday 02 May 2005 07:10 pm, 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? 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
6957
days inactive
6958
days old
20 comments
7 participants
participants (7)
-
Jan Janak -
Juha Heinanen -
Klaus Darilion -
Martin Koenig -
Michael Ulitskiy -
Michael Ulitskiy -
reticent