Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations

Oleg Moskalenko <mom040267@gmail.com> Mon, 23 September 2013 06:41 UTC

Return-Path: <mom040267@gmail.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEE821F9E14 for <pntaw@ietfa.amsl.com>; Sun, 22 Sep 2013 23:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.566
X-Spam-Level:
X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[AWL=-0.982, BAYES_20=-0.74, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SUBJECT_FUZZY_TION=0.156]
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 8vOorivewOkv for <pntaw@ietfa.amsl.com>; Sun, 22 Sep 2013 23:41:37 -0700 (PDT)
Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 46C9321F9E13 for <pntaw@ietf.org>; Sun, 22 Sep 2013 23:41:37 -0700 (PDT)
Received: by mail-pb0-f43.google.com with SMTP id md4so2811558pbc.30 for <pntaw@ietf.org>; Sun, 22 Sep 2013 23:41:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tlTfUUEabuA3D4iYpXyAQD5Qj3aMHcn1ZAIL/lMDNnM=; b=m8CFa+ZjoEFeCbTCYagg5EfRim2aY68pxttltKt5CmZDJzpL3Q9RaiaPHYiDaLuPW0 c0AM1ekaXSkqKVW6zdjWczhRCWOZwliHm56VtMxjYWSwwrgK9GB+k9ZeeP29GYBNEEJ6 rDaG3sUkvCP7Y0V0+Erly8zBoxufvcxoD85dEZek2AFmVn/uK6kknyULo8zwuoZzned4 58zOTvW9WIVwnS404SmoK/74+SKiFuuqTe9ws2k7wNgf84sx35U6jbGXxmbI7fJeC5Tq kXQbb0s+S2bm6UFdYs81W4U+yX4mdfTT3nB3fKaHys66zawTdYZ2CvmOoXTugogWE3dz ZVlQ==
MIME-Version: 1.0
X-Received: by 10.68.197.3 with SMTP id iq3mr21952785pbc.113.1379918495950; Sun, 22 Sep 2013 23:41:35 -0700 (PDT)
Received: by 10.68.91.163 with HTTP; Sun, 22 Sep 2013 23:41:35 -0700 (PDT)
In-Reply-To: <523FD5FD.8030601@gmail.com>
References: <9F33F40F6F2CD847824537F3C4E37DDF17BCF3A5@MCHP04MSX.global-ad.net> <523CCD06.3030902@gmail.com> <BLU169-W136A55AC013DA147313576D93220@phx.gbl> <523CD42E.8070102@gmail.com> <BLU169-W82036280852F26ED26283C93230@phx.gbl> <523D4F17.2040202@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17BD01A8@MCHP04MSX.global-ad.net> <CALDtMrL5pT3MfbQufCphEKq0-pXj+JcfwW__wzG3T6wZ=TuWhg@mail.gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17BD08EA@MCHP04MSX.global-ad.net> <CALDtMrLcUrxseyiaPc_0AWJw3HPdaBuAS+xpviT2q=y4zmdNgw@mail.gmail.com> <523FD5FD.8030601@gmail.com>
Date: Sun, 22 Sep 2013 23:41:35 -0700
Message-ID: <CALDtMrK=9D3qXXK6EeWF4RDk26GHPDgkYfQzdJpD33JNK_MeRw@mail.gmail.com>
From: Oleg Moskalenko <mom040267@gmail.com>
To: Melinda Shore <melinda.shore@gmail.com>
Content-Type: multipart/alternative; boundary="e89a8ff1c650c5337404e7074f63"
Cc: "pntaw@ietf.org" <pntaw@ietf.org>
Subject: Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Sep 2013 06:41:37 -0000

On Sun, Sep 22, 2013 at 10:47 PM, Melinda Shore <melinda.shore@gmail.com>wrote:

> but you all seem to want to extend it to allow
> operation across firewalls *which by policy do not permit
> the traffic in question*.  It's probably too late to do much
> about it but I hope that you're having lots of conversations
> with lots of enterprises whose firewalls you're planning on
> forcing your way through, to make sure that they're on board
> with this.
>
>
Melinda, you are assuming that the policies are a precise accurate
instrument that can be used to set the exact network access rules.

They are not. The reality is that the modern state of network policies is
rather behind the real-world requirements.

I suppose that a real solution would be an "enterprise TURN server" that is
located in the DMZ, and that routes all the TURN-related traffic and the IT
department will handle the policies on the TURN server: user database,
quotas, black and white IP lists, etc. The enterprise IT department is
always free to set such a TURN server. That would merge the two worlds,
perfectly. If they do not want to get into TURN server setup, but there is
a requirement for TURN operations, then there are these new draft specs for
"external" TURN servers.

I've been thinking and working on an "enterprise TURN server" for a while
and I think that eventually the companies will start setting them.