16 Nov
2007
16 Nov
'07
11:25 a.m.
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
16 Nov
16 Nov
12:37 p.m.
New subject: [OpenSER-Users] record_route() for responses
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
3:56 p.m.
Juha Heinanen schrieb:
Klaus Darilion writes:
MAybe we should stay away from SIP :-)
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.
4:20 p.m.
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
9:13 p.m.
On Friday 16 November 2007, Juha Heinanen wrote:
Klaus Darilion writes:
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.
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. 
18 Nov
18 Nov
1:26 a.m.
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
5:21 p.m.
At 03:36 18/11/2007, Juha Heinanen wrote:
Iñaki Baz Castillo 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
--
Jiri Kuthan http://iptel.org/~jiri/
> 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.
1:51 a.m.
On Sunday 18 November 2007, Juha Heinanen wrote:
Jiri Kuthan 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. 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
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
3:50 a.m.
At 23:51 18/11/2007, Robert Dyck wrote:
On Sunday 18 November 2007, Juha Heinanen wrote:
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.
Jiri Kuthan 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 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 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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
--
Jiri Kuthan http://iptel.org/~jiri/
5:59 a.m.
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
18 Nov
18 Nov
6:11 p.m.
El Domingo, 18 de Noviembre de 2007, Juha Heinanen escribió:
Iñaki Baz Castillo writes:
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.
--
Iñaki Baz Castillo
> 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. 
8:42 p.m.
On Sun, 18 Nov 2007, Iñaki Baz Castillo wrote:
El Domingo, 18 de Noviembre de 2007, Juha Heinanen
escribió:
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"...
Iñaki Baz Castillo writes:
Anyway I think most SIP UA use "outbound proxy" (if configured) just for
initial requests, not for incoming initial or sequential requests. > 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. 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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
19 Nov
19 Nov
1:38 p.m.
Iñaki Baz Castillo schrieb:
El Viernes, 16 de Noviembre de 2007, Juha Heinanen
escribió:
Yep. IMO this should be the default values.
regards
klaus
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"). 
16 Nov
16 Nov
12:39 p.m.
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(a)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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
6201
days inactive
6204
days old
15 comments
7 participants
participants (7)
-
Aymeric Moizard -
Dan-Cristian Bogos -
Iñaki Baz Castillo -
jh＠tutpro.com -
Jiri Kuthan -
Klaus Darilion -
Robert Dyck