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

Melinda Shore <melinda.shore@gmail.com> Tue, 24 September 2013 05:02 UTC

Return-Path: <melinda.shore@gmail.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 03B0E11E8103 for <pntaw@ietfa.amsl.com>; Mon, 23 Sep 2013 22:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.443
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7yM-WHmfIJnv for <pntaw@ietfa.amsl.com>; Mon, 23 Sep 2013 22:02:17 -0700 (PDT)
Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0FE11E80D9 for <pntaw@ietf.org>; Mon, 23 Sep 2013 22:02:17 -0700 (PDT)
Received: by mail-pd0-f173.google.com with SMTP id p10so4113596pdj.18 for <pntaw@ietf.org>; Mon, 23 Sep 2013 22:02:17 -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 :content-type:content-transfer-encoding; bh=v3s2PwKUVPTbRKAp+rL4MpYLRxYmGjpk2ejQLD/tmvw=; b=Ujwaf4eC0j5e/uKlQBQEgJBGTDTwnZ7lhukA7fiYr92woM1SxU5NFIcXcZLgOcAJbM hc5b6wg6lo0CnCFphhZqYEf4QA3k9teOgwl1rp+kfUFVgFeP70MbC8gmORdyV7nyBBus 1LrpGAx/phkg3OewJmMDdPMORqgnBbVbjB0Ouzs/khaYvR8X2EAdpBvOE3ZUeaaq9YUc 5Up3pxftP9tRMWALdf6DqxiN3QbMCgFbagmM9DccshxheDZMHSQjUmNs8SPUbkFq1bsp 0S6zP6Q3hLCCMyzCjUI+I9lSLWxRyj9DeArfyFhYEIZtByoPv6N/ehqY0Lsl6lzQ9+0h 58nQ==
X-Received: by with SMTP id ca3mr26065491pbb.20.1379998937199; Mon, 23 Sep 2013 22:02:17 -0700 (PDT)
Received: from spandex.local (63-140-98-62.dynamic.dsl.acsalaska.net. []) by mx.google.com with ESMTPSA id py4sm38009758pbb.33.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 22:02:16 -0700 (PDT)
Message-ID: <52411CD5.1050909@gmail.com>
Date: Mon, 23 Sep 2013 21:02:13 -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" <pntaw@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [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 05:02:18 -0000

I think you really need to be clearer about the distinction
between NAT and firewall, and that firewalls are policy
enforcement devices.  NATs arguably are (address policy)
but to the extent they're deployed as access control
mechanisms that function is incidental to their design.
This matters a lot when you're talking about ICE, since
it was designed as a *NAT* traversal mechanism, not a
firewall traversal mechanism.  There's been a long history
of highly contentious middlebox work in the IETF and
it's probably better to address those questions sooner
rather than later, as I think they're bound to come up.

So, you're extending ICE to firewall traversal, because
... ?

In particular I'd put some text in section 1 addressing
the difference between NATs and firewalls, the policy
enforcement role of firewalls, that it is explicitly
not the intention of this draft to propose a mechanism
for violating local firewall policy, and that you recognize
a need to give the network administrator control over
what does and does not enter their network.  That said,
if they do wish to allow WebRTC traffic, this is how to
do it.  I think that will help fend off irritating questions
from people like, say, me.

I think there's probably a lot more that can be said about
addressing and policy, particularly around authenticity, but
I'm going to save that for after having re-read the WebRTC
documents.  But I'd like to skip ahead to the security
considerations section, because that's really critically
important and can't be left empty (to be honest I'm considering
proposing to my own working group and others that we not
adopt any working group draft that has an empty security
considerations section - it's a big problem).

I think there are two broad classes of security issues here:
1) the security of the mechanism itself, and
2) security in the context of the environment

In this case the two are not cleanly separable, to the
extent that presumably the reason for subverting the
security of a WebRTC traversal mechanism would be to
compromise the firewall (with one prominent exception, which
I'll get to below).

As I mentioned in previous email, you cannot allow the
WebRTC firewall traversal technology to be subverted
to allow "unauthorized" pinholing.  This is kind of a
messy problem, since it can involve port numbers (which
doesn't apply in the creation of real-time media
streams), stateful traffic inspection (which doesn't
work in the presence of encrypted signaling traffic),
and so on.  It *may* be the case that there's an authoritative,
trusted entity somewhere in the application architecture
that can make authoritative statements about what's
allowed, and you could leverage a third-party mechanism
like OAuth if you can live with the added latency.

I can give you a long, long list of reasons I don't like
STUN (and, to a lesser extent, TURN), but prominent among
them is that without some sort of application-layer
authentication it is trivially easy to use it to hijack media
streams.  All you have to do is send a bogus STUN or
TURN response with an address of your choosing, since the
answer is unauthenticated.  Using TCP as the TURN
transport makes an attack more challenging but it doesn't
eliminate it entirely.  In VoIP scenarios, what they typically
do is accept the response but then authenticate the
application traffic, so if they get a bogus response
the media streams can't be established, anyway.
So, either think about how to protect against an insertion
attack, or make it clear that you've got protection
available at the application layer.