Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations

[Sergio Garcia Murillo <[e-mail]>]

El 23/09/2013 7:47, Melinda Shore escribió:
> On 9/22/13 9:36 PM, Oleg Moskalenko wrote:
>> Each large enterprise IT has a complex history and complex web of
>> policies. If a new standard provides new capabilities and useful
>> possible scenarios, without imposing strict rules on IT departments,
>> then I guess that would be a right thing.
> I think this is actually a pretty serious problem, but Elvis,
> as they say, has left the building.  The IETF RAI area has
> standardized protocols for avoiding the enforcement of local
> access policies.  The earlier work on STUN and TURN was to
> allow operation across NAT, which is (arguably) not a policy
> mechanism, but you all seem to want to extend it to allow
> operation across firewalls *which by policy do not permit
> the traffic in question*.  It's probably too late to do much
> about it but I hope that you're having lots of conversations
> with lots of enterprises whose firewalls you're planning on
> forcing your way through, to make sure that they're on board
> with this.
>

Hi Melinda,

The fact is that there is already an agreed requirement in WebRTC that 
supports it:

    F37     The browser must be able to send streams and
            data to a peer in the presence of FWs that only
            allows http(s) traffic.


And while we could discuss about it, this would not be the correct 
mailing list to do it.

Given said that, I agree with your view that WebRTC should not force its 
way through
corporate firewalls, punching  open holes and sneaking TURN inside TLS 
to bypass the
enterprise policies.

The TURN over websocket proposal tries to address that issue by playing 
"nice" with
corporate firewalls, by encapsulating the WebRTC media into  legit and 
valid HTTP
traffic.

This will allow IT administrator to allow/block and apply same corporate 
policies to
WebRTC media as they would do with any web content. Without having to 
deploy
any new infrastructure and with the same administrative interfaces as 
they have
today.

Regarding the security section that you mention in a later email, I 
agree with you again
and it is a chapter we would have to address in next versions of the 
draft. Would you
be willing to collaborate in writing it by listing which kind of issues 
would you like to be
covered in there?

Best regards
Sergio