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
Hi Klaus,
On 1/4/10 7:53 PM, Klaus Darilion wrote:
Hi Daniel!
Thanks for topoh, a great module.
- 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.
- 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
Hi Klaus,
On 1/4/10 7:53 PM, Klaus Darilion wrote:
Hi Daniel!
Thanks for topoh, a great module.
- 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.
- 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
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.
- 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.
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
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.
- 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
On 1/4/10 11:39 PM, Klaus Darilion wrote:
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.
- 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.
What about Contact URI encoding/decoding? Does topoh parse all Contact headers and looks for URIs to encode? (e.g. in 200 OK response).
only one, IIRC.
Cheers, Daniel
Daniel-Constantin Mierla schrieb:
On 1/4/10 11:39 PM, Klaus Darilion wrote:
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.
- 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.
What about Contact URI encoding/decoding? Does topoh parse all Contact headers and looks for URIs to encode? (e.g. in 200 OK response).
only one, IIRC.
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
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.
- 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.
- 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
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
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
-
Daniel-Constantin Mierla -
Klaus Darilion