Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt

Richard Barnes <rlb@ipv.sx> Fri, 24 May 2013 17:52 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589F321F9651 for <behave@ietfa.amsl.com>; Fri, 24 May 2013 10:52:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.247
X-Spam-Level:
X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 6FSNBdw0AJGC for <behave@ietfa.amsl.com>; Fri, 24 May 2013 10:52:52 -0700 (PDT)
Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0B85721F95EC for <behave@ietf.org>; Fri, 24 May 2013 10:52:47 -0700 (PDT)
Received: by mail-oa0-f52.google.com with SMTP id h1so6593056oag.11 for <behave@ietf.org>; Fri, 24 May 2013 10:52:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=4/8ezoRymLgYaW5UV+BFWCV3lwZDPqbB+H8Fp3KiTyo=; b=LacuPAsluAeSYqvYh33VSAW1xHPVF+flmRq6iREeTBrQFQqGX21KrjqswL1VH8w7lo dsKD+gaEyxdxeWkfqvm6CYlCLfbQv8KAhB4OFCqCKcHQd6/drRhZ2ePwyXrBafiLOXfX uCcYV/9UycyHI0UgeIu8Fv/PvPMuHiD8kYlm7nArIh+77qch6+rrlymijzKptW0yR94K VVQ7l6a3ciJ5ZiDZ7FS1oxr6auMndeJKU5k3JMLcMQWN9rw4eLiJaaWHzuNsMm/RpcHX 5tPcapnpw+btjSKntqnx2A7B1x1qttCylldPdzCD8BLnQ4e8u6TC8HwsJ7PTJ56Hkynl y2+Q==
MIME-Version: 1.0
X-Received: by 10.60.42.104 with SMTP id n8mr12735649oel.94.1369417967588; Fri, 24 May 2013 10:52:47 -0700 (PDT)
Received: by 10.60.102.146 with HTTP; Fri, 24 May 2013 10:52:47 -0700 (PDT)
X-Originating-IP: [128.89.254.202]
In-Reply-To: <519F8F13.8020204@acm.org>
References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <BLU169-W4995BC8B88C6AD60F4CA5093A20@phx.gbl> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <519F8F13.8020204@acm.org>
Date: Fri, 24 May 2013 13:52:47 -0400
Message-ID: <CAL02cgR8H2A-Z7fCbboy=Hq6r63hm1KyOe8YP9n8tDnVVb6hVA@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Marc Petit-Huguenin <petithug@acm.org>
Content-Type: multipart/alternative; boundary=089e0149ca5c81ec2204dd7a7752
X-Gm-Message-State: ALoCoQkIXUIkFkH5B3X7QpGpN7Hy5NSyGpKQVGTTL1kbAVVaEZgz3fHsl45jnsE6OsOUOAgPhm6L
X-Mailman-Approved-At: Tue, 28 May 2013 08:38:47 -0700
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, Lorenzo Miniero <lorenzo@meetecho.com>, "behave@ietf.org" <behave@ietf.org>
Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2013 17:52:52 -0000

This is probably about the appropriate point in the thread to drop in a
reference to Firewall Enhancement Protocol, RFC 3093:
<http://tools.ietf.org/html/rfc3093>
FEP has the benefit that you don't even negotiate the connection, since it
tunnels the entire IP datagram, not just the UDP part.
</sarcasm>




On Fri, May 24, 2013 at 12:02 PM, Marc Petit-Huguenin <petithug@acm.org>wrote;wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 05/20/2013 02:15 AM, Lorenzo Miniero wrote:
> > Il giorno Sun, 19 May 2013 23:20:41 -0700 Gustavo García <ggb@tokbox.com
> >
> > ha scritto:
> >
> >> I agree that TURN over websockets doesn't solve much more scenarios than
> >> TURN/TLS.   If trying to fix HTTP Proxy traversal why not doing it over
> >> HTTP that aside of philosophical discussions would be the solution with
> >> better success rate?  Otherwise we will have to continue answering for
> >> another 10 years "why is this app not working if skype does".
> >>
> >> Something like this draft sent some months ago but perhaps for TURN
> >> instead of direct connections:
> >> http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt
> >>
> >
> >
> > When I submitted that draft this summer, I had that exact purpose in
> mind,
> > that is taking care of corner edge cases like restrictive proxies and the
> > like. Of course it was not meant to be a solution, just a way to foster
> > discussion in that direction. In that discussion I also mentioned some
> work
> > we did about this in the past, which in part apparently ended up in
> > draft-hutton-rtcweb-nat-firewall-considerations:
> >
> > http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html
> >
> > At the time most people in the ML thought it was either too useless, too
> > complex or even harmful, considering it could be considered as a "sneaky"
> > way to circumvent rules added by a network administrator, and so
> > unacceptable. Anyway, as I said back then, a solution like this doesn't
> > have to be sneaky, and it could very well be conceived in order to be
> > admin-friendly rather than have a parrot and a wooden leg.
>
> About circumventing rules added by a network administrator, I do think that
> using TURN over Websocket or HTTP is doing in fact the opposite:  It is the
> only way to obey the wish of the network administrator, as long as you
> classify Webrtc is a *web* technology and not as a VoIP technology.
>
> Think about it this way:  An administrator restricting UDP but authorizing
> HTTP is basically saying: All web applications are fine, and Webrtc being a
> Web application, it should just work fine, and should not be a collateral
> damage of restricting UDP.  So TURN over Websocket/HTTP should be a
> mandatory
> part of Webrtc.
>
> Now the administrator should also have access to tools to restrict some
> classes of web applications, and Webrtc should be one of these classes.
>  But
> that should not be done as a side-effect of closing the UDP ports.
>
> - --
> Marc Petit-Huguenin
> Email: marc@petit-huguenin.org
> Blog: http://blog.marc.petit-huguenin.org
> Profile: http://www.linkedin.com/in/petithug
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iQIcBAEBCAAGBQJRn48NAAoJECnERZXWan7Eve4P/3Y1SL2IuHZw6Iqats3ZwXG9
> dRxG5JSWEqKbVBgiPNUvXocMu7MbclAB1PC8K++roBDjayqlL9bh2EGmolyLDMLr
> oloAFLRUmo4Yccj+IkECODbgVowtE9rNl9BudUk4hDk151Z6HLgu8wjAR05aLaM2
> 9PHnAmp4JZt6BlrOytkUj9yHLsSSCPNqZpYSFFbrCEkURQLZTXlPw0BOtRVoBb8a
> zBwDVSaW7IdgOuIwq5kbxaITXXrrezCspMesMucVFfp9f0k1AtR3ARjhPj6wAogv
> WJvtBnJYUDw8fpZplyPmKK8af7jEpfbr5IrkzE5JPrmeCdLElzqb6BSpe+GP6EqH
> 0QSDZe73HqwMso90VAFPitGnTK91qLk7R3c//W3J0GQ6sSwUYrArjx5sO5uS7N9n
> 78YIZXoEYgPMfetkGIMJddSRkJxNjQAyi9kmcWyss8CgvqEnWCZbFlnz8I0Eeh+8
> tOI4nhyJGVsSKAn1uORGvnrOXID8oTOhXfwh2r4yDQRpu8outqZuSeksSEtOgoYe
> Jli9boycKkXCilBDHkf+YhY5bqETvDunFyb+O1NQnpIogQOrxucX8Jr9YyAbRxbw
> xb0qNyMPLpp75jXfgFQ4Cxc+f8Nm7xYG8GKrSKHxiqazo6aOKZ1rxWdv5945iB53
> HJsMG1MkVKRwRBgLsM9S
> =HTew
> -----END PGP SIGNATURE-----
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>