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

Randell Jesup <randell-ietf@jesup.org> Tue, 11 October 2011 04:26 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 8B8F921F8C26 for <rtcweb@ietfa.amsl.com>; Mon, 10 Oct 2011 21:26:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 wAeKC8+fkn+G for <rtcweb@ietfa.amsl.com>; Mon, 10 Oct 2011 21:26:19 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0351221F8C1A for <rtcweb@ietf.org>; Mon, 10 Oct 2011 21:26:18 -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 1RDTv0-0002Ep-9W for rtcweb@ietf.org; Mon, 10 Oct 2011 23:26:18 -0500
Message-ID: <4E93C46B.1000902@jesup.org>
Date: Tue, 11 Oct 2011 00:22:03 -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> <E6AA070839B987489960B202AD80E18D019D9119@ftrdmel0.rd.francetelecom.fr> <4E935A8B.8020700@alvestrand.no> <CABcZeBNd0wnAv3KHkzCa4g6tFmGJhADOQDCz-7G=DYwp1yOGzA@mail.gmail.com> <4E9389C0.5050607@jesup.org> <4E93B43C.3060106@jdrosen.net>
In-Reply-To: <4E93B43C.3060106@jdrosen.net>
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] 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: Tue, 11 Oct 2011 04:26:19 -0000

On 10/10/2011 11:13 PM, Jonathan Rosenberg wrote:
> Security issues aside, the proposed solution does not work with existing
> SIP/RTP implementations. The main drawback of the ICE solution is that
> it won't work with deployed equipment. I see little benefit in
> specifying another solution which does not fix the main limitation we
> have with ICE.

The only thing I've come up with that can work with existing equipment 
is a variant of CORS.

Basically, if the destination doesn't respond to ICE (or more likely the 
app tells you it won't) you do a CORS-style 'preflight' check to the 
same IP address.  If you're told "I'm an RTP gateway that accepts 
non-ICE traffic" with a valid handshake from the signalling (ala an ICE 
check), then traffic can flow/continue flowing (you may want to allow it 
to start before the check is complete, with a limited time/data until 
verification is required to continue).

In practice, this could be implemented by redirecting HTTP/HTTPS traffic 
to the gateway's IP to an internal webserver that would respond.  This 
allows layering onto existing gateways permission for a webrtc/rtcweb 
client to send to them, without modifying the gateway itself.

Downsides: More complex.  Assumes the gateway can either run a (dummy) 
webserver, at least enough to redirect, or it's behind a firewall that 
can port-forward traffic.

An advantage, if the gateway is willing to risk DoS attempts, is that 
the gateway could indicate a max age for the CORS-type check, and so 
indicate that for future calls to that address the browser doesn't have 
to check.  This is optional, though, and just saves checks (and if 
pre-check-complete data sending isn't allowed, then it may save setup 
time as well, except on the first call to a particular gateway).


Is it workable?  I think so.  Is it worthwhile?  I don't know.  I'm 
somewhat skeptical since it solves only a subset of the problem space 
(for connecting to legacy devices/gateways).

-- 
Randell Jesup
randell-ietf@jesup.org