[VOIPSEC] RE: TLS as the SIP security mechanism

Brian Rosen br at brianrosen.net
Wed Aug 10 07:56:44 PDT 2005


I think I grasp the realities quite well, thank you.

First of all, I again believe there are restart avalance problems when a
very large number of CLIENTs fail, for example, a large sustained power
outage.  Failure at any carrier facility, I assume, should never have a
restart avalanche.

I do wonder how your "core" system faired in the Northeast power outage.
Did it have sufficient diesel to operate throughout the outage?  Many
systems don't have adequate fuel, nor adequate preparations to get more.  We
discovered that more specifically in cellphone systems of course.

Anyway, back to SIP.

The failure of any proxy should not cause any user visible problems.  Calls
that are up, stay up.  Calls that start signaling after the failure should
go through with minimal effect.  Calls that were literally in the middle of
signaling may "fail", in the sense that the attempt to finish the SIP
transaction may fail, but a normal retry on the origination end should
succeed.  That may cause some extra call set up time, but not a user
perception of failure.

We use load balancers, redundant state saving mechanisms, and intelligent
use of DNS to make sure that a failure of a single component does not cause
a subscriber perceptible outage.  This is all standard stuff, nothing
special.  Depending on your architecture, you may want TLS acceleration, but
I have not seen that being necessary very often.

A SIP proxy is a computer, nothing more, nothing less.  1U per 33K
subscribers is around 1M subscribers per rack.  Not too bad.  You can push
100K per; depends on how your redundancy plan is organized and the services
you offer.  If you plan on a lot of services, I'd keep the number of
subscribers per box low, and replicate the services.  Some systems go the
other way; they have boxes per service.  YMMV.

When a routing proxy fails, very little is affected if you have replicated
state.  Sessions that are up route to a different proxy when new services
are invoked, or the session is torn down.  New session initiations just
work.  The thing that is relevant here is that the TCP keep alives fail, but
the restarts are spread out by the keep alive timer mechanism.  Let's say
you have 1M subscribers, and at peak busy hour, 1/4 of them are active
(that's way to high for residential, but let's say it's American Idol voting
night).  So, you have 250K TLS session restarts over perhaps a minute or
two.  That's one accelerator, or a dozen processors.  Big deal, and that
assumes a 1M subscriber single box dies.  The right thing happens: the keep
alives spread out the restart load over minutes, a call attempting to be
placed gets restarted as the signaling starts.

Where is the problem?

Again, web services do this now.  Can't say that we have lots of examples of
SIP proxies doing it now; little demand yet.

Brian



-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
Behalf Of Geoff Devine
Sent: Tuesday, August 09, 2005 8:50 AM
To: Voipsec at voipsa.org
Subject: [VOIPSEC] RE: TLS as the SIP security mechanism

I think you fail to grasp the requirements of primary line telephony.  The
telephone network has been designed to avoid outages since it's good public
policy to have telephone service available... even when the power goes out.
In my voice over cable space, residential VoIP devices have battery backup.
The network has battery backup and diesel generators.  Everything is
engineered so the core maintains five 9's up time.  This is required so when
someone needs telephone service in an emergency, they'll get dialtone.  
 
The telephone network is, of course, imperfect and doesn't achieve true five
9's at the core.  If the intent hadn't been to engineer a five 9's system,
it would certainly be an order of magnitude less stable than it is.  If you
design a network where you have restart avalanches after every bounce of a
SIP proxy, you can't possibly achieve these objectives.  You have a moral
and ethical obligation to engineer them out.
 
You ask why anyone would want to have hundreds of thousands of subscribers
on a proxy?  In my voice over cable space, you'd be laughed out the door if
you didn't have a scaling story that looked like that with product that can
do 100K today.  Nobody wants to manage a wall of equipment racks full of
machines to service a city.  The operators don't have the space in the head
end for all the equipment.  Problems like restart avalanches certainly go
away if you can limit a SIP proxy to 1000 subscribers but you wouldn't sell
any in my space.
 
Geoff

________________________________

From: Brian Rosen [mailto:br at brianrosen.net]
Sent: Tue 8/9/2005 8:04 AM
To: Geoff Devine; Voipsec at voipsa.org
Subject: RE: [VOIPSEC] RE: TLS as the SIP security mechanism



There are one heck of a lot of web servers that do this; I can't imagine
what ills you are worried about that the web servers don't handle other than
the idea that you tend to keep the TLS connection longer lived on a SIP
connection than you do on most web connections.  There are "web services"
that DO keep connections alive. 

Of course, I'm not sure why you would want to have a single SIP proxy with
hundreds of thousands of connections on it; seems like a poor system design,
but your mileage may vary.

Then again, why would a failure that requires you to recreate the TLS
connection count as an outage?  Certainly it would not be visible to a
subscriber.  Remember you have three basic states:
        No call in progress, active registration
        Call in the middle of being established
        Call established, still in progress

Proxy outages typically have zero effect on the first and third cases.  It
may be that the session establishment gets abandoned on a proxy failure
(case 2), but a retry on the end user agent would succeed.  Not user
visible.

I know there is brain power being applied to recovery from restart
avalanche.  This is what happens if the service actually goes down hard, for
example, if a large area has a power outage that takes down the CPE, and
then the power comes back on. 

I'm watching DTLS.  May be interesting.

Brian

-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
Behalf Of Geoff Devine
Sent: Monday, August 08, 2005 9:03 AM
To: Voipsec at voipsa.org
Subject: [VOIPSEC] RE: TLS as the SIP security mechanism

I believe TLS is a poor choice as a security mechanism.  It's unfortunate
that it was placed in RFC 3261 as the recommended security method.  TLS must
be run over a reliable transport (TCP).  TCP has all kinds of scaling issues
when you're running hundreds of thousands of instances of TCP on a big
Carrier-class SIP proxy.  It's almost impossible to make TCP redundant so if
the SIP proxy bounces, all the SIP user agents have to establish new TCP
connections and then negotiate new security associations.  This creates an
avalanche of SYN messages and looks just like a classic SYN attack.  I don't
know how you achieve carrier-class five 9's availability in this kind of
environment since your 10 minute outage budget for the year is blown out of
the water any time you bounce a SIP proxy.

There's an IETF draft for a security mechanism called DTLS.  DTLS runs over
UDP so it doesn't suffer the TCP scaling and starup issues.  The only issue
with UDP-based SIP is that you need to keep the messages "small" to avoid
fragmentation.  SIP messages are typically fairly small but they can explode
in size when you start doing media security key exchanges embedded in your
SIP messaging using MIKEY or SDESCRIPTIONS.  We're seeing sizes get bigger
and bigger.  For example, in the session description protocol, you can't
offer buth SRTP and RTP due to a difficiency in the way SDP was specified.
The work-around is to offer two different instances of SIP as multipart
MIME.  Add in media security keys and Proxy-inserted headers to do things
like assert identity and you start blowing through 1500 bytes.  At that
point, you have two choices... either use a transport like TCP to deal with
message fragmentation (a poor choice, in my opinion), or start compressing
the signaling using methods like SIGCOMP (RFC 3320/3321).

Sigh.... so much for SIP being a simple, lightweight protocol.

Geoff



________________________________________

Date: Thu, 4 Aug 2005 14:41:45 -0700
From: John Todd <jtodd at loligo.com>
Subject: Re: [VOIPSEC] Are there any SIP client and proxy server that
        supports        IPSec or transport layer security ( hop-by-hop
protection)?
To: Voipsec at voipsa.org
Message-ID: <p06020411bf1839520b0f at loligo.com>
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"

At 9:27 AM -0600 8/4/05, Pankaj Shroff wrote:
>
>I think implementing TLS in the Sip User Agent is a prerogative of the User
>Agent developer. I think almost all commercial SIP products out there (such
>as software SIP User Agents, Proxies, etc., as well as Session Border
>Controllers) should support TLS. I am not so sure about IPSec support
>however. Also, S-RTP is still too new. I do not know of any product
>available today that supports S-RTP out of the box. Good luck on your
>project.
>  Pankaj
>
>  On 8/4/05, dennis <m8939605 at yahoo.com.tw> wrote:
>>
>>  I intend to start a project(client) that will
>>  implement TLS, IPsec(secure SIP) and secure RTP. I'm
>>  surveying the products(client and server) that support
>>  TLS or IPsec. But
>>  I don't find any SIP client product that support TLS
>>  or IPsec. Does anyone know such SIP security products ?
>>
>>  __________________________________________________
>>  ëzë¶éûùæìûêVêMí ímÅH
>>  înè"â?çZYahoo!äÔñÄë¶éûí êu
>  > http://messenger.yahoo.com.tw/
>  >
>--
>Pankaj Shroff
>shroffG at Gmail.com


I believe that the Sipura and Zultys platforms
support both TLS and SRTP.  However, both
companies have done what I belive to be a
terrible job in advertising and promoting this
capability, and there are very few SIP
proxies/gateways which support either protocol.
Zultys sells their own proxy/gateway, so is not
inclined to help develop anything.  I'm sure
there are others - Google should help you out
here.

More open-source efforts towards implementing TLS
and SRTP would be welcome, as far as I'm
concerned.  The number of locations using
Asterisk as both a SIP element and gateway
element would make it a natural choice for such a
stack to be implemented for open-source
environments.  The topic of SRTP and TLS comes up
every 6 months or so and gets a lot of approval,
but the important half of "rough consensus and
running code" never happens.

JT



------------------------------

Message: 3
Date: Sat, 6 Aug 2005 00:40:38 +0200
From: Johan Bilien <jobi at via.ecp.fr>
Subject: Re: [VOIPSEC] Are there any SIP client and proxy server that
        supports        IPSec or transport layer security ( hop-by-hop
protection)?
To: dennis <m8939605 at yahoo.com.tw>
Cc: Voipsec at voipsa.org
Message-ID: <20050805224037.GA28110 at via.ecp.fr>
Content-Type: text/plain; charset=us-ascii

On Thu, Aug 04, 2005, dennis wrote:
> I intend to start a project(client) that will
> implement TLS, IPsec(secure SIP) and secure RTP. I'm
> surveying the products(client and server) that support
> TLS or IPsec. But
> I don't find any SIP client product that support TLS
> or IPsec. Does anyone know such SIP security products ?

Have a look at minisip (http://www.minisip.org/). It supports TLS for
SIP messages, and both SRTP and IPsec to protect the media.

Johan.



------------------------------

_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org


End of Voipsec Digest, Vol 8, Issue 5
*************************************





_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org






More information about the Voipsec mailing list