[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
>