Re: [rtcweb] SBC hardware and SHA1

Dzonatas Sol <dzonatas@gmail.com> Fri, 30 September 2011 19:29 UTC

Return-Path: <dzonatas@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10B421F8696 for <rtcweb@ietfa.amsl.com>; Fri, 30 Sep 2011 12:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.793
X-Spam-Level:
X-Spam-Status: No, score=-3.793 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ttsgriNNCGh for <rtcweb@ietfa.amsl.com>; Fri, 30 Sep 2011 12:29:46 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D794A21F867F for <rtcweb@ietf.org>; Fri, 30 Sep 2011 12:29:45 -0700 (PDT)
Received: by ywa6 with SMTP id 6so2215101ywa.31 for <rtcweb@ietf.org>; Fri, 30 Sep 2011 12:32:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=o75akZwMhDUJrdnkggR916ebF8L76hoplsI/9wSV6Ig=; b=wO3coohILarJUKRym3yXBW/w44xsdPkrm4+UoHJ83z9zPp7FxdzlVCmm1U4bzZo34M oPkWfrcrCj6lKkzkYmykfJNrEgpEBLidGkN1bhtfKD2NZMqcvhyORISqvGeJjoKjENOj DvhdklfWhXVOwiRTDCgDgd1Jb3m0gJ9eNGwfc=
Received: by 10.68.71.163 with SMTP id w3mr29149308pbu.130.1317411158501; Fri, 30 Sep 2011 12:32:38 -0700 (PDT)
Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id ml4sm21202663pbc.0.2011.09.30.12.32.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Sep 2011 12:32:37 -0700 (PDT)
Message-ID: <4E8619E6.9000100@gmail.com>
Date: Fri, 30 Sep 2011 12:35:02 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CAD5OKxtNjmWBz92bRuxka7e-BUpTPgVUvr3ahJGpmZ-U5nuPbQ@mail.gmail.com> <4E80984A.903@skype.net> <CALiegfmyvTb57WVooKryS-ubfcg+w5gZ+zfO1zzBLn3609AzaA@mail.gmail.com> <4E809EE6.2050702@skype.net> <CAD5OKxvUOadaU0dnB7-Ho9cZ92VY+4Owuhj7oKPCx9Jy1iwT1Q@mail.gmail.com> <C2DF2C51-B3F7-443D-A047-7E6FB03E6D20@phonefromhere.com> <CAOJ7v-3AJJcdrCKcH4AJmv_016sZtcOPOo8yCv3Va65eJogAkQ@mail.gmail.com> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> <CALiegf=nG+KXto9CXfn64CQSp3P5Lfm+S8c0xnA187Fhz=fcrQ@mail.gmail.com> <05B54E0C-B867-4D7F-825D-2E008E69B07F@acmepacket.com> <4E84F06B.7020705@skype.net> <2C381E05-59C5-4678-A431-CFDAC1098050@acmepacket.com> <CABcZeBMgFetriRkyvR_pOczWX6RCpMisjzjQeBsPYj9Zg3S0zQ@mail.gmail.com> <DF6B5635-BD84-4F87-9228-3EF3BBCC7129@acmepacket.com> <CD38B852-5FA5-4CFC-B941-9C4F97BED622@edvina.net> <C3C7D62E-6BA8-43F4-A29D-FC9AF3BE689F@acmepacket.com> <CAD6AjGSoBN7eig-RnLWJFj4q0QgS81gHwT5dqjzK-ivN9Ag5Ng@mail.gmail.com>
In-Reply-To: <CAD6AjGSoBN7eig-RnLWJFj4q0QgS81gHwT5dqjzK-ivN9Ag5Ng@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] SBC hardware and SHA1
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2011 19:29:49 -0000

On 09/30/2011 09:50 AM, Cameron Byrne wrote:
> On Fri, Sep 30, 2011 at 9:39 AM, Hadriel Kaplan<HKaplan@acmepacket.com>  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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>    


-- 

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