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

Dan Wing <> Wed, 25 September 2013 18:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F113521F9A05 for <>; Wed, 25 Sep 2013 11:17:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.582
X-Spam-Status: No, score=-110.582 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YG+4V+3psnFc for <>; Wed, 25 Sep 2013 11:16:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2F9F821F991E for <>; Wed, 25 Sep 2013 11:16:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2507; q=dns/txt; s=iport; t=1380133016; x=1381342616; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=uubJEFaljRLsEf7ZPdf/UXP08LP+OjO3y5YT1ljJ1lU=; b=fn9o14q8ppCLp3fJ+KLBEKkGIR+237jsMDzsyzLPgCN1+yA9S9NuUjDR 0jE7hhFnG6kFH7e6sdL6hU3bkf2bYM0b27xULHa/6b1GpcbtnJaClbxoc isAc7pTg9x6gUaAKJ3/oYkPNQtEYbVpKw4+ONKO+SjdNKUuxikB5Pn0J6 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjIFAGkoQ1KrRDoJ/2dsb2JhbABbgwfBVIEfFnSCJQEBAQMBOj8FCwsSBi4hKA4GE4d0AwkFsjsNiWqMZoI4MweDHYEAA4k4jFuBaYxEhTODRBw
X-IronPort-AV: E=Sophos;i="4.90,979,1371081600"; d="scan'208";a="90600896"
Received: from ([]) by with ESMTP; 25 Sep 2013 18:16:51 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r8PIGoI4018854; Wed, 25 Sep 2013 18:16:50 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Dan Wing <>
In-Reply-To: <>
Date: Wed, 25 Sep 2013 11:17:50 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Melinda Shore <>
X-Mailer: Apple Mail (2.1508)
Subject: Re: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Sep 2013 18:17:06 -0000

On Sep 25, 2013, at 10:27 AM, Melinda Shore <> wrote:

> 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.

"Policy" is a broad word.  Nailing down something more specific would be helpful for the discussion.  

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.  

If that strawman is not quite right, please adjust and build a new straw man.