Re: [rtcweb] Summary of ICE discussion

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 05 October 2011 08:16 UTC

Return-Path: <magnus.westerlund@ericsson.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 250D921F8AE1 for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 01:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.483
X-Spam-Level:
X-Spam-Status: No, score=-106.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, 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 jLEJCXwTjRwh for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 01:16:06 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 51DBA21F862F for <rtcweb@ietf.org>; Wed, 5 Oct 2011 01:16:05 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-e8-4e8c1300c540
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.115.81]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B8.5C.20773.0031C8E4; Wed, 5 Oct 2011 10:19:13 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 5 Oct 2011 10:19:10 +0200
Message-ID: <4E8C12FD.5010007@ericsson.com>
Date: Wed, 05 Oct 2011 10:19:09 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
References: <4E8B192E.80809@ericsson.com> <2E239D6FCD033C4BAF15F386A979BF510F142C@sonusinmail02.sonusnet.com>
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F142C@sonusinmail02.sonusnet.com>
X-Enigmail-Version: 1.3.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Summary of ICE discussion
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, 05 Oct 2011 08:16:07 -0000

On 2011-10-05 08:07, Ravindran Parthasarathi wrote:
> In case user consent is the reason for ICE, ICE may not be right
> choice because of the multiplexing RTP in RTCWeb and user may be
> consent for audio and not for video which is not possible to indicate
> through ICE. It is possible to achieve by having different streams
> for each media but I strongly believe that it is not interesting
> topic for RTCWeb.

No, it is not user consent, it is data transmission consent that is the
issue here.

> 
> I think that trust model with browser---RTCWeb server---browser for
> the user consent with individual media stream works because browser
> user trust RTCWeb server. I could think of offer/answer as user
> consent with media stream mechanism because offer or answer indicates
> media port is allocated in browser and listening for media from
> remote party, the consent reaches remote browser through RTCWeb
> server. The advantage in the model is that RTCWeb server shall have
> the policy to control media. Please let me know your comments on
> this.


My interpretation is that several has disagreed with you on this model.
I personally also disagree with this. There is a big difference between
allowing a webservice access to my media devices, i.e. microphone and
video as will expect it to perform a communication service where I at
least see parts of that communication happening. However, the user has
no way of verifying that of the media streams being setup by the web
service that it in fact not in addition uses the users resources for a
DoS attack. It is the destination of the media stream that needs to
consent to the media delivery, not the siganlling node for it. Thus a
path based media verification that ensures that information from the
signalling and the media path agrees provides a reasonable but not
perfect security against attacks. This is still vulnerable to attackers
that have the capability of both running the web service and intercept
and inject packets in the network on path between the web client and the
target of the attack.

> 
> The other reason like NAT & FW is not mandatory for intranet RTCWeb
> applications. I have mentioned as part of
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01619.html

My interpretation of your statement was that it was disputed and that
the disputing statement was not faulty.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------