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

Melinda Shore <melinda.shore@gmail.com> Tue, 24 September 2013 17:37 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 B7A6B21F9E99 for <pntaw@ietfa.amsl.com>; Tue, 24 Sep 2013 10:37:53 -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=[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 o8X0L1ifpPKn for <pntaw@ietfa.amsl.com>; Tue, 24 Sep 2013 10:37:52 -0700 (PDT)
Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8E58511E8146 for <pntaw@ietf.org>; Tue, 24 Sep 2013 10:37:50 -0700 (PDT)
Received: by mail-pd0-f179.google.com with SMTP id v10so4875470pde.24 for <pntaw@ietf.org>; Tue, 24 Sep 2013 10:37:50 -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=ankFM2MDgZuimXN/lwEcntCewWEyMZmay3bw6o0cN38=; b=Ckm/05uaQbFOzlijQXOiBOzmyK+fv9H4eeCDiddye8Q6m2c16gB5LqlscFpYfIg5sQ 1nYeYa8sJU9MbWOJOG5N5kaHlQ8ofBCg7Jqtngr3eMJ/bpTM0IOYDUk4jJvj6WpDWbT/ jsr1Hf6UsrB6WGuxwJsyMhEXVNpiBlQp7NHvyS2SN1tQyYlGmu6ofm3W4ggW6sS2ff5+ 3DswrujsyDv/tlfC1+74Cngu9WCTyZlh+k+7NiS796X6Me3bW73oVYmW1twPXXDtm4oG 6/K6qEKgdFjzGldO2nVeIbjBuv7FN8Fzz8TuC8w0LehUQOGEzqsSCYyDUj2F/MSBifzu TZqA==
X-Received: by 10.66.121.131 with SMTP id lk3mr29461585pab.61.1380044270296; Tue, 24 Sep 2013 10:37:50 -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 sb9sm42290944pbb.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 10:37:49 -0700 (PDT)
Message-ID: <5241CDEA.1060306@gmail.com>
Date: Tue, 24 Sep 2013 09:37:46 -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: "Tirumaleswar Reddy (tireddy)" <tireddy@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> <913383AAA69FF945B8F946018B75898A1907E091@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A1907E091@xmb-rcd-x10.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "pntaw@ietf.org" <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: Tue, 24 Sep 2013 17:37:53 -0000

On 9/24/13 9:11 AM, Tirumaleswar Reddy (tireddy) wrote:
> Agreed. The firewall problem is solved by the technique proposed in
> draft http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-01.
> This draft describes the mechanism for firewalls to only permit UDP
> media session associated with specific WebRTC servers. This addresses
> the firewall problem in Enterprise network without having to do DPI
> on WebRTC signaling protocol.

There's a lot of history here.  pcp was preceded by midcom,
which did the same thing but failed to get any uptake at all
other than briefly appearing in Asterisk.  There were two
reasons for midcom's failure: 1) it used SNMPv3 for transport,
which everybody hated, and 2) it required a forklift network
upgrade.  You wouldn't be able to buy a VoIP system that
used it without also upgrading all your firewalls.

Midcom was standardized in the transport area and it seems
unlikely to me that pcp would have been chartered if they'd
gone back to the transport area, or if the ADs who'd run
the transport area at the time midcom was in business were
still in office.  When pcp was in charter discussions I asked
Jari, who was internet AD at the time, why he thought this
would succeed where midcom had failed and he really didn't
have an answer for that other than his personal optimism.

I worked for Cisco during this and what I heard from product
managers was that they had no interest in undermining the
value in their inspection technology by allowing entities
outside the firewall (including other Cisco devices - this
is one of the prices of corporate Balkanization) to make
decisions about what traffic should be permitted.  Unless
that situation has changed you're likely to encounter the
same resistance.  That said, that said, the popularity of
unilateral hole-punching technologies, that do not consult
the firewall, might be the right argument for something like
midcom or pcp.  But if I were a betting person I would not
bet on firewalls supporting  pcp hitting the market any
time soon (and to be clear, I think that's unfortunate
because I do think that's the better solution to the hole
punching and NAT mapping installation problem, even if it
was already standardized about a decade ago).

In the future there may be a better solution still based
on something like VNF.

But there's a long history here, as I said, and there may or
may not be something to learn from it.

Melinda