[VOIPSEC] VoIP Attack : How feasible

Tue Jul 25 10:05:29 CDT 2006

Hi

I would like to point out a wireless perspective on utilizing multiple IPSEC tunnels for integrity & confidentiality protection for SIP and RTP.  Many access gateways (PDSN, HA, GGSN, ASN GW, PDG, PDIF etc) and session controllers (P-CSCF, I-CSCF, I-BCF etc.,) currently/plan to support cost effective security hardware engines, making Integrity & Confidentiality utilizing IPSEC economical and simple.  These same hardware solutions have been/will be implemented in other bearer elements (MRF, IM-MGW, I-BGF etc.,).  

Additionally, wireless equipment and standards are consolidating around better Authentication and Key Agreement mechanisms (EAP-AKA, EAP-SIM, IPSEC-3GPP etc.) that are making Security Association procedures more secure and more scalable.  The introduction of IKEv2 and AKA mechanism continue to improve control plane performance issues for setting up IPSEC SA.

I my opinion even though TLS (SIPS, HTTPS, S/MIME) and SRTP provide better end-to-end security; are optional for wireless standards (3GPP, 3GPP2 and WIMAX), they do not fit as economically as IPSEC from a network equipment deployment perspective, yet!

I believe having multiple IPSEC SA per device and per session to all the necessary intermediate nodes (access, intra or inter-domain), is/will be the most common and simple mechanism to prevent VoIP attacks.  This will largely be enabled by silicon economics in devices and network elements.

John 

-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org]On
Behalf Of Geoff Devine
Sent: Tuesday, July 25, 2006 6:24 AM
To: Pankaj Shroff
Cc: Voipsec at voipsa.org
Subject: Re: [VOIPSEC] VoIP Attack : How feasible

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

"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."