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

[Dan Wing <[e-mail]>]

On Sep 25, 2013, at 10:27 AM, Melinda Shore <[e-mail]> 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.

-d