A few comments that I hope will be useful! On Mon, Jan 31, 2011 at 7:22 AM, Steven S. Critchfield <[email protected]> wrote: > > ----- Original Message ----- > > Yes I realize the more people that are listening or watching. > > This is why I was looking for a VPN program. > > Something you need to consider, VoIP uses UDP because it is better to have > a drop out during live voice calls than to introduce further latency waiting > for a retransmission to make it to you. > > VPN uses TCP because it is a layer that does not know what it is transporting > and therefore needs to make sure all the bits make it from one side to the > other.
VPN is an abstract concept and not necessarily implemented on TCP or any other specific protocol. These days, your VPN options often boil down to: - OpenVPN[1] which can use UDP or TCP. For protocols where dropping packets is okay, it's nice to use their UDP tunnels (either the ESP-inspired type or the DTLS one). - Any of the proprietary VPN over SSL solutions (msft, cisco anyconnect, juniper sslvpn, ...). These are often a custom version of TLS over TCP or DTLS over UDP with untested fallbacks to IKEv2. - Any of the billion configurations of IPSec. In this case, IPSec usually expects at least one exposed endpoints (except with the newer IKEv2[2] mediation stuff.). Probably not appropriate for this usecase - though it might be! That said, IPSec is implemented at the IP layer (AH, ESP) and doesn't suffer from the TCP tunneling problem (instead it suffers from other issues :/ ) - Hamachi[3], n2n[4], etc: p2p-style VPNs that don't explicitly require the endpoints be exposed (just that they support mediation). - Good ol' ssh tunneling (yup, tcp :) Without more details of deployment, it sounds like a hamachi or n2n-style vpn would make sense: a mediation endpoint which allows an arbitrary number of firewalled members to join tunnelled over UDP. (IKEv2 with a mediation server a la strongswan would work wonders but I'm not sure how cross-platform ikev2 support is these days.) Hamachi is proprietary so there is still the chance of key disclosure/listeners, but I believe the hamachi2 beta is free and the older hamachi1 for linux/mac/windows (pre-LogMeIn) days may still be working. n2n is cool, but I have no idea if it has had any security review. (You pick, protected from eavesdroppers but maybe insecure, or possibly tapped but robust...) Anyway. :/ 1- OpenVPN: http://openvpn.net/ 2- StrongSWAN: http://wiki.strongswan.org/wiki/1/UserDocumentation 3- Hamachi2: https://secure.logmein.com/US/labs/?wt.ac=73-516-440 4- n2n: http://www.ntop.org/n2n/ > > So UDP within TCP doesn't help you on the quality front. In fact, it is likely > going to make things worse as you will introduce jitter. Jitter is the term > used for the differing times it takes for packets to arrive. Higher jitter > means the phone has to add delay to the fast packets to keep a smooth flow for > the slow packets. If in the VPN world, you have a retransmission to get the > VPN packet through that happens to contain a VoIP UDP packet, you introduced > jitter that wouldn't have been there without it. > > I know there was discussion of doing encryption within the VoIP stream, as > then you could eliminate the overhead of VPN and the increased config > overhead. > The trouble with the VoIP encryption that I remember was how do you encrypt > each packet going out such that the loss of a packet doesn't cause the > decryption to fail. > > You may want to look at this article for more info about encypted VoIP. > http://www.voip-info.org/wiki/view/Asterisk+encryption SRTP, and I think ZRTP, both expect packet loss in the network layer and are meant to be resilient to it. Last time, I looked at asterisk (2008), zrtp wasn't easily supported and srtp + sip/tls was a pain to get working depending with the clients. A low overhead, mediated vpn solution might provide better guarantees than trying to coerce asterisk+openser into being secure. (I'm sure someone on the list with more current asterisk experience would know more, though!) Of course, then you'll need something to do the audio/video conferences in the first place. Hopefully some of the other suggestions on the list help. I tend to use google voice and video, but it doesn't do conference calls. hth! will -- You received this message because you are subscribed to the Google Groups "NLUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en
