Re: [rtcweb] Summary of ICE discussion

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 04 October 2011 16:44 UTC

Return-Path: <bernard_aboba@hotmail.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 6001A21F8BEE for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 09:44:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.196
X-Spam-Level:
X-Spam-Status: No, score=-101.196 tagged_above=-999 required=5 tests=[AWL=-0.752, BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, 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 05m0-36cv8BC for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 09:44:02 -0700 (PDT)
Received: from blu0-omc3-s4.blu0.hotmail.com (blu0-omc3-s4.blu0.hotmail.com [65.55.116.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8C39421F8BF3 for <rtcweb@ietf.org>; Tue, 4 Oct 2011 09:44:02 -0700 (PDT)
Received: from BLU152-W23 ([65.55.116.74]) by blu0-omc3-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Oct 2011 09:47:08 -0700
Message-ID: <BLU152-W2342F5823933FA1F2B9F9C93FB0@phx.gbl>
Content-Type: multipart/alternative; boundary="_22edb0fd-c8a1-4564-9286-bee206ebf313_"
X-Originating-IP: [98.237.179.165]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Date: Tue, 04 Oct 2011 09:47:07 -0700
Importance: Normal
In-Reply-To: <BLU152-W139AA2913C1CFFDB50726193FB0@phx.gbl>
References: <4E8B192E.80809@ericsson.com>, , <CALiegfmnxO+BrfycOmL=hptBFdcEpsLeBn=zsJTX=ivKBBumWw@mail.gmail.com>, <BLU152-W139AA2913C1CFFDB50726193FB0@phx.gbl>
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Oct 2011 16:47:08.0271 (UTC) FILETIME=[414627F0:01CC82B5]
Cc: rtcweb@ietf.org
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: Tue, 04 Oct 2011 16:44:03 -0000

In particular, I'm concerned about vulnerabilities created by multiplexing
audio and video on the same port.  When that is done, the ICE procedure loses
some of its DoS prevention properties.

From: bernard_aboba@hotmail.com
To: magnus.westerlund@ericsson.com
Date: Tue, 4 Oct 2011 09:28:34 -0700
CC: rtcweb@ietf.org
Subject: Re: [rtcweb] Summary of ICE discussion








I think this is a good summary of where we are with respect to ICE, and
since there are no good alternatives on the table, it seems reasonable to
move on to the next step. 

IMHO, this would involve a more detailed analysis of the threats and what
needs to be done to resolve them. 

In particular, the statement "STUN Connectivity Check MUST have succeeded" is 
necessary but not sufficient.   We need to get into a discussion of the specific
conditions under which media can be sent, and what attacks are still
possible.  For example, there exist public STUN servers on the Internet, and 
RTCWEB should not permit the browser to execute a DoS attack on these servers. 
Also, it would be desirable to prevent a browser from sending much more
bandwidth than the receiver has consented to;  however, because signaling
is largely opaque to the browser, it is not obvious (at least to me) how to 
prevent this. 

> 2011/10/4 Magnus Westerlund <magnus.westerlund@ericsson.com>:
> 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

 		 	   		  

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb