Hi!
I just was thinking about the follwing scenario_
client a--->proxy--->client b
the proxy does record routing
a calls b
b send back 200 OK, but does NOT mirror the Record-route headers. in-dialog requests sent from a to b will bypass the proxy, thus bypass proxy security features (e.g. removing the credentials).
Thus IMO we should have some settings which allow the proxy to add RR header also for relayed response if during request processing record-route was called and the proxy misses itself as the top RR header. what do you think?
regards klaus
Klaus Darilion writes:
Thus IMO we should have some settings which allow the proxy to add RR header also for relayed response if during request processing record-route was called and the proxy misses itself as the top RR header. what do you think?
klaus,
in my opinion also sip ua vendors should also take some responsibility of security. it cannot be so that proxy gets very day more and more complicated in order to cope with brain damaged sip uas.
this particular problem is easy to avoid in sip ua by configuring it to always use your sip proxy as its outbound proxy. defining an outbound proxy should imply that the ua refuses to talk with anybody else.
-- juha
Juha Heinanen schrieb:
Klaus Darilion writes:
Thus IMO we should have some settings which allow the proxy to add RR header also for relayed response if during request processing record-route was called and the proxy misses itself as the top RR header. what do you think?
klaus,
in my opinion also sip ua vendors should also take some responsibility of security. it cannot be so that proxy gets very day more and more complicated in order to cope with brain damaged sip uas.
this particular problem is easy to avoid in sip ua by configuring it to always use your sip proxy as its outbound proxy. defining an outbound proxy should imply that the ua refuses to talk with anybody else.
MAybe we should stay away from SIP :-)
Klaus Darilion writes:
MAybe we should stay away from SIP :-)
not necessarily. you just as proxy operator don't take responsibility of brain damaged sip user agents. people who use them assume the risks by themselves. if user agent is willing to speak with anyone, then of course it has to protect itself by itself.
-- juha
On Friday 16 November 2007, Juha Heinanen wrote:
Klaus Darilion writes:
MAybe we should stay away from SIP :-)
not necessarily. you just as proxy operator don't take responsibility of brain damaged sip user agents. people who use them assume the risks by themselves. if user agent is willing to speak with anyone, then of course it has to protect itself by itself.
Perhaps it would be useful if openser could be configured to preserve the RR list. I encountered a situation where the ACK was not being delivered during re-INVITE. Since the UAC had the correct route set for the re-INVITE, the ACK should have followed the same route. I found that this behaviour occurred when the UAS did not send an RR list with its 200 OK. The spec says within a dialogue the UAS MAY send RR. It also says the route set must remain unchanged once the dialogue is established. It would seem that in this case the UAC is creating an empty route set when it does not receive an RR list, thus destroying the proper route set.
Would it be useful to create a module parameter in TM such as "preserve_RR_list.
PS: the UAC mentioned is a PSTN gateway. It is not identified but I think it is an Asterisk.
El Viernes, 16 de Noviembre de 2007, Juha Heinanen escribió:
this particular problem is easy to avoid in sip ua by configuring it to always use your sip proxy as its outbound proxy.
For example, Twinkle softphone has the option: "[X] Send in-dialog request to proxy"
defining an outbound proxy should imply that the ua refuses to talk with anybody else.
Sure of that? does this behaviour appear in any RFC and so? I agree with you, but sincerely I'm not sure if most vendors interpret the same for the "outbound proxy" concept.
IMHO there should be some security options in any good SIP device:
- [X] "Allow incomings calls just from proxy" It could involves a DNS query for incoming calls since the IP can change, humm... Anyway Linksys device have this option.
- [X] "Send in-dialog request to proxy" Even if there are not RR headers, in-dialog request should be sent to our proxy.
- [X] "Use outbound proxy" This option could involve the second option ("Send in-dialog request to proxy").
Unfortunatelly most of SIP devices have no all those options.
Iñaki Baz Castillo writes:
defining an outbound proxy should imply that the ua refuses to talk with anybody else. Sure of that? does this behaviour appear in any RFC and so?
it is a common sense implementation issue of a sip ua, not a protocol (rfc) issue.
-- juha
At 03:36 18/11/2007, Juha Heinanen wrote:
Iñaki Baz Castillo writes:
defining an outbound proxy should imply that the ua refuses to talk with anybody else. Sure of that? does this behaviour appear in any RFC and so?
it is a common sense implementation issue of a sip ua, not a protocol (rfc) issue.
just wondering if you can refer me to some common-sense sip ua? (I agree with your point, I'm just painfuly anaware of such a ua.)
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
On Sunday 18 November 2007, Juha Heinanen wrote:
Jiri Kuthan writes:
just wondering if you can refer me to some common-sense sip ua? (I agree with your point, I'm just painfuly anaware of such a ua.)
jiri,
try twiinkle.
-- juha
Speaking of Twinkle, that is the UA I was referring to in my previous post on this thread. During a re-INVITE it does not return an Record-Route list with its 200 OK. This does not violate the spec but it causes inter-working problems with asterisk because asterisk appears to create an empty route set and the ACK will not find its way. I had a brief Email exchange with the author of Twinkle. He was reluctant to implement a work around to fix a problem with another UA. Other UA's that I have encountered send an RR list with the 200 OK during re-INVITE.
Rob
At 23:51 18/11/2007, Robert Dyck wrote:
On Sunday 18 November 2007, Juha Heinanen wrote:
Jiri Kuthan writes:
just wondering if you can refer me to some common-sense sip ua? (I agree with your point, I'm just painfuly anaware of such a ua.)
jiri,
try twiinkle.
-- juha
Speaking of Twinkle, that is the UA I was referring to in my previous post on this thread. During a re-INVITE it does not return an Record-Route list with its 200 OK. This does not violate the spec
Let me defend Twinkle here -- it not only does not violate the spec, it follows it. in-dialog messages are not supposed to change route set.
but it causes inter-working problems with asterisk because asterisk appears to create an empty route set and the ACK will not find its way. I had a brief Email exchange with the author of Twinkle. He was reluctant to implement a work around to fix a problem with another UA. Other UA's that I have encountered send an RR list with the 200 OK during re-INVITE.
Well -- I think you should have had first a conversation with asterisk developers.
-jiri
Rob
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-- Jiri Kuthan http://iptel.org/~jiri/
Robert Dyck writes:
Speaking of Twinkle, that is the UA I was referring to in my previous post on this thread. During a re-INVITE it does not return an Record-Route list with its 200 OK. This does not violate the spec but it causes inter-working problems with asterisk because asterisk appears to create an empty route set and the ACK will not find its way.
instead of making a workaround in twinkle, i would suggest that asterisk folks fix their sip implementation.
by the way, someone recently posted to this list a reference to a french sip vulnerability report and suggested that openser should do something about it. after reading the report, i got an impression that the attack described in it only works if a sip ua responds directly to a re-invite instead of sticking to its original route set. based on what you describe in above, looks like asterisk may be hit also by this attack.
-- juha
El Domingo, 18 de Noviembre de 2007, Juha Heinanen escribió:
Iñaki Baz Castillo writes:
defining an outbound proxy should imply that the ua refuses to talk with anybody else.
Sure of that? does this behaviour appear in any RFC and so?
it is a common sense implementation issue of a sip ua, not a protocol (rfc) issue.
Anyway I think most SIP UA use "outbound proxy" (if configured) just for initial requests, not for incoming initial or sequential requests.
Is there any SIP UA with the behaviour you mean?
Regards.
On Sun, 18 Nov 2007, Iñaki Baz Castillo wrote:
El Domingo, 18 de Noviembre de 2007, Juha Heinanen escribió:
Iñaki Baz Castillo writes:
defining an outbound proxy should imply that the ua refuses to talk with anybody else.
Sure of that? does this behaviour appear in any RFC and so?
it is a common sense implementation issue of a sip ua, not a protocol (rfc) issue.
Anyway I think most SIP UA use "outbound proxy" (if configured) just for initial requests, not for incoming initial or sequential requests.
I think this is one of the topmost wrong behavior implemented in UAs: today, most UAs contains several "checkbox" for defining such behavior:
* send all message to an IP whatever its content. * send to an IP first message, for others, follow "normal routing rules". * always follow normal rules.
Other possible "checkbox" (about building content of messages): * always add an optionnal "pre-route" set. * add an optionnal "pre-route" set only if calling an "external address" (just to get the SIP trapezoid) * never add an optionnal "pre-route" even if the call is for a remote domain.
All those checkbox are just "workarounds" for proxy that are not correctly configured for example. * The Route header is often NOT removed in initial INVITEs and that leads to 483 Too many hops... * Some admin don't know about "record-routing"...
Is there any SIP UA with the behaviour you mean?
I've never seen any SIP UA in the market that don't have those "checkbox": except when they cannot be configured to use "any" network.
Even if I'm personnaly pushing my customers to use pre-route set and follow the "transport layer" routing rules: they require me to offer configuration alternative because they must be able to interoperate with any mis-configured/broken proxy. In 90% case, they just remove the pre-route set and makes it the default behavior. I cannot blame them....
Another well-know example is xlite. you have 3 checkbox: * outbound proxy * domain * target domain
-> Those are just variant of the SIP "transport layer".
-> In fact, among those checkbox, there is only 1 compliant way: but those options needs to exist to interoperate with mis-configured proxy. (Note that in most case, any of those algo leads to the same behavior if the proxy is correctly configured...)
My own opinions... Aymeric
Regards.
-- Iñaki Baz Castillo
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Iñaki Baz Castillo schrieb:
El Viernes, 16 de Noviembre de 2007, Juha Heinanen escribió:
this particular problem is easy to avoid in sip ua by configuring it to always use your sip proxy as its outbound proxy.
For example, Twinkle softphone has the option: "[X] Send in-dialog request to proxy"
defining an outbound proxy should imply that the ua refuses to talk with anybody else.
Sure of that? does this behaviour appear in any RFC and so? I agree with you, but sincerely I'm not sure if most vendors interpret the same for the "outbound proxy" concept.
IMHO there should be some security options in any good SIP device:
- [X] "Allow incomings calls just from proxy"
It could involves a DNS query for incoming calls since the IP can change, humm... Anyway Linksys device have this option.
- [X] "Send in-dialog request to proxy"
Even if there are not RR headers, in-dialog request should be sent to our proxy.
- [X] "Use outbound proxy"
This option could involve the second option ("Send in-dialog request to proxy").
Yep. IMO this should be the default values.
regards klaus
Hi Klaus,
I had a similar issue with the following scenario: Client -> Openser -> Other Softswitch
The problem was that not only that the Softswitch was removing the Record-Route header, but also rewriting it with it's own.
Bellow is a quote from RFC 3261: """ 12.1.1 UAS behavior
When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values. """
So, it is obvious that this was a broken implementation. The only way I could fix that was using another SBC in front of Openser.
Cheers, DanB
On Nov 16, 2007 9:25 AM, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Hi!
I just was thinking about the follwing scenario_
client a--->proxy--->client b
the proxy does record routing
a calls b
b send back 200 OK, but does NOT mirror the Record-route headers. in-dialog requests sent from a to b will bypass the proxy, thus bypass proxy security features (e.g. removing the credentials).
Thus IMO we should have some settings which allow the proxy to add RR header also for relayed response if during request processing record-route was called and the proxy misses itself as the top RR header. what do you think?
regards klaus
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-
Aymeric Moizard -
Dan-Cristian Bogos -
Iñaki Baz Castillo -
jh＠tutpro.com -
Jiri Kuthan -
Klaus Darilion -
Robert Dyck