[VOIPSEC] VoIP Attack : How feasible

[Geoff Devine]

VPNs are "notoriously difficult to configure and deploy"?  Maybe in your
universe.  In my universe, I can get a VPN working on my PC to my
corporate network in about 10 seconds.  At any meeting I've attended in
recent memory, virtually every person at the conference table was
attached to their corporate network via VPN.

You cite requirements that just don't pertain to many network
topologies.  In the typical service provider model, there is no need at
all for end-to-end authentication.  I refer you to PacketCable 1 and
3GPP as examples.  These same networks don't need to provide end-to-end
encryption.  They only need to assure privacy on the access network.  In
cable, this is done by encrypting the DOCSIS layer 2 stream using BPI+.

VPNs are excellent at dealing with NAT traversal.  The issue at the
moment is that Microsoft has not implemented header suppression for RTP
which would make VoIP over VPN work efficiently.  When we have a
Micro$oft release that does this, the entire industry will follow.

In the mean time, I'll continue to VPN into my corporate network to make
phone calls from my soft client.  From my home network, I really don't
care about the extra header overhead.

Geoff

---------------------------------------------------
From: Simon Horne <s.horne at packetizer.com>
Subject: Re: [VOIPSEC] VoIP Attack : How feasible

The problem with VPN's is they are notoriously difficult to configure
and 
deploy and I abandoned them 4 years ago to find a better and more easily

deployable solution.

He's my points on the topic.
VPNs do not provide end to end authentication.
They only provide from you to the next hop and even then you cannot
verify 
the callers authentication credentials within the VoIP client. The only
way 
you can provide end-to-end authentication is to embed the authentication

information into the call signalling so it goes end to end. Now in some 
protocols this is easy as there is a end to end call signalling channel 
(which can optionally be routed) and a standard framework to carry these

messages. The ability to do this is further complicated with protocols
who 
prefer to do signalling over UDP which cannot handle the large message 
sizes required to carry the security credentials.

VPNs do not provide end to end encryption.
They provide only to the next hop and then has to decrypt and re-encrypt

for the next hop. There already is much better solution like SRTP, ZRTP
or 
just encrypted RTP etc which do not require the extra burden required on

the hop. The fact that some protocols have no standard framework to 
exchange key material makes wholesale interoperable, ubiquitous
deployment 
of encrypted media services into existing networks near impossible 
resulting in the need for intersite VPN's. This is very much a protocol
issue.

VPNs do not provide efficient NAT Traversal.
It is my opinion that the choice of VPN for NAT traversal should be last

resort. Protocols that use symmetric RTP have particular problems 
traversing NAT which excludes methods like UPnP from being a functional 
solution and greatly complicates NAT detection and traversal mechanisms.

There are already well know standards in some protocols (and more in 
development) for efficient NAT traversal without resorting to requiring
a 
peer to peer architecture.

In 10 years of VoIP NAT and security development and after truckloads of

publicized RFC's and white papers why are we still talking about VPN's? 
Surely there must be better solutions that can be deployed today. There
is, 
just they are not available in SIP.