Re: [rtcweb] Let's define the purpose of WebRTC

"Olle E. Johansson" <oej@edvina.net> Tue, 08 November 2011 15:00 UTC

Return-Path: <oej@edvina.net>
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 1163A21F8CE6 for <rtcweb@ietfa.amsl.com>; Tue, 8 Nov 2011 07:00:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.049
X-Spam-Level:
X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 tYWQpXEsj178 for <rtcweb@ietfa.amsl.com>; Tue, 8 Nov 2011 07:00:09 -0800 (PST)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 0317821F8CE5 for <rtcweb@ietf.org>; Tue, 8 Nov 2011 07:00:09 -0800 (PST)
Received: from [192.168.20.63] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp7.webway.se (Postfix) with ESMTPA id 71948754BCD5; Tue, 8 Nov 2011 15:00:05 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="us-ascii"
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com>
Date: Tue, 08 Nov 2011 15:58:26 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net>
References: <CALiegfkVNVAs_MyU_-4koA4zRwSn1-FwLjY9g_oZVkhi9rSK5Q@mail.gmail.com> <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <CABw3bnPE=OY_h5bM7GA6wgrXiOBL8P4J0kw1jLv-GSpHAbg=Cg@mail.gmail.com> <CABcZeBNqdkh8u=gwOvKfDCQA7rXdAyQkfaM1r2Sx10787btP6A@mail.gmail.com> <B10FEFF6-0ADC-4DB1-83BB-50A11C65EC35@acmepacket.com> <CABcZeBNSXtim_VqzqAd8Z-u4zWSjaYmsVZPN=7sDYkJsgtRAHA@mail.gmail.com> <4EB7E6A5.70209@alvestrand.no> <F8003BA9-BCD8-4F02-B514-8B883FF90F91@acmepacket.com> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com>
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Let's define the purpose of WebRTC
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: Tue, 08 Nov 2011 15:00:10 -0000

8 nov 2011 kl. 15:30 skrev Ravindran Parthasarathi:

> I agree with Hadriel that it is not required to mandate SRTP for WebRTC. My reasoning are as follows:
> 
> 1) Security could be in the lower layer itself (IPsec, VPN, private MPLS cloud). For Enterprise-only-WebRTC application (no federation & no interop), there is no need of security by specific application like WebRTC as it is ensured in the infrastructure. WebRTC security will be duplicated for these infrastructure and may leads double encryption unnecessarily.
For me this is not a valid objection. You can not ask the customer to try to find out if they are using the web browser in a secure or in an insecure 
network... That paradigm will just fail.

> 
> 2) Being in India, I'm interested in avoiding Government restriction on WebRTC proposal (Thanks to Tim for pointing this). I may not surprise to see that WebRTC mechanism is banned in India because intelligent agency struggles to break the key in each terrorist WebRTC site. (http://www.pcworld.com/businesscenter/article/235639/india_wants_to_intercept_skype_google_communications.html)
That is an interesting objection. I don't think SRTP by default is the problem here. In the case where you need lawful interception in the application,
the server needs to route the calls through an RTCweb b2b media server.

/O
> 
> In case there is no use case to illustrate in RTCWeb draft, let us discuss in detail.
> 
>> -----Original Message-----
>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>> Of Hadriel Kaplan
>> Sent: Monday, November 07, 2011 9:12 PM
>> To: Eric Rescorla
>> Cc: <rtcweb@ietf.org>
>> Subject: Re: [rtcweb] Let's define the purpose of WebRTC
>> 
>> 
>> On 11/07/2011 02:50 PM, Eric Rescorla wrote:
>>> On Sun, Nov 6, 2011 at 7:20 PM, Hadriel Kaplan<HKaplan@acmepacket.com>
>> wrote:
>>>> Who said "too slow"?  There *is* an extra round-trip or two involved
>> I presume, if we're talking DTLS-SRTP, but no I didn't mean that as a
>> "hit".  I just meant the extra computing cycles for SRTP being a "hit".
>> For WebRTC-to-WebRTC I don't think that matters at all.  For WebRTC-to-
>> media-server it might, for a free game app or greeting card app that
>> don't care about it to begin with, and which use plaintext HTTP to begin
>> with.
>>> Sorry, I didn't mean to put words in your mouth. Performance
>> measurements
>>> of HTTP versus HTTPS in modern Web environments suggest that the
>> additional
>>> load for HTTPS is not significant. Do you have evidence that the
>> situation is
>>> different for SRTP versus RTP?
>> 
>> Only from the DSP guys, and those would be hardware DSPs not softDSPs.
>> It runs them anywhere from 10-25% overhead, they say, depending on the
>> vendor and what else their DSPs are doing at the time.
>> 
>> But ultimately even in software I assume it's all relative to what other
>> work you're doing.  If you have to render a video stream on a screen and
>> encode camera input into a codec being sent out, then my guess is SRTP
>> overhead is a tiny factor not worth talking about.  If you're mixing
>> multiple RTP streams as a conference server, then I assume doing SRTP
>> for thousands of simultaneous audio RTP streams for multiple
>> simultaneous conferences becomes noticeable.  Or at least so they seem
>> to claim - I don't know since I don't build a media server (hardware
>> SBCs often offload SRTP onto dedicated hardware).  One large software
>> company even created their own proprietary packet format for SRTP that
>> they claimed was done for improving performance/scalability, so I assume
>> it has some impact they don't want their customers to incur.
>> 
>> -hadriel
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

---
* Olle E Johansson - oej@edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden