Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism

Randell Jesup <randell-ietf@jesup.org> Mon, 26 September 2011 05:24 UTC

Return-Path: <randell-ietf@jesup.org>
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 3C22221F84FD for <rtcweb@ietfa.amsl.com>; Sun, 25 Sep 2011 22:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.961
X-Spam-Level:
X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=-0.602, BAYES_00=-2.599, 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 PDMJouPTVfW2 for <rtcweb@ietfa.amsl.com>; Sun, 25 Sep 2011 22:24:49 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9591D21F84FC for <rtcweb@ietf.org>; Sun, 25 Sep 2011 22:24:49 -0700 (PDT)
Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1R83j0-0004Kj-4J for rtcweb@ietf.org; Mon, 26 Sep 2011 00:27:30 -0500
Message-ID: <4E800C67.9070006@jesup.org>
Date: Mon, 26 Sep 2011 01:23:51 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <ED2DB00E-A64B-405F-96AC-2269258F6FFC@cisco.com> <4E799ECC.8030306@ericsson.com> <DB6B2796-9762-47CA-9A45-62476146DF04@cisco.com> <4E7B7272.7020204@alvestrand.no> <CALiegfkWv9wPj8N3FLT2UpksHARp7qdSXTJVTSEyBpL7pdujcg@mail.gmail.com> <18FFF339-E7EB-4EEB-BCD8-E6728A56A24A@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FBC@ESESSCMS0356.eemea.ericsson.se> <271E29CD-D561-4E29-9E2D-DD15B9461F98@cisco.com>
In-Reply-To: <271E29CD-D561-4E29-9E2D-DD15B9461F98@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism
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 05:24:50 -0000

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