Re: [rtcweb] SBC hardware and SHA1

Eric Rescorla <ekr@rtfm.com> Fri, 30 September 2011 19:08 UTC

Return-Path: <ekr@rtfm.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 7E6D121F8BB9 for <rtcweb@ietfa.amsl.com>; Fri, 30 Sep 2011 12:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.903
X-Spam-Level:
X-Spam-Status: No, score=-102.903 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 zEHWkB-F4tOa for <rtcweb@ietfa.amsl.com>; Fri, 30 Sep 2011 12:08:49 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5823721F8CC1 for <rtcweb@ietf.org>; Fri, 30 Sep 2011 12:08:49 -0700 (PDT)
Received: by wwf22 with SMTP id 22so2220686wwf.13 for <rtcweb@ietf.org>; Fri, 30 Sep 2011 12:11:43 -0700 (PDT)
Received: by 10.227.208.137 with SMTP id gc9mr14030484wbb.91.1317409901809; Fri, 30 Sep 2011 12:11:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.227.196.83 with HTTP; Fri, 30 Sep 2011 12:11:00 -0700 (PDT)
In-Reply-To: <C3C7D62E-6BA8-43F4-A29D-FC9AF3BE689F@acmepacket.com>
References: <CAD5OKxtNjmWBz92bRuxka7e-BUpTPgVUvr3ahJGpmZ-U5nuPbQ@mail.gmail.com> <CAD6AjGSmz5T_F+SK2EoBQm6T-iRKp7dd4j8ZAF5JKdbbyomZQA@mail.gmail.com> <CALiegfmO54HC+g9L_DYn4jtXAAbLEvS++qxKa6TNrLDREs9SeA@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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 30 Sep 2011 12:11:00 -0700
Message-ID: <CABcZeBM9a6J845VZ=mPXw0MZpK9FjYLdxPdbtJNBeh+jHsmh1Q@mail.gmail.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Content-Type: multipart/alternative; boundary="0015174be9a638926904ae2d6573"
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
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:08:50 -0000

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

I don't know a huge amount about how hardware-based SBCs are constructed,
but it's important
to remember that DTLS-SRTP is DTLS key management but SRTP data transport,
so the naive
way to build the system would be to do the DTLS in software and then push
the keys onto
SRTP, thus using all the normal SRTP packet processing.

Obviously, there will be some performance cost associated with this (as
there is for any
asymmetric key exchange). The typical acceleration strategy for TLS is to
have hardware
acceleration for the asymmetric operations but have the actual TLS stack in
software,
for the obvious reasons of flexibility and upgradeability. Don't know how
much that
helps.

-Ekr



> 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
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>