TCP and TLS transport support for TURN

[Warren McDonald]

Hi,

I have just update the bug report for TLS and TCP support with the same question but thought I would air it here.

The title of this bug seems to indicate it is limited to enabling TCP for the control connection, but to still use UDP for data relay.

The ?transport=tcp parameter in a TURN uri is to signal request of TCP relay ports. 

Securing the control connection requires the uri scheme to be "turns" instead of "turn" . 
Specifying both should secure the transport as well.

+---------------------------------+----------+--------+-------------+
   | URI                             | <secure> | <port> | <transport> |
   +---------------------------------+----------+--------+-------------+
   | turn:example.org                | false    |        |             |
   | turns:example.org               | true     |        |             |
   | turn:example.org:8000           | false    | 8000   |             |
   | turn:example.org?transport=udp  | false    |        | UDP         |
   | turn:example.org?transport=tcp  | false    |        | TCP         |
   | turns:example.org?transport=tcp | true     |        | TLS         |
   +---------------------------------+----------+--------+-------------+
 

So it would be good to get an idea of how these will fit into the releases.

Warren

[Oleg Moskalenko]

By the way, it would also be interesting to know whether WebRTC is going to support DTLS (the URL would be something like turns:example.org?transport=udp). That would a much better option for secure media than TLS. There are TURN servers available with "experimental" DTLS support.

Thanks
Oleg

[Justin Uberti]

transport=tcp indicates the client connection to the TURN server is to go over TCP instead of UDP - this basically tells the client "for this TURN server, connect over TCP instead of UDP".

Allocation of TCP ports on the TURN server is handled internally by the stack.

I will reply with more specifics in the bug.

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Justin Uberti]

There is no plan to support DTLS connections to the TURN server. Media is encrypted via SRTP; it's not clear how much value encrypting the TURN connection adds, if any.

On Sat, Feb 23, 2013 at 1:32 AM, Oleg Moskalenko <mom0...@gmail.com> wrote:

--

[Oleg Moskalenko]

I'd like to clarify what "TCP/T:LS support" means for TURN:

RFC5766 defines only "one-sided" support for TURN protocol: the communications between the client and the TURN server may go over TCP/TLS, but the TURN server always relays the packets over UDP.

There is an extension to TURN, RFC 6062, that defines the "full" TCP support: the data "after" TURN can be relayed over TCP (not TLS). The connection between the client and the TURN server must be TCP or TLS if we want the traffic to be relayed over TCP.

Our new TURN server version supports this RFC 6062 now:

http://code.google.com/p/rfc5766-turn-server/

But I am not sure that this feature is useful for WebRTC traffic. I have no idea whether WebRTC is going to support "full" TCP relaying and whether it has a real use case for WebRTC.

[Justin Uberti]

On Fri, Mar 15, 2013 at 12:43 PM, Oleg Moskalenko <mom0...@gmail.com> wrote:

I'd like to clarify what "TCP/T:LS support" means for TURN:

RFC5766 defines only "one-sided" support for TURN protocol: the communications between the client and the TURN server may go over TCP/TLS, but the TURN server always relays the packets over UDP.

There is an extension to TURN, RFC 6062, that defines the "full" TCP support: the data "after" TURN can be relayed over TCP (not TLS). The connection between the client and the TURN server must be TCP or TLS if we want the traffic to be relayed over TCP.

Our new TURN server version supports this RFC 6062 now:

http://code.google.com/p/rfc5766-turn-server/

But I am not sure that this feature is useful for WebRTC traffic. I have no idea whether WebRTC is going to support "full" TCP relaying and whether it has a real use case for WebRTC.

I don't think this feature is useful for WebRTC traffic. 

[Kaiduan Xie]

Totally agree with Justin.

With the support of UDP allocation on TURN server over TCP transport
between client and TURN server, it is sufficient to traverse NAT where
UDP is blocked entirely.

/Kaiduan