Re: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations

Melinda Shore <melinda.shore@gmail.com> Wed, 25 September 2013 20:15 UTC

Return-Path: <melinda.shore@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 AB86721E8088 for <pntaw@ietfa.amsl.com>; Wed, 25 Sep 2013 13:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.443
X-Spam-Level:
X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 lMW6fTC9pTjl for <pntaw@ietfa.amsl.com>; Wed, 25 Sep 2013 13:15:15 -0700 (PDT)
Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2C84821E8063 for <pntaw@ietf.org>; Wed, 25 Sep 2013 13:15:15 -0700 (PDT)
Received: by mail-pb0-f54.google.com with SMTP id ro12so143854pbb.41 for <pntaw@ietf.org>; Wed, 25 Sep 2013 13:15:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=X5E1gg8H7vy2BIiyiVkKlKQWSj8K4VDKeuJb81pPEDA=; b=opgM1Glu7pmDc//D1iGJ/ledU4ewMlxUiLUBn/KAGgLxwrVtj1kMs/JHoyXldWTFAC gvN4yajVmRxeJYk4ZlSkPyrJUnxadsAOP9TL/u8g2RyGLVPfKmlXt0VqYXm20lvGCqze cTafl56qhuOvBt40hY8bXPflwoXGMpcM54BzpiDItEcRJndvDdXh8UEDRQX3RrVnjL3A 3JzPII/LjlLPGhVZj9GPBX3E7HrTuXiitml6xX8w87M3FlE7lS9pMMahveaSHgp+aL0a vN8DTtM/2xNSg+ZaBD3MXAjyv4KRkP0MwlWhwtqaJHvE42HjuoXYa+mxBQ2kdfwbA2nA s3KQ==
X-Received: by 10.68.224.131 with SMTP id rc3mr3664400pbc.204.1380140114898; Wed, 25 Sep 2013 13:15:14 -0700 (PDT)
Received: from spandex.local (63-140-98-62.dynamic.dsl.acsalaska.net. [63.140.98.62]) by mx.google.com with ESMTPSA id qw8sm34827218pbb.27.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Sep 2013 13:15:14 -0700 (PDT)
Message-ID: <5243444F.6020204@gmail.com>
Date: Wed, 25 Sep 2013 12:15:11 -0800
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Dan Wing <dwing@cisco.com>
References: <52411CD5.1050909@gmail.com> <CALDtMr+O8__AUk9qXm9yz4ePNtV_n=V31oHNQ_a068viV_uZYg@mail.gmail.com> <913383AAA69FF945B8F946018B75898A1907DC09@xmb-rcd-x10.cisco.com> <5241BB6D.2000104@gmail.com> <5242D393.4070500@alvestrand.no> <52431CEF.40101@gmail.com> <25FBF706-368A-4CCC-AEEA-1C4C5B9DC86C@cisco.com>
In-Reply-To: <25FBF706-368A-4CCC-AEEA-1C4C5B9DC86C@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: pntaw@ietf.org
Subject: Re: [pntaw] More on 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: Wed, 25 Sep 2013 20:15:15 -0000

On 9/25/13 10:17 AM, Dan Wing wrote:
> My strawman is:  arbitrary UDP pinholes through the firewall are
> denied, but WebRTC sessions originated by certain domains (or by all
> domains?) are permitted to create UDP pinholes through the firewall.

This is where the IETF really is terribly limited by not having
more participation from people who actually run networks.

The most common case is that all outgoing traffic is permitted
but it's not the only case.  I've seen some networks in which
nearly nothing is allowed that's not proxied, and not just
inside the DOD.  In those environments it's likely that they
wouldn't permit any WebRTC traffic.  But there are networks
access policies in-between maximally strict and maximally lax
and that's the area that needs to be considered, I think.
It seems to me that the primary question is whether or not the
network administrators have the tools to be able to selectively
disallow traffic at their network boundaries.

Melinda