Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion)

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Tue, 11 October 2011 12:05 UTC

Return-Path: <mperumal@cisco.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 263E221F8560 for <rtcweb@ietfa.amsl.com>; Tue, 11 Oct 2011 05:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.445
X-Spam-Level:
X-Spam-Status: No, score=-8.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_HI=-8]
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 M7EYTLarYyEH for <rtcweb@ietfa.amsl.com>; Tue, 11 Oct 2011 05:05:28 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id AFE0821F851F for <rtcweb@ietf.org>; Tue, 11 Oct 2011 05:05:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=6883; q=dns/txt; s=iport; t=1318334727; x=1319544327; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=0neOKqUQ2k/T3pxSYR2kcmE9Np24xEG6OBEcf6dWp20=; b=kbAm+9/QSYdu/7Ys7X9WWROosuAZPhvBMStksZqfBZ38y+S21KHAiqey B42MDziC0zelNi/oZRh1URB5uKNFG5v5xsEB505iXHQBMmdVA5CUUON+/ khDL6pAQHHL1hYY2+Qn1h4LEYIFguz2Od+W52j9JCIf0HAsMG992QcGSh o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnkAAI8wlE5Io8UR/2dsb2JhbABDmQSPIoEFgVMBAQEEAQEBCQYBChM+FwICAgEIEQEDAQELBhcBBgEaDB8DBggBAQQBCggIEweHY5plAZ5QAwKGaWEEh08ukSmMKQ
X-IronPort-AV: E=Sophos;i="4.68,523,1312156800"; d="scan'208";a="57554604"
Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 11 Oct 2011 12:05:25 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9BC5NaP017193; Tue, 11 Oct 2011 12:05:24 GMT
Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 17:35:14 +0530
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 11 Oct 2011 17:35:07 +0530
Message-ID: <1D062974A4845E4D8A343C6538049202068FED61@XMB-BGL-414.cisco.com>
In-Reply-To: <4E935A8B.8020700@alvestrand.no>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion)
Thread-Index: AcyHjkLROLg5C5rpSKevWSMpyvuZJwAYOygA
References: <4E8B192E.80809@ericsson.com><E6AA070839B987489960B202AD80E18D019D9119@ftrdmel0.rd.francetelecom.fr> <4E935A8B.8020700@alvestrand.no>
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: "Harald Alvestrand" <harald@alvestrand.no>, <rtcweb@ietf.org>
X-OriginalArrivalTime: 11 Oct 2011 12:05:14.0613 (UTC) FILETIME=[08D70250:01CC880E]
Subject: Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: 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: Tue, 11 Oct 2011 12:05:29 -0000

|> - Assuming B receives these packets, it then sends 
|> via the signalling channel an information from the 
|> media path unknown from S (i.e. not accessible via JS).

A requirement hidden here is that B shouldn't alert the user till the entire consent verification is complete (otherwise B would have to buffer the media coming from the user). If B is a PSTN gateway this isn't going to be trivial to implement.

If we go down this path, I think we would end up reinventing ICE/ICE-Lite in a different form (which doesn't look worth the effort), so we should just make use of ICE.

Muthu

|-----Original Message-----
|From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
|Sent: Tuesday, October 11, 2011 2:20 AM
|To: rtcweb@ietf.org
|Subject: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion)
|
|Changing the subject to keep threads separate....
|
|On 10/09/2011 12:00 PM, sebastien.cubaud@orange.com wrote:
|> Hi there,
|>
|> Re Magnus's call for proposal (If anyone can find a solution that fulfill
|>   the security goals and have improved legacy interoperability people would
|> be interested in that solution. So far RTCP has been discarded as insufficient.)
|> on media consent verification, here is below a suggestion for the group:
|>
|> Basically, the idea, compared to Hadriel's RTCP proposal, relies on the use
|> of the signalling path instead of RTCP as a feedback channel for media
|> consent verification.
|>
|> Here are the steps I foresee before allowing the establishment of a media session:
|>
|> - Let's consider A (a RTC-Web compliant browser) connected to server S and
|> wishing to share real-time media with destination B (potentially a SIP
|> endpoint or a browser)
|> - A&  B learn via the signalling channel the triple @IP, transport proto and
|> associated listening port of the remote media
|> - A sends a few RTP packets to B (3 as in RFC 2833/4733 or more?).- This would
|>   allow the mechanism to resist against packet loss -. The format of such packets
|>   are to be discussed
|> - Assuming B receives these packets, it then sends via the signalling channel
|> an information from the media path unknown from S (i.e. not accessible via JS).
|> I propose to use the min of the sequence number of the RTP packets received
|> (which is random per RFC 3550)
|The sequence number is a 16-bit number, so there are 16 bits of
|randomness to play with here.
|An attack based on just returning a random number will succeed 1 out of
|65.536 times; if any of the 3 packets' sequence numbers are acceptable,
|it will succeed 1 out of 21.845 times.
|
|A browser can reasonably limit the number of attempts per second (either
|overall or per-script); multiple browsers will not be able to coordinate
|on any such limit.
|
|Is this defense strong enough to warrant considering this further?
|
|> - A receives via S this info granting B's consent to receiving media from A
|> - A now can start sending media to B
|>
|> When B uses SIP as its signalling channel, Step 4 would probably require a
|> SDP extension to convey this info, as well as possibly extended H.248/Diameter
|>   informations would be required in a decoupled sig./media architecture.
|> Of course, a solution avoiding extensions would be more than welcome.
|>
|> The benefit of this mechanism largely relies on the assumption that the
|> transmission of information from the media termination of the destination
|> to its associated signalling channel is less costly than implementing ICE connectivity
|> checks. Which is still to be checked.
|>
|> This mechanism provides basic media consent verification and if it turns out
|> that it provides less security properties than ICE or other drawbacks (e.g.
|> increasing media session establishment delay, issues with the few initial RTP
|> packets,..), it could be seen as a fallback media consent verification
|> when ICE is not implemented at each end of media terminations.
|>
|> Looking forward to hearing feedbacks from the group on this.
|>
|> Cheers
|> Sebastien
|>
|> -----Message d'origine-----
|> De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part de Magnus Westerlund
|> Envoyé : mardi 4 octobre 2011 16:33
|> À : rtcweb@ietf.org
|> Objet : [rtcweb] Summary of ICE discussion
|>
|> WG,
|>
|> I have bellow tired to summarize the result of the ICE discussion. This
|> is intended as furthering this discussion and form a basis for going
|> forward in the consensus process. I do expect people that disagree with
|> my summary of the discussion to speak up.
|>
|> Major requirements
|>
|> - Need for data transmission consent for protocols using UDP as the
|> traffic receiver needs to consent to receiving the data
|>
|> - Perform NAT and FW traversal when ever needed
|>
|> - Support IPv4 to IPv6 transition
|>
|> Desired behavior:
|>
|> - Be interoperable with deployed legacy systems as SIP Trunk, PSTN
|> gateways, VoIP phones.
|>
|> WG chairs conclusion of discussion so far:
|>
|> - ICE is so far the only solution that provides the security goals and
|> have any legacy deployment.
|>
|> - ICE usage will require that STUN connectivity MUST have succeeded
|> prior to any data transmission to fulfill security goals.
|>
|>    * The Browser will enforce this requirement to prevent being an attack
|> vector in all cases.
|>
|> - If anyone can find a solution that fulfill the security goals and have
|> improved legacy interoperability people would be interested in that
|> solution. So far RTCP has been discarded as insufficient.
|>
|> - Media Gateway can support a reduced functionality set from Full ICE
|>
|> Cheers
|>
|> Magnus Westerlund
|> as WG chair
|>
|> ----------------------------------------------------------------------
|> 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
|> ----------------------------------------------------------------------
|>
|> _______________________________________________
|> rtcweb mailing list
|> rtcweb@ietf.org
|> https://www.ietf.org/mailman/listinfo/rtcweb
|> _______________________________________________
|> rtcweb mailing list
|> rtcweb@ietf.org
|> https://www.ietf.org/mailman/listinfo/rtcweb
|>
|
|_______________________________________________
|rtcweb mailing list
|rtcweb@ietf.org
|https://www.ietf.org/mailman/listinfo/rtcweb