Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates

youenn fablet <youennf@gmail.com> Fri, 14 September 2018 17:45 UTC

Return-Path: <youennf@gmail.com>
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 61E3B130E25 for <rtcweb@ietfa.amsl.com>; Fri, 14 Sep 2018 10:45:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 8X052gho36MP for <rtcweb@ietfa.amsl.com>; Fri, 14 Sep 2018 10:45:04 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 790A8130DFB for <rtcweb@ietf.org>; Fri, 14 Sep 2018 10:45:03 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id j19-v6so8182786ljc.7 for <rtcweb@ietf.org>; Fri, 14 Sep 2018 10:45:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xfMcpq7Ja9nVNG1Do3qKHQq+onmKOA98Ehv0imMgU5s=; b=V+Kc0BlTH5esDUuriDFI6hcT8oEa+EzoduV9dgWzKZrXtSxiPhQYjB1golefNrQwiw p/ZcsEMjBJOOHjI7TE53DI2hNoJXBh2zSOTfk7/xcua3j/D9W4HLTIo/PbjHv/qHdpv5 kdagbIKnzaYK8wHHVbcJfCOt3zlpSBkSG0DafHADw1ICtZ9J/SfWykqXY9/8UMw7NJGE i43H7ian4JNsjVgm0TkrUZ/ESXOmmCFJL5Bg1P7W8vTZX52WqPp4BWGkKLe8+0OyjCVF vyQlCtkKkgHb4HChzOztEzqdTL/qnJG6q8j4ptYkHjvl9xnNfdu+g1ODSGa/Rs5lAYrJ sMOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xfMcpq7Ja9nVNG1Do3qKHQq+onmKOA98Ehv0imMgU5s=; b=kTh4X7lKCRhfivyfXqkyIhMV47/0LzXtg0RLFvdyU3ml0AbX2CWG2YPJzNIyp/kWuh Yo7l4+vN2Y5Cw0kiwIe6ClrP1o6Bsi9n3RbmHp8KwrjXw6+a8ZqSkXtJjNkrro8ssxoU WwNRBb9Q4cbx8IwOArkjnICE7b3sAxLJgbH+Pw+upCt+8+5Zl++o/UPgIC4KVilKJORp ZfxSPuMhkwfuS74Tsjj1Cc9geGMQl3bJvDD4vACuj8q5spK8vDWdS0EdlgT5IqeqlHaJ sHPzoCVD7Jf1opdx0eIiMYSjkZv7KTtOUbiT+7K1c65yI56NHZzfIBhGigWCIOt2TRDt 0bMg==
X-Gm-Message-State: APzg51C3Y2auSvHDl8DtdZjfd0DaIPRUY0zg1EXRtir26iryJsSxtSa0 n/W44nkIp0TICUTG7cOytFUDen0hFftEsPmsD7dGzg==
X-Google-Smtp-Source: ANB0VdabJk2GVou3obcPOTP+bytj02U56Ivu6z3pgRX7IyaPS3oIP+Dp74+hW7qeWw1kwRUUN8aBrWsNGFdg4nROHzw=
X-Received: by 2002:a2e:87cf:: with SMTP id v15-v6mr249626ljj.13.1536947101425; Fri, 14 Sep 2018 10:45:01 -0700 (PDT)
MIME-Version: 1.0
References: <CAOW+2dtkNjzS0DkD37SD=POtC2Nd6Xe=upyjvVoyBnnMw7qwbQ@mail.gmail.com>
In-Reply-To: <CAOW+2dtkNjzS0DkD37SD=POtC2Nd6Xe=upyjvVoyBnnMw7qwbQ@mail.gmail.com>
From: youenn fablet <youennf@gmail.com>
Date: Fri, 14 Sep 2018 10:44:49 -0700
Message-ID: <CANN+akb1S=eJNhSOT-e6R1yn_u20nuZNwDFEK7S90ksJ3wt95A@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000004e6900575d86290"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/xkA8B0rxAPeEvlgd6-FwqvgZMGU>
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 14 Sep 2018 17:45:07 -0000

Thanks for the review Bernard,

Agreed that this proposal does not solve all cases.
But it does so in a number of cases like home/small office scenarios.

In general, I do not think there is a guarantee to successfully connect
without sometimes relying on TURN servers.
This proposal and other solutions should allow reducing the need to use
TURN.

Describing precisely the problematic scenarios is useful as we can find
additional means specific to those scenarios.
For instance, can it be envisioned to deploy STUN servers inside the user
network for the financial applications/branch offices scenarios you are
mentioning?

Le ven. 14 sept. 2018 à 00:10, Bernard Aboba <bernard.aboba@gmail.com> a
écrit :

> While I understand the overall goal of this document,  it strikes me as
> suffering from two major problems:
>
> a. Introduction of backwards compatibility problems and potential
> additional delays due to utilization of name resolution mechanisms in ICE,
> with a corresponding benefit (successful connectivity checks between host
> candidates on the same network) which is only a marginal improvement over
> mode 3 (no host candidates).
>
> b. Over-reliance on permission mechanisms which have already been
> stretched to the breaking point, leaving the potential for collateral
> damage in data channel-only scenarios. Due to limitations in the current
> permissions mechanisms, it is not currently practically impossible to
> distinguish legitimate data channel applications that would obtain
> permissions if there were usable means to do so from illegitimate
> applications attempting to compromise user privacy.
>
> Data-channel only scenarios that would be impacted include those where:
>
> 1. Permissions cannot be obtained (e.g. where there is no microphone or
> camera attached to the device so that getUserMedia will always fail).
>
> 2. Low latency communications is a requirement so that TURN server
> traversal is unacceptable (e.g. in financial applications where there may
> be regulatory requirements relating to allowable delays).
>
> 3. TURN traversal would impose an unacceptable financial cost, such as in
> branch office scenarios where a TURN servers is not provided in each branch
> office, and branch office connectivity may be constrained (still an issue
> for branch offices located on other continents).
>
> Essentially, the problem is that these scenarios may have valid reasons
> why they cannot utilize or do not wish to utilize getUserMedia as a
> permission-granting mechanism.
>
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>