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

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Mon, 23 September 2013 12:35 UTC

Return-Path: <sergio.garcia.murillo@gmail.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 E4BC921F9DFA for <pntaw@ietfa.amsl.com>; Mon, 23 Sep 2013 05:35:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.452
X-Spam-Level:
X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wnqWpXdPCvkS for <pntaw@ietfa.amsl.com>; Mon, 23 Sep 2013 05:35:59 -0700 (PDT)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6E50921F979E for <pntaw@ietf.org>; Mon, 23 Sep 2013 05:35:56 -0700 (PDT)
Received: by mail-we0-f182.google.com with SMTP id q59so3115355wes.27 for <pntaw@ietf.org>; Mon, 23 Sep 2013 05:35:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=rSJu29DNj//lvv2Q/RdMUINWNWODYjefzdKBNX1pPvc=; b=kU1jIxIDsVzuCC6gvKOK2ugDGvnShGtbYNKrOLU8fl4RIJXuGrRfv/i82M4Ojikh0r 1SIwPTHX35rRGXj66kKcuDtHQB2fILIJrTB6AkiW4sg303qmSeaytu53ma3xJUcYZ7Po k5dqP+WCOwmuiwlKd2/9VnJwtRWm4PrNoVChRknW5UqlcqRoP70i7zT2Lpcmxs5perXH wsZ6xAZOrNFojsFnJ1lYEajMGRkhdxbXCRGTH9MMwpDh4TARbPzm2fdaUSVM9OgiOcjy Uq5JaUYb7QYHTcQ4Kf9WsZ4/EA4hfQ3Q539uhsXXO1CMvyoZ4PQBWC/OEyP7FD/avte2 34dw==
X-Received: by 10.180.185.97 with SMTP id fb1mr13477719wic.61.1379939755293; Mon, 23 Sep 2013 05:35:55 -0700 (PDT)
Received: from [192.168.1.45] (54.Red-83-61-124.dynamicIP.rima-tde.net. [83.61.124.54]) by mx.google.com with ESMTPSA id u15sm25043045wib.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 05:35:54 -0700 (PDT)
Message-ID: <524035A8.4030003@gmail.com>
Date: Mon, 23 Sep 2013 14:35:52 +0200
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: pntaw@ietf.org
References: <E44893DD4E290745BB608EB23FDDB7620A0C0ACE@008-AM1MPN1-043.mgdnok.nokia.com>
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620A0C0ACE@008-AM1MPN1-043.mgdnok.nokia.com>
Content-Type: multipart/alternative; boundary="------------090805050501070707070602"
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:36:14 -0000

El 23/09/2013 14:15, 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