Re: [rtcweb] Summary of ICE discussion

Harald Alvestrand <harald@alvestrand.no> Wed, 05 October 2011 12:04 UTC

Return-Path: <harald@alvestrand.no>
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 9E86921F8C8D for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 05:04:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.338
X-Spam-Level:
X-Spam-Status: No, score=-108.338 tagged_above=-999 required=5 tests=[AWL=2.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Y1a5-wjViKVw for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 05:03:59 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A1BDD21F8C45 for <rtcweb@ietf.org>; Wed, 5 Oct 2011 05:03:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ADB7939E0A7 for <rtcweb@ietf.org>; Wed, 5 Oct 2011 14:07:06 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSpLnqeDaBzM for <rtcweb@ietf.org>; Wed, 5 Oct 2011 14:07:06 +0200 (CEST)
Received: from [172.16.41.139] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 2743D39E048 for <rtcweb@ietf.org>; Wed, 5 Oct 2011 14:07:06 +0200 (CEST)
Message-ID: <4E8C4868.8060509@alvestrand.no>
Date: Wed, 05 Oct 2011 14:07:04 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E8B192E.80809@ericsson.com> <4E8B20BA.3080906@jesup.org>
In-Reply-To: <4E8B20BA.3080906@jesup.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Wed, 05 Oct 2011 12:04:00 -0000

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

Concur that the first form of the objection is invalid without further 
description ... I would note that any proposed solution that allows the 
attacker to be MITM on the path for verification of 
acceptance-to-receive (such as a hypothetical RTCP-based mechanism where 
mechanisms exist to let RTCP use IP addresses completely independent of 
the RTP path) would make the MITM objection valid.

(ouch. That was a convoluted sentence. Parse leniently!)
>
>