[rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary of ICE discussion)
Harald Alvestrand <harald@alvestrand.no> Mon, 10 October 2011 20:50 UTC
Return-Path: <harald@alvestrand.no>
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 C49E721F8532 for <rtcweb@ietfa.amsl.com>; Mon, 10 Oct 2011 13:50:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.826
X-Spam-Level:
X-Spam-Status: No, score=-107.826 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_HI=-8, RCVD_IN_SORBS_WEB=0.619, 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 DQ+8JI6BeUn1 for <rtcweb@ietfa.amsl.com>; Mon, 10 Oct 2011 13:50:19 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9ED21F8CE9 for <rtcweb@ietf.org>; Mon, 10 Oct 2011 13:50:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2548739E0F3 for <rtcweb@ietf.org>; Mon, 10 Oct 2011 22:50:17 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5sKdi0X368K for <rtcweb@ietf.org>; Mon, 10 Oct 2011 22:50:16 +0200 (CEST)
Received: from [10.168.111.151] (unknown [91.143.127.70]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C923439E082 for <rtcweb@ietf.org>; Mon, 10 Oct 2011 22:50:15 +0200 (CEST)
Message-ID: <4E935A8B.8020700@alvestrand.no>
Date: Mon, 10 Oct 2011 22:50:19 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E8B192E.80809@ericsson.com> <E6AA070839B987489960B202AD80E18D019D9119@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <E6AA070839B987489960B202AD80E18D019D9119@ftrdmel0.rd.francetelecom.fr>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: [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: Mon, 10 Oct 2011 20:50:19 -0000
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 >
- Re: [rtcweb] Summary of ICE discussion Randell Jesup
- [rtcweb] Summary of ICE discussion Magnus Westerlund
- Re: [rtcweb] Summary of ICE discussion Iñaki Baz Castillo
- Re: [rtcweb] Summary of ICE discussion Randell Jesup
- Re: [rtcweb] Summary of ICE discussion Olle E. Johansson
- Re: [rtcweb] Summary of ICE discussion Eric Rescorla
- Re: [rtcweb] Summary of ICE discussion Cary Bran (cbran)
- Re: [rtcweb] Summary of ICE discussion Hadriel Kaplan
- Re: [rtcweb] Summary of ICE discussion Bernard Aboba
- Re: [rtcweb] Summary of ICE discussion Bernard Aboba
- Re: [rtcweb] Summary of ICE discussion Cullen Jennings
- Re: [rtcweb] Summary of ICE discussion Cullen Jennings
- Re: [rtcweb] Summary of ICE discussion Matthew Kaufman
- Re: [rtcweb] Summary of ICE discussion Matthew Kaufman
- Re: [rtcweb] Summary of ICE discussion Matthew Kaufman
- Re: [rtcweb] Summary of ICE discussion Bernard Aboba
- Re: [rtcweb] Summary of ICE discussion Matthew Kaufman
- Re: [rtcweb] Summary of ICE discussion Ravindran Parthasarathi
- Re: [rtcweb] Summary of ICE discussion Roman Shpount
- Re: [rtcweb] Summary of ICE discussion Magnus Westerlund
- Re: [rtcweb] Summary of ICE discussion Magnus Westerlund
- Re: [rtcweb] Summary of ICE discussion Harald Alvestrand
- Re: [rtcweb] Summary of ICE discussion Harald Alvestrand
- Re: [rtcweb] Summary of ICE discussion Jonathan Lennox
- Re: [rtcweb] Summary of ICE discussion Ravindran Parthasarathi
- Re: [rtcweb] Summary of ICE discussion Bernard Aboba
- Re: [rtcweb] Summary of ICE discussion Harald Alvestrand
- Re: [rtcweb] Summary of ICE discussion Cullen Jennings
- Re: [rtcweb] Summary of ICE discussion Paul Hoffman
- Re: [rtcweb] Summary of ICE discussion sebastien.cubaud
- Re: [rtcweb] Summary of ICE discussion Iñaki Baz Castillo
- [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re… Harald Alvestrand
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… sebastien.cubaud
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Eric Rescorla
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Iñaki Baz Castillo
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Randell Jesup
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Jonathan Rosenberg
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Randell Jesup
- Re: [rtcweb] Summary of ICE discussion sebastien.cubaud
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Iñaki Baz Castillo
- Re: [rtcweb] Summary of ICE discussion Iñaki Baz Castillo
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Tim Panton
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… sebastien.cubaud
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… sebastien.cubaud
- Re: [rtcweb] Summary of ICE discussion sebastien.cubaud