4 Jan
2010
4 Jan
'10
8:53 p.m.
Hi Daniel!
Thanks for topoh, a great module.
1. topology hiding is skipped for REGISTER and PUBLISH - why? For
example I use Kamailio as an outbound proxy for our office as some kind
of firewall and want to add topology hiding (to hide the details of our
LAN). In this scenario it is also needed to mangle REGISTER and PUBLISH too.
Are there any issues from implementation point of view which prevents
mangling for REGISTER|PUBLISH?
I tried removing the method-check and it seems to work fine (at least
for REGISTER with single Contact headers)
Of course this brings in another problem - at the upstream server the
registered Contact is now sip:10.1.1.2;line=sr-......
It would be necessary to have the host part configurable, e.g. in my
setup I would set it to the public IP address of the outbound proxy.
Thus,
str th_ip = {"10.1.1.2", 0};
should be the default and there should be a module paramter to override it.
2. the module uses a default value for encryption. IMO this is insecure.
IMO, either the mask_key parameter should be mandatory or a random one
should be generated at startup.
regards
klaus
4 Jan
4 Jan
9:08 p.m.
Hi Klaus,
On 1/4/10 7:53 PM, Klaus Darilion wrote:
Hi Daniel!
Thanks for topoh, a great module.
1. topology hiding is skipped for REGISTER and PUBLISH - why? For
example I use Kamailio as an outbound proxy for our office as some
kind of firewall and want to add topology hiding (to hide the details
of our LAN). In this scenario it is also needed to mangle REGISTER and
PUBLISH too.
Are there any issues from implementation point of view which prevents
mangling for REGISTER|PUBLISH?
I thought these messages are intended to terminate
in the sip server,
not to be forwarded to insecure network. The plan is to make that filter
a module paraemter, but no time so far. I see no problem topoh-ing them
right now.
I tried removing the method-check and it seems to work fine (at least
for REGISTER with single Contact headers)
Of course this brings in another problem - at the upstream server the
registered Contact is now sip:10.1.1.2;line=sr-......
It would be necessary to have the host part configurable, e.g. in my
setup I would set it to the public IP address of the outbound proxy.
Thus,
str th_ip = {"10.1.1.2", 0};
should be the default and there should be a module paramter to
override it.
I forgot to make it a parameter, it is intended to be one -- i will fix.
2. the module uses a default value for encryption. IMO this is
insecure. IMO, either the mask_key parameter should be mandatory or a
random one should be generated at startup.
Could be made mandatory -- randomization will create issues after restart.
Thanks for feedback and testing,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
9:08 p.m.
Hi Klaus,
On 1/4/10 7:53 PM, Klaus Darilion wrote:
Hi Daniel!
Thanks for topoh, a great module.
1. topology hiding is skipped for REGISTER and PUBLISH - why? For
example I use Kamailio as an outbound proxy for our office as some
kind of firewall and want to add topology hiding (to hide the details
of our LAN). In this scenario it is also needed to mangle REGISTER and
PUBLISH too.
Are there any issues from implementation point of view which prevents
mangling for REGISTER|PUBLISH?
I thought these messages are intended to terminate
in the sip server,
not to be forwarded to insecure network. The plan is to make that filter
a module paraemter, but no time so far. I see no problem topoh-ing them
right now.
I tried removing the method-check and it seems to work fine (at least
for REGISTER with single Contact headers)
Of course this brings in another problem - at the upstream server the
registered Contact is now sip:10.1.1.2;line=sr-......
It would be necessary to have the host part configurable, e.g. in my
setup I would set it to the public IP address of the outbound proxy.
Thus,
str th_ip = {"10.1.1.2", 0};
should be the default and there should be a module paramter to
override it.
I forgot to make it a parameter, it is intended to be one -- i will fix.
2. the module uses a default value for encryption. IMO this is
insecure. IMO, either the mask_key parameter should be mandatory or a
random one should be generated at startup.
Could be made mandatory -- randomization will create issues after restart.
Thanks for feedback and testing,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
5 Jan
5 Jan
12:39 a.m.
On 04.01.2010 20:08, Daniel-Constantin Mierla wrote:
Hi Klaus,
On 1/4/10 7:53 PM, Klaus Darilion wrote:
What about Contact URI encoding/decoding? Does topoh parse all Contact
headers and looks for URIs to encode? (e.g. in 200 OK response).
regards
klaus
Hi Daniel!
Thanks for topoh, a great module.
1. topology hiding is skipped for REGISTER and PUBLISH - why? For
example I use Kamailio as an outbound proxy for our office as some
kind of firewall and want to add topology hiding (to hide the details
of our LAN). In this scenario it is also needed to mangle REGISTER and
PUBLISH too.
Are there any issues from implementation point of view which prevents
mangling for REGISTER|PUBLISH?
I thought these messages are intended to terminate
in the sip server,
not to be forwarded to insecure network. The plan is to make that filter
a module paraemter, but no time so far. I see no problem topoh-ing them
right now.
I tried removing the method-check and it seems to work fine (at least
for REGISTER with single Contact headers)
Of course this brings in another problem - at the upstream server the
registered Contact is now sip:10.1.1.2;line=sr-......
It would be necessary to have the host part configurable, e.g. in my
setup I would set it to the public IP address of the outbound proxy.
Thus,
str th_ip = {"10.1.1.2", 0};
should be the default and there should be a module paramter to
override it.
I forgot to make it a parameter, it is intended to be one -- i will fix.
2. the module uses a default value for encryption. IMO this is
insecure. IMO, either the mask_key parameter should be mandatory or a
random one should be generated at startup.
Could be made mandatory -- randomization will create issues after restart.
Thanks for feedback and testing,
Daniel
12:46 p.m.
On 1/4/10 11:39 PM, Klaus Darilion wrote:
On 04.01.2010 20:08, Daniel-Constantin Mierla wrote:
only one, IIRC.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
Hi Klaus,
On 1/4/10 7:53 PM, Klaus Darilion wrote:
What about Contact URI encoding/decoding? Does topoh parse all Contact
headers and looks for URIs to encode? (e.g. in 200 OK response). Hi Daniel!
Thanks for topoh, a great module.
1. topology hiding is skipped for REGISTER and PUBLISH - why? For
example I use Kamailio as an outbound proxy for our office as some
kind of firewall and want to add topology hiding (to hide the details
of our LAN). In this scenario it is also needed to mangle REGISTER and
PUBLISH too.
Are there any issues from implementation point of view which prevents
mangling for REGISTER|PUBLISH?
I thought these messages are intended to terminate
in the sip server,
not to be forwarded to insecure network. The plan is to make that filter
a module paraemter, but no time so far. I see no problem topoh-ing them
right now.
3:28 p.m.
Daniel-Constantin Mierla schrieb:
On 1/4/10 11:39 PM, Klaus Darilion wrote:
I just found out that in case of relaying REGISTER requests the topoh
module needs to be extended, because the 200 OK response does not
contain the clear contact of the other party, but the protected contact
of the sender.
Thus, in case of REGISTER, during decoding of the reply we would need a
th_unmask_contact() function to unmask protected contacts (probably
similar to th_unmask_ruri()) and we must not call th_mask_contact() on
response sending.
regards
klaus
On 04.01.2010 20:08, Daniel-Constantin Mierla wrote:
only one, IIRC.
Hi Klaus,
On 1/4/10 7:53 PM, Klaus Darilion wrote:
What about Contact URI encoding/decoding? Does topoh parse all Contact
headers and looks for URIs to encode? (e.g. in 200 OK response). Hi Daniel!
Thanks for topoh, a great module.
1. topology hiding is skipped for REGISTER and PUBLISH - why? For
example I use Kamailio as an outbound proxy for our office as some
kind of firewall and want to add topology hiding (to hide the details
of our LAN). In this scenario it is also needed to mangle REGISTER and
PUBLISH too.
Are there any issues from implementation point of view which prevents
mangling for REGISTER|PUBLISH?
I thought these messages are intended to terminate
in the sip server,
not to be forwarded to insecure network. The plan is to make that filter
a module paraemter, but no time so far. I see no problem topoh-ing them
right now.
1:29 a.m.
Hi Daniel!
What happens if topoh receives a manipulated request - e.g. if somebody
manipulates the encoded line parameter. Will topoh detect the
manipulation (e.g. is there is checksum encoded too) or will topoh just
decode this parameter into a malformed URI?
What happens if decoding fails - will be message be dropped?
regards
klaus
On 04.01.2010 20:08, Daniel-Constantin Mierla wrote:
Hi Klaus,
On 1/4/10 7:53 PM, Klaus Darilion wrote:
Hi Daniel!
Thanks for topoh, a great module.
1. topology hiding is skipped for REGISTER and PUBLISH - why? For
example I use Kamailio as an outbound proxy for our office as some
kind of firewall and want to add topology hiding (to hide the details
of our LAN). In this scenario it is also needed to mangle REGISTER and
PUBLISH too.
Are there any issues from implementation point of view which prevents
mangling for REGISTER|PUBLISH?
I thought these messages are intended to terminate
in the sip server,
not to be forwarded to insecure network. The plan is to make that filter
a module paraemter, but no time so far. I see no problem topoh-ing them
right now.
I tried removing the method-check and it seems to work fine (at least
for REGISTER with single Contact headers)
Of course this brings in another problem - at the upstream server the
registered Contact is now sip:10.1.1.2;line=sr-......
It would be necessary to have the host part configurable, e.g. in my
setup I would set it to the public IP address of the outbound proxy.
Thus,
str th_ip = {"10.1.1.2", 0};
should be the default and there should be a module paramter to
override it.
I forgot to make it a parameter, it is intended to be one -- i will fix.
2. the module uses a default value for encryption. IMO this is
insecure. IMO, either the mask_key parameter should be mandatory or a
random one should be generated at startup.
Could be made mandatory -- randomization will create issues after restart.
Thanks for feedback and testing,
Daniel
12:53 p.m.
Hi Klaus,
On 1/5/10 12:29 AM, Klaus Darilion wrote:
Hi Daniel!
What happens if topoh receives a manipulated request - e.g. if
somebody manipulates the encoded line parameter. Will topoh detect the
manipulation (e.g. is there is checksum encoded too) or will topoh
just decode this parameter into a malformed URI?
What happens if decoding fails - will be message be dropped?
topoh operations are transparent to cfg script -- in the cfg you get the
SIP message decoded, with clear values, so accounting, authorization and
other checks are not affected.
If the SIP message becomes malformed, it is same situation as you would
get a malformed SIP message when not using topoh -- you can use sanity
module to detect and drop/whatsoever.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/
3:25 p.m.
Hi Daniel!
I am trying to understand better how topoh works.
I see it registers callbacks, e.g.:
sr_event_register_cb(SREV_NET_DATA_IN, th_msg_received);
When th_msg_received() is executed, - is the SIP message already parsed?
If yes, why calling th_prepare_msg() and parse the message again?
If no, if parsing in th_prepare_msg() fails, shouldn't the return value
of th_prepare_msg() be evaluated?
regards
Klaus
Daniel-Constantin Mierla schrieb:
Hi Klaus,
On 1/5/10 12:29 AM, Klaus Darilion wrote:
Hi Daniel!
What happens if topoh receives a manipulated request - e.g. if
somebody manipulates the encoded line parameter. Will topoh detect the
manipulation (e.g. is there is checksum encoded too) or will topoh
just decode this parameter into a malformed URI?
What happens if decoding fails - will be message be dropped?
topoh operations are transparent to cfg script -- in the cfg you get the
SIP message decoded, with clear values, so accounting, authorization and
other checks are not affected.
If the SIP message becomes malformed, it is same situation as you would
get a malformed SIP message when not using topoh -- you can use sanity
module to detect and drop/whatsoever.
Cheers,
Daniel
5438
days inactive
5439
days old
8 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Klaus Darilion