Re: [pntaw] Indicating that the TLS connection is for PeerConnection? (RE: New version of draft-hutton-rtcweb-nat-firewall-considerations)

["Hutton, Andrew" <[e-mail]>]

Also the WebRTC client I assume  could make use of the "Referer" header to tell the proxy the URI of the WebRTC application that initiated the connection.

This would apply both to the HTTP Connect and WS approach.

Regards
Andy



From: [e-mail] [mailto:[e-mail]] On Behalf Of Sergio Garcia Murillo
Sent: 23 September 2013 13:36
To: [e-mail]
Subject: Re: [pntaw] Indicating that the TLS connection is for PeerConnection? (RE: New version of draft-hutton-rtcweb-nat-firewall-considerations)

El 23/09/2013 14:15, [e-mail]<mailto:[e-mail]> escribió:

Hi Andy,



Hutton, Andrew [mailto:[e-mail]] wrote:



On: 23 September 2013 10:35 Markus.Isomaki Wrote:



There will be networks and administrators that explicitly want to

restrict WebRTC. I think one part of the WebRTC firewall traversal

"solution" needs to be an explanation HOW they can do it.





I agree with this it is something we need to discuss and elaborate on in the

draft.



The motivation behind the draft is to standardize the browser behavior in a

way that there is a good chance of WebRTC media traversing firewalls by

default but also to make it clear how browsers behave so that policy can be

enforced when needed.





Standardizing the browser behavior already helps. But rather than leaving it as an exercise to the reader, I think it would be better also to explain how an enlightened network admin can either let the WebRTC traffic flow better (e.g. using UDP rather than TCP), or explicitly restrict it.



Traffic identification is clearly a crucial component here. For instance, when the browser does TURN allocation with HTTP CONNECT, could it include an indication that this is for the purposes of RTCPeerConnection to distinguish that from anything else. Like:



CONNECT turn.example.com HTTP/1.1

Connection-Originator: RTCPeerConnection



This may sound like a naïve proposal ("the HTTP evil bit header" ;-), but if we assumed that browser as trusted and standards compliant (huh...), it would not allow Javascript to establish such connections without that indicator. So at least that would be something.



There are those who believe that rather than making traffic more identifiable, we should actually obfuscate it more to make things like mass-surveillance harder. So it's going to hard to find a win-win position.




Like..


     GET / HTTP/1.1

     Host: TURN-ws.example.com

     Upgrade: websocket

     Connection: Upgrade

     Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

     Origin: http://www.example.com

     Sec-WebSocket-Protocol: turn

     Sec-WebSocket-Version: 13

;)

Best regards
Sergio