IETF Logo Mail Archive

Re: [rtcweb] Requiring ICE for RTC calls

"Ravindran Parthasarathi" <pravindran@sonusnet.com> Mon, 26 September 2011 18:29 UTC

Return-Path: <pravindran@sonusnet.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 6ECCE21F8DCD for <rtcweb@ietfa.amsl.com>; Mon, 26 Sep 2011 11:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 kp3HFO6464ps for <rtcweb@ietfa.amsl.com>; Mon, 26 Sep 2011 11:29:08 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id DCBEB21F8DCC for <rtcweb@ietf.org>; Mon, 26 Sep 2011 11:29:07 -0700 (PDT)
Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p8QIWLrV001453; Mon, 26 Sep 2011 14:32:21 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 14:31:50 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Tue, 27 Sep 2011 00:01:46 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com>
In-Reply-To: <4E809EE6.2050702@skype.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Requiring ICE for RTC calls
Thread-Index: Acx8Y/qkWDkNsFldQJS0ak/HpL4WuAAFc21Q
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>
From: Ravindran Parthasarathi <pravindran@sonusnet.com>
To: Matthew Kaufman <matthew.kaufman@skype.net>, Iñaki Baz Castillo <ibc@aliax.net>
X-OriginalArrivalTime: 26 Sep 2011 18:31:50.0052 (UTC) FILETIME=[8E33DE40:01CC7C7A]
Cc: Randell Jesup <randell-ietf@jesup.org>, rtcweb@ietf.org
Subject: Re: [rtcweb] Requiring ICE for RTC calls
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: Mon, 26 Sep 2011 18:29:08 -0000

I'm sort of lean towards ICE or ICElite mechanism for NAT traversal of media because there is no known better mechanism. In case there is known better mechanism, Please list out for discussion.

Thanks
Partha

>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>Of Matthew Kaufman
>Sent: Monday, September 26, 2011 9:19 PM
>To: Iñaki Baz Castillo
>Cc: Randell Jesup; rtcweb@ietf.org
>Subject: Re: [rtcweb] Requiring ICE for RTC calls
>
>On 9/26/2011 8:29 AM, Iñaki Baz Castillo wrote:
>> 2011/9/26 Matthew Kaufman<matthew.kaufman@skype.net>:
>>> For example, an evil overlord that creates a web site for allowing
>its
>>> clients to attack systems behind a firewall could relax those
>requirements
>>> and not mandate ICE/SRTP when opening arbitrary connections to
>systems
>>> behind said firewall.
>>>
>>> The "configuration" must be retrieved by the WebRTC client *from the
>system
>>> it will be sending traffic to*... the best format we have for that is
>to
>>> send a (rate-limited) STUN connectivity check with short-term
>credentials
>>> and see if it is replied to properly. That's how ICE works.
>> I understand your points and I agree. That would be the perfect
>scenario.
>
>That would be the only scenario that is safe enough to ship in a
>browser.
>
>> But I'm worried about the price to pay for these security constrains
>> (no interoperability with 95% of SIP-PSTN providers within next 3-5
>> years).
>
>The alternative is that you don't ship anything in the browser, because
>the browser *cannot* become an attack vector as a result of adding this
>feature.
>
>And "interoperability with SIP-PSTN providers" is only relevant if you
>are trying to turn the browser into another phone. We have enough
>phones. What we don't have are new real-time communication experiences
>that can only be created within this environment.
>
>Matthew Kaufman
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb

v2.27.8 | Report a Bug | By Email | System Status