Re: [rtcweb] Summary of ICE discussion

Randell Jesup <randell-ietf@jesup.org> Tue, 04 October 2011 15:06 UTC

Return-Path: <randell-ietf@jesup.org>
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 EC41A21F8C50 for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 08:06:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.57
X-Spam-Level:
X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599]
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 DhfKzPy0kYnz for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 08:06:24 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 694DE21F8BBD for <rtcweb@ietf.org>; Tue, 4 Oct 2011 08:06:24 -0700 (PDT)
Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1RB6cb-00014r-DB for rtcweb@ietf.org; Tue, 04 Oct 2011 10:09:29 -0500
Message-ID: <4E8B20BA.3080906@jesup.org>
Date: Tue, 04 Oct 2011 11:05:30 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E8B192E.80809@ericsson.com>
In-Reply-To: <4E8B192E.80809@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
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 15:06:25 -0000

On 10/4/2011 10:33 AM, Magnus Westerlund wrote:
> 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.

I've been discussing some options on this with Cullen on the side.  No 
breakthroughs yet, though there may still be some hope.  If there's 
something there I'll post it soon, otherwise assume it didn't pan out.

One observation about the security/attack-vector side of this:  Any 
objection that includes "if an attacker is in a MITM position they could 
trick the rtcweb client into sending media" is an invalid objection.  A 
MITM attacker could inject or re-route any amount of traffic they wanted 
already if they're in the media path.  I'll also note that an attacker 
could be in MITM on the signalling side or DNS, but not MITM on the 
media/ICE routing; those are valid cases to consider.  And DNS poisoning 
doesn't require MITM.


-- 
Randell Jesup
randell-ietf@jesup.org