Re: [rtcweb] SBC hardware and SHA1

[Dzonatas Sol <[e-mail]>]

On 09/30/2011 09:50 AM, Cameron Byrne wrote:
> On Fri, Sep 30, 2011 at 9:39 AM, Hadriel Kaplan<[e-mail]>  wrote:
>    
>> On Sep 30, 2011, at 2:36 AM, Olle E. Johansson wrote:
>>
>> Hadriel,
>> While on the topic of the hardware, I would like to ask how these systems
>> handle DTLS and SRTP.
>>
>> Assuming you mean terminating the SRTP, I only know of one hardware-based
>> SBC that claims support for terminating DTLS-SRTP, but I don't know if it's
>> real or slideware. �I know of a couple software-based ones that do. (you can
>> probably google it to find out who)
>> But in general the most popular support by far is for SDES-based keying.
>> �There are a couple of off-the-shelf chip solutions for large-scale SRTP
>> that handle it as a bump-in-the wire, but they need to be told the keys per
>> stream and don't handle DTLS inline themselves to do so, so naturally SDES
>> made it a lot easier to use them. �Having said that, I do believe that more
>> SBC vendors in the US market will be supporting DTLS-SRTP in the future
>> because the US government has it mandated in some agency or other I've been
>> told. �Whether other governments will do the same I don't know. (then again
>> the US government mandates a lot that never gets used in practice)
>> Also, someone asked on this list if SBC vendors support SRTP to begin with.
>> �Almost every SBC vendor I know of does support SRTP (at least with SDES
>> keying), but it usually costs more to do so, because it's done in dedicated
>> hardware. �So most deployed SBC systems don't do SRTP, because the people
>> buying/deploying them have decided they don't need it and don't want to pay
>> for it. �It's more popular in specific vertical markets, but overall it's
>> definitely a minority today.
>> -hadriel
>>
>>      
> As a service provider, i cannot imagine rolling out a solution that
> lacks encryption.


Perhaps node.js would be easier for browsers such that the browser's JS 
API can forward-to node.js where available. I'd imagine despite the 
choice of browser flavor that something like "use local node.js for 
encryption" in each may be ideal over direct to cloud/SBC. That may be 
easier for this WG for select innovation.

Either that, or let browsers run API regression against JS-UNIX (i.e. 
jslinux) with RTP and with hardcoded SHA validators in /dev. This may be 
more ideal for B2B portability and manufacturer automation, yet it may 
seem anti-game despite being more federal-ready.

I can imagine the JS API that includes encryption with real-time 
constraints. I have no interest in JS other than it helps convey that idea.




>   Cost of bad press and unmet user expectations is
> higher than a few extra boxes. If you choose not to encrypt, well...
> that becomes a differentiation for those that do.
>
> We have already bought and paid for SRTP in our existing IMS/SIP
> applications that exist on the Internet and will mandate it for
> anything we do with RTCWeb too, it's policy.
>
> Cameron
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>    


-- 

---
<i>The wheel.</i metro-link=t dzonatasolyndra>