[VOIPSEC] SIP complexity, was VPNs and VoIP

[Geoff Devine]

SS#7 implies one static architecture and a suite of protocols that exist
in that architecture.  SIP can be used in many architectures.  Some keep
state all over the place; some use stateless proxies where only the
endpoints have state.  

The biggest issue with SIP is that it has no inherent notion of flow
control, congestion control, or fault management.  When you are
designing large five 9's networks, SIP creates 'challenges'.

Geoff

-----Original Message-----
From: Philip Walenta [mailto:pwalenta at wi.rr.com] 
Sent: Monday, July 31, 2006 8:44 AM
To: Geoff Devine; Voipsec at voipsa.org
Subject: RE: [VOIPSEC] SIP complexity, was VPNs and VoIP

I actually a conversation with an ex-AT&T individual about SIP.

He made some rather interesting comments which got me thinking (and
which I
blogged about back in May).

To him, the biggest problem with SIP and even some of the proprietary
protocols out there is that they aren't stateful in any way.  If a call
is
active, all you pretty much see is the RTP stream with very limited (if
any)
control traffic while the call is active.  He noted that this makes the
management (and resiliency) of these protocols limited in many aspects.


By comparison, SS7 has two paths (bearer and control) through almost the
entire network.  This facilitates some excellent resiliency in the event
of
failures, and also allows "easy" monitoring.  I should note I'm not
trying
to start any sort of flame war by talking about SS7, just using it as an
example.

Now, SS7 has a complex structure compared to many packet network
protocols,
but it is arguably more secure, predictable and manageable.  If we had
something similar on the packet network, firewall/SBC and network
management
would all be easier.  Also, in theory security would be improved.  

Looking at many of the RFC specs for protocols that have come out over
the
years, even though many of them look complex, they really aren't that
complex.  They are (in many cases) compromised, easier versions of
things
that could have been.  Look at HTML and how it evolved.  

All I am really saying is that SIP is a good start.  But in my mind
something better might be needed.  Something designed from the ground up
for
security, and management, but not necessarily ease of use.  As an end
user,
how often are you expected to know what a SIP invite is?  As someone who
deals with networks and VoIP of many varieties on a daily basis, I'd
rather
have a protocol that is more complex, but does everything we want it to
versus something "the masses" can hack on.

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] On Behalf Of Geoff Devine
> Sent: Monday, July 31, 2006 7:09 AM
> To: Voipsec at voipsa.org
> Subject: Re: [VOIPSEC] SIP complexity, was VPNs and VoIP
> 
> Michael Slavitch writes:
> 
> > "Given the incredible complexity of SIP"
> >
> > Buh?  SIP is simple. It's the bellheads who made it hard.
> 
> Nope.  It's the protocol designers who invented a protocol 
> without first looking at the functional requirements who made 
> it hard.  Instead, we end up with hundreds of IETF RFCs with 
> hack workarounds to the deficiencies in the original RFC 3261 
> spec.  Anyone who has architected a telephone system can tell 
> you that an architecture that can make a simple line to line 
> phone call is trivial.  An architecture that can do all the 
> features and meet all the requirements is difficult.  
> 
> Geoff
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org