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
- [pntaw] More on draft-hutton-rtcweb-nat-firewall-… Melinda Shore
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Tirumaleswar Reddy (tireddy)
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Simon Perreault
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Tirumaleswar Reddy (tireddy)
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Dan Wing
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Melinda Shore
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Tirumaleswar Reddy (tireddy)
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Melinda Shore
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Harald Alvestrand
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Melinda Shore
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Dan Wing
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Melinda Shore
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Oleg Moskalenko
- Re: [pntaw] More on draft-hutton-rtcweb-nat-firew… Hutton, Andrew