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

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:

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