Re: [rtcweb] HTTP Fallback draft

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/07/2012 12:54 PM, Lorenzo Miniero wrote:
> Hi Iñaki,
> 
> 
> On Tue, 7 Aug 2012 21:34:09 +0200 Iñaki Baz Castillo <[e-mail]>
> wrote:
> 
>> Hi Lorenzo, sorry for opening another thread about this (I didn't check
>> my unread emails before reading the draft). Please see comments inline:
>> 
> 
> 
> No harm done, don't worry!
> 
> 
>> 
>>> Hannes Tschofenig <[e-mail]> wrote:
>> 
>>>> Just to be clear, I don't have objections regarding your draft. I
>>>> just would like to understand what motives people to run everything
>>>> over HTTP (besides using HTTP features, which you don't really do).
>> 
>> Honestly I don't like the "all-over-http" vision. Admins filtering 
>> traffic other than HTTP or HTTPS will also do their best efforts for 
>> filtering specific traffic over HTTP, and IMHO making specifications to
>> run protocolos over HTTP legitimizes those hateful filtering techniques.
>> 
> 
> 
> I'm not a fan either, believe me :)
> 
> That said, as I said in another post I still think that, if RTCWEB/WebRTC
> is going to be deployed in browsers, they'll expect it to work in all the
> places where all other web applications do. Many proprietary protocols that
> do real-time communication implement tunneling somehow, or pretend to do
> so, which means something in line with that is needed for RTCWEB as well.
> 
> 
>> 
>> 
>> 
>> 
>> 2012/8/7 Lorenzo Miniero <[e-mail]>:
>> 
>>> I agree with you and I'm not really dying to do RTP over HTTP either,
>>> but if some scenarios make it impossible for use cases to work (and
>>> some firewall/NAT deployers are to blame here, probably) then a
>>> fallback mechanism is something that can be nice to have, especially if
>>> we're interested in something that "just works".
>> 
>> That's the problem (IMHO): if we make all to work over HTTP then some day
>> telcos providers will just offer HTTP (as "Internet") and we'll need to
>> study a new OSI model in which the lowest layer is called "HTTP".
>> 
> 
> 
> Which is close enough to the hourglass draft Hannes mentioned in his post,
> I'm afraid. I can't but agree with you, but, again, if we have use cases
> and we want to have them working in as many topologies as possible,
> something must be done.
> 
> 
>> BTW: I sitll don't understand which is the advantage of using RTP over 
>> HTTPS in comparison to TURN over TLS:443. Does is exist?
>> 
> 
> 
> If we talk about a simple comparison, I'm sure TURN:TLS:443 performs much
> better than RTP over HTTPS, or at least, over the simple approach I
> documented in the draft at least (even though I tried to keep the overhead
> as little as possible). Comparing them is probably not fair, though, as
> they address two different scenarios: that's why HTTP would be just a
> fallback, and not something you'd use when you have alternatives.
> 
> Referring to the steps I described in my previous answer to Hannes,
> TURN:TLS:443 is probably the most useful option for scenarios 1 and 2, that
> is, where you can just pipe what you want on port 443 and be sure it will
> be ignored by the proxy. If the proxy checks what's going on, though, that
> may not be as easy. The proxy may be acting as a MITM for HTTPS, as Roman
> described, or just doing some traffic monitoring with anomaly detection or
> something like that: faking to be HTTPS is not going to work in that case,
> since the proxy may just see it's not HTTP at all, or may just understand
> it's not what it claims to be because it doesn't behave as it should; HTTP
> connections have a usually quite simple pattern (e.g., much more traffic
> going in one direction than the other and never at the same time),
> something that would be very different in a TURN connection instead.
> 

I think that this problem should be looked from another point of view.  One of
the basic assumption of ICE is that a TURN address is always added with the
lowest priority to the gathered candidate addresses, because it guarantees
that ICE will always works.  Now we all now that this assumption is not true
in 100% of the cases, and this is the reason why years ago I added a TURN over
HTTP(S) transport in the product I was developing at the time and worked on an
I-D (never published).  So instead of seeing TURN over Websocket as a way to
work in difficult environments, we can just see it as a way to fulfill the
promise of ICE, which is to find a path in 100% of the cases, by adding TURN
over UDP then TURN over TCP/TLS, then TURN over Websockets as the lowest
priority in the gathered candidate addresses (that will probably require a
modification in RFC 5245, as it already recommends a priority of 0 for TURN
over UDP).

After Taipei I restarted working on this idea, but using Websocket this time.
 I gave up when I discovered that there was no Websocket dissector in
Wireshark, but now that this issue seems to be fixed, perhaps it is a good
idea to finish this work.

- -- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJQIYpfAAoJECnERZXWan7EWv0QAK3VY6SzGdzyNCj1PeyMTVb7
UtAbaLWowhpnTYcMsX21qfU5wpH5r9hukJF9hLAxHEe3pYfo6LQaX3Hy18G/kjVo
xt7yLmmCvfzV3opbXIoMRiOjLEVLdtLAQLnAEBHwWlP7S32FNCGo45MXu7pg752T
6mWxqyujQJPHSsHZh6b3ayLnjaH2yP6d+hhiuIynta1XuWdsvzi5CBVFB5iLTeKA
bAgknMU5O6+j4aJHagNeyybUA/BGmcbday7UomSyJsvEvkcZ1OnFRA6IFU/s+pCp
y6f4NrVcJfkL0DC2P1Tu24hd1HcajBFrnn7CPe6x5qZinw0GH0m537QQJG4iqKcr
NVdwYvDTl3kJISS/L15jGIat9QLelNqq2ZWmoXIZ/D6NXN4SzlGp91tLCSdiJPtH
ODgt8UOdPXuYEDso7uN/LatCRrdc0cSEDFcx+6ipptgaL3nFlrbArXsAnlVdCDo0
a17XiFvpj3NQXXfmYWcJeFvlyh0M8O00+rnjxl1srze+2GR/zZpF9chVxjq8AfVC
y3e7n4AyZhtu1B3byYte92abOHgsTW4VQtJrREeTHi3cW5yAGusjfk3XTpQ31YhU
FP7t8XARaKI2GOyiUOESbmK1JkCYs8VpdvrM81yVbrRB0DuvUa84caFohAm/VhRm
2pgS8vEHgeO4wXmhGGbq
=Ckmc
-----END PGP SIGNATURE-----