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

["Hutton, Andrew" <[e-mail]>]

Below.

> -----Original Message-----
> From: Oleg Moskalenko [mailto:[e-mail]]
> Sent: 25 September 2013 19:40
> To: Hutton, Andrew
> Cc: [e-mail]
> Subject: Re: [pntaw] TURN over websockets or just TURN.
> 
> Andy, you are not mentioning the case when no explicit web proxy is
> configured. See below:

[AndyH] True I was considering that as the simple case and of course there is no HTTP CONNECT in that scenario. So are you saying that when there is no proxy then a websockets connection is more likely to work than a TURN/TCP or TURN/TLS connection. I would be interested in whether there is evidence of that I am not sure whether it is true or not certainly in the encrypted case I don't see how this can be but I am not an expert on this.  


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

[AndyH] Sorry I don't get this argument at all the question is simply whether the websockets overhead is worthwhile or not.



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