Re: [rtcweb] SBC hardware and SHA1

Cameron Byrne <> Fri, 30 September 2011 16:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCB9221F8BF3 for <>; Fri, 30 Sep 2011 09:47:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.459
X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jrd6yOSo1TyU for <>; Fri, 30 Sep 2011 09:47:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 35BE721F8BEE for <>; Fri, 30 Sep 2011 09:47:59 -0700 (PDT)
Received: by qyk33 with SMTP id 33so1866923qyk.10 for <>; Fri, 30 Sep 2011 09:50:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=htrsnHvqGFK+zq9Z5IHb8bMUPRu2plr0eWV94A4UksE=; b=kI0JZkXEFzhyQabkFDnzQqjGvhYDu4GvkHootPGlToCdAnQ7T5PRsftkKM4JP+QYh0 1+xkX26c7JrvnkK1jLni1SVSVQqbN23/l3MtL6mlmCWic5i12tNq4Eh6fTdJf7vFpXG6 /9oR3/6RlP0mcrO5goXn9flnWhDN93K4uRsNw=
MIME-Version: 1.0
Received: by with SMTP id r6mr59581415pbj.77.1317401452867; Fri, 30 Sep 2011 09:50:52 -0700 (PDT)
Received: by with HTTP; Fri, 30 Sep 2011 09:50:52 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Fri, 30 Sep 2011 09:50:52 -0700
Message-ID: <>
From: Cameron Byrne <>
To: Hadriel Kaplan <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "<>" <>
Subject: Re: [rtcweb] SBC hardware and SHA1
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Sep 2011 16:47:59 -0000

On Fri, Sep 30, 2011 at 9:39 AM, Hadriel Kaplan <> 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.  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.