[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 rfc6062                               
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.


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:






Rosenberg & Mahy          Expires May 14, 2008                  [Page 5]


Internet-Draft                  TURN TCP                   November 2007


   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








Rosenberg & Mahy          Expires May 14, 2008                  [Page 6]


Internet-Draft                  TURN TCP                   November 2007


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 [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 [9].


13.  Acknowledgements

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


14.  References

14.1.  Normative References

   [1]   Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D.
         Wing, "Session Traversal Utilities for (NAT) (STUN)",
         draft-ietf-behave-rfc3489bis-11 (work in progress),
         October 2007.

   [2]   Rosenberg, J., "Traversal Using Relays around NAT (TURN): Relay
         Extensions to Session  Traversal Utilities for NAT (STUN)",
         draft-ietf-behave-turn-04 (work in progress), July 2007.

   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.




Rosenberg & Mahy          Expires May 14, 2008                  [Page 7]


Internet-Draft                  TURN TCP                   November 2007


14.2.  Informative References

   [4]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
         "RTP: A Transport Protocol for Real-Time Applications", STD 64,
         RFC 3550, July 2003.

   [5]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.

   [6]   Kent, S., "IP Authentication Header", RFC 4302, December 2005.

   [7]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
         December 2005.

   [8]   Daigle, L. and IAB, "IAB Considerations for UNilateral Self-
         Address Fixing (UNSAF) Across Network Address Translation",
         RFC 3424, November 2002.

   [9]   Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
         Protocol for Network Address  Translator (NAT) Traversal for
         Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in
         progress), October 2007.

   [10]  Audet, F. and C. Jennings, "NAT Behavioral Requirements for
         Unicast UDP", draft-ietf-behave-nat-udp-08 (work in progress),
         October 2006.


Authors' Addresses

   Jonathan Rosenberg
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

   Phone: +1 973 952-5000
   Email: jdrosen@cisco.com
   URI:   http://www.jdrosen.net


   Rohan Mahy
   Plantronics, Inc.

   Email: rohan@ekabal.com






Rosenberg & Mahy          Expires May 14, 2008                  [Page 8]


Internet-Draft                  TURN TCP                   November 2007


Full Copyright Statement

   Copyright (C) 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).





Rosenberg & Mahy          Expires May 14, 2008                  [Page 9]