Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations
draft-ietf-behave-turn-tcp-00.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 14, 2008.

Copyright Notice

Copyright © The IETF Trust (2007).

Abstract

This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for NAT traversal, to allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept and manage TCP connection with the client's peers. TURN and this extension both purposefully restricts the ways in which the relayed address can be used. In particular, it prevents users from running general purpose servers from ports obtained from the STUN server.

Table of Contents

1.  Introduction
2.  Initial Allocations
3.  Managing TCP Peers
    3.1.  Connect Request
    3.2.  Listen Permission Request
    3.3.  Connection Status Indication
4.  Forwarding
5.  New value in REQUESTED-TRANSPORT
6.  New CONNECT-STAT Attribute
7.  New Error Reponse Codes
8.  Security Considerations
9.  IANA Considerations
    9.1.  New STUN Requests, Responses, and Indications
    9.2.  New STUN Attributes
    9.3.  New STUN response codes
10.  Security Considerations
11.  IANA Considerations
12.  IAB Considerations
13.  Acknowledgements
14.  References
    14.1.  Normative References
    14.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

For TCP connections, the Connection Request allows the client to ask the server to open a connection to the peer. This also adds a permission to accept an incoming TCP connection from the remote address of the peer. When the server and the peer try to open a TCP connection at the same time, this is called TCP simultaneous open. With a Listen Permission request a client can ask the server just to add a permission to the peer and listen for a connection request.

When the TURN-to-peer leg is TCP, the TURN client needs to be aware of the status of these TCP connections. Consequently, the TURN server sends a Connection State Indication for a binding whenever the relay connection status changes for one of the client's bindings, except when the status changes due to a TURN client request (ex: an explicit binding deallocation).

2.  Initial Allocations

The procedures for an initial allocation are nearly identical to those in the core TURN specification (Rosenberg, J., “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” July 2007.) [2]. Define new value for REQUESTED-TRANSPORT attribute. The client MUST NOT request the TCP transport in an Allocate request sent to the TURN server over UDP.

3.  Managing TCP Peers

3.1.  Connect Request

The Connect Request is used by a client when it has obtained an allocated transport address that is TCP. The client can use the Connect Request to ask the server to open a TCP connection to a specified destination address included in the request.

If the allocation is for a UDP port, the server MUST reject the request with a 445 (Operation for TCP Only) response. If the request does not contain a REMOTE-ADDRESS attribute, the server sends a 400 (Bad Request) Connect error response,.

If the request contains a REMOTE-ADDRESS attribute, the IP address contained within it is added to the permissions for this allocation, if it was not already present. This happens regardless of whether the subsequent TCP connection attempt succeeds or not.

If a connection already exists for this address and port, the server returns a 446 (Connection Already Exists) Connect error response. Otherwise the server tries to establish the corresponding TCP connection and returns a Connect Success Response. This just indicates that the server added the permission and is attempting to establish a TCP connection. The server does not wait for the connection attempt to succeed or fail. The status of the connection attempt is returned via the Connect Status Indication.

Note that the server needs to use the same source connection address for all connections/permissions associated with an allocation. For servers written using Berkeley sockets, the SO_REUSEADDR flag is typically used to use the same local address with multiple sockets.

3.2.  Listen Permission Request

The Listen Permission Request is used by the client to ask the server to create a permission for a TCP peer without attempting to make a connection to that peer. If it has not already done so, the server should start listening on the allocated port and should be prepared to accept any incoming connection requests from a peer with an active permission.

Note that the server needs to use the same source connection address for all connections/permissions associated with an allocation. For servers written using Berkeley sockets, the SO_REUSEADDR flag is typically used to use the same local address with multiple sockets.

3.3.  Connection Status Indication

When the TURN to peer leg is TCP, the TURN client needs to be aware of the status of TCP connections and other open permissions created on its behalf. The TURN extension defines application states for a TCP connection as follows: LISTEN, ESTABLISHED, CLOSED. Consequently, the TURN server sends a Connection State Indication for a TCP permission whenever the relay connection status changes for one of the client's permissions except when the status changes due to a TURN client request (ex: an explicit binding close or deallocation). A Connection Status Indiciation MUST also contain a REMOTE-ADDRESS attribute.

A TURN can only relay to a peer over TCP if the client communicates with the server over TCP or TLS over TCP. Because of this, the server can be assured that Connection Status Indications are received reliably.

4.  Forwarding

If a server receives a TCP connection request on an allocated TCP transport address, it checks the permissions associated with that allocation. If the source IP address of the TCP SYN packet matches one of the permissions (the source port does not need to match), the TCP connection is accepted. Otherwise, it is rejected. When a TCP connection is accepted, the server sends the corresponding client a Connect Status Indication with the CONNECT-STAT attribute set to ESTABLISHED. No information is passed to the client if the server rejects the connection because there is no corresponding permission.

If a server receives data on a TCP connection that terminates on the allocated TCP transport address, the server sends the data received on the TCP connection to the client as described in [TODO].

Note that, because data is forwarded blindly across TCP bindings, TLS will successfully operate over a TURN allocated TCP port if the linkage to the client is also TCP.

5.  New value in REQUESTED-TRANSPORT

This attribute is used by the client to request a specific transport protocol for the allocated transport address. It is a 32 bit unsigned integer. Its values are:

0x0000 0000: UDP
0x0000 0001: TCP

If an Allocate request is sent over TCP and requests a UDP allocation, or an Allocate request is sent over TLS over TCP and requests a UDP or TCP allocation, the server will relay data between the two transports.

Extensions to TURN can define additional transport protocols in an IETF-consensus RFC.

6.  New CONNECT-STAT Attribute

The connection status attribute is used by the server to convey the status of server-to-peer connections. It is a 32 bit unsigned integer. Its values are:

0x0000 0000: LISTEN
0x0000 0001: ESTABLISHED
0x0000 0002: CLOSED

7.  New Error Reponse Codes

445 (Operation for TCP Only): The client tried to send a request to perform a TCP-only operation on an allocation, and allocation is UDP.

446 (Connection Already Exists): The client tried to open a connection to a peer, but a connection to that peer already exists.

8.  Security Considerations

9.  IANA Considerations

This specification defines several new STUN messages, STUN attributes, and STUN response codes. This section directs IANA to add these new protocol elements to the IANA registry of STUN protocol elements.

9.1.  New STUN Requests, Responses, and Indications

Request/Response Transactions
0x007  :  Connect
0x008  :  Listen Permission

Indications
0x009  :  Connect Status

9.2.  New STUN Attributes

0x0023: CONNECT-STAT

9.3.  New STUN response codes

445    Operation for TCP Only
446    Connection Already Exists

10.  Security Considerations

TBD

11.  IANA Considerations

TBD

12.  IAB Considerations

The IAB has studied the problem of "Unilateral Self Address Fixing", which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism RFC 3424 (Daigle, L. and IAB, “IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation,” November 2002.) [8]. The TURN extension is an example of a protocol that performs this type of function. The IAB has mandated that any protocols developed for this purpose document a specific set of considerations.

TURN is an extension of the STUN protocol. As such, the specific usages of STUN that use the TURN extensions need to specifically address these considerations. Currently the only STUN usage that uses TURN is ICE (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.) [9].

13.  Acknowledgements

The authors would like to thank Marc Petit-Huguenin for his comments and suggestions.

14.  References

14.1. Normative References

14.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).