Re: [tram] TURN over WebSocket

[Sergio Garcia Murillo <[e-mail]>]

Sorry for the late reply, busy week.. :)

Regarding #2 and #3, I agree that it needs to be look further.

Anyway, as I said in a previous email, it should not be a show stopper 
for working on the draft on the TRAM group, even if they are not 
clarified and we can state that TURN over WS provides same connectivity 
level than TURN over TLS + HTTP CONNECT.

Also, regarding 1, I have been thinking about it and it is not only 
about easing the deployment in some constrained scenarios. It would 
provide a much better integration with Web usage than normal TURN.

For example in our service, we have a couple balanced nginx servers 
acting ssl terminator ands reverse proxy for http and ws. So adding 
TURNS over WS to our deployment would be kind of trivial and would allow 
us to keep all our urls under the same domain. (I think that the extra 
delay of having a new intermediary proxy would be neglectable). So we 
could have:

https://www.xxxxx.xx/rest
https://www.xxxxx.xx/html
wss://www.xxxxx.xx/sip
wss://www.xxxxx.xx/turn

Theres huge is a side benefit for that, as all of them shares same 
domain, we can share cookies with authentication tokens and the other 
HTTP headers (like Origin) between the different websockets (sip/turn) 
and rest apis. Note that we had to add an HTTP REST API to the TURN 
server for short time credentials and load balancing and add origin 
header to STUN/TURN messages, to be able to do what is natively 
supported by websockets.

Best regards
Sergio
On 11/12/2014 20:46, Justin Uberti wrote:
> So I see 3 arguments being made here:
> 1) WSS allows the app and TURN server to be the same entity.
> 2) TURN/WSS works where TURN/TLS doesn't, because DPI.
> 3) TURN/WS works where TURN/TLS doesn't, because DPI.
>
> #2 seems very hard to believe; both of these things will try to 
> establish a TLS connection and then run WS or TURN over top. It's not 
> clear to me that DPI will be able to reliably ID TURN packets versus 
> TURN/WS packets when they are encrypted. (Clearly if the DPI is able 
> to intercept the TLS, it's a different story.)
> #3 implies that HTTPS and WSS doesn't work, so not sure how useful 
> that is.
>
> As Brandon says, I agree we need to understand the problem better 
> before deciding whether this has value.
>
>
> On Wed, Dec 3, 2014 at 12:36 PM, Lorenzo Miniero <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Not to mention the fact that even with plain WS instead of WSS you
>     could
>     transport TURNS and keep it secure.
>
>     Lorenzo
>
>
>
>     On Wed, 3 Dec 2014 13:30:21 -0700
>     toadzky <[e-mail] <mailto:[e-mail]>> wrote:
>
>     > As a developer, I would much prefer to do this kind of thing
>     over WSS.
>     > Websockets allow the application to control processing on the
>     packets,
>     > rather than relying on a framework to do. As far as I can tell,
>     > nothing really supports ALPN at all. If I wanted to write a proxy in
>     > Java that only listened on 80 and 443, to do ALPN, Jersey (or
>     > whichever framework I choose) would need to support ALPN and
>     allow me
>     > to register different handlers for different types. That would be
>     > fine if it was a network library (like Netty), but it's an HTTP
>     > framework that would be dealing with other TCP protocols. On top of
>     > that, the websocket solution can be supported quickly and easily
>     with
>     > existing frameworks and infrastructure - no waiting for someone else
>     > to decide to finally support ALPN.
>     >
>     > David
>     >
>     > On Wed, Dec 3, 2014 at 8:57 AM, Brandon Williams <
>     > [e-mail]
>     <mailto:[e-mail]>> wrote:
>     >
>     > > The only thing that makes sense to me to explain the problem you
>     > > describe is that the proxy is splitting the TLS session so that it
>     > > can view the data flow. If such a proxy only supports HTTP (and by
>     > > extension Websockets) for the data flow, then it would make sense
>     > > that TURNS over 443 does not work. The piece I'm missing though is
>     > > how the proxy could be splitting the TLS session in this way
>     > > without you knowing, unless the client is accepting a certificate
>     > > signed by someone else's CA. Nevertheless, if TLS splitting is
>     > > what's happening and the proxy is rejecting data flows that do not
>     > > look like HTTP, I can understand how WSS might resolve the problem
>     > > under conditions where TURNS with ALPN might not.
>     > >
>     > > That having been said, if I'm correct about the source of the
>     > > problem, I'm conflicted about taking up work intended to make a
>     > > proxy like this function for WebRTC. If TLS is being used solely
>     > > for the purpose of firewall traversal, then it's OK to split the
>     > > session. But what if that isn't the case? There are significant
>     > > security implications associated with helping such a system to
>     > > function transparently. I personally would rather see my WebRTC
>     > > sessions fail than accept decryption by an unknown MITM.
>     > >
>     > > Of course, it might be the case that something else is happening
>     > > here and there is no decryption happening on the proxy, which
>     > > returns me to the point that Andrew made ... I think we need to
>     > > better understand the nature of the problem in order to decide
>     > > whether it makes sense to adopt the draft and add a milestone.
>     > >
>     > > --Brandon
>     > >
>     > >
>     > > On 12/03/2014 09:39 AM, Sergio Garcia Murillo wrote:
>     > >
>     > >> Maybe then is me the one I am missing something, can you explain
>     > >> how is ALPN meant to solve the problem if TURNS over 443 is
>     > >> blocked by the proxy?
>     > >>
>     > >> Best regards
>     > >> Sergio
>     > >> On 03/12/2014 15:21, Brandon Williams wrote:
>     > >>
>     > >>> What am I missing? Why would ALPN require changing the wifi
>     > >>> network? I can accept that it may be necessary, but in the
>     > >>> absence of someone explaining why the wifi network needs to
>     care,
>     > >>> it really doesn't make sense to me.
>     > >>>
>     > >>> --Brandon
>     > >>>
>     > >>> On 12/03/2014 04:24 AM, Oleg Moskalenko wrote:
>     > >>>
>     > >>>> That is a good point. A solution must not require changing
>     every
>     > >>>> wifi network in the world. A "pure" ALPN  solution is a great
>     > >>>> way to kill the whole WebRTC idea.
>     > >>>>
>     > >>>> On Wed, Dec 3, 2014 at 1:19 AM, Sergio Garcia Murillo
>     > >>>> <[e-mail]
>     <mailto:[e-mail]>
>     > >>>> <mailto:[e-mail]
>     <mailto:[e-mail]>>> wrote:
>     > >>>>
>     > >>>>      Am I supposed to change every hotel, cafe or airport wifi
>     > >>>> in the world in order to make it work? That's what I mean.
>     > >>>>
>     > >>>>      Don't take me wrong, ALPN seems a good solution, as
>     good as
>     > >>>> ipv6 is for removing NAT, but it is something out my control to
>     > >>>> have it deployed worldwide, so I can't rely on it as a
>     solution.
>     > >>>> From a webrtc point of view we only control the client and the
>     > >>>> turn server,
>     > >>>>      everything in between should be considered hostile.
>     > >>>>
>     > >>>>      Best regards
>     > >>>>      Sergio
>     > >>>>
>     > >>>>
>     > >>>>      On 03/12/2014 1:58, Brandon Williams wrote:
>     > >>>>
>     > >>>>          What part of ALPN is not under your control? If you're
>     > >>>> doing WSS, then you've already got TLS in the picture, so ALPN
>     > >>>> and WSS
>     > >>>>          seem to both solve the server-side multiplexing
>     problem
>     > >>>> from the
>     > >>>>          original problem statement. What part of the problem
>     > >>>> statement does WSS solve that ALPN does not?
>     > >>>>
>     > >>>>          If you're concerned about unencrypted TURN
>     multiplexing
>     > >>>> with unencrypted HTTP on port 80, then I can see WS solving a
>     > >>>> problem
>     > >>>>          that ALPN can't solve.
>     > >>>>
>     > >>>>          --Brandon
>     > >>>>
>     > >>>>          On 12/02/2014 03:26 PM, Sergio Garcia Murillo wrote:
>     > >>>>
>     > >>>>              We control the client and the server, and you are
>     > >>>> asking me to wait
>     > >>>>              until what is not in our control is changed.
>     > >>>> Obviously, not working for me
>     > >>>>
>     > >>>>              BTW, I am talking about real life experiences,
>     when
>     > >>>> WSS works and TURNS
>     > >>>>              over 443 doesn't.
>     > >>>>
>     > >>>>              Best regards
>     > >>>>              Sergio
>     > >>>>
>     > >>>>              On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy)
>     > >>>> wrote:
>     > >>>>
>     > >>>>
>     > >>>>                  why will it not work when ALPN is used ?
>     > >>>>
>     > >>>>                  -Tiru
>     > >>>>
>     > >>>>                  *From:*Sergio Garcia Murillo
>     > >>>>                  [mailto:sergio.garcia.murillo@
>     <mailto:sergio.garcia.murillo@>__gmail.com <http://gmail.com>
>     > >>>>                  <mailto:[e-mail]
>     <mailto:[e-mail]>>] ?
>     > >>>>
>     > >>>>                  *Sent:* Wednesday, December 03, 2014 12:52 AM
>     > >>>>                  *To:* Tirumaleswar Reddy (tireddy)
>     > >>>>                  *Cc:* Jonathan Lennox; [ACME] Victor Pascual
>     > >>>> Avila; Simon Perreault;
>     > >>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>;
>     > >>>> [e-mail]
>     <mailto:[e-mail]>
>     > >>>> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>     > >>>>                  *Subject:* RE: [tram] TURN over WebSocket
>     > >>>>
>     > >>>>
>     > >>>>                  El 02/12/2014 20:04, "Tirumaleswar Reddy
>     > >>>> (tireddy)" <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     > >>>>                  <mailto:[e-mail]
>     <mailto:[e-mail]>
>     > >>>> <mailto:[e-mail] <mailto:[e-mail]>>>>
>     escribió:
>     > >>>>                   >
>     > >>>>                   > From: Simon Perreault
>     > >>>>                   > [mailto:[e-mail]
>     <mailto:[e-mail]>
>     > >>>>                  <mailto:[e-mail]
>     <mailto:[e-mail]>>
>     > >>>>                  <mailto:[e-mail]
>     <mailto:[e-mail]>
>     > >>>> <mailto:[e-mail] <mailto:[e-mail]>>>]
>     > >>>>                   > Sent: Tuesday, December 02, 2014 10:19 PM
>     > >>>>                   >
>     > >>>>                   > To: Tirumaleswar Reddy (tireddy)
>     > >>>>                   > Cc: Jonathan Lennox; Sergio Garcia Murillo;
>     > >>>>                   > Victor
>     > >>>>                  Pascual Avila;
>     > >>>> [e-mail]
>     <mailto:[e-mail]>
>     > >>>> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>     > >>>>
>     <mailto:[e-mail]
>     <mailto:[e-mail]>
>     > >>>> <mailto:[e-mail]
>     <mailto:[e-mail]>>>__;
>     > >>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>     > >>>>                  <mailto:[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
>     > >>>>                   > Subject: Re: [tram] TURN over WebSocket
>     > >>>>                   >
>     > >>>>                   >
>     > >>>>                   >
>     > >>>>                   >
>     > >>>>                   >
>     > >>>>                   > On Tue, Dec 2, 2014 at 9:34 AM,
>     Tirumaleswar
>     > >>>>                   > Reddy
>     > >>>>                  (tireddy)
>     > >>>>                  <[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>     > >>>>                  <mailto:[e-mail]
>     <mailto:[e-mail]>
>     > >>>> <mailto:[e-mail] <mailto:[e-mail]>>>> wrote:
>     > >>>>                   >
>     > >>>>                   > Transparent proxies like firewalls keep
>     > >>>>                   > getting
>     > >>>>                  upgraded frequently
>     > >>>>                  to handle new applications, threats etc. If
>     > >>>> firewall has
>     > >>>>                  a feature to
>     > >>>>                  block WebRTC traffic then by sending traffic
>     > >>>> over WebSocket will not
>     > >>>>                  solve the problem.
>     > >>>>                   >
>     > >>>>                   >
>     > >>>>                   >
>     > >>>>                   > (As a participant...)
>     > >>>>                   >
>     > >>>>                   >
>     > >>>>                   > This has also been discussed before.
>     > >>>> TURN-over-WebSockets is not a
>     > >>>>                  way for applications to circumvent policy.
>     > >>>>                   >
>     > >>>>                   >
>     > >>>>                   >
>     > >>>>                   > The problem is there are networks that are
>     > >>>>                   > set up so
>     > >>>>                  that "the web"
>     > >>>>                  is open, through a transparent proxy.
>     WebRTC is
>     > >>>> part of "the web".
>     > >>>>                  Making TURN fit the mould of "the web" is
>     is not
>     > >>>>                  circumventing policy,
>     > >>>>                  it's making WebRTC work. You should not
>     need to
>     > >>>> update your
>     > >>>>                  proxy/firewall config for WebRTC to just work
>     > >>>> if "the web" already
>     > >>>>                  does work.
>     > >>>>                   >
>     > >>>>                   >
>     > >>>>                   >
>     > >>>>                   > [TR] Okay, so looks like the problem can
>     > >>>>                   > also be
>     > >>>>                  solved by running
>     > >>>>                  TURN over 443 similar to proposals in
>     DPRIVE WG
>     > >>>> to run DNS over 443.
>     > >>>>                   >
>     > >>>>                   >
>     > >>>>
>     > >>>>                  Good try! Unlucky enough, doesn't work.
>     > >>>>
>     > >>>>                  Best regards
>     > >>>>                  Sergio
>     > >>>>
>     > >>>>
>     > >>>>
>     > >>>>
>     > >>>> _________________________________________________
>     > >>>>      tram mailing list
>     > >>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>     > >>>> https://www.ietf.org/mailman/__listinfo/tram
>     > >>>>      <https://www.ietf.org/mailman/listinfo/tram>
>     > >>>>
>     > >>>>
>     > >>>>
>     > >>>
>     > >>
>     > > --
>     > > Brandon Williams; Senior Principal Software Engineer
>     > > Emerging Products Engineering; Akamai Technologies Inc.
>     > >
>     > > _______________________________________________
>     > > tram mailing list
>     > > [e-mail] <mailto:[e-mail]>
>     > > https://www.ietf.org/mailman/listinfo/tram
>     > >
>
>     _______________________________________________
>     tram mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tram
>
>