idnits 2.17.1
draft-patil-tram-turn-serv-disc-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
== There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses
in the document. If these are example addresses, they should be changed.
-- The document has examples using IPv4 documentation addresses according
to RFC6890, but does not use any IPv6 documentation addresses. Maybe
there should be IPv6 examples, too?
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (May 2, 2014) is 3647 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-07) exists of
draft-wing-mmusic-ice-mobility-06
** Obsolete normative reference: RFC 3188 (Obsoleted by RFC 8458)
** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656)
Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 TRAM P. Patil
3 Internet-Draft T. Reddy
4 Intended status: Standards Track D. Wing
5 Expires: November 3, 2014 Cisco
6 May 2, 2014
8 TURN Server Auto Discovery
9 draft-patil-tram-turn-serv-disc-01
11 Abstract
13 Current Traversal Using Relays around NAT (TURN) server discovery
14 mechanisms are relatively static and limited to explicit
15 configuration. These are usually under the administrative control of
16 the application or TURN service provider, and not the enterprise or
17 the ISP, the network in which the client is located. Enterprises and
18 ISPs wishing to provide their own TURN servers need auto discovery
19 mechanisms that a TURN client could use with no or minimal
20 configuration. This document describes two such mechanisms for TURN
21 server discovery.
23 Status of This Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at http://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on November 3, 2014.
40 Copyright Notice
42 Copyright (c) 2014 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 3. Discovery Procedure . . . . . . . . . . . . . . . . . . . . . 3
60 4. Discovery using Service Resolution . . . . . . . . . . . . . 4
61 4.1. Retrieving Domain Name . . . . . . . . . . . . . . . . . 4
62 4.1.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 4
63 4.1.2. IP Address . . . . . . . . . . . . . . . . . . . . . 5
64 4.1.3. From own Identity . . . . . . . . . . . . . . . . . . 5
65 4.2. Resolution . . . . . . . . . . . . . . . . . . . . . . . 5
66 4.2.1. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 6
67 5. Discovery using Anycast . . . . . . . . . . . . . . . . . . . 7
68 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 7
69 6.1. Mobility and Changing IP addresses . . . . . . . . . . . 7
70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
71 7.1. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 8
72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
73 8.1. Service Resolution . . . . . . . . . . . . . . . . . . . 8
74 8.2. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 8
75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
77 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
78 10.2. Informative References . . . . . . . . . . . . . . . . . 10
79 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 10
80 A.1. Change from draft-patil-tram-serv-disc-00 to -01 . . . . 10
81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
83 1. Introduction
85 TURN [RFC5766] is a protocol that is often used to improve the
86 connectivity of P2P applications. By providing a relay service, TURN
87 ensures that a connection can be established even when one or both
88 sides is incapable of a direct P2P connection. It is an important
89 building block for interactive, real-time communication using audio,
90 video, collaboration etc. While TURN services are extensively used
91 today, the means to auto discover TURN servers do not exist. TURN
92 clients are usually explicitly configured with a well known TURN
93 server. To allow TURN applications operate seamlessly across
94 different types of networks and encourage the use of TURN without the
95 need for manual configuration, it is important that there exists an
96 auto discovery mechanism for TURN services. WebRTC usages and
97 related extensions, which are mostly based on web applications, need
98 this immediately.
100 This document describes two discovery mechanisms. The reason for
101 providing two mechanisms is to maximize the opportunity for
102 discovery, based on the network in the which the TURN client sees
103 itself.
105 o A resolution mechanism based on straightforward Naming Authority
106 Pointer (S-NAPTR) resource records in the Domain Name System
107 (DNS). [RFC5928] describes details on retrieving a list of server
108 transport addresses from DNS that can be used to create a TURN
109 allocation.
111 o A mechanism based on anycast address for TURN.
113 In general, if a client wishes to communicate using one of its
114 interfaces using a specific IP address family, it SHOULD query the
115 TURN server(s) that has been discovered for that specific interface
116 and address family. How to select an interface and IP address
117 family, is out of the scope of this document.
119 2. Terminology
121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
123 document are to be interpreted as described in [RFC2119].
125 3. Discovery Procedure
127 A TURN client that implements the auto discovery algorithm MUST
128 proceed with discovery in the following order:
130 1. Local Configuration : Local or manual configuration should be
131 tried first, as it may be an explicit preferred choice of a user.
132 An implementation MAY give the user an opportunity (e.g., by
133 means of configuration file options or menu items) to specify a
134 TURN server for every address family.
136 2. Service Resolution : The TURN client attempts to perform TURN
137 service resolution using the DNS domain name that the host
138 belongs to OR the hosts' global IP address. The TURN client will
139 attempt to do this for each combination of interface and address
140 family. The retrieved DNS domain names OR IP addresses are then
141 used for NAPTR lookups.
143 3. Anycast : Send TURN allocate request to the assigned TURN anycast
144 request for each combination of interface and address family.
146 While it is expected that Step-3 be performed if Step-2 fails, an
147 implementation may choose to perform steps 2 and 3 in parallel.
149 4. Discovery using Service Resolution
151 This mechanism is performed in two steps:
153 1. A DNS domain name is retrieved for each combination of interface
154 and address family.
156 2. Retrieved DNS domain names are then used for S-NAPTR lookups as
157 per [RFC5928]. Further DNS lookups may be necessary to determine
158 TURN server IP address(es).
160 On hosts with more than one interface or address family (IPv4/v6),
161 the TURN server discovery procedure has to be run for each
162 combination of interface and address family.
164 4.1. Retrieving Domain Name
166 The domain, in which the client is located, can be determined using
167 one of the techniques provided below. An implementation can choose
168 to use any or all techniques.
170 Implementations may allow the user to specify a default name that is
171 used if no specific name has been configured. Other means of
172 retrieving domain names may be used, which are outside the scope of
173 this document e.g. local configuration.
175 4.1.1. DHCP
177 DHCP can be used to determine the domain name related to an
178 interface's point of network attachment. Network operators may
179 provide the domain name to be used for service discovery within an
180 access network using DHCP. [RFC5986] defines DHCP IPv4 and IPv6
181 access network domain name options to identify a domain name that is
182 suitable for service discovery within the access network. [RFC2132]
183 defines the DHCP IPv4 domain name option. While this option is less
184 suitable, it still may be useful if the option defined in [RFC5986]
185 is not available.
187 For IPv6, the TURN server discovery procedure MUST try to retrieve
188 DHCP option 57 (OPTION_V6_ACCESS_DOMAIN). If no such option can be
189 retrieved, the procedure fails for this interface. For IPv4, the
190 TURN server discovery procedure MUST try to retrieve DHCP option 213
191 (OPTION_V4_ACCESS_DOMAIN). If no such option can be retrieved, the
192 procedure SHOULD try to retrieve option 15 (Domain Name). If neither
193 option can be retrieved the procedure fails for this interface. If a
194 result can be retrieved it will be used as an input for S-NAPTR
195 resolution.
197 4.1.2. IP Address
199 Typically, but not necessarily, the DNS domain name is the domain
200 name in which the client is located, i.e., a PTR lookup on the
201 client's IP address (according to [RFC1035], Section 3.5 for IPv4 or
202 [RFC3596], Section 2.5 for IPv6) would yield a similar name.
203 However, due to the widespread use of Network Address Translation
204 (NAT), the client MAY need to determine its public IP address using
205 mechanisms described in [I-D.ietf-geopriv-res-gw-lis-discovery].
207 4.1.3. From own Identity
209 A TURN client could also wish to extract the domain name from its own
210 identity i.e canonical identifier used to reach the user.
212 Example
214 SIP : 'sip:alice@example.com'
215 JID : 'alice@example.com'
216 email : 'alice@example.com'
218 'example.com' is retrieved from the above examples.
220 The means to extract the domain name may be different based on the
221 type of identifier and is outside the scope of this document.
223 4.2. Resolution
225 Once the TURN discovery procedure has retrieved domain names, the
226 resolution mechanism described in [RFC5928] is followed. An S-NAPTR
227 lookup with 'RELAY' application service and the desired protocol tag
228 is made to obtain information necessary to connect to the
229 authoritative TURN server within the given domain.
231 In the example below, for domain 'example.net', the resolution
232 algorithm will result in IP address, port, and protocol tuples as
233 follows:
235 example.net.
236 IN NAPTR 100 10 "" RELAY:turn.udp "" example.net.
238 example.net.
239 IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net.
241 _turn._udp.example.net.
242 IN SRV 0 0 3478 a.example.net.
244 a.example.net.
245 IN A 192.0.2.1
247 +-------+----------+------------+------+
248 | Order | Protocol | IP address | Port |
249 +-------+----------+------------+------+
250 | 1 | UDP | 192.0.2.1 | 3478 |
251 +-------+----------+------------+------+
253 If no TURN-specific S-NAPTR records can be retrieved, the discovery
254 procedure fails for this domain name (and the corresponding interface
255 and IP protocol version). If more domain names are known, the
256 discovery procedure may perform the corresponding S-NAPTR lookups
257 immediately. However, before retrying a lookup that has failed, a
258 client MUST wait a time period that is appropriate for the
259 encountered error (NXDOMAIN, timeout, etc.).
261 4.2.1. SOA
263 If no TURN-specific S-NAPTR records can be retrieved using the
264 previous step, additional steps described in this section have to be
265 followed. First, an SOA record for the "reverse zone" i.e., the zone
266 in the in-addr.arpa. or ip6.arpa. domain that contains the IP
267 address(s) in question, has to be retrieved. IP addresses can be
268 determined, if not done already, as described in Section 4.1.2.
270 A sample SOA record could be:
272 100.51.198.in-addr.arpa
273 IN SOA dns1.isp.example.net. hostmaster.isp.example.net. (
274 1 ; Serial
275 604800 ; Refresh
276 86400 ; Retry
277 2419200 ; Expire
278 604800 ) ; Negative Cache TTL
280 If this lookup fails, the discovery procedure is aborted without a
281 result.
283 Once the SOA record is available, the discovery procedure extracts
284 the MNAME field, i.e., the responsible master name server from the
285 SOA record. An example MNAME could be: dns1.isp.example.net. Then,
286 an S-NAPTR lookup as specified in the previous step Section 4.2 is
287 performed on this MNAME to discover the TURN service. If no TURN-
288 specific S-NAPTR records can be retrieved, the discovery procedure
289 fails for this domain name (and the corresponding interface and IP
290 protocol version).
292 5. Discovery using Anycast
294 IP anycast is an elegant solution for TURN service discovery. A
295 packet sent to an anycast address is delivered to the "topologically
296 nearest" network interface with the anycast address. Using the TURN
297 anycast address, the only two things that need to be deployed in the
298 network are the two things that actually use TURN.
300 When a client requires TURN services, it sends a TURN allocate
301 request to the assigned anycast address. The TURN anycast server
302 responds with a 300 (Try Alternate) error as described in [RFC5766];
303 The response contains the TURN unicast address in the ALTERNATE-
304 SERVER attribute. For subsequent communication with the TURN server,
305 the client uses the responding server's unicast address. This has to
306 be done because two packets addressed to an anycast address may reach
307 two different anycast servers. The client, thus, also needs to
308 ensure that the initial request fits in a single packet. An
309 implementation may choose to send out every new request to the
310 anycast address to learn the closest TURN server each time.
312 6. Deployment Considerations
314 6.1. Mobility and Changing IP addresses
316 A change of IP address on an interface may invalidate the result of
317 the TURN server discovery procedure. For instance, if the IP address
318 assigned to a mobile host changes due to host mobility, it may be
319 required to re-run the TURN server discovery procedure without
320 relying on earlier gained information. New requests should be made
321 to the newly learned TURN servers learned after TURN discovery re-
322 run. However, if an earlier learned TURN server is still accessible
323 using the new IP address, procedures described for mobility using
324 TURN defined in [I-D.wing-mmusic-ice-mobility] can be used for
325 ongoing streams.
327 7. IANA Considerations
329 7.1. Anycast
331 IANA should allocate an IPv4 and an IPv6 well-known TURN anycast
332 address. 192.0.0.0/24 and 2001:0000::/48 are reserved for IETF
333 Protocol Assignments, as listed at
335 and
337
339 8. Security Considerations
341 In general, it is recommended that a TURN client authenticate with
342 the TURN server to identify a rouge server.
343 [I-D.petithuguenin-tram-turn-dtls] can be potentially used by a
344 client to validate a previously unknown server.
346 8.1. Service Resolution
348 The primary attack against the methods described in this document is
349 one that would lead to impersonation of a TURN server. An attacker
350 could attempt to compromise the S-NAPTR resolution. Security
351 considerations described in [RFC5928] are applicable here as well.
353 In addition to considerations related to S-NAPTR, it is important to
354 recognize that the output of this is entirely dependent on its input.
355 An attacker who can control the domain name can also control the
356 final result. Because more than one method can be used to determine
357 the domain name, a host implementation needs to consider attacks
358 against each of the methods that are used.
360 If DHCP is used, the integrity of DHCP options is limited by the
361 security of the channel over which they are provided. Physical
362 security and separation of DHCP messages from other packets are
363 commonplace methods that can reduce the possibility of attack within
364 an access network; alternatively, DHCP authentication [RFC3188] can
365 provide a degree of protection against modification. When using DHCP
366 discovery, clients are encouraged to use unicast DHCP INFORM queries
367 instead of broadcast queries which are more easily spoofed in
368 insecure networks.
370 8.2. Anycast
372 In a network without any TURN server that is aware of the TURN
373 anycast address, outgoing TURN requests could leak out onto the
374 external Internet, possibly revealing information.
376 Using an IANA-assigned well-known TURN anycast address enables border
377 gateways to block such outgoing packets. In the default-free zone,
378 routers should be configured to drop such packets. Such
379 configuration can occur naturally via BGP messages advertising that
380 no route exists to said address.
382 Sensitive clients that do not wish to leak information about their
383 presence can set an IP TTL on their TURN requests that limits how far
384 they can travel into the public Internet.
386 9. Acknowledgements
388 Discovery using Service Resolution described in Section 4 of this
389 document was derived from similar techniques described in ALTO Server
390 Discovery [I-D.ietf-alto-server-discovery] and
391 [I-D.kist-alto-3pdisc].
393 10. References
395 10.1. Normative References
397 [I-D.ietf-geopriv-res-gw-lis-discovery]
398 Thomson, M. and R. Bellis, "Location Information Server
399 (LIS) Discovery using IP address and Reverse DNS", draft-
400 ietf-geopriv-res-gw-lis-discovery-08 (work in progress),
401 December 2013.
403 [I-D.petithuguenin-tram-turn-dtls]
404 Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
405 Layer Security (DTLS) as Transport for Traversal Using
406 Relays around NAT (TURN)", draft-petithuguenin-tram-turn-
407 dtls-00 (work in progress), January 2014.
409 [I-D.wing-mmusic-ice-mobility]
410 Wing, D., Reddy, T., Patil, P., and P. Martinsen,
411 "Mobility with ICE (MICE)", draft-wing-mmusic-ice-
412 mobility-06 (work in progress), February 2014.
414 [RFC1035] Mockapetris, P., "Domain names - implementation and
415 specification", STD 13, RFC 1035, November 1987.
417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
418 Requirement Levels", BCP 14, RFC 2119, March 1997.
420 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
421 Extensions", RFC 2132, March 1997.
423 [RFC3188] Hakala, J., "Using National Bibliography Numbers as
424 Uniform Resource Names", RFC 3188, October 2001.
426 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
427 "DNS Extensions to Support IP Version 6", RFC 3596,
428 October 2003.
430 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
431 Relays around NAT (TURN): Relay Extensions to Session
432 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
434 [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT
435 (TURN) Resolution Mechanism", RFC 5928, August 2010.
437 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
438 Location Information Server (LIS)", RFC 5986, September
439 2010.
441 10.2. Informative References
443 [I-D.ietf-alto-server-discovery]
444 Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
445 S. Yongchao, "ALTO Server Discovery", draft-ietf-alto-
446 server-discovery-10 (work in progress), September 2013.
448 [I-D.kist-alto-3pdisc]
449 Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party
450 ALTO Server Discovery (3pdisc)", draft-kist-alto-3pdisc-05
451 (work in progress), January 2014.
453 Appendix A. Change History
455 [Note to RFC Editor: Please remove this section prior to
456 publication.]
458 A.1. Change from draft-patil-tram-serv-disc-00 to -01
460 o Added IP address (Section 4.1.2) and Own identity (4.1.3) as new
461 means to obtain domain names
463 o New Section 4.2.1 SOA (inspired by draft-kist-alto-3pdisc)
465 o 300 (Try Alternate) response for Anycast
467 Authors' Addresses
469 Prashanth Patil
470 Cisco Systems, Inc.
471 Bangalore
472 India
474 Email: praspati@cisco.com
476 Tirumaleswar Reddy
477 Cisco Systems, Inc.
478 Cessna Business Park, Varthur Hobli
479 Sarjapur Marathalli Outer Ring Road
480 Bangalore, Karnataka 560103
481 India
483 Email: tireddy@cisco.com
485 Dan Wing
486 Cisco Systems, Inc.
487 170 West Tasman Drive
488 San Jose, California 95134
489 USA
491 Email: dwing@cisco.com