TOC 
Network Working GroupM. Petit-Huguenin
Internet-Draft(Unaffiliated)
Intended status: Standards TrackNovember 25, 2009
Expires: May 29, 2010 


Traversal Using Relays around NAT (TURN) Resolution Mechanism
draft-ietf-behave-turn-uri-05

Abstract

This document defines a resolution mechanism to generate a list of server transport addresses that can be tried to create a Traversal Using Relays around NAT (TURN) allocation.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 29, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.



Table of Contents

1.  Introduction
2.  Terminology
3.  Resolution Mechanism
4.  Examples
    4.1.  Multiple Protocols
    4.2.  Remote Hosting
5.  Security Considerations
6.  IANA Considerations
    6.1.  RELAY Application Service Tag Registration
    6.2.  turn.udp Application Protocol Tag Registration
    6.3.  turn.tcp Application Protocol Tag Registration
    6.4.  turn.tls Application Protocol Tag Registration
7.  Acknowledgements
8.  References
    8.1.  Normative References
    8.2.  Informative References
Appendix A.  Release notes
    A.1.  Modifications between ietf-05 and ietf-04
    A.2.  Modifications between ietf-04 and ietf-03
    A.3.  Modifications between ietf-03 and ietf-02
    A.4.  Modifications between ietf-02 and ietf-01
    A.5.  Modifications between ietf-01 and ietf-00
    A.6.  Modifications between petithuguenin-03 and ietf-00
    A.7.  Modifications between petithuguenin-03 and petithuguenin-02
    A.8.  Modifications between petithuguenin-02 and petithuguenin-01
    A.9.  Modifications between petithuguenin-01 and petithuguenin-00
    A.10.  Design Notes
    A.11.  Running Code Considerations
    A.12.  TODO List
§  Author's Address




 TOC 

1.  Introduction

The TURN specification (Rosenberg, J., Mahy, R., and P. Matthews, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” July 2009.) [I‑D.ietf‑behave‑turn] defines a process for a TURN client to find TURN servers by using DNS SRV resource records, but this process does not let the TURN server administrators provision the preferred TURN transport protocol between the client and the server and for the TURN client to discover this preference. This document defines an S-NAPTR application (Daigle, L. and A. Newton, “Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS),” January 2005.) [RFC3958] for this purpose. This application defines "RELAY" as an application service tag and "turn.udp", "turn.tcp", and "turn.tls" as application protocol tags.

Another usage of the resolution mechanism described in this document would be Remote Hosting as described in [RFC3958] (Daigle, L. and A. Newton, “Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS),” January 2005.) section 4.4. For example a VoIP provider who does not want to deploy TURN servers could use the servers deployed by another company but could still want to provide configuration parameters to its customers without explicitly showing this relationship. The mechanism permits one to implement this indirection, without preventing the company hosting the TURN servers from managing them as it see fit.

[I‑D.petithuguenin‑behave‑turn‑uri‑bis] (Petit-Huguenin, M., “Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers,” November 2009.) can be used as a convenient way of carrying the four components needed by the resolution mechanism described in this document.



 TOC 

2.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

3.  Resolution Mechanism

The resolution mechanism is used only to create an allocation. All other transactions use the IP address, transport and port used for a successful allocation creation.

The resolution algorithm uses a boolean flag, <secure>; an IP address or domain name, <host>; a port number that can be empty, <port>; and a transport name that can be "udp", "tcp" or empty, <transport> as input. This four parameters are part of the user configuration of the TURN client. The resolution mechanism also uses as input a list ordered by preference of TURN transports (UDP, TCP, TLS) supported that is provided by the application using the TURN client. This list reflects the capabilities and preferences of the application code as opposed to the configuration parameters that reflect the preferences of the user of the application. The output of the algorithm is a list of {IP address, transport, port} tuples that a TURN client can try in order to create an allocation on a TURN server.

An Allocate error response as specified in section 6.4 of [I‑D.ietf‑behave‑turn] (Rosenberg, J., Mahy, R., and P. Matthews, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” July 2009.) is processed as a failure as specified by [RFC3958] (Daigle, L. and A. Newton, “Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS),” January 2005.) section 2.2.4. The resolution stops when a TURN client gets a successful Allocate response from a TURN server. After an allocation succeeds or all the allocations fail, the resolution context MUST be discarded and the resolution algorithm MUST be restarted from the beginning for any subsequent allocation. Servers blacklisted as described in section 6.4 of [I‑D.ietf‑behave‑turn] (Rosenberg, J., Mahy, R., and P. Matthews, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” July 2009.) SHOULD NOT be used for the specified duration even if returned by a subsequent resolution.

First the resolution algorithm checks that the parameters can be resolved with the list of TURN transports supported by the application:

After verifying the validity of the URI elements, the algorithm filters the list of TURN transports supported by the application by removing the UDP and TCP TURN transport if <secure> is true. If the list of TURN transports is empty after this filtering, the resolution MUST stop with an error.

After filtering the list of TURN transports supported by the application, the algorithm applies the steps described below. Note that in some steps, <secure> and <transport> have to be converted to a TURN transport. If <secure> is false and <transport> is defined as "udp" then the TURN UDP transport is used. If <secure> is false and <transport> is defined as "tcp" then the TURN TCP transport is used. If <secure> is true and <transport> is defined as "tcp" then the TURN TLS transport is used. This is summarized in Table 1.



<secure><transport>TURN Transport
false "udp" UDP
false "tcp" TCP
true "tcp" TLS

 Table 1 

  1. If <host> is an IP address, then it indicates the specific IP address to be used. If <port> is not defined, the default port declared in [I‑D.ietf‑behave‑turn] (Rosenberg, J., Mahy, R., and P. Matthews, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” July 2009.) for the "turn" SRV service name if <secure> is false, or the "turns" SRV service name if <secure> is true MUST be used for contacting the TURN server. If <transport> is defined then <secure> and <transport> are converted to a TURN transport as specified in Table 1. If <transport> is not defined, the filtered TURN transports supported by the application are tried by preference order. If the TURN client cannot contact a TURN server with this IP address and port on any of the transports supported by the application then the resolution MUST stop with an error.

  2. If <host> is a domain name and <port> is defined, then <host> is resolved to a list of IP addresses via DNS A and AAAA queries. If <transport> is defined, then <secure> and <transport> are converted to a TURN transport as specified in Table 1. If <transport> is not defined, the filtered TURN transports supported by the application are tried in preference order. The TURN client can choose the order to contact the resolved IP addresses in any implementation-specific way. If the TURN client cannot contact a TURN server with this port, the transport or list of transports, and the resolved IP addresses, then the resolution MUST stop with an error.

  3. If <host> is a domain name and <port> is not defined but <transport> is defined, then the SRV algorithm defined in [RFC2782] (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.) is used to generate a list of IP address and port tuples. <host> is used as Name, a value of false for <secure> as "turn" for Service, a value of true for <secure> as "turns" for Service and <transport> as Protocol in the SRV algorithm. <secure> and <transport> are converted to a TURN transport as specified in Table 1 and this transport is used with each tuple for contacting the TURN server. The SRV algorithm recommends doing an A query if the SRV query returns an error or no SRV RR; in this case the default port declared in [I‑D.ietf‑behave‑turn] (Rosenberg, J., Mahy, R., and P. Matthews, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” July 2009.) for the "turn" SRV service name if <secure> is false, or the "turns" SRV service name if <secure> is true MUST be used for contacting the TURN server. Also in this case, this specification modifies the SRV algorithm by recommending an A and AAAA query. If the TURN client cannot contact a TURN server at any of the IP address and port tuples returned by the SRV algorithm with the transport converted from <secure> and <transport> then the resolution MUST stop with an error.

  4. If <host> is a domain name and <port> and <transport> are not defined, then <host> is converted to an ordered list of IP address, port and transport tuples via the S-NAPTR algorithm defined in [RFC3958] (Daigle, L. and A. Newton, “Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS),” January 2005.) by using <host> as the initial target domain name and "RELAY" as the Application Service Tag. The filtered list of TURN transports supported by the application are converted in Application Protocol Tags by using "turn.udp" if the TURN transport is UDP, "turn.tcp" if the TURN transport is TCP and "turn.tls" if the TURN transport is TLS. The order to try the Application Protocol Tags is provided by the ranking of the first set of NAPTR records. If multiple Application Protocol Tags have the same ranking, the preferred order set by the application is used. If the first NAPTR query fails, the processing continues in step 5. If the TURN client cannot contact a TURN server with any of the IP address, port and transport tuples returned by the S-NAPTR algorithm then the resolution MUST stop with an error.

  5. If the first NAPTR query in the previous step does not return any result then the SRV algorithm defined in [RFC2782] (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.) is used to generate a list of IP address and port tuples. The SRV algorithm is applied by using each transport in the filtered list of TURN transports supported by the application for the Protocol, <host> for the Name, "turn" for the Service if <secure> is false or "turns" for the Service if <secure> is true. The same transport that was used to generate a list of tuples is used with each of this tuples for contacting the TURN server. The SRV algorithm recommends doing an A query if the SRV query returns an error or no SRV RR; in this case the default port declared in [I‑D.ietf‑behave‑turn] (Rosenberg, J., Mahy, R., and P. Matthews, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” July 2009.) for the "turn" SRV service name if <secure> is false, or the "turns" SRV service name if <secure> is true MUST be used for contacting the TURN server. Also in this case, this specification modifies the SRV algorithm by recommending an A and AAAA query. If the TURN client cannot contact a TURN server at any of the IP address and port tuples returned by the SRV algorithm with the transports from the filtered list then the resolution MUST stop with an error.



 TOC 

4.  Examples



 TOC 

4.1.  Multiple Protocols

With the DNS RRs in Figure 1 and an ordered TURN transport list of {TLS, TCP, UDP}, the resolution algorithm will convert the parameters <secure> with a value of false, <host> with a value of "example.net" and <port> and <transport> been empty to the list of IP addresses, port and protocol tuples in Table 2.



example.net.
IN NAPTR 100 10 "" RELAY:turn.udp "" datagram.example.net.
IN NAPTR 200 10 "" RELAY:turn.tcp:turn.tls "" stream.example.net.

datagram.example.net.
IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net.

stream.example.net.
IN NAPTR 100 10 S RELAY:turn.tcp "" _turn._tcp.example.net.
IN NAPTR 200 10 A RELAY:turn.tls "" a.example.net.

_turn._udp.example.net.
IN SRV   0 0 3478 a.example.net.

_turn._tcp.example.net.
IN SRV   0 0 5000 a.example.net.

a.example.net.
IN A     192.0.2.1

 Figure 1 



OrderProtocolIP addressPort
1 UDP 192.0.2.1 3478
2 TLS 192.0.2.1 5349
3 TCP 192.0.2.1 5000

 Table 2 



 TOC 

4.2.  Remote Hosting

In the example in Figure 2, a VoIP provider (example.com) is using the TURN servers managed by the administrators of the example.net domain (defined in Figure 1). The resolution algorithm using the ordered TURN transport list of {TLS, TCP, UDP} would convert the same parameters than in the previous example but with the <host> parameter equal to "example.com" to the list of IP addresses, port and protocol tuples in Table 2.




example.com.
IN NAPTR 100 10 "" "RELAY:turn.udp:turn.tcp:turn.tls" "" example.net.

 Figure 2 



 TOC 

5.  Security Considerations

Security considerations for TURN are discussed in [I‑D.ietf‑behave‑turn] (Rosenberg, J., Mahy, R., and P. Matthews, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” July 2009.).

The Application Service Tag and Application Protocol Tags defined in this document do not introduce any specific security issues beyond the security considerations discussed in [RFC3958] (Daigle, L. and A. Newton, “Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS),” January 2005.). [RFC3958] (Daigle, L. and A. Newton, “Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS),” January 2005.) requests that an S-NAPTR application defines some form of end-to-end authentication to ensure that the correct destination has been reached. This is achieved by the Long-Term Credential Mechanism defined in [RFC5389], which is mandatory for TURN (Rosenberg, J., Mahy, R., and P. Matthews, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” July 2009.) [I‑D.ietf‑behave‑turn]. Additionally the usage of TLS has the capability to address the requirement. In this case the client MUST verify the identity of the server by following the identification procedure in section 7.2.2 of [RFC5389] (Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for NAT (STUN),” October 2008.).



 TOC 

6.  IANA Considerations

This section contains the registration information for one S-NAPTR Application Service Tag and three S-NAPTR Application Protocol Tags (in accordance with [RFC3958] (Daigle, L. and A. Newton, “Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS),” January 2005.)).



 TOC 

6.1.  RELAY Application Service Tag Registration

Application Protocol Tag: RELAY

Intended usage: See Section 3 (Resolution Mechanism).

Interoperability considerations: N/A

Security considerations: See Section 5 (Security Considerations).

Relevant publications: This document.

Contact information: Marc Petit-Huguenin <petithug@acm.org>

Author/Change controller: The IESG



 TOC 

6.2.  turn.udp Application Protocol Tag Registration

Application Protocol Tag: turn.udp

Intended usage: See Section 3 (Resolution Mechanism).

Interoperability considerations: N/A

Security considerations: See Section 5 (Security Considerations).

Relevant publications: This document.

Contact information: Marc Petit-Huguenin <petithug@acm.org>

Author/Change controller: The IESG



 TOC 

6.3.  turn.tcp Application Protocol Tag Registration

Application Protocol Tag: turn.tcp

Intended usage: See Section 3 (Resolution Mechanism).

Interoperability considerations:

Security considerations: See Section 5 (Security Considerations).

Relevant publications: This document.

Contact information: Marc Petit-Huguenin <petithug@acm.org>

Author/Change controller: The IESG



 TOC 

6.4.  turn.tls Application Protocol Tag Registration

Application Protocol Tag: turn.tls

Intended usage: See Section 3 (Resolution Mechanism).

Interoperability considerations: N/A

Security considerations: See Section 5 (Security Considerations).

Relevant publications: This document.

Contact information: Marc Petit-Huguenin <petithug@acm.org>

Author/Change controller: The IESG



 TOC 

7.  Acknowledgements

Thanks to Pasi Eronen, Margaret Wasserman, Magnus Westerlund, Juergen Schoenwaelder, Sean Turner, Ted Hardie, Dave Thaler, Alfred E. Heggestad, Eilon Yardeni, Dan Wing, Alfred Hoenes and Jim Kleck for their comments, suggestions and questions that helped to improve this document.

This document was written with the xml2rfc tool described in [RFC2629] (Rose, M., “Writing I-Ds and RFCs using XML,” June 1999.).



 TOC 

8.  References



 TOC 

8.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” RFC 2782, February 2000 (TXT).
[RFC3958] Daigle, L. and A. Newton, “Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS),” RFC 3958, January 2005 (TXT).
[RFC5234] Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” STD 68, RFC 5234, January 2008 (TXT).
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for NAT (STUN),” RFC 5389, October 2008 (TXT).
[I-D.ietf-behave-turn] Rosenberg, J., Mahy, R., and P. Matthews, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” draft-ietf-behave-turn-16 (work in progress), July 2009 (TXT).


 TOC 

8.2. Informative References

[RFC2629] Rose, M., “Writing I-Ds and RFCs using XML,” RFC 2629, June 1999 (TXT, HTML, XML).
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, “Guidelines and Registration Procedures for New URI Schemes,” BCP 35, RFC 4395, February 2006 (TXT).
[I-D.petithuguenin-behave-turn-uri-bis] Petit-Huguenin, M., “Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers,” draft-petithuguenin-behave-turn-uri-bis-00 (work in progress), November 2009 (TXT).


 TOC 

Appendix A.  Release notes

This section must be removed before publication as an RFC.



 TOC 

A.1.  Modifications between ietf-05 and ietf-04



 TOC 

A.2.  Modifications between ietf-04 and ietf-03



 TOC 

A.3.  Modifications between ietf-03 and ietf-02



 TOC 

A.4.  Modifications between ietf-02 and ietf-01



 TOC 

A.5.  Modifications between ietf-01 and ietf-00



 TOC 

A.6.  Modifications between petithuguenin-03 and ietf-00



 TOC 

A.7.  Modifications between petithuguenin-03 and petithuguenin-02



 TOC 

A.8.  Modifications between petithuguenin-02 and petithuguenin-01



 TOC 

A.9.  Modifications between petithuguenin-01 and petithuguenin-00



 TOC 

A.10.  Design Notes



 TOC 

A.11.  Running Code Considerations



 TOC 

A.12.  TODO List

(Empty)



 TOC 

Author's Address

  Marc Petit-Huguenin
  (Unaffiliated)
Email:  petithug@acm.org