Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling

Nils Ohlmeier <nohlmeier@mozilla.com> Mon, 16 April 2018 22:24 UTC

Return-Path: <nohlmeier@mozilla.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 B5A35129C51 for <rtcweb@ietfa.amsl.com>; Mon, 16 Apr 2018 15:24:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=mozilla.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 aGcNYaT0aXqd for <rtcweb@ietfa.amsl.com>; Mon, 16 Apr 2018 15:24:37 -0700 (PDT)
Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (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 26DBD129C6B for <rtcweb@ietf.org>; Mon, 16 Apr 2018 15:24:37 -0700 (PDT)
Received: by mail-pl0-x22e.google.com with SMTP id bj1-v6so10816127plb.8 for <rtcweb@ietf.org>; Mon, 16 Apr 2018 15:24:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=F588ZyYFdAuMLjJa5MYxHuatGEAXtaEWekIshncOv6E=; b=MmLB/t5rPcV9ZnScWwBD5mSopR65u1cOsELEFoGKYLP+hjBE4clqL/5OdgwFil5Dch cLqFy3d/VNn8ESpDmuXN9cO+V90xRi6WXc4Pa0KUQH5UcXQXrMVHNhn2T38R1zXZCc+h w4fq59G7WEGbKMrGNoUXygqNmZ4FVQw+98Q2I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=F588ZyYFdAuMLjJa5MYxHuatGEAXtaEWekIshncOv6E=; b=QJ9hFae0zxGgARTw4mHaquQPXxVmnISt+TO8SijQDOVwnTwjd1V/Geqfu4dFU/Dwul P8rmmXZf4AysTzHFgFBC0ePfBYTJ0O7olEatJx5jvSrXYwGE1o7bgLRa84c/B5VeDtCY 8/T5epm+ZpWFjj0zkiYYfW7uTNTmID7dLpXZcdlIiwLte3tB/T0gzMZ9Tb5jhU0FEtl0 5iswMpgYxKWXBhBSLDVwy/DAFcFwA2WHUB0EqCuU15JOd+gkw3HGK+4457wqwZhNXEcq KS5b/ZIE73DLmqOctEVkyjvIRqUEDwWkHJDq7u4RreU98svJoxu6GXfI9Uc9As/HYXzs GfQg==
X-Gm-Message-State: ALQs6tB/UypsJk7qfVVVGxq58YBL9oZidJJZ/wnhTpbOjhvxvwx3a14t 6N8hwY62fn2stJWAuNvH6WnSCXmRfK4=
X-Google-Smtp-Source: AIpwx4+JWHhG1aABRYiYdhgxlLvGdYKl9nNlfp7W05TgQnMeKYdfLzHgpEaHH+WVu0NkOeqfBX8HcA==
X-Received: by 2002:a17:902:b58e:: with SMTP id a14-v6mr17313346pls.175.1523917476463; Mon, 16 Apr 2018 15:24:36 -0700 (PDT)
Received: from ?IPv6:2601:647:4600:3f31:f852:23b2:93cc:d900? ([2601:647:4600:3f31:f852:23b2:93cc:d900]) by smtp.gmail.com with ESMTPSA id b65sm36852129pfl.145.2018.04.16.15.24.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Apr 2018 15:24:34 -0700 (PDT)
From: Nils Ohlmeier <nohlmeier@mozilla.com>
Message-Id: <F9EB7388-9E76-43E0-8C9B-61D3E50357F7@mozilla.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_481FD60F-799F-4832-9A0D-D423E0FE9E9E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Mon, 16 Apr 2018 15:24:33 -0700
In-Reply-To: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com>
Cc: RTCWeb IETF <rtcweb@ietf.org>
To: Sean Turner <sean@sn3rd.com>
References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/sPUVPTI8-pe_quI7AdRi--72cdY>
Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 16 Apr 2018 22:24:40 -0000

> On Mar 7, 2018, at 11:49, Sean Turner <sean@sn3rd.com> wrote:
> This is the WGLC for the "WebRTC IP Address Handling Requirements” draft available @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/.  Please review the draft and send your comments to this list by 2359UTC on 30 March 30 2017.

I apologize for bringing this up so late, but it looks to me like we should consider phrasing the words for Mode 4 in this draft more precisely.

As shown here https://bugs.chromium.org/p/chromium/issues/detail?id=767304 <https://bugs.chromium.org/p/chromium/issues/detail?id=767304> and here https://bugzilla.mozilla.org/show_bug.cgi?id=1452713 <https://bugzilla.mozilla.org/show_bug.cgi?id=1452713> implementers are somewhat confused what to do if Mode 4 is chosen, but no HTTP proxy is configured.

At a minimum I would suggest to insert “HTTP” before each of the occurrences of the word proxy in the description:

Mode 4:  Force proxy: This forces all WebRTC media traffic through a
            proxy, if one is configured.  If the proxy does not support
            UDP (as is the case for all HTTP and most SOCKS [RFC1928 <https://tools.ietf.org/html/rfc1928>]
            proxies), or the WebRTC implementation does not support UDP
            proxying, the use of UDP will be disabled, and TCP will be
            used to send and receive media through the proxy.  Use of
            TCP will result in reduced quality, in addition to any
            performance considerations associated with sending all
            WebRTC media through the proxy server.
Because apparently some people think of proxies and TURN relays being the same thing. Which I don’t think is/was the intention here.

Second of all I think the draft would benefit from explaining what to do expect in Mode 4 in the absence of a HTTP proxy.

And lastly I think the discussions in the above bug reports have brought up the point that TURN relays might not be trustworthy either.
I’m assuming it’s only a matter of time until when some evil actors will provide fake TURN implementations to gather the browsers routable IP from the TURN layer.
Therefore I think it would make a lot more sense to specify two different modes:
- Mode 4: Relay only: only TURN relay candidates are gathered.
- Mode 5: HTTP proxy only: all WebRTC media traffic is forced through a HTTP proxy.
                If no HTTP proxy is configured no candidates are gathered.
I realize that the process might have gotten already to far to follow this suggestion.

Best regards
  Nils Ohlmeier