[VOIPSEC] SRTP

[Christian Stredicke]

As a phone vendor I can say that SRTP is relatively cheap - you dont see
it on the CPU load. However, the key negotiation requires a lot of
number crunching, which may block the CPU for a few feconds. IMHO this
is not acceptable when you pick up a phone call, therefore we decided to
go with sdes.

Hardware accelerators are pretty useless here. If you have a problem
with several megabits for video, your CPU must be able to deal with this
heavy load anyway and the SRTP piece does not make a difference any
more.

Security does *not* increase the price of a device. The extra memory
that you need is neglectable.

Christian

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] On Behalf Of Randell Jesup
> Sent: Monday, March 20, 2006 3:47 PM
> To: Simon Horne
> Cc: Richard Polishak; Voipsec at voipsa.org; dan_york at Mitel.com
> Subject: Re: [VOIPSEC] SRTP
> 
> Simon Horne <s.horne at packetizer.com> writes:
> >I have to totally agree, using a handset to me is much better then 
> >using headphone/speakers (says the guy who writes 
> softphones) but its true.
> 
> The same applies to webcams/chat vs standalone videophones 
> (which is why we're selling home H.264 videophones with 
> LCDs).  Not to mention your computer is likely not to be in 
> the same sort of room where you like to talk to people 
> (kitchen, family room, perhaps bedroom, etc).
> 
> >The price of secure IP phones is most likely going to be 
> quite high as 
> >these devices would need quite a lot of expensive upgrades 
> and include 
> >things like encryption accelerator chips etc and they can be 
> expensive. 
> >Are people going to pay the money for them and is there a 
> "big enough" 
> >market for it?
> 
> SRTP doesn't need all that junk.  Even for videophones, we're 
> not encrypting a huge amount of traffic; a megabit or so at 
> the outside (and generally 384K or less - our videophone runs 
> at 80-250K total including audio and overhead at 30FPS).  For 
> a DSP SRTP/AES is no challenge at all.
> Or use a standard network processor with a built-in crypto 
> engine as the main controller CPU.  Might cost you $5 more 
> than the chip without it - maybe.  Added hardware cost 
> (ignoring NRE) for encryption should be <$5, and quite possibly $0.
> 
> >Then on the technical standpoint - there is no common 
> standard way of 
> >doing key exchange so it needs to support all or none. If the device 
> >talks to another device that does not support the 
> implemented method of 
> >encryption, will the call fail? Can the call revert back to standard 
> >RTP?  These issues and the "answer on zero ring" encrypted 
> call problem 
> >are going to hamper development of these devices.
> 
> These are the REAL issues.  We have a good standard for the 
> streams (SRTP); we have sucky (working) to non-existant 
> standardization on the key exchange and call-setup side.  
> Isn't that what we're in theory trying to deal with here? 
> 
> >Another major issue for home office uses in the "Cool I have this 
> >secure IP phone now how the heck do I get it to traverse my NAT?" 
> >issue. Get an SBC!  :(
> 
> SRTP has no or little impact on NAT traversal.  So long as 
> you don't encrypt the SIP traffic, in _theory_ key exchange 
> doesn't mess up SBCs.
> But that's edging into the vortex of problems with call setup.
> 
> --
> Randell Jesup, Worldgate (developers of the Ojo videophone), 
> ex-Amiga OS team rjesup at wgate.com
> 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 
> 
>