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

[Brian Rosen]

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