[VOIPSEC] VoIP Attack : How feasible

[Simon Horne]

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.


Simon

At 11:37 PM 25/07/2006, you wrote:
>This is the simplest form of security, which makes it good.
>
>- At the current time it is the easiest to deploy in any IT
>environment above the consumer level.
>
>- The only requirement is for enough bandwidth in the path or codecs that are
>   efficent. Speex works great, and works well even over dialup.
>
>- Algorithmic efficiency isn't needed because even low-cost processors
>are already
>   vastly overengineered.  A Nokia 770 handheld with a cheap processor can 
> run a
>   VPN client and SIP over WIFI or Bluetooth just fine.  Skype WIFI
>phones suffer
>   similar algorithmic complexity but they are relatively cheap and work well.
>
>- NAT and in certain cases end-to-end authentication are taken care of
>via the VPN.
>   There are caveats and limits that come with VPN's however as they require
>   engineering and don't handle duplicate IP's at the far end very well.
>   The answer to this  is proper end-to-end that includes NAT
>traversal, ie P2PSIP
>   (or Skype), or tunnelling algorithms like Teredo.
>
>- With a VPN there is never need for a cert except for the ingress
>point from the
>   public internet. In the real world most certs are either faked or
>stale and people
>   ignore the warnings.
>
>Our experience is that people will abandon cellphones and the wireline
>PSTN for VOIP over VPN once the sound is better than analog cellphone
>quality and it is as easy or easier to make the call.  For example,
>click to call from a web link or a hotlink in an email message.
>
>If sound quality is worse they will only use VOIP if tolls are
>prohibitive and the social costs are low. These are primarily personal
>calls or intra-organizational calls.
>
>If it is not easy to make the call it doesn't matter what the call
>costs, the user will just use the PSTN and ignore VOIP altogether.
>This has been the problem at hand for well over a decade.
>
>Given that the call is already secured by a VPN the biggest threat is
>a DOS attack.
>This can be adderessed by network engineering, there are well known
>techniques that are simple to deploy and require no new technology on
>the VOIP side.
>
>A DOS attack can also be mitigated if the CODEC used in the call is
>rugged.  We notice that Speex makes a difference when the underlying
>link is bad. A good CODEC and an end-to-end regime (especially P2P,
>with no central servers to attack) that has session handover to other
>addresses would be harder to disrupt.
>
>M
>
>On 7/25/06, Geoff Devine <gdevine at cedarpointcom.com> wrote:
> > I make phone calls all the time from a SIP soft client on my notebook 
> computer down a VPN to my corporate network.  Both signaling and media go 
> down the tunnel.  It's secure and you can't see RTP headers.  If I'm 
> sitting in an overseas hotel room, I really don't care about header 
> overhead of running RTP down a tunnel.  As this becomes popular, vendors 
> will start using header compression techniques to make it more efficient. 
> The VoIP infrastructure is hidden behind the VPN box and can't be 
> attacked from the public internet.
> >
> > It's simple and, with Cavium chips or other similar security processor 
> technology, it's scalable at fairly low cost.  With some minor tweaks to 
> compress headers at the client and VPN server, it's as efficient as 
> RTP.  It traverses NAT without needing a session border controller to 
> hack the SDP.  The only drawback is that, like using an SBC, it is 
> sometimes inefficient since the media doesn't always take the shortest 
> path through the routed network.
> >
> > Geoff
> >
> >
> > -----Original Message-----
> > From: Pankaj Shroff [mailto:shroffg at gmail.com]
> > Sent: Mon 7/24/2006 9:56 PM
> > To: Geoff Devine
> > Cc: Voipsec at voipsa.org
> > Subject: Re: [VOIPSEC] VoIP Attack : How feasible
> >
> > SS7 and SIGTRAN discussions aside, the biggest threat to a voip
> > network provider is a DDos type attack on its network elements. I
> > think the biggest variable in the effectiveness of these attacks is
> > the network topology and deployment of the network elements. If a
> > global corporation has offices all over the world and are networked
> > together with dedicated lines, the problem is non-existent - all VoIP
> > traffic is corporate traffic - but I suspect that is seldom the case.
> > The enterprise VoIP network is often a separate network from the more
> > secure data network. The enterprise VoIP calls may also go over public
> > internet, which means there are border network elements which are
> > susceptible to attacks if their identities are publicised
> > (inevitably). Signalling data can be protected using the standard
> > TLS/SSL/IPSec technologies but RTP is another beast. Even with SRTP
> > encryption, RTP header is still in the open and hence can easily be
> > observed to determine RTP endpoints and hence can be attacked. A DDos
> > attack on RTP elements could be much more debilitating than an attack
> > on SIP only servers.
> >
> > Pankaj
> >
> > On 7/2/06, Geoff Devine <gdevine at cedarpointcom.com> wrote:
> > > Christopher A. Martin writes:
> > > > SS7 may be going back inband over IP from some of the trends that I
> > > > have been seeing/hearing about.
> > >
> > > Right.  SS#7 over IP using SIGTRAN is becoming more and more common.
> > > The circuit switched solution tends to have big access charges compared
> > > to the IP-based solution so operators are prone deploy signaling
> > > gateways to share the expensive circuit switched connection among
> > > multiple media gateway controllers.  The signaling gateway sometimes
> > > resides at another service provider (Level3, for example.) The signaling
> > > gateway has two IP network interfaces.  The SCTP transport uses
> > > redundant paths through the IP network that are typically statically
> > > routed.  Unlike TCP, SCTP is multi-threaded so a dropped packet on one
> > > thread doesn't grind the transport to a halt and minor amounts of
> > > dropped packets does not invoke flow control.  SCTP is also
> > > packet-oriented rather than TCP's byte-stream orientation.  You'd
> > > usually run SCTP behind a firewall on a managed IP network or on a
> > > private network/VPN.
> > >
> > > The downside of this approach is that you dramatically increase your
> > > failure group size.  SS#7 networks are pretty bomb-proof so if you
> > > direct-connect to them, your failure group size is your switching office
> > > size (usually limited to ~100k lines).  If a signaling gateway goes down
> > > or if the redundant internet links go down, you take out everybody who
> > > uses the signaling gateway.  A service provider could have an outage
> > > that impacts millions of customers.
> > >
> > > Geoff
> > >
> > > _______________________________________________
> > > Voipsec mailing list
> > > Voipsec at voipsa.org
> > > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> > >
> >
> >
> > --
> > Pankaj Shroff
> > shroffG at Gmail.com
> >
> >
> > _______________________________________________
> > Voipsec mailing list
> > Voipsec at voipsa.org
> > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >
>
>_______________________________________________
>Voipsec mailing list
>Voipsec at voipsa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org