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

<Markus.Isomaki@nokia.com> Mon, 23 September 2013 12:47 UTC

Return-Path: <Markus.Isomaki@nokia.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C2121F9DF6 for <pntaw@ietfa.amsl.com>; Mon, 23 Sep 2013 05:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.386
X-Spam-Level:
X-Spam-Status: No, score=-6.386 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSTt5OfOiUzL for <pntaw@ietfa.amsl.com>; Mon, 23 Sep 2013 05:47:08 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E839621F9C12 for <pntaw@ietf.org>; Mon, 23 Sep 2013 05:47:07 -0700 (PDT)
Received: from smtp.mgd.nokia.com ([65.54.30.58]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r8NCd8Ft002121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 23 Sep 2013 15:39:09 +0300
Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.213]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.03.0136.001; Mon, 23 Sep 2013 12:39:07 +0000
From: Markus.Isomaki@nokia.com
To: sergio.garcia.murillo@gmail.com, pntaw@ietf.org
Thread-Topic: [pntaw] Indicating that the TLS connection is for PeerConnection? (RE: New version of draft-hutton-rtcweb-nat-firewall-considerations)
Thread-Index: AQHOuFmdS3enGEyJ7k+cfol1zNYIJZnTQq9Q
Date: Mon, 23 Sep 2013 12:39:07 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB7620A0C0B12@008-AM1MPN1-043.mgdnok.nokia.com>
References: <E44893DD4E290745BB608EB23FDDB7620A0C0ACE@008-AM1MPN1-043.mgdnok.nokia.com> <524035A8.4030003@gmail.com>
In-Reply-To: <524035A8.4030003@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Nokia Internal Use Only; Project=None;
x-titus-version: 3.5.9.3
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IraeuiQL2d/B8zqVB7Lw/+e0Ht90QqrTcQBdNsJxfJgsN8MRWEbOmpyfF8IynA4huWqh0KoKv/jQyxIQjYOqEEwfu68BUUHdBdbaNppu4Z9BTc6F3KWHNFTTaxb059rnntMjYPr6PqfTcc1bMMRtAxKITTn9pdKjK/EMemjPHC8YQvCNsGYScEU/cgHSl1nVpDjdYsjAdSmYta8Bumwm9FTP4V/HWJWOgjAevDqL/ZeCGP4HbNrmvwu/xIcuNVVimYKJrv8B/+9Zv5q4QBtXp0NdulVb3GRVRtrLXK/OAf+33t+RdBDk34t94gj/u4JpSOZF75kJuOu1AjSDc2FjWONy8buWPT7NXgtGD/Cu9yAb
x-originating-ip: [172.21.80.69]
Content-Type: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB7620A0C0B12008AM1MPN1043mg_"
MIME-Version: 1.0
X-Nokia-AV: Clean
Subject: Re: [pntaw] Indicating that the TLS connection is for PeerConnection? (RE: New version of draft-hutton-rtcweb-nat-firewall-considerations)
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Sep 2013 12:47:14 -0000

Hi,

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

Markus

From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf Of ext Sergio Garcia Murillo
Sent: 23 September, 2013 15:36
To: pntaw@ietf.org
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, Markus.Isomaki@nokia.com<mailto:Markus.Isomaki@nokia.com> escribió:

Hi Andy,



Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] 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