Re: [rtcweb] Please require user consent for data channels

Simon Perreault <sperreault@jive.com> Sat, 18 July 2015 20:59 UTC

Return-Path: <sperreault@jive.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A576D1A1AAD for <rtcweb@ietfa.amsl.com>; Sat, 18 Jul 2015 13:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level:
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOkJsSje6VRF for <rtcweb@ietfa.amsl.com>; Sat, 18 Jul 2015 13:59:28 -0700 (PDT)
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549CD1A1A6F for <rtcweb@ietf.org>; Sat, 18 Jul 2015 13:59:28 -0700 (PDT)
Received: by iehx8 with SMTP id x8so16396734ieh.3 for <rtcweb@ietf.org>; Sat, 18 Jul 2015 13:59:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZmYlMoAHxNnBGrNFDOGDXH0MNXPUuA1maI4SIaNuDLs=; b=CvRcR4ROA9sqfDktmgVOFtPufQGCLoazp44YgBw8zTC93uVFEuZ81TjJnd1JyRyPqs eNR0p0pP1/MU0KD23OEYMIoMmXX6VAQZGO+hjfVL/76gTANeZmKyIWtL3qua/FcWiKmY fxuwwCAIscb1rb4o/7WQa4Gp06CZzHXDZFkDnNvj/cBnpQMy1yfxPQE7kxegSw2Q9PdU 5rOQxqWxKn00O/FTXcDQk1TZekcJrxa6jqb40FbVwSMXV2gdtc4tmIXRS8/m7EGK3wSk El/vocABUKuQuSK7RFHldxB7eveuixs9uQLrBZkHu+xDkefj0N8qDzGVqBQDRvfJZ6oP CJ9A==
X-Gm-Message-State: ALoCoQl1n5jMucGfx6qBVMA6RqTv3kZPtT/GhPZtQnY3Orh3ueSynKNUxxnXleGhGQ9OuwAMFVnq
X-Received: by 10.107.15.18 with SMTP id x18mr29676875ioi.167.1437253167704; Sat, 18 Jul 2015 13:59:27 -0700 (PDT)
Received: from Simons-MacBook-Air.local ([206.47.252.21]) by smtp.googlemail.com with ESMTPSA id p82sm5659941ioi.14.2015.07.18.13.59.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jul 2015 13:59:26 -0700 (PDT)
Message-ID: <55AABE28.8070105@jive.com>
Date: Sat, 18 Jul 2015 16:59:20 -0400
From: Simon Perreault <sperreault@jive.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Iñaki Baz Castillo <ibc@aliax.net>, Roman Shpount <roman@telurix.com>
References: <CA+65OspMD_PVjk0BXh7t4LtjmFDcDatoeNjFQOO_OVtC-Br+OA@mail.gmail.com> <CAOJ7v-24VCW6kkn7LOLkqZzhYEU0r=nmd_F7Zns1rnyqKN6xAg@mail.gmail.com> <55A95364.2070806@gmail.com> <CAOJ7v-3t9BQabR2e4EHs4G0Sec4sU9DFC2aiSXXYrat+an+RYg@mail.gmail.com> <55A96DA3.1040907@gmail.com> <CAOJ7v-1ui7349NzK6NZNRHPbnHWZajctk4cDgMKqRZSv47EYdA@mail.gmail.com> <55A9860D.8030903@gmail.com> <CAOJ7v-3LGd32rnpFVW_U0s3+iVaJXsL4vt_YAo=cyp6YyOArdw@mail.gmail.com> <CALiegfmiS18Jux-kCgOhTKKiyGtMertj6xCegpFrox5NOf9EJg@mail.gmail.com> <CABkgnnW0Tmjqz823vKiF84_u6HasBJC7ERMYCO2HL_NPj5saTA@mail.gmail.com> <CALiegfkpbLy1QXxr-RRF0oOpVv1sWsFeab=vvC4iT4DnPtjKQw@mail.gmail.com> <CABkgnnVWcuhX2NjZgx87L+Uo6df6rEBWW73cxbaX3mu_VfHmCA@mail.gmail.com> <CALiegfkQWAn-jMrjhcDPA3rtowOPVk-S8z3c-jvjpNmjtf=3hA@mail.gmail.com> <CABkgnnWERM4oxozNCSvRf1o0Wm-d9Bjw=9B+xh_NJ+h6GfBJ6Q@mail.gmail.com> <CAD5OKxt-DZCGFECv2UYH8g0fD6EAk39cdpWD-CsN_ED6L4hfKg@mail.gmail.com> <CALiegf=zM54gNjgj65VYV5H3tS-iV5Kg0PrBeF7svYRYZ-JLPw@mail.gmail.com>
In-Reply-To: <CALiegf=zM54gNjgj65VYV5H3tS-iV5Kg0PrBeF7svYRYZ-JLPw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/PKW2r2N4USbpYNtT4eh4jVOCD0M>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Please require user consent for data channels
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 18 Jul 2015 20:59:29 -0000

Le 2015-07-18 06:01, Iñaki Baz Castillo a écrit :
> 2015-07-18 11:38 GMT+02:00 Roman Shpount <roman@telurix.com>:
>> Sending data to a particular destination over an interface that is not
>> supposed to be used based on the local routing is definitely something that
>> goes against the local policy and should be discouraged. For instance on a
>> mobile device, not being able to reach a particular STUN/TURN server over
>> WiFi, should not give the browser an automatic permission to send media over
>> cell data interface and generate a huge bill for the customer. Forcibly
>> overwriting default route is something that should need user consent. I
>> understand that we want the call to succeed in as many cases as possible,
>> but blindly assuming that the local routing policy exists for no reason
>> whatsoever is somewhat dangerous.
> 
> +1

-1

Justin and Martin are right.

This is a concept that was explained during the ICE tutorial that was
presented at IETF 92.

Imagine the following multihomed host with three interfaces:

- Wi-fi interface with default route.
- Wired interface with default route.
- VPN interface with default route.

Which one should you use to talk to the STUN/TURN server? If you bind to
0.0.0.0 then the kernel *will* pick one, but only because it *has to.
All three interfaces are equivalent: they all have a default route and
can a priori be used to talk to the server.

Being multihomed means multiple interfaces with a default route. There's
no "going against the local policy" in this case when sending packets on
any interface.

The point is that in this case, all three interfaces can potentially
yield different server-reflexive candidates, which is why they must be
gathered separately. As for relayed candidates, they also need to be
gathered separately because some interfaces may be faster for talking to
the TURN server and it is useful to compare the candidates gathered on
all 3 interfaces. Also nothing guarantees that you're allowed to reach
the server server on any interface that has a default route, so you need
to try them all.

Simon