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

[<[e-mail]>]

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.

Markus