Re: [rtcweb] Summary of ICE discussion

<sebastien.cubaud@orange.com> Sun, 09 October 2011 10:00 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 955B121F8B25 for <rtcweb@ietfa.amsl.com>; Sun, 9 Oct 2011 03:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.317
X-Spam-Level: *
X-Spam-Status: No, score=1.317 tagged_above=-999 required=5 tests=[AWL=-1.188, BAYES_50=0.001, 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 nS5hYbK2mMKz for <rtcweb@ietfa.amsl.com>; Sun, 9 Oct 2011 03:00:05 -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 B923621F8B33 for <rtcweb@ietf.org>; Sun, 9 Oct 2011 03:00:04 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D6735FC400A; Sun, 9 Oct 2011 12:00:03 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id C83CAFC4006; Sun, 9 Oct 2011 12:00:03 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 9 Oct 2011 12:00:03 +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: Sun, 9 Oct 2011 12:00:02 +0200
Message-ID: <E6AA070839B987489960B202AD80E18D019D9119@ftrdmel0.rd.francetelecom.fr>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Summary of ICE discussion
Thread-Index: AcyCorfYEOy7oXJvRF2NDEycgSphrQChiXRwAE+CiBAAAD10gAAAeaTA
References: <4E8B192E.80809@ericsson.com>
From: <sebastien.cubaud@orange.com>
To: <magnus.westerlund@ericsson.com>, <rtcweb@ietf.org>
X-OriginalArrivalTime: 09 Oct 2011 10:00:03.0820 (UTC) FILETIME=[373B72C0:01CC866A]
Subject: Re: [rtcweb] 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: Sun, 09 Oct 2011 10:00:05 -0000

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