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

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

El 21/09/2013 0:48, Bernard Aboba escribió:
> Sergio said:
>
> "Why are you leaving out of scope the case when the WebRTC service is 
> not deployed by the corporate organization and/or the HTTP proxy has 
> DPI validation? "
>
> [BA ]  My reading of the document is that it is attempting to respect 
> the restrictions set by the firewall administrator.   If UDP and TCP 
> to ports other than 80/443 is denied, and in addition DPI is deployed, 
> then you often will only have a subset of HTTP functionality available 
> to speak to port 80 and maybe a subset of TLS which you can speak 
> to port 443.

I am not against providing firewall administrators with tools for 
applying corporate policies to outbound connections, in fact I am all 
for it. But in my point of view, if the web part of my service is 
allowed by the company policies (either because it is no black listed, 
or it is whitelisted) then the webrtc part should work also.

>
> This can significantly restrict the choices available.  In my 
> experience, customers denying UDP in/out and only allowing TCP 
> destined to selected ports (e.g. 80/443) as well as deploying DPI 
> validation typically will not allow HTTP CONNECT (or even WebSockets).
>
> We are sometimes successful in making TURN allocation requests over 
> TCP to port 80 or over TLS to port 443 in these scenarios, but TURN 
> over TCP/TLS requests to other ports can fail. Similarly, one should 
> not expect TURN over WebSockets to work in these kind of 
> installations; the DPI box probably hasn't been updated to handle 
> WebSockets, or if it was, is configured to prevent WebSocket use.

Most of webrtc services I have seen so far are using websockets for 
signaling already, so if websockets are not supported by the firewall 
you have bigger problem.
Also, if TURN over TLS on port 443 works (i.e. no DPI in place), secure 
websockets works. So in 100% cases that TURN over TLS works, TURN over 
websocket works too. The other way round is not true.

Best regards
Sergio