Implement RFC-6062

[kleky]

Summary

Implement RFC-6062, Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations

Motivation

To provide a TCP relay client for use with a service such as Coturn.

Describe alternatives you've considered

Unable to find any clients that support RFC-6062.

Additional context

Already discussed over Slack with a colleague of mine, Lewis Jessett and @Sean-Der :

https://gophers.slack.com/archives/CAK2124AG/p1579206089185600

We've been given the clearance to contribute on this, but will probably need some guidance from the pion community.

Looking at the RFC I've tried to summarize what is required as follows:

1. Client to setup a Turn ALLOCATE request for TCP ( REQUESTED-TRANSPORT attribute == 6)
2. Refresh of ALLOCATION identical to UDP
3. Ability for client to send a Connect request over control connection (including an XOR-PEER-ADDRESS attribute containing the transport address of the peer to which a connection is desired). -Upon success response the CONNECTION-ID attribute is returned to client.
4. Ability for client to initiate another TCP connection using a different local transport address, then a ConnectionBind request over the new connection that includes the CONNECTION-ID attribute. Upon success, this is the client data connection.

Does another new data connection get created when a peer tries to connect, as per RFC-6062 Section 4.4?

[Sean-Der]

Fantastic news! So excited you are able to use Pion @kleky I will make sure to help with the whole process/get things landed :)

I am reading the RFC now and will come back with my thoughts!

[kleky]

pion/transport#27

Looks like we need to update vnet as it doesn't support TCP.

[Sean-Der]

@kleky

Don't worry about adding TCP support to vnet. I don't think that blocks us getting this in at all. It is useful for testing how things behave in different network topologies, but I think it is less useful for TCP.

I read the RFC and seems pretty straight forward. We need to add some new handlers in turn.go to handle Connect + ConnectionBind

Then we need to make a ConnHandler equivalent here this is the relay.

I am going to setup coturn and do a wireshark of TCP traffic. If you already have it setup would you mind sharing a pcap I can move a lot faster that way, but if you don't have one it is totally fine :)

[kleky]

Thanks @Sean-Der , at client.go:45, Net appears to be tied to vnet.

Glad you think it's pretty straight forward! 😆

I created a fork here and pushed a change already. not wanting to duplicate on this so shall we decide who's on what? Unless you've got it all covered or prefer a different way of working?

Many thanks.

..will look into getting you coturn. no idea about a pcap though sorry

[Sean-Der]

@kleky I added both of you to the pion organization. You can push a branch directly here!

That will make it a lot easier for us all to work together :) You will also get all the nice tooling/be able to pin easier.

---

I think we need to modify Client extensively, and have a TCP and UDP mode. We will can add a new entry TCPConn that takes a net.Conn

We also need to support it running it as connecting to the Relay or Control socket. The currently Client only targets connecting to the control socket.

[Sean-Der]

This is a pretty big paradigm shift, but we will make it work :)

Feel free to refactor/change aggressively as well. I will work on getting test coverage up higher also, will make things a lot less brittle.

[kleky]

Haha yes indeed, we realized there appears more work than anticipated, but we'll get there. Although, because we're using coturn maybe someone else could take on the pion turn server side of it?

Thanks for adding us, it'll be much easier.

We started looking at (3) the sending of the Connect request, which will involve a new message type in stun/message.go

[Sean-Der]

I can do all the server work!

If you can get the client + tests passing with coturn, I can then point them against the server and implement everything.