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

From: <[email-masked]>
Date: Mon, 23 Sep 2013 12:15:20 +0000

Hi Andy,

Hutton, Andrew [mailto:[email-masked]] 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

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 23 Sep 2013 14:35:52 +0200

> 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…
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

---

From: <[email-masked]>
Date: Mon, 23 Sep 2013 12:39:07 +0000

Hi,

Yes, with WS handshake you can also indicate the subprotocol.

Markus

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Sergio Garcia Murillo
Sent: 23 September, 2013 15:36
To: [email-masked]
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, [email-masked]<mailto:[email-masked]> escribió:

Hi Andy,

draft.

enforced when needed.

Like..

     GET / HTTP/1.1

     Upgrade: websocket

     Connection: Upgrade

     Sec-WebSocket-Protocol: turn

;)

Best regards
Sergio

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 24 Sep 2013 17:38:51 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Sergio Garcia Murillo
Sent: 23 September 2013 13:36
To: [email-masked]
Subject: Re: [pntaw] Indicating that the TLS connection is for PeerConnection? (RE: New version of draft-hutton-rtcweb-nat-firewall-considerations)

Hi Andy,

draft.

enforced when needed.

Like..

     GET / HTTP/1.1

     Upgrade: websocket

     Connection: Upgrade

;)

Best regards
Sergio