[VOIPSEC] SRTP

[Mark Baugher]

Christian,

On Mar 20, 2006, at 5:14 PM, Christian Stredicke wrote:

> 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.

Unfortunately, the authorization and key management infrastructure 
needed for security is not cheap.

Mark
>
> 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
>>
>>
>>
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>