TURN has been an integral part of internet based communication, in a standalone capacity and as a part of the ICE protocol. TURNs ability to relay a data stream allows even the most stubborn of NATs to be overcome. Unfortunately the original TURN (rfc 5766) protocol was designed only with UDP transmission in mind.
Since TURN is a traversal method in which clients behind more restrictive NATs (think symmetric) are able to communicate, it should also go hand-in-hand that these clients most likely want to communicate in a way where connection and security are both guaranteed. Due to this consideration it can be seen why UDP was not the optimal transport method for these situations. TURN needed to be optimized to support more secure, and higher level transports such as TCP and TLS.
It is important to note, at this point TCP for TURN (rfc6062) is an addendum to the original TURN specs and that everything below is in addition to, or in contrast to, those specs. Also note that the following method is client based and not the server method.
TCP TURN Control Connection
As with any TURN negotiation, the first step of the process is to create an allocation. When using TCP TURN it is necessary that the transport type of the allocation be that of TCP. Although a UDP allocation can be created by using a TCP transport, this property is not reciprocal. In addition, UDP based attributes such as tokens, and even-ports, must be left out of all TCP allocation requests. TCP allocation authentication, success/failure responses, and the creation of permissions are identical to those of UDP TURN. It is important however to identify this allocated connection as a “Control Connection,” as it serves a specific purpose in TCP applications.
TCP TURN Data Connection
At this point, the control connection allocation and permissions have been established with the TURN server, the next step is to create the “data connection” where most of the information transaction will take place. In UDP applications this would normally just take place on the already established connection as long as the proper permissions were in place. With TCP TURN an additional step is necessary.
When creating a connection as the establisher, a Connection request is sent to the server over the control connection. This Connect request must contain the XOR address of the peer with which to establish a connection. If everything is good, and the peer has created the proper permissions on their end to accept contact, the server will send back a success response containing the stun attribute “connectionID.”
Once this response is received, it is necessary to open a new connection with the server using a different local port, but sending data to the same established socket on the TURN server. Once the port is open, a “connectionBind” request can be sent over this new pathway. The connectionBind request must contain the previously sent connectionID, XOR peer address, and any of the negotiated authentications of the established control connection. The inclusion of these attributes greatly reduces the chances of hijacking and improves the security of the established data connection.
Once a success response is received, data may flow over this connection in a normal manner, if additional media types are required, a data connection for each must be established in an appropriate manner adhering to the procedure above. If receiving a connection from the client, the method is the same, but using a “connectionAttempt” to start the process off. As long as a permission is in place for the inquiring address, a connectionBind request will be sent back to the server and a data connection established.
Once both the Control Connection and Data Connections have been established for both client and peer, data may flow from one data connection to the other. All TURN based messaging, such as refreshes, must be sent on the Control Connection. If at any point the client or peer closes the control connection, the related data connection must be closed as well.