Re: [pntaw] TURN over websockets or just TURN.

[Oleg Moskalenko <[e-mail]>]

Andy, you are not mentioning the case when no explicit web proxy is
configured. See below:

On Wed, Sep 25, 2013 at 11:19 AM, Hutton, Andrew <
[e-mail]> wrote:

>
> >
> > That overhead is relatively minor.
>
> [AndyH] But it is still something that we would be better without unless
> it serves a good purpose.
>

it provides benefits when no explicit web proxy is configured in the
enterprise network.


>
> >
> >
> > The purpose of the extra HTTP handshake to upgrade to HTTP to a
> > websockets connection is to allow an HTTP Server to use the same port
> > for both HTTP and the websockets protocol.
> >
> > No, in this particular case the purpose is to use HTTP protocol as a
> > tunnel for TURN protocol.
> >
>
> [AndyH] Not really the proposal is to encapsulate TURN within a websockets
> connection not HTTP.
>

I meant just that. From the firewall perspective it will be HTTP.


>
>
> >
> >  However I don't think this is necessary for WebRTC media connections
> > as it is very unlikely that a web server will want to handle WebRTC
> > media/TURN at all never mind on the HTTP port as the media.
> >
> > I do not understand how a web server jumped into the picture. The
> > proposal has nothing to do with the web servers.
> >
>
> [AndyH] Exactly the media handling has nothing to do with the web server
> but websockets uses HTTP upgrade mechanism because it was designed to allow
> the web server to use the same port for HTTP and websockets (See
> http://tools.ietf.org/html/rfc6455#section-1.3). This mechanism is not
> needed in WebRTC because the web server and TURN server are not the same
> server.
>

Web servers and TURN servers are not the same - a good observation. They
use different IP addresses. And both are allowed to use port 80, 443 or
8080 or whatever.

The analogy is media over TCP. TCP was not designed as a suitable for media
protocol. It is inferior to UDP and any media channel over TCP is
artificial and totally against the TCP original intentions and TCP design.

According to your logic, TCP has unnecessary (for media) overhead over UDP
So, if we are all technological purists here, we must immediately ban any
media over TCP and remove that from WebRTC specs. But we discovered that in
some cases TCP is necessary because there is no other way to deliver the
data. This is a compromise.

This is totally the same with websockets. It was designed for a different
purpose. But while technology progresses, it uses the available tools and
gadgets to move ahead. We found that websockets is helpful in extending
WebRTC connectivity. Pretty much the same as earlier it was found that
media over TCP is sometimes required (and accepted).

So, if we do not accept TURN inside Websockets then we must start an
immediate campaign against media inside TURN TCP connections and through it
out of WebRTC specs. These things are totally symmetrical in all senses,
and they serve the same purpose - the connectivity purpose, and they have
the same problems.


> >
> > So does encapsulating the TURN data in websocket frames provide any
> > benefit.
> >
> > It provides a benefit of encapsulating TURN protocol into HTTP protocol
> > that is usually easily understandable and "parseable" by the firewalls.
> > The firewall can examine the subprotocol header and make a decision.
> >
>
> [AndyH] The subprotocol is nice but I assume the firewall only sees this
> if the websockets connection is not encrypted it seems to me that it might
> be better to have something like the subprotocol indicating TURN in the
> HTTP CONNECT making it clear to the proxy the purpose of the connection
> encrypted or not.
>

Again, sometimes we have to HTTP CONNECT when explicit proxy is not present.


>
> > I can imagine that there might be some scenarios in which using a
> > websockets connection might work when TURN might not simply because the
> > media is buried in further layers of encapsulation. However I don't
> > know if this is really the case and also we are of course not trying to
> > hide the fact that this is media.
> >
> > There are scenarios when difference between HTTP and TURN is as simple
> > as "connectivity" vs "no connectivity". That's rather important.
> >
>
> [AndyH] Can you explain in what scenarios TURN over Websockets would work
> and TURN/TCP with HTTP Connect would not?
>

When explicit proxy is not configured.


>
>
> >
> > The extra websockets overhead for all the media packets is surely a
> > drawback of this approach.
> >
> > When no packets can be passed through, then the network overhead is
> > exactly 0 (zero) but we do not consider it as a great scenario.
> >
>
> [AndyH] I am not sure I understand your point here. If there are no
> significant advantage to using the websockets encapsulation and I have not
> heard one yet, then the overhead is again something we could do without.
>
>
when explicit proxy is not configured


>
> >
> > Not encapsulating the TURN in websockets would also probably provide
> > better control for those wanting to assert policies on the handling of
> > media.
> >
> > DPI of the TURN packets is a hard task, especially considering that the
> > IP addresses in the TURN packets are obfuscated. On the other hand, we
> > may require some headers in the websocket connection to contain
> > information about the protocol, so it may be more firewall-friendly and
> > "examinable", without serious investment into new DPI algorithms.
> >
>
> [AndyH] I don't think we should discuss DPI it should simply be out of
> scope.
>
>
OK


> >
> > Therefore as you can see I don't see the benefit of encapsulating TURN
> > in websockets but I look forward to hearing other opinions and maybe I
> > have missed something important.
> >
> >
> > I hope I provide an opinion.
>
> [AndyH] You have but I am not yet convinced of the benefit I think we need
> concrete examples of why a websockets approach would be more successful
> than just TURN/TCP using HTTP CONNECT.
>
>
See above

Regards,
Oleg