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

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Wed, 09 November 2011 13:05 UTC

Return-Path: <keith.drage@alcatel-lucent.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 C902B21F8C50 for <rtcweb@ietfa.amsl.com>; Wed, 9 Nov 2011 05:05:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.725
X-Spam-Level:
X-Spam-Status: No, score=-105.725 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 D0eLZQJfa4Hx for <rtcweb@ietfa.amsl.com>; Wed, 9 Nov 2011 05:05:17 -0800 (PST)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4B46921F8C4E for <rtcweb@ietf.org>; Wed, 9 Nov 2011 05:05:17 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pA9D5CAI003948 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Nov 2011 14:05:14 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 9 Nov 2011 14:04:56 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Neil Stratford <neils@belltower.co.uk>, Iñaki Baz Castillo <ibc@aliax.net>
Date: Wed, 09 Nov 2011 14:04:55 +0100
Thread-Topic: [rtcweb] Let's define the purpose of WebRTC
Thread-Index: Acye3pUFe/nx9KxRT1Oz4agdkhbsQgAAOcfQ
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE22186AAFD@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
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> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <CALiegfmf59jb4asUu9LA6YY_aMtKEnM1Wy34KbuLEn3_h1xBXA@mail.gmail.com> <1D062974A4845E4D8A343C653804920206D3B9C1@XMB-BGL-414.cisco.com> <CALiegfmM1PB=VAQjfh4rW3-3C8aumHdWy9nZxD0-BWBq9Kq_tg@mail.gmail.com> <CABRok6nha3Ut5A1c1k=WUYxrn6kxDD=P2no6EFaf4=Uzdbbpwg@mail.gmail.com>
In-Reply-To: <CABRok6nha3Ut5A1c1k=WUYxrn6kxDD=P2no6EFaf4=Uzdbbpwg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE22186AAFDFRMRSSXCHMBSC3d_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
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: Wed, 09 Nov 2011 13:05:18 -0000

If you want to be in the world of telecommunications you carry a legacy baggage.

Your proposal to provide a gateway is just one way of dealing with the legacy baggage. It does however carry the downside that you need a player to provide such gateways in support of interworking to the legacy.

Suppose I make an emergency call to a PSAP. The legacy baggage here is that unless someone volunteers to provide all those PSAPs worldwide with new kit, the majority will remain connected to the PSTN (i.e. not even SIP). I need a guarantee that someone out there will provide a gateway. Which player provides that in your business model.

Keith

________________________________
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Neil Stratford
Sent: 09 November 2011 12:53
To: Iñaki Baz Castillo
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Let's define the purpose of WebRTC

Wouldn't it be great if we had an opportunity to start from a clean sheet, carry no legacy baggage and design a platform for the future? Isn't that the opportunity presented by WebRTC?

It will always be possible to gateway to legacy SIP devices, even if we have to bridge the media. It seems there is far too much focus on interop and not enough on what is best for the WebRTC platform.

Neil

On Wed, Nov 9, 2011 at 11:58 AM, Iñaki Baz Castillo <ibc@aliax.net<mailto:ibc@aliax.net>> wrote:
2011/11/9 Muthu Arul Mozhi Perumal (mperumal) <mperumal@cisco.com<mailto:mperumal@cisco.com>>:
> I am thinking we could burn SRTP into the browser such that the decision of whether or not to use SRTP vests solely with the browser.
The "browser" cannot decide that. Probably you mean the user, that
person that in 99.999% of cases does not know what "encryption" or
"SRTP" is, and in 85% of cases does not matter about security.


> If a WebRTC browser is exchanging media with another WebRTC browser they always do SRTP/SRTCP.
The browser has NO way to determine whether it's exchanging media with
another browser or not. And what you state is that, in case the peer
does not annouce support for SRTP then the browser should downgrade
security to plain RTP. The user (web visitor) has no way to know
whether the WebRTC application will contact a WebRTC browser or
another device at the media plane.


> If either side isn't WebRTC compliant they end up with RTP/RTCP.
So no security. Bad.


> This way we don't need to trust the JS, instead trust only the browser.
You mean the user.


> We can also interoperate with legacy devices without taxing them.
Sorry, but WebRTC is about "realtime communications for the Web",
rather than "SIP business coming to the Web". SIP uses RTP, including
RFC's about SRTP. If you want SIP interoperability with a WebRTC
device, then make your work as vendor and add security to your SIP
devices rather than asking no-security for WebRTC.

Please, take a look to XMPP/Jingle !!  They implement SRTP and ICE
from the beginning!! *Do* your homeworks as SIP vendor.

This is a problem of SIP vendors/telcos, this is not a problem of
WebRTC. You should implement SRTP in your legacy and non-secure SIP
devices and make them valid for communication across the open Internet
in which security is a MUST (Internet is not a telco wallen garden).
The main purpose of WebRTC is not to interoperate with insecure
devices, do we all agree here?

I don't support this kind of arguments in favour of non mandating SRTP.


PS: Somebody could argue that, in the Web, neither HTTPS or
WebSocket+TLS is a MUST but optional per website, so why to make SRTP
mandatory? That would be a very different argument I could understand
and discuss about. But forcing a *new* specification to be insecure
just to allow interoperability with non-secure devices is not welcome.
WebRTC is for the Web, not for SIP.

PS: This kind of discussions give the reason to recent comments like
the one from Tim Parton. This WG is too much focused on SIP
vendors/telcos which are not fully interested in RTC communications in
pure Web/Internet environments, but in making the web browsers a new
SIP phone for integratting them into their telco business. Bad.

PS: I'm also interested in interoperability between WebRTC browsers
and SIP devices (as much as you), but I assume that just a few SIP
devices MUST be able to interop with WebRTC (those that have done
their homeworks by implementing SRTP and ICE).


And those discussions are becoming very boring. There are not new
arguments at all. It seems than within next weeks/months, SIP
telcos/vendors will continue requesting not mandatory SRTP just to
facilitate their business without investing in improving their
non-secure devices. This is a no-go.


Regards.


--
Iñaki Baz Castillo
<ibc@aliax.net<mailto:ibc@aliax.net>>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb