Re: [rtcweb] Summary of ICE discussion

Bernard Aboba <> Tue, 04 October 2011 16:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2149E21F8DE6 for <>; Tue, 4 Oct 2011 09:25:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.338
X-Spam-Status: No, score=-101.338 tagged_above=-999 required=5 tests=[AWL=-0.894, BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i+RzS0S0qPs1 for <>; Tue, 4 Oct 2011 09:25:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7AAF321F8DE5 for <>; Tue, 4 Oct 2011 09:25:29 -0700 (PDT)
Received: from BLU152-W13 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Oct 2011 09:28:34 -0700
Message-ID: <BLU152-W139AA2913C1CFFDB50726193FB0@phx.gbl>
Content-Type: multipart/alternative; boundary="_e9b4e328-0b7e-448d-a368-01bc48755880_"
X-Originating-IP: []
From: Bernard Aboba <>
To: Magnus Westerlund <>
Date: Tue, 4 Oct 2011 09:28:34 -0700
Importance: Normal
In-Reply-To: <>
References: <>, <>
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Oct 2011 16:28:34.0995 (UTC) FILETIME=[A9B5B830:01CC82B2]
Subject: Re: [rtcweb] Summary of ICE discussion
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Oct 2011 16:25:32 -0000

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