SIP blocked countries issue. Do any bodyhavethesolution?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi Ravi,

>> I will be using the ecryption like blowfish and deffie hellman key

>> exchange. The architecture would be like that the program would support

>> two modes one is server mode running on the Softswitch in my case and one is

>> client end mode running on the softphone end in my case. The server end

>> program would be running as always as the server is always up and waiting

>> for the clients to setup the tunnel using the secret key sharing using

>> deffie hellman algo


One way i could think of would be to use GDOI. Set up the GDOI key controller. Add ur softswitch and softphone client as group members. Push and pull the keys for the IPSec tunnel as u like - http://en.wikipedia.org/wiki/GDOI

I once did an analysis using GDOI (from vovida.org) to setup a secure tunnel. GDOI is similar to what u mentioned above except that its design for group communication (build upon IKE). It can use PSK for level 1 authentication. After negotiation, session level keys are exchange between 2 peers using diffie hellman. This session key also keeps changing to achieve PFS (perfect forward secrecy). The end result is an IPSEC ESP tunnel.

Bandwidth and latency due to encryption/decryption will be No1 cause of concern not to mention the need to distribute the secret PSK and the need of every client to run a gdoi client.

best,
Nigel

From: zpbappi@xxxxxxxxx
Date: Thu, 30 Jul 2009 15:10:11 +0700
To: pjsip at lists.pjsip.org
Subject: Re: SIP blocked countries issue. Do any bodyhavethesolution?

hi voip guru,
do you have suggestion to implement http/vpn tunneling using pjsip? please tell us something about the required modification/addition to be done in pjproject.regards,


zp bappi.



On Thu, Jul 30, 2009 at 6:24 AM, VOIP Guru <voicecanada at gmail.com> wrote:


Most of the operators are using DPI or deep packet inspection

mechnism. Also some of them block RTP as well. TLS will not work

because they are also recognizable.

Only tested solution is HTTP tunneling. operator have to block every

traffic before they block HTTP.



Good luck



On 7/29/09, Gang Liu <gangban.lau at gmail.com> wrote:

> I also prefer encryption. I built h323 softphone at middle east serval years

> ago which they all use different encryption. And as I know they still work

> well now.But some solutions based on standard VPN failed because sometimes

> VPN were blocked too if you have many softphone clients.

>

> regards,

> Gang

>

> On Sat, Jul 25, 2009 at 8:18 AM, Joegen Baclor

> <joegen.baclor at gmail.com>wrote:

>

>>  You got the general concept correct.  Encryption should be done between

>> your client towards a switch that supports your proprietary encryption.

>> The

>> switch should be in a network that allows SIP to flow.  All communications

>> to the outside internet should always traverse the switch as the first

>> hop.

>>

>> UA-Blocked [encrypted] -> ((Blocked Network)) -> [encrypted]

>> Switch-Non-Blocked [SIP]  -> ((Open-Internet)) -> Carrier

>>

>> One piece of advise.  You don?t have to use complex encryption to achieve

>> this.  A simple XOR on RTP and SIP using a shared key would be enough.

>> This

>> would make your encryption algo light weight.

>>

>> This is getting a bit off-topic in this list.   Just send me an off-list

>> message if you have more questions before the mailing list police kicks us

>> out [image: Smile emoticon].

>>

>>

>>  *From:* varun pratapsingh <varunps2003 at gmail.com>

>> *Sent:* Friday, July 24, 2009 5:44 PM

>> *To:* pjsip list <pjsip at lists.pjsip.org>

>> *Subject:* Re: [pjsip] SIP blocked countries issue. Do any

>> bodyhavethesolution?

>>

>> Hi Joegen and Syd,

>>

>> Mr. Syd can you tell me any VPN name which would be suitable for it. Can

>> you provide me some implementation details too. It would be a better

>> solution if you have already used VPN solutions in such cases and you ca

>> guide me in the implementation.

>>

>> Mr. Joegen I got your point, according to your discussion I have an

>> implentation in my mind. How will it be if we use some encrypted

>> Tunnelling

>> in this. The summary of the implemantaion is as below. Please see it and

>> do

>> tell me the limitations of the model if you feel beacuse then i will be

>> working on it. All suggestions are invited:

>>

>> I will be using the ecryption like blowfish and deffie hellman key

>> exchange. The architecture would be like that the program would support

>> two

>> modes one is server mode running on the Softswitch in my case and one is

>> client end mode running on the softphone end in my case. The server end

>> program would be running as always as the server is always up and waiting

>> for the clients to setup the tunnel using the secret key sharing using

>> deffie hellman algo then they the further communication would be agreed on

>> some defined ports hence making the tunnel then the further communication

>> would go through this tunnel. The packets in this tunnel are too encrypted

>> by using the blowfish encryption. Now as we know SIP signalling is through

>> 5060 port and RTP through 4000 port but now using our program the ports

>> would be changed after encryption and two new tunnels would be formed one

>> for SIP and other for RTP by the user end and server end by using deffie

>> hellman.

>>

>> So I think this model can be used for SIP communication without any need

>> of

>> VPN overhead and SIP blocked areas would not be able to catch the type of

>> communication.

>>

>> Please anyone who goes through this mail please if you see any loop holes

>> in this model. Kindly let me know immediately because it would be a great

>> help and will be appreciable.

>> An especially mr. Joegen and Mr Syd I expect you some special comments on

>> this.

>>

>> So please find anu bugs and provide me any suggestion for making this

>> system more robust then I will provide a complete documented design and

>> architecture of this model to be revised again. and one day i hope we will

>> have a god solution added to pjsip in this regard.

>>

>> Thanks and Regards:

>> Ravi

>>

>>

>> On Fri, Jul 24, 2009 at 2:07 PM, syd <cherkazoo at live.co.uk> wrote:

>>

>>>  A VPN solution would work in this case. On the plus side, is it will not

>>> require changes on your soft switch set up, but you will need to make

>>> sure

>>> your client set up handles the VPN traffic correctly. It is widely being

>>> used for such purposes.

>>>

>>>

>>>

>>> Syd

>>>

>>>

>>>

>>> *From:* pjsip-bounces at lists.pjsip.org [mailto:

>>> pjsip-bounces at lists.pjsip.org] *On Behalf Of *Joegen Baclor

>>> *Sent:* 24 July 2009 09:25

>>>

>>> *To:* pjsip list

>>> *Subject:* Re: [pjsip] SIP blocked countries issue. Do any body

>>> havethesolution?

>>>

>>>

>>>

>>> TLS/SRTP is not guaranteed.   Since SRTP is still RTP, it is

>>> distinguishable by the filters so even if you get TLS to penetrate the

>>> filters there is a big possibility that you won't get any audio.   You

>>> have

>>> to find a way to mangle the RTP packets in some way that they won't be

>>> recognized by the filters.  And so far, the only way it can be done is

>>> through proprietary means.

>>>

>>>

>>>

>>>

>>>

>>> *From:* varun pratapsingh <varunps2003 at gmail.com>

>>>

>>> *Sent:* Friday, July 24, 2009 3:57 PM

>>>

>>> *To:* pjsip list <pjsip at lists.pjsip.org>

>>>

>>> *Subject:* Re: [pjsip] SIP blocked countries issue. Do any body

>>> havethesolution?

>>>

>>>

>>>

>>> Hi Joegen,

>>>

>>> So using TLS/SRTP in Pjsip will resolve the issue. Will it be a right

>>> choice. Can you guide me something more on this implementation. What are

>>> the

>>> limitations which you have tried to point out in the your reply in using

>>> TLS

>>> /SRTP.

>>>

>>> Thanks ....

>>>

>>> Regards:

>>> Ravi

>>>

>>>

>>>

>>>  On Fri, Jul 24, 2009 at 9:33 AM, Joegen Baclor <joegen.baclor at gmail.com>

>>> wrote:

>>>

>>> In countries that are blocked (mostly in middle east), they are using

>>> deep

>>> penetration packet analyzers for both SIP and RTP.  So changing the ports

>>> wont usually work.  You might get away with a TLS/SRTP combo but this is

>>> an

>>> end to end requirement limiting the softphone to only work with providers

>>> that support both.   Another option would be to install SBC's with

>>> proprietary encryption support within the blocked country and in another

>>> location where SIP is allowed.   This would hide SIP and RTP from the

>>> filters.  OpenSBC for example works with grandstream proprietary CBCom

>>> encryption and is tested to bypass these types of blockage.

>>>

>>> Joegen

>>>

>>> --------------------------------------------------

>>> From: "Paulo Rog?rio Panhoto" <paulo@xxxxxxxxxxxxxxxxxxxxxx>

>>> Sent: Thursday, July 23, 2009 10:57 PM

>>> To: "pjsip list" <pjsip at lists.pjsip.org>

>>> Subject: Re: SIP blocked countries issue. Do any body have

>>> thesolution?

>>>

>>>

>>>

>>> Hello Ravi,

>>>

>>>   I guess someone might have asked this before: is SIPS also blocked?

>>>

>>> varun pratapsingh wrote:

>>>

>>> Hi All,

>>>

>>> In some countries SIP is blocked means our softphones are not working. Is

>>> there any way which can be used to reslove this issue. some peoples are

>>> suggesting VPNs but can,t it be like if we do some encryption of our SIP

>>> traffic.

>>>

>>> Please if any body can give  a real solution then it would be a great

>>> help.

>>>

>>>

>>> Regards:

>>> Ravi

>>> ------------------------------------------------------------------------

>>>

>>> _______________________________________________

>>> Visit our blog: http://blog.pjsip.org

>>>

>>> pjsip mailing list

>>> pjsip at lists.pjsip.org

>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

>>>

>>>

>>>

>>> _______________________________________________

>>> Visit our blog: http://blog.pjsip.org

>>>

>>> pjsip mailing list

>>> pjsip at lists.pjsip.org

>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

>>>

>>>

>>>

>>> _______________________________________________

>>> Visit our blog: http://blog.pjsip.org

>>>

>>> pjsip mailing list

>>> pjsip at lists.pjsip.org

>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

>>>

>>>

>>>

>>>  ------------------------------

>>>

>>> _______________________________________________

>>> Visit our blog: http://blog.pjsip.org

>>>

>>> pjsip mailing list

>>> pjsip at lists.pjsip.org

>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

>>>

>>> _______________________________________________

>>> Visit our blog: http://blog.pjsip.org

>>>

>>> pjsip mailing list

>>> pjsip at lists.pjsip.org

>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

>>>

>>>

>>  ------------------------------

>>

>> _______________________________________________

>> Visit our blog: http://blog.pjsip.org

>>

>> pjsip mailing list

>> pjsip at lists.pjsip.org

>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

>>

>> _______________________________________________

>> Visit our blog: http://blog.pjsip.org

>>

>> pjsip mailing list

>> pjsip at lists.pjsip.org

>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

>>

>>

>



_______________________________________________

Visit our blog: http://blog.pjsip.org



pjsip mailing list

pjsip at lists.pjsip.org

http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org



_________________________________________________________________
Show them the way! Add maps and directions to your party invites. 
http://www.microsoft.com/windows/windowslive/products/events.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090731/b06e9bad/attachment-0001.html>


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux