[rtcweb] Requiring ICE for RTC calls

Roman Shpount <roman@telurix.com> Mon, 26 September 2011 14:27 UTC

Return-Path: <roman@telurix.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 B7A2B21F8C6A for <rtcweb@ietfa.amsl.com>; Mon, 26 Sep 2011 07:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.273
X-Spam-Level:
X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[AWL=-2.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, SARE_LWSHORTT=1.24]
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 aJPL7WVyB8iK for <rtcweb@ietfa.amsl.com>; Mon, 26 Sep 2011 07:27:24 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD3221F8C69 for <rtcweb@ietf.org>; Mon, 26 Sep 2011 07:27:23 -0700 (PDT)
Received: by qyk32 with SMTP id 32so9885617qyk.10 for <rtcweb@ietf.org>; Mon, 26 Sep 2011 07:30:04 -0700 (PDT)
Received: by 10.229.46.65 with SMTP id i1mr4839421qcf.86.1317047401289; Mon, 26 Sep 2011 07:30:01 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id he10sm14214469qab.25.2011.09.26.07.30.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Sep 2011 07:30:00 -0700 (PDT)
Received: by gyd12 with SMTP id 12so5261526gyd.31 for <rtcweb@ietf.org>; Mon, 26 Sep 2011 07:29:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.22.105 with SMTP id c9mr29785624pbf.88.1317047399199; Mon, 26 Sep 2011 07:29:59 -0700 (PDT)
Received: by 10.68.55.39 with HTTP; Mon, 26 Sep 2011 07:29:59 -0700 (PDT)
Date: Mon, 26 Sep 2011 10:29:59 -0400
Message-ID: <CAD5OKxtNjmWBz92bRuxka7e-BUpTPgVUvr3ahJGpmZ-U5nuPbQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Randell Jesup <randell-ietf@jesup.org>
Content-Type: multipart/alternative; boundary=bcaec52154c561b3ea04add8fe65
Cc: rtcweb@ietf.org
Subject: [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 14:27:24 -0000

I think requiring ICE in RTC is not only unfortunate, it will make it
impossible to connect to PSTN without media gateway. If we complete this
specification, and phone carriers decide that there is a business case for
them to support RTC clients directly, it will take them 3-5 years to
implement ICE in SBC. From what I've seen major carriers run SBC firmware
which is normally 2-3 years old. If we add time it takes to implement ICE in
SBC, plus time it will take PSTN provider to verify and test the feature, we
are easily looking into 5 year time frame.

Since we need to have user confirmation to start a media call anyway, and
since this is not going to be any different from what SIP clients are
currently doing, it would make sense to allow a plain non-ICE, non-SRTP
call.

Finally, ICE specification are desinged to interop with non-ICE end points.
We will need to change ICE to accomplish what you are doing.
_____________
Roman Shpount


On Mon, Sep 26, 2011 at 1:23 AM, Randell Jesup <randell-ietf@jesup.org>wrote;wrote:

> On 9/22/2011 4:37 PM, Cullen Jennings wrote:
>
>> On Sep 22, 2011, at 2:04 PM, Christer Holmberg wrote:
>>
>>  If so, what is your assumption then regarding ICE? That the SIP nodes
>>> will support ICE, or that the browser will be allowed to communicate with
>>> the SIP nodes without enabling ICE?
>>>
>> I see no way of solving the security problems without having ICE or
>> something more or less like it. Therefore, I'm working on the assumption
>> that it will only work if the SIP side supports ICE, or is front ended by a
>> SBC with media GW that does ICE. In the short term, there will be some
>> devices that don't do ICE but SIP devices are increasingly having ICE added.
>> Particularly SIP devices that are internet facing because the need for NAT
>> traversal.
>>
>> I find requiring ICE to be a very unfortunate assumption to have to make -
>> obviously it reduces the number of legacy voip devices WebRTC devices can
>> talk to without an SBC but I don't see any way around this limitation.
>> Allowing web browsers inside the firewall to send packets to an arbitrary
>> address that is inside the firewall with no validation that address speaks
>> RTP is not acceptable.
>>
>
> I agree we can't solve the security issue with permission to send with the
> current threat model without ICE or some equivalent.
>
> There is another option that may help with some of the use cases (I've
> mentioned
> this before in the discussion on screensharing, among others).  For a
> number
> of the use cases security is an impassible problem with the current threat
> model.
> Those use cases generally involve replacing cases where an existing desktop
> install or plugin was used (webex, screensharing, vnc, SIP softclient,
> Skype, etc).
> Those cases all currently involve the user implicitly giving these apps
> total
> or close to code that could do pretty much anything on the user's computer,
> and are also often the "ongoing usage" authentication cases.
>
> The only mitigating safety of the external app/plugin model is that they're
> typically
> signed and go through the platforms software-install procedure,
> cert-showing, UACs, etc.
>
> Currently people are trying to work out the HTML5 "installed" webapp
> security model;
> if that's far enough along we may be able to piggyback off that.   I'm
> looking into it.
>
>
> --
> Randell Jesup
> randell-ietf@jesup.org
>
> ______________________________**_________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>