Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary ofICE discussion)
<sebastien.cubaud@orange.com> Tue, 11 October 2011 12:57 UTC
Return-Path: <sebastien.cubaud@orange.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 EA04E21F8CD9 for <rtcweb@ietfa.amsl.com>; Tue, 11 Oct 2011 05:57:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.38
X-Spam-Level:
X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, FRT_BELOW2=2.154, HELO_EQ_FR=0.35]
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 uujhQRd55M7t for <rtcweb@ietfa.amsl.com>; Tue, 11 Oct 2011 05:57:13 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id AE9E621F8C00 for <rtcweb@ietf.org>; Tue, 11 Oct 2011 05:57:12 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 02AE44010B; Tue, 11 Oct 2011 14:49:05 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id B56C5340128; Tue, 11 Oct 2011 14:44:58 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 14:44:58 +0200
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 14:44:57 +0200
Message-ID: <E6AA070839B987489960B202AD80E18D01A179EE@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <1D062974A4845E4D8A343C6538049202068FED61@XMB-BGL-414.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary ofICE discussion)
Thread-Index: AcyHjkLROLg5C5rpSKevWSMpyvuZJwAYOygAAAgRaIA=
References: <4E8B192E.80809@ericsson.com><E6AA070839B987489960B202AD80E18D019D9119@ftrdmel0.rd.francetelecom.fr><4E935A8B.8020700@alvestrand.no> <1D062974A4845E4D8A343C6538049202068FED61@XMB-BGL-414.cisco.com>
From: sebastien.cubaud@orange.com
To: mperumal@cisco.com, harald@alvestrand.no, rtcweb@ietf.org
X-OriginalArrivalTime: 11 Oct 2011 12:44:58.0847 (UTC) FILETIME=[95F43EF0:01CC8813]
Subject: Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary ofICE 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:57:14 -0000
Hi Muthu, |>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). I am not sure to follow your concern here: alerting the user would look to me as associated to the first signalling step in which B provides its @IP, transport port, listening port. For instance, as in your example, if B is a PSTN gateway, assuming SIP is the protocol used by the GW to interoperate with RTC-Web, the PSTN gateway may send a IAM message upon reception on the initial SIP INVITE. And this IAM would trigger the alerting of the user (and should alerting the user be a concern, SIP preconditions could be used to prevent it until a precondition being that A has received media consent verification from B be satisfied). If you mean that the initial "testing" RTP packets could be rendered to the user, this is what I meant as "the format [of the initial RTP packets] are to be discussed" in my initial mail. I guess there are possible ways to make those RTP flows transparent to the end user (e.g. having them discarded by a standard RTP implementations, containing white noise, etc..). Prior to discussing these details, I guess the main point is to determine whether an extension to SIP, as minimal as it can be, is a viable option for SIP endpoints interfacing with RTC-Web compared to ICE connectivity checks procedure. Kind regards, Sebastien -----Message d'origine----- De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] De la part de Muthu Arul Mozhi Perumal (mperumal) Envoyé : mardi 11 octobre 2011 14:05 À : Harald Alvestrand; rtcweb@ietf.org Objet : Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re: Summary ofICE discussion) |> - 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 _______________________________________________ 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