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

Eric Rescorla <ekr@rtfm.com> Mon, 10 October 2011 23:04 UTC

Return-Path: <ekr@rtfm.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 6F8E321F8B43 for <rtcweb@ietfa.amsl.com>; Mon, 10 Oct 2011 16:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.823
X-Spam-Level:
X-Spam-Status: No, score=-100.823 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1, 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 frkuUZ9Ty0Wl for <rtcweb@ietfa.amsl.com>; Mon, 10 Oct 2011 16:04:58 -0700 (PDT)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6309A21F8B3A for <rtcweb@ietf.org>; Mon, 10 Oct 2011 16:04:58 -0700 (PDT)
Received: by wwn22 with SMTP id 22so4293675wwn.1 for <rtcweb@ietf.org>; Mon, 10 Oct 2011 16:04:56 -0700 (PDT)
Received: by 10.227.27.165 with SMTP id i37mr6629353wbc.106.1318287896058; Mon, 10 Oct 2011 16:04:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.227.196.83 with HTTP; Mon, 10 Oct 2011 16:04:16 -0700 (PDT)
In-Reply-To: <4E935A8B.8020700@alvestrand.no>
References: <4E8B192E.80809@ericsson.com> <E6AA070839B987489960B202AD80E18D019D9119@ftrdmel0.rd.francetelecom.fr> <4E935A8B.8020700@alvestrand.no>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 10 Oct 2011 16:04:16 -0700
Message-ID: <CABcZeBNd0wnAv3KHkzCa4g6tFmGJhADOQDCz-7G=DYwp1yOGzA@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
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: Mon, 10 Oct 2011 23:04:59 -0000

On Mon, Oct 10, 2011 at 1:50 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
> 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?

IMO, this is far too little entropy.

It's also unclear to me why this is significantly easier than just
doing ICE Lite.

-Ekr

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