Behave J. Rosenberg
Internet-Draft Cisco Systems
Intended status: Standards Track R. Mahy
Expires: May 14, 2008 Plantronics, Inc.
November 11, 2007
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 (C) 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
Rosenberg & Mahy Expires May 14, 2008 [Page 1]
Internet-Draft TURN TCP November 2007
servers from ports obtained from the STUN server.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Initial Allocations . . . . . . . . . . . . . . . . . . . . . . 3
3. Managing TCP Peers . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Connect Request . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Listen Permission Request . . . . . . . . . . . . . . . . . 4
3.3. Connection Status Indication . . . . . . . . . . . . . . . 4
4. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. New value in REQUESTED-TRANSPORT . . . . . . . . . . . . . . . 5
6. New CONNECT-STAT Attribute . . . . . . . . . . . . . . . . . . 5
7. New Error Reponse Codes . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9.1. New STUN Requests, Responses, and Indications . . . . . . . 6
9.2. New STUN Attributes . . . . . . . . . . . . . . . . . . . . 6
9.3. New STUN response codes . . . . . . . . . . . . . . . . . . 6
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
12. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 7
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
14.1. Normative References . . . . . . . . . . . . . . . . . . . 7
14.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Rosenberg & Mahy Expires May 14, 2008 [Page 2]
Internet-Draft TURN TCP November 2007
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 [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
Rosenberg & Mahy Expires May 14, 2008 [Page 3]
Internet-Draft TURN TCP November 2007
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.
Rosenberg & Mahy Expires May 14, 2008 [Page 4]
Internet-Draft TURN TCP November 2007
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.