Subject: [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt

From: "Chenxin (Xin)" <[email-masked]>
Date: Fri, 13 Sep 2013 08:58:08 +0000

Hi all,
	We have been working on a new version of the TURN over Websocket draft, 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.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Friday, September 13, 2013 8:59 AM
>To: Sergio Garcia Murillo; Chenxin (Xin); Victor Pascual; Oleg Moskalenko;
>Lorenzo Miniero; Chenxin (Xin)
>Subject: New Version Notification for
>draft-chenxin-behave-turn-websocket-01.txt
>
>
>A new version of I-D, draft-chenxin-behave-turn-websocket-01.txt
>has been successfully submitted by Xin Chen and posted to the
>IETF repository.
>
>Filename:	 draft-chenxin-behave-turn-websocket
>Revision:	 01
>Title:		 WebSocket Protocol as a Transport for Traversal Using Relays
>around NAT (TURN)
>Creation date:	 2013-09-12
>Group:		 Individual Submission
>Number of pages: 10
>URL:
>http://www.ietf.org/internet-drafts/draft-chenxin-behave-turn-websocket-01.tx
>t
>Status:
>http://datatracker.ietf.org/doc/draft-chenxin-behave-turn-websocket
>Htmlized:
>http://tools.ietf.org/html/draft-chenxin-behave-turn-websocket-01
>Diff:
>http://www.ietf.org/rfcdiff?url2=draft-chenxin-behave-turn-websocket-01
>
>Abstract:
>   This document defines an extension to the Traversal Using Relays
>   around NAT (TURN) protocol, in order to allow it to run over a
>   WebSocket channel.  This will allow clients in restrictive networks
>   to traverse them and effectively exchange and relay media or data
>   over WebSockets.
>
>
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat

---

From: Simon Perreault <[email-masked]>
Date: Fri, 13 Sep 2013 11:23:46 +0200

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

There are two major things missing in this draft:

- How are TURN UDP "channels" supported? (See RFC 5766 section 2.5.)

- How are TURN TCP "data connections" supported? (See RFC 6062 section 3.)

I think the answers to these questions will greatly affect the overall 
design of TURN-over-WebSocket.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Simon Perreault <[email-masked]>
Date: Sat, 14 Sep 2013 08:02:44 +0200

Le 2013-09-13 22:26, Sergio Garcia Murillo a écrit :
> So, at the end, the ChannelData message is just another TURN message, so
> it will be encapsulated inside a websocket frame. If you feel it is not
> clear, we can add more details about it in next draft.

You're right, I was mistaken about this. Thanks for the detailed 
explanation. No need for more details.

> Regarding RFC 6062, we had some internal discussion regarding if we
> should add websocket support at all to it or not. Mainly, because AFAIK,
> webrtc will use RFC 5766 and not 6062. Anyone please correct me if I am
> wrong.

I think a better justification would be "because WebRTC data channel 
will use SCTP over DTLS".

> I agree with you that this has not been well covered in the draft. In
> order to make the minimun changes possible, and align it with the
> general view of changing just the turn client to turn server
> encapsulation protocol, I would propose to extend websockets usage only
> for the turn control connection in RFC 6062 but keep turn data
> connections on TCP.

So with an HTTP proxy the control would be over websockets and the data 
would be through the CONNECT method? Yuck...

> That, or drop RFC 6062 extension altogether and just
> focus on 5766. What do you feel it would be best?

I say focus on 5766.

I have a new question: what does the TURN server put in the 
XOR-MAPPED-ADDRESS attribute? The proxy's address or the client's 
address? Can TURN over WebSockets be used to gather server-reflexive 
candidates?

Simon

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Sat, 14 Sep 2013 08:53:21 +0000

Hi Simon,

>would be through the CONNECT method? Yuck...

Or using websocket multiplexing http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-11 . 
>address? 

The proxy's address. I do not think this attribute will help ICE process. 

Can TURN over WebSockets be used to gather server-reflexive
>candidates?

Yes, It could do as UDP and TCP. But when there is a http proxy. I think the server reflexive candidates will be the address of proxy, which means nothing for the peer. But if there is only NAT, the server reflexive candidates is possible to work in the ICE.

Best Regard,
  Xin
>_______________________________________________
>rtcweb mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Simon Perreault <[email-masked]>
Date: Sat, 14 Sep 2013 11:13:54 +0200

Le 2013-09-14 10:53, Chenxin (Xin) a écrit :
> Yes, It could do as UDP and TCP. But when there is a http proxy. I think the server reflexive candidates will be the address of proxy, which means nothing for the peer.

Isn't this a big problem? I mean, if the client cannot trust the value 
of the XOR-MAPPED-ADDRESS attribute, doesn't that break STUN/TURN/ICE 
and everything else?

Simon

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Sat, 14 Sep 2013 10:23:43 +0000

Hi Simon,
>> Yes, It could do as UDP and TCP. But when there is a http proxy. I think the
>server reflexive candidates will be the address of proxy, which means nothing for
>the peer.
>
Thanks for your question. You are right about it. We should consider more about gathering the server reflexive candidates in turn over websocket.
I have checked the RFC 5766 again:
      Reflexive Transport Address:  A transport address learned by a client
      that identifies that client as seen by another host on an IP
      network, typically a STUN server.  When there is an intervening
      NAT between the client and the other host, the reflexive transport
      address represents the mapped address allocated to the client on
      the public side of the NAT.  Reflexive transport addresses are
      learned from the mapped address attribute (MAPPED-ADDRESS or XOR-
      MAPPED-ADDRESS) in STUN responses.
Which restricts that the "Reflexive Transport Address" should be obtained from NAT. It will be semantic problem if this address is from proxy.

In ICE, I have not found out the harmful scenario yet. It will be possible to make ICE Connectivity Checks failed, but it will be possible to be useful. 
I am still thinking about how to handle it. Should we just leave it to for the usage of gathering candidate from NAT? OR totally forbid it in the turn over websocket?
What is your suggestion?

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 13 Sep 2013 22:26:45 +0200

Hi Simon,

As per RFC 5766:

    For some applications (e.g., Voice over IP), the 36 bytes of overhead
    that a Send indication or Data indication adds to the application
    data can substantially increase the bandwidth required between the
    client and the server.  To remedy this, TURN offers a second way for
    the client and server to associate data with a specific peer.

    This second way uses an alternate packet format known as the
    ChannelData message.  The ChannelData message does not use the STUN
    header used by other TURN messages, but instead has a 4-byte header
    that includes a number known as a channel number.

connections on TCP. That, or drop RFC 6062 extension altogether and just 

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 14 Sep 2013 22:30:43 +0200

> address? Can TURN over WebSockets be used to gather server-reflexive 
 From my point of view, the value of the XOR-MAPPED-ADDRESS should be 
the same as when using TURN over TLS on the same scenario (if it happens 
to work), that would be either the HTTP proxy address or any NAT 
happening after it.

Best regards
Sergio

---

From: Simon Perreault <[email-masked]>
Date: Sun, 15 Sep 2013 09:24:29 +0200

Le 2013-09-15 08:42, Martin Thomson a écrit :
> On 14 September 2013 02:13, Simon Perreault <[email-masked]> wrote:
>> Isn't this a big problem? I mean, if the client cannot trust the value of
>> the XOR-MAPPED-ADDRESS attribute, doesn't that break STUN/TURN/ICE and
>> everything else?
>
> Hardly.  You just lose that option.  It might suck if you needed it,
> but given that you are using a relay, it's probably not that bad.
>
> The value of XOR-MAPPED-ADDRESS is degraded by a lesser degree with
> TURN over TCP.  Same upside.

True.

Then shouldn't server-reflexive candidates always be gathered using 
plain STUN or TURN-over-UDP? That is, the XOR-MAPPED-ADDRESS attribute 
would be ignored (or even not sent) for TURN-over-anything-but-UDP.

Simon

---

From: Martin Thomson <[email-masked]>
Date: Sat, 14 Sep 2013 23:42:58 -0700

---

From: Matt Fredrickson <[email-masked]>
Date: Mon, 16 Sep 2013 14:39:34 -0500

On Sun, Sep 15, 2013 at 2:24 AM, Simon Perreault <
[email-masked]> wrote:

> Then shouldn't server-reflexive candidates always be gathered using plain
> STUN or TURN-over-UDP? That is, the XOR-MAPPED-ADDRESS attribute would be
> ignored (or even not sent) for TURN-over-anything-but-UDP.

That's what I was beginning to think as well...  Is there any utility to be
gained by advertising XOR-MAPPED-ADDRESS on transport types that (at least
it would so seem to me) preclude its usage?

Matthew Fredrickson