[VOIPSEC] Evaluating DoS Attacks Against SIP-Based VoIP Systems

Wed Aug 19 10:30:11 CDT 2009

Humans no longer expect the functions we insist on putting into their phone
systems implemented the same way we did it.  New UI mechanisms mean totally
different ways to meet a need.

You can express the need, and provide a better way to meet the need if you
don't require that the signaling interwork with the PSTN.

SIP exploded in complexity because we continually have to add features to
emulate the PSTN and in addition, add features that have no equivalent in
the PSTN. The complexity of doing that leads to the testing problem.  It's
no different than a class 5 switch.  The testing is horrendous because there
are so many features to be tested.

What we learned from mobile phones is that we don't need 99% of the
features.  You don't see the simplest features like "Do Not Disturb" in any
mobile system.  We simply don't need it, or to be more practical, we like
the feature set we have well enough that we don't miss it.

Your fears that TLS prohibits testing are baseless: TLS is hop by hop; a
simple B2BUA with wireshark works fine.

On 8/18/09 12:13 PM, "Geoff Devine" <geoff at geoffdevine.com> wrote:

> Yep.  You've captured the essence, Brian.  Crusty.   ;)
> 
> We're always going to disagree on what I think is the fundamental
> requirement of any telecom protocol.... that it be able to properly
> interwork with the PSTN and the feature set humans have come to expect from
> their communications systems.   SIP exploded in complexity and rogue
> implementations because the authors rejected that requirement.   What you
> end up with is closed proprietary implementations where the interworking
> complexity can be minimized.  ...or even worse, you end up with a bloated
> hyper-overspecified protocol variant like 3GPP which is still so complex and
> with so many implementation options that it still doesn't interwork very
> well.   It's a competitive advantage for the large vendors.   The last thing
> they want is open standards where best of breed new products from
> entrepreneurial companies and easily interwork with the big guys.   If I
> take your "no emulation of PSTN functions" at face value, then SIP is not a
> telecom protocol.  3GPP, 3GPP2, PacketCable, ATIS, any PBX vendor... they
> can't ignore the real world requirements of interworking with the PSTN and
> providing feature transparency for all the legacy telephony features.   We
> end up with a job security program where thousands of software engineers are
> using the wrong protocol to implement their products.
> 
> The pragmatic reality is that any SIP core out there is fairly fragile.
> Ask any QA manager how difficult it is to make their product die a miserable
> death.   It's just too complex an environment.   You end up with a
> multi-dimensional test matrix with all the equipment you need to interwork
> against and all the software release levels available on that equipment.
> You can't test it all give the practical commercial constraints of paying
> customers and fixed release dates.   It's a miracle it works in that kind of
> closed system.   If you start allowing rogue SIP implementations into your
> network, the complexity is such that you have basically zero confidence that
> your network will be stable.   If you want to name your largest security
> vulnerability, it's "INVITE of Death".
> 
> The problem with running signaling over a secure channel is that you lose
> any ability to debug and troubleshoot it using conventional network
> debugging tools like Wireshark.   You are placed at the mercy of your
> vendors to implement reasonable tool sets on their products to be able to
> get at the data.   In a heterogeneous environment, the poor guys at the NOC
> have to train up on a dozen different tool set implementations at various
> quality levels.   Most service providers don't pay well enough to have staff
> who are up to the task.   If you mandated TLS, every service provider would
> insist on a mechanism to disable it so they can actually get their network
> to function.  
> 
> Crustily yours,
> Geoff
> 
> -----Original Message-----
> From: Brian Rosen [mailto:br at brianrosen.net]
> Sent: Monday, August 17, 2009 10:03 PM
> To: 'Geoff Devine'; voipsec at voipsa.org
> Subject: RE: [VOIPSEC] Evaluating DoS Attacks Against SIP-Based VoIP Systems
> 
> Hehe
> 
> Bit crusty are you?
> 
> I think the virtues of a text protocol outweigh the problems.  TLV doesn't
> really help you figure out mandatory elements, a parser is a parser and once
> you have parsed, you have the elements, parameters, etc.  It's slightly
> annoying that the SIP grammar is not completely explicitly defined by the
> ABNF, but once you get the parser right, it's right, and figuring out if you
> have all the mandatory elements, and if you have malformed elements or
> parameters is as straightforward as any other decoder.
> 
> It's clear to most of us that the single biggest mistake we made with SIP is
> emulating the PSTN.  If we ever did it over, Rule 1 would be "no PSTN
> emulation".  It's the main reason SIP is as complex as it is and it's a
> mistake to have the set of features we now have in both SIP and the PSTN.
> The UI on phones is changing rapidly towards what you find on an iPhone, and
> the feature set you need is much different.
> 
> SIP is flavor of the decade, or maybe two decades. We'll see.
> 
> Emulating a closed network is futile.  Using security protocols such as TLS
> is a very good idea on every network.  If we did it over, we probably would
> define it on TLS only, with no possibility of not using it.
> 
> Brian
> 
>  
> 
>> -----Original Message-----
>> From: voipsec-bounces at voipsa.org [mailto:voipsec-bounces at voipsa.org] On
>> Behalf Of Geoff Devine
>> Sent: Monday, August 17, 2009 5:39 PM
>> To: voipsec at voipsa.org
>> Subject: Re: [VOIPSEC] Evaluating DoS Attacks Against SIP-Based VoIP
>> Systems
>> 
>> I find that "INVITE of Death" captures the fundamental problem with
>> SIP.
>> In the good ol' days when men were men and protocols were Type-Length-
>> Value,
>> it was fairly straightforward to implement a protocol stack that didn't
>> die
>> a miserable death whenever it saw a new implementation or a malicious
>> attack.  You could easily write a pre-parser that rooted through the
>> message
>> looking for mandatory information elements and ensuring that the
>> critical
>> ones weren't malformed.  That enabled robust and machine-efficient
>> implementations that could actually be tested in a deterministic way.
>> 
>> I always look at SIP and scratch my head.  The mantra is "we are
>> leveraging
>> HTTP" and all o' that kind o' stuff.  The problem is that HTTP is a
>> completely different animal.   The complexity of the protocol is
>> intentionally very 1-way.   Downstream, it's quite complex and
>> typically
>> interoperates very well with the dreaded Microsoft Internet Exploder
>> implementations and not quite so well with all the other
>> implementations.
>> The complexity has created an anti-virus industry with mansions, exotic
>> automobiles, and a plush Gulfstream V for the entrepreneurs who created
>> solutions to the whole attack problem.  Upstream, the protocol is quite
>> simple and significantly less vulnerable to attack.  SIP is a symmetric
>> protocol with completely different behavior.  It's damned tough to test
>> a
>> SIP stack into submission and Touring tells us it's theoretically
>> impossible
>> to know for sure whether it really works.   I'm a Keep It Simple,
>> Stupid
>> kind-a engineer.   KISS permeates everything I've built in my 30-year
>> career.  You just can't use SIP and "simple" and the same sentence.
>> 
>> Since SIP is flavor-of-the-week for telecom protocols, we're stuck
>> dealing
>> with it.  In a closed network, you pretty much have to assume that you
>> have
>> to bake any new implementation in an interop lab for a few months to
>> shake
>> out all the issues.  When you deploy, you just cross your fingers and
>> pray
>> since there's no such thing as 100% test coverage with a protocol as
>> complex
>> as SIP.   In an open network, you pretty much have to run a security
>> mechanism like TLS or IPSec to approximate a closed network.   "INVITE
>> of
>> Death" indeed captures the essence of the problem.
>> 
>> I sure hope we do the great circle thing and the next flavor-of-the-
>> week
>> protocol ends up being a Type-Length-Value design.   It will certainly
>> save
>> a lot of angst among a bajillion software engineers who have to cope
>> with
>> the disaster.  It would also be quite nice if the protocol designers
>> actually paid attention to all the requirements of the legacy telecom
>> environment the next time around.  The world doesn't need another IETF
>> BLISS
>> project to sort out the 50 different ways to do basic telephony things
>> that
>> have been around since IBM 029 key punch machines like basic key system
>> emulation.
>> 
>> Geoff
>> 
>> -----Original Message-----
>> 
>> From: zubair rafique <m_zubair_rafique at yahoo.com>
>> Subject: [VOIPSEC] Fw: Evaluating DoS Attacks Against SIP-Based VoIP
>> Systems (INVITE of Death)
>> 
>>> Evaluating DoS Attacks Against SIP-Based VoIPSystems (INVITE of
>> Death)
>>> Paper accepted at IEEE-GLOBECOM
>> 2009http://www.nexginrc.org/~zubair.rafique/papers/globecomm-zubair.pdf
>>> 
>>> In contrast, little work is done to analyze therobustness and
>> reliability
>> of SIP severs under DoS attacks.
>>> M Zubair RafiquenexGIN RC
>>> http://www.nexginrc.org/~zubair.rafique/
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Voipsec mailing list
>> Voipsec at voipsa.org
>> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 