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
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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:
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serdev mailing list serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Yes, this is indeed a great problem. It is not easy to authenticate loose_route processed messages. e.g. the following example:
a@a.com calls b@b.com. b forwards the request to c@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Juha Heinanen wrote:
Klaus Darilion writes:
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?
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(...) } } }
Juha Heinanen wrote:
Klaus Darilion writes:
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.
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@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
-- juha
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
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
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
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
Juha Heinanen wrote:
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).
ACK. But still I see no reason why an incoming call for example will use a pre-route set?
regards, klaus
On 04-05-2005 17:06, Klaus Darilion wrote:
Juha Heinanen wrote:
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).
ACK. But still I see no reason why an incoming call for example will use a pre-route set?
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.
Jan Janak wrote:
On 04-05-2005 17:06, Klaus Darilion wrote:
Juha Heinanen wrote:
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).
ACK. But still I see no reason why an incoming call for example will use a pre-route set?
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.
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
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:
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).
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Jan Janak -
Juha Heinanen -
Klaus Darilion -
Martin Koenig -
Michael Ulitskiy -
Michael Ulitskiy -
reticent