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

Melinda Shore <melinda.shore@gmail.com> Wed, 25 September 2013 17:27 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 8581E21F9950 for <pntaw@ietfa.amsl.com>; Wed, 25 Sep 2013 10:27: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=[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 e-dob2M1sJbH for <pntaw@ietfa.amsl.com>; Wed, 25 Sep 2013 10:27:15 -0700 (PDT)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1692711E80F3 for <pntaw@ietf.org>; Wed, 25 Sep 2013 10:27:15 -0700 (PDT)
Received: by mail-pa0-f43.google.com with SMTP id hz1so128670pad.30 for <pntaw@ietf.org>; Wed, 25 Sep 2013 10:27: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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=A/+AgF1VAHMluA8P1gWt1wo+6lcHwQA2DGOJvf5VA90=; b=zNfFeCf8HofGI/A9kMQa0NhD1KsWpS2S1i+r7I1essXBZ2WkoiBN7ynOpxzCFzOsP8 +P5uC6+OgWAilOcnUYqfnJ4nf/BFMLox5akp9KZJZIuXnE6qJJlphyf9IhqmCP4RL0k+ VHGSfIPGx7wR1q8RzAaVv2I0W51JHvSPN9qCWKRSkhnR5xI/lIv3Y0qXqN4/onQvvDwR 6Ie3+XbiwNBXIZJGXHI7HUA7BpFjyJplDJZOq+fc09ETzlodcuuFmp+l/bo2t0bUCGnv i5m+YU+6RJgtaWT1EC+3VQAVRBzUnJCQEELO4EFO989nkYoD10N1/X9xe3/wnKswigh+ rQTA==
X-Received: by 10.68.136.7 with SMTP id pw7mr34229106pbb.106.1380130034751; Wed, 25 Sep 2013 10:27: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 k4sm48981667pbd.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Sep 2013 10:27:13 -0700 (PDT)
Message-ID: <52431CEF.40101@gmail.com>
Date: Wed, 25 Sep 2013 09:27: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: pntaw@ietf.org
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>
In-Reply-To: <5242D393.4070500@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 17:27:15 -0000

On 9/25/13 4:14 AM, Harald Alvestrand wrote:
> I'm not sure authentication helps here - once you've sent off a request
> to the evil server, you've opened the hole. It would even be good for
> the evil server to give a correct answer, since that increases the
> chances that the hole would remain open - you'll be using it.

Authentication doesn't help - there needs to be some trusted
party to the transaction who can vouch for the legitimacy of
the request.  It's a lot easier with VoIP, as you've generally
got some sort of call control server mediating the transaction
and that terminates (and reoriginates) signaling requests,
so they know what's going on.

> But - all those packets will end up at the WebRTC client. And that had
> *better* be hardened against outsiders anyway, because that hole *is*
> going to be open.

That's a broader firewall issue, I think, regardless of
whether or not <whatever> is being used to open firewall
pinholes.  But basically I see two issues here:

1) that an attacker can subvert the technology to
open firewall pinholes, and
2) undermining the ability of the firewall to enforce local
policy by giving users the ability to punch holes in
contravention of that policy

>From an operational standpoint the second is the more serious
issue, I think.  Most of the arguments I've heard against that
being an issue have been ideological in nature.  That's not
necessarily a bad thing and I actually agree that firewalls
are harmful to network architecture, that they're largely
responsible for crunchy-on-the-outside-soft-on-the-inside
mindsets on the parts of network and security admins (and
corporate auditors), etc., but I think in the real world we
need to acknowledge that they're out there and are perceived
has having value by the people who deploy them, and giving
users the ability to scoot around firewall policy is
problematic.

Melinda