Subject: [pntaw] New version of TURN over websockets draft

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 13 Sep 2013 09:41:00 +0200

Hi all

We have been working on a new version of the TURN over Websocket draft 
originally proposed by Xin, which is now available at:

http://www.ietf.org/id/draft-chenxin-behave-turn-websocket-01.txt

We believe that it is very well aligned with the spirit of 
draft-hutton-rtcweb-nat-firewall-considerations and should be considered 
to be endorsed by WebRTC.

Also, in order to address the concerns about the impact on TURN servers 
we will be working in providing a working prototype over the following 
weeks by adding a preliminary support of TURN over websockets into the 
rfc5766-turn-server.

Any kind of feedback would be very welcome.

Best regards
Sergio

---

From: "Yanqiang (Michael)" <[email-masked]>
Date: Fri, 13 Sep 2013 09:29:00 +0000

Hi All,

	I read the revised draft again. For I'm not so familiar with RFC 6455. So just share some of my comments:

1. has an explicit requirement to allow such peers to use some kind of fallback communication in HTTP-only networks, as specified in [I-D.ietf-rtcweb-use-cases-and-requirements](F37).
  Is it better to use 'HTTP(s)-only networks'?

2. the involved WebSocket server have to relay the application data to each other by either UDP, TCP or other existing ways
  Since 3.2 has mentioned the connection between TURN/WebSocket servers could by UDP, TCP or other ways, should the Figure 2 change to 'UDP/TCP/Others' or 'UDP/TCP/...'?

3. The WebSocket messages transmitted over this connection MUST conform to the negotiated WebSocket sub-protocol.
  Should we restrict the 80/443 port only run websocket once the handshake or negotiation finish? Or there are other better ways? I thought other people in NAT network can still use 80 port to explore internet. (maybe I made some mistake here.)

	The 1st time I started to work with Xin about this idea was original from Lorenzo's HTTP fallback proposal and rtcweb requirement F37. We thought HTPP fallback proposal *still* need to work on many new parameters for mechanism suggested (chunked or non-chunked mode). At that time someone had propose several documents about 'over websocket'. So we tried to assume the media stream of webrtc application can traverse the restricted networking via websocket as well. There were several points we thought:

1. What's the usage or motivation of this mechanism? Except the networking restricting area(prisons, hotels, airports) is there any better case?
2. Will it be better or easier to use TURN over WS/WSS than TURN over TCP/TLS? Or it is an alternative choice?
3. Will the combo 'TURN+HTTP(s) Port+WebSocket' works well and easily deploying?

	Are they handled well now?

Thanks,
Michael

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sergio Garcia Murillo
> Sent: Friday, September 13, 2013 3:41 PM
> To: [email-masked]
> Cc: Oleg Moskalenko; Victor Pascual Avila; Lorenzo Miniero; Chenxin (Xin)
> Subject: [pntaw] New version of TURN over websockets draft
> 
> Hi all
> 
> _______________________________________________
> pntaw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pntaw

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 20 Sep 2013 10:54:36 -0700

I read the draft and I have some questions:

After TCP allocation over TURN Websocket, what is the Websocket equivalent of
initiating a new TCP connection (RFC 6062) after sending a ConnectionBind or
receiving a ConnectionAttempt?  Is a new Websocket connection opened and if it
is the case, shouldn't it require a different subprotocol?  Perhaps a better
alternative would be to use multiplexing
(draft-ietf-hybi-websocket-multiplexing) to not have to create multiple
Websocket connections to one TURN server?

See these links for a alternate way of multiplexing data exchanged with
multiple TCP peers over one connection:

http://www.ietf.org/proceedings/74/slides/behave-17.pdf
http://tools.ietf.org/html/draft-petithuguenin-turn-tcp-variant-01

On 09/13/2013 12:41 AM, Sergio Garcia Murillo wrote:
> draft-hutton-rtcweb-nat-firewall-considerations and should be considered to
> be endorsed by WebRTC.
> 
> Also, in order to address the concerns about the impact on TURN servers we
>  will be working in providing a working prototype over the following weeks
>  by adding a preliminary support of TURN over websockets into the 
> rfc5766-turn-server.
> 

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 20 Sep 2013 11:59:15 -0700

On 09/20/2013 11:19 AM, Oleg Moskalenko wrote:
> Thank you Marc for your comments and suggestions.
> 
> RFC 6062 is a relatively seldom used specs, this new draft is directed
> mostly toward extension of RFC 5766 for WebRTC users. They will be using
> TURN in RFC 5766 manner, with a single Websocket connection per Allocation.
> RFC 6062 is a rather exotic use case and it is not used in WebRTC. So I'd
> not complicate this draft with a new subprotocol.

Yes, after sending my email, I realized that it was not necessary.

> 
> In practice, even in the case of a few RFC 6062 users, in most cases a
> TURN allocation is created with a single or a few connections, so there
> will be no significant flood of TCP connections if we will keep a new
> Websocket connection for each new peer.
> 
> I'd suggest to keep it as simple as possible and as close to RFC 5766 and
> RFC 6062 as possible for most practical purposes. This draft originated
> mostly out of WebRTC requirements and as I said before the WebRTC
> allocations will be using a single Websocket connection.
> 
> If there will be a significant demand for RFC 6062-style communications
> with Websockets, then we can consider an extension.
> 
> So, I'd suggest to keep a new Websocket connection for every new peer, for
> RFC 6062 - style communications.

OK so I suggest to say in the draft that a new Websocket connection will be
created for each TCP peer, because that have an impact on implementation design.

> 
> Regards, Oleg
> 
> 
> 
> 
> 
> On Fri, Sep 20, 2013 at 10:54 AM, Marc Petit-Huguenin
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> After TCP allocation over TURN Websocket, what is the Websocket equivalent
> of initiating a new TCP connection (RFC 6062) after sending a
> ConnectionBind or receiving a ConnectionAttempt?  Is a new Websocket
> connection opened and if it is the case, shouldn't it require a different
> subprotocol?  Perhaps a better alternative would be to use multiplexing 

- -- 
Marc Petit-Huguenin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 20 Sep 2013 13:14:10 -0700

On 09/20/2013 12:57 PM, Oleg Moskalenko wrote:
> 
> 
> 
> On Fri, Sep 20, 2013 at 11:59 AM, Marc Petit-Huguenin
> OK so I suggest to say in the draft that a new Websocket connection will
> be created for each TCP peer, because that have an impact on implementation
> design.
> 
> 
> ... for RFC 6062 TURN TCP, of course. The key key words here are "TCP
> peers" (as in RFC 6062, unlike "UDP peers" in RFC 5766). That may be worth
> mentioning, indeed.
> 
> This draft is mostly driven by the necessity of enhanced connectivity of
> the clients (browsers) in WebRTC environment. So the question of
> multiplicity of TCP / Websocket connections is not very important in this
> context.

If having TCP peers is not important, then remove RFC 6062 from this draft.

Also, the draft does not explain the procedures related to SRV and NAPTR RRs:

example.net.
IN NAPTR 100 10 "" RELAY:turn.ws "" websocket.example.net.

websocket.example.net.
IN NAPTR 100 10 S RELAY:turn.ws "" _turn._ws.example.net.

_turn._ws.example.net.
IN SRV   0 0 80 a.example.net.

a.example.net.
IN A     192.0.2.1

- -- 
Marc Petit-Huguenin

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 20 Sep 2013 22:33:24 +0200

> IN SRV   0 0 80 a.example.net.

Hi Marc

It was my error to keep the websocket support  for RFC 6062 in the draft 
(against Oleg recommendations, by the way).  I agree with both of you 
that it will be better to remove it from the draft, as it is causing 
most of the discussions and will not provide anything to webrtc.

Regarding the SRV and NAPTR RRs, for webrtc are not needed AFAIK, but we 
could add it to the draft for completeness. Would you be willing to 
collaborate in order to write that chapter?

Also, I would like to introduce in next draft version how HTTP 
authentication/authorization (oAuth, cookies, etc) mechanisms could be 
used in the TURN over websocekt connection on top of the standard TURN 
authentication. That would remove the need for the current REST API fro 
access to TURN services. If anyone would be willing to collaborate on 
this (or any other subject) will be very welcome.

Best regards
Sergio

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 20 Sep 2013 11:19:13 -0700

In practice, even in the case of a few RFC 6062 users, in most cases a TURN
allocation is created with a single or a few connections, so there will be
no significant flood of TCP connections if we will keep a new Websocket
connection for each new peer.

Regards,
Oleg

On Fri, Sep 20, 2013 at 10:54 AM, Marc Petit-Huguenin <
[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> of
> to
> we
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
>
> iQIcBAEBCAAGBQJSPIvbAAoJECnERZXWan7E5ukP/jHhs1I4I3GIXoRfvPPNHsFZ
> CuGUwg/4cXKb0FPzeMkjNL8rv13DutWydt5nJcKrNcypMbnIj8uzRBFD/ZboEap0
> RxkX56QmNGhhhFMcnEIrSMfFbX83m9Y9IHFJIEUtginLygIJJkjwaS++PoFK2WGA
> wmVaXJwgrEJyeDPCiW4i9ukhZcQk4/pVCLMvyDY0g5L0BEEeYUJrufLWorUztDFD
> gtASRVMdO5EyyRM0Z23xuOyf5oBd7nqWFhoiA15BxLeodfss0g5Gx9sW6IDPWdXn
> vVguNbB4fKe/C0+bjN8FkXrziKaf9/wsWeuXMrDnh5lvjAtnP//n9DBEl1iFlHrf
> DIZRC0Wr0HOIsVAl2iczzaB73Ds53KYRzzuPlTlkocW0yhKd4eJEB4LC1UkBmrV0
> O8N88G2jpQCF2VR4D9Ut0kxhg35bARtYZwcZ45z4Vc6vDRUwBKeI7TQOjYwcA8e9
> ySea2gIhtB+A1dxTOX8Ynk5I39imiRUiU3MuNmdWK+FHPB6TLYbjBk57sVN5+ZKj
> Ts4UL1b+E15WA4aEAFitH4ptnXSF80mmRg9Bp5VHDUWYqnIloha52g+RBa0bgCrM
> ksIb86D1GJo8c4kVnStPZ/Q8lvomeM9IVtOFUpuV6QZJ9FwYvYaWaLinH9cQHcw9
> CrANHoFIUigxL4mtdOwc
> =zjII
> -----END PGP SIGNATURE-----
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 20 Sep 2013 12:57:12 -0700

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 20 Sep 2013 13:46:47 -0700

On 09/20/2013 01:33 PM, Sergio Garcia Murillo wrote:
>>> OK so I suggest to say in the draft that a new Websocket connection
>>> will be created for each TCP peer, because that have an impact on
>>> implementation design.
>>> 
>>> 
>>> peers" (as in RFC 6062, unlike "UDP peers" in RFC 5766). That may be
>>> worth mentioning, indeed.
>>> 
>>> This draft is mostly driven by the necessity of enhanced connectivity
>>> of the clients (browsers) in WebRTC environment. So the question of 
>>> multiplicity of TCP / Websocket connections is not very important in
>>> this context.
>> example.net. IN NAPTR 100 10 "" RELAY:turn.ws "" websocket.example.net.
>> 
>> websocket.example.net. IN NAPTR 100 10 S RELAY:turn.ws ""
>> _turn._ws.example.net.
>> 
>> _turn._ws.example.net. IN SRV   0 0 80 a.example.net.
>> 
>> a.example.net. IN A     192.0.2.1
>> 
>> 
> 
> Hi Marc
> 
> (against Oleg recommendations, by the way).  I agree with both of you that
> it will be better to remove it from the draft, as it is causing most of
> the discussions and will not provide anything to webrtc.
> 

Sure, I'll send you a patch this week-end.

> authentication/authorization (oAuth, cookies, etc) mechanisms could be used
> in the TURN over websocekt connection on top of the standard TURN
> access to TURN services. If anyone would be willing to collaborate on this
> (or any other subject) will be very welcome.

I think that this is a very good idea to do that.  Not sure I'll have the time
to help on the draft itself, but I certainly will try find the time to review it.

- -- 
Marc Petit-Huguenin

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 20 Sep 2013 23:25:13 +0200

So, would we then just keep the websocket connection only for the TURN 
connection in RFC 6062 and let the client data connection stay as it is 
(ie. in TCP)? As:

                         +-------------+
           TURN Control  |             |
          +--------------+ TURN Server +----------------+
          |    WS/WSS    |             |    TCP         |
          |              +------+------+                |
          |                     |                       |
          |                     |                       |
      +---+---+   Client Data   |                   +---+---+
      | Alice |-----------------+                   |  Bob  |
      +-------+       TCP                           +-------+

Or what should we do with the client data connection instead?

Best regards
Sergio
El 20/09/2013 23:12, Oleg Moskalenko escribió:
> RFC 6062 is not very important but I cannot say that it is not 
> relevant. For the purpose of the new proposal we do not make a 
> distinction between RFC 5766 and RFC 6062 - this new proposal is about 
> a new TURN transport (Websockets). This transport is supposed to work 
> universally in all accepted TURN RFCs. So it would be unnatural and 
> illogical to remove RFC 6062 from the draft.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 21 Sep 2013 01:25:45 +0200

El 21/09/2013 1:14, Oleg Moskalenko escribió:
> On Fri, Sep 20, 2013 at 1:33 PM, Sergio Garcia Murillo 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     authentication/authorization (oAuth, cookies, etc) mechanisms
>     could be used in the TURN over websocekt connection on top of the
>     standard TURN authentication. That would remove the need for the
>     current REST API fro access to TURN services. If anyone would be
>     willing to collaborate on this (or any other subject) will be very
>     welcome.
>
>
> Sergio, regarding the authentication stuff that you are proposing: 
> that may change the nature of the draft. The current draft does not 
> affect TURN functionality - it only adds a new option for the 
> client-server transport. That may be a very good thing about the 
> draft; it makes it acceptable, I guess, to most of the concerned 
> people. If you are going to introduce changes in the TURN protocol 
> (like new attributes and new behavior), then the draft will get 
> another dimension, and it may make it more difficult to get accepted 
> and approved (and implemented, too).
>
> The original purpose of the draft was to allow WebRTC communications 
> in some very unforgiving strict corporate environments (correct me if 
> this is not true). A new authentication mechanism, strictly speaking, 
> has nothing to do with that original goal. It may be a nice thing - 
> but it may be a theme for an add-on next-step specification.
>
> Just my opinion.
>
> Regards,
> Oleg
>

Hi Oleg,

I will definitively will be working on the authentication part, as it 
may be a very interesting feature for webrtc and would provide a 
differential value for TURN over websockets compared to TURN over 
TCP/TLS . But I agree that maybe it will be better to create a different 
draft to not mix discussions.

Best regard
Sergio

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 20 Sep 2013 14:12:20 -0700

RFC 6062 is not very important but I cannot say that it is not relevant.
For the purpose of the new proposal we do not make a distinction between
RFC 5766 and RFC 6062 - this new proposal is about a new TURN transport
(Websockets). This transport is supposed to work universally in all
accepted TURN RFCs. So it would be unnatural and illogical to remove RFC
6062 from the draft.

On Fri, Sep 20, 2013 at 1:46 PM, Marc Petit-Huguenin <
[email-masked]> wrote:

> that
> used
> this
> iQIcBAEBCAAGBQJSPLQ0AAoJECnERZXWan7ExzgQALZo/mdZqeGH3IdRzIflKAa9
> TnpU7SF/L3hOdyizgw7ftpzG1FDHfXrS12APmBOAt7F7ec5Q7p4W2tscXebTeSO4
> uQ/gYb50ekbGkVOVWHwzPP7k3lMNe3FnNnycYO9JJc/qpF9XeBKNnCaVPKbjW74K
> dIX/i+YeCqjoY0E2YQNeCzq2uX18Ygeals6/C+XOyxO+31GQPWLcIXr3ME8LZnAS
> QwUmL3+6/17kDdfK0xhtXl4oB44rpDhUNAodaxr6FUY0SOvp5GqsKKxOESSA3ltn
> K6ZpWuRBVBuaPdaQDrNT0xbNHjiA6WKnyjKfd0/8F0xZe13Sd3WTR2r6S9+QWS44
> TM3y4er4P7ISc11p5HHMwN3xf7kxCwwRbU3lK7Rq0M5Nlw69QXA/D2HY1txioumW
> fBbtAVwhx9M88bj4/sqViV0LIDPo/h/OVrkYncD7aJgISSKApuZMAjYegC/iYufz
> C4M5dZRub6PHoljTSFAs72bGC+yyvStsJxnrYN8pPF33MHRfbNdBdLZOpJq0ynU/
> ku0arxu6LwNBedno/B77WvUPG/x2ilKDcfDgxHSwkm3e/sWggZgkR1E7R/cXyFNK
> cO172tJlQPGF68QRjj1y7ulQb60cAscn51LRo5iTH6Xd8LcGxun+jWa09opuBtNo
> eRxWcQ3hI897vUZUzWMO
> =KM9Z

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 20 Sep 2013 14:16:40 -0700

On Fri, Sep 20, 2013 at 1:33 PM, Sergio Garcia Murillo <
[email-masked]> wrote:

> it will be better to remove it from the draft, as it is causing most of the
> discussions and will not provide anything to webrtc.
>
>
>
Sergio, RFC 6062 indeed make this draft somewhat more complex but I am
afraid that removing it from the draft at the moment can be controversial,
too. As I mentioned in previous communications, RFC 6062 may be really a
challenge because RFC 6062 call for a "continuous" communication channel
(unlike message-based communication in RFC 5766). But I am not sure that
removing it completely would be the right thing. This is up to you.

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 20 Sep 2013 15:01:15 -0700

I think that we either have to remove RFC 6062 altogether or allow
Websockets for both TURN and DATA connections. If we allow Websockets for
TURN but we do not allow it for data then it would be useless, I believe.

REgards,
Oleg

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 20 Sep 2013 16:14:24 -0700

> (or any other subject) will be very welcome.

Sergio, regarding the authentication stuff that you are proposing: that may
change the nature of the draft. The current draft does not affect TURN
functionality - it only adds a new option for the client-server transport.
That may be a very good thing about the draft; it makes it acceptable, I
guess, to most of the concerned people. If you are going to introduce
changes in the TURN protocol (like new attributes and new behavior), then
the draft will get another dimension, and it may make it more difficult to
get accepted and approved (and implemented, too).

The original purpose of the draft was to allow WebRTC communications in
some very unforgiving strict corporate environments (correct me if this is
not true). A new authentication mechanism, strictly speaking, has nothing
to do with that original goal. It may be a nice thing - but it may be a
theme for an add-on next-step specification.

Just my opinion.

Regards,
Oleg

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 21 Sep 2013 06:35:52 +0000

Hi Sergio,

Please see inline

> Sent: Saturday, September 21, 2013 2:03 AM
> To: Marc Petit-Huguenin
> Cc: Victor Pascual Avila; Oleg Moskalenko; [email-masked]; Lorenzo Miniero;
> Chenxin (Xin)
> Subject: Re: [pntaw] New version of TURN over websockets draft
> 
> access to TURN services. 

we had discussed in BEHAVE WG to change REST API draft to use OAuth (http://www.ietf.org/mail-archive/web/behave/current/msg11095.html). You may want to check with Justin.

-Tiru.

> If anyone would be willing to collaborate on