1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
|
Internet Engineering Task Force (IETF) M. Petit-Huguenin
Request for Comments: 5928 Unaffiliated
Category: Standards Track August 2010
ISSN: 2070-1721
Traversal Using Relays around NAT (TURN) Resolution Mechanism
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 is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5928.
Copyright Notice
Copyright (c) 2010 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 Simplified BSD License.
Petit-Huguenin Standards Track [Page 1]
^L
RFC 5928 TURN Resolution August 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Resolution Mechanism . . . . . . . . . . . . . . . . . . . . . 3
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Multiple Protocols . . . . . . . . . . . . . . . . . . . . 6
4.2. Remote Hosting . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Compatibility with TURN . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. RELAY Application Service Tag Registration . . . . . . . . 9
6.2. turn.udp Application Protocol Tag Registration . . . . . . 9
6.3. turn.tcp Application Protocol Tag Registration . . . . . . 9
6.4. turn.tls Application Protocol Tag Registration . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
1. Introduction
The Traversal Using Relays around NAT (TURN) specification [RFC5766]
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 does not allow the TURN client
to discover this preference. This document defines an S-NAPTR
application [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], Section 4.4. For
example, a Voice over IP (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 sees fit.
[TURN-URI] can be used as a convenient way of carrying the four
components (see Section 3) needed by the resolution mechanism
described in this document. A reference implementation is available
[REF-IMPL].
Petit-Huguenin Standards Track [Page 2]
^L
RFC 5928 TURN Resolution August 2010
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].
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 mechanism only
selects the transport used between the TURN client and the TURN
server. The transport used by the allocation itself is selected by
the REQUESTED-TRANSPORT attribute as described in Section 6.1 of
[RFC5766].
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. These 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 supported TURN transports (UDP, TCP,
Transport Layer Security (TLS)), that is provided by the application
using the TURN client. This list reflects the capabilities and
preferences of the application code that is using the S-NAPTR
resolver and TURN client, 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 [RFC5766]
is processed as a failure, as specified by [RFC3958], 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 temporarily blacklisted as described
in Section 6.4 of [RFC5766], specifically because of a 437, 486, or
508 error code, MUST 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:
Petit-Huguenin Standards Track [Page 3]
^L
RFC 5928 TURN Resolution August 2010
o If <secure> is false and <transport> is defined as "udp" but the
list of TURN transports supported by the application does not
contain UDP, then the resolution MUST stop with an error.
o If <secure> is false and <transport> is defined as "tcp" but the
list of TURN transports supported by the application does not
contain TCP, then the resolution MUST stop with an error.
o If <secure> is true and <transport> is defined as "udp", then the
resolution MUST stop with an error.
o If <secure> is true and <transport> is defined as "tcp" but the
list of TURN transports supported by the application does not
contain TLS, then the resolution MUST stop with an error.
o If <secure> is true and <transport> is not defined but the list of
TURN transports supported by the application does not contain TLS,
then the resolution MUST stop with an error.
o If <transport> is defined but unknown, then the resolution MUST
stop with an error.
After verifying the validity of the parameters, 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
Petit-Huguenin Standards Track [Page 4]
^L
RFC 5928 TURN Resolution August 2010
1. If <host> is an IP address, then it indicates the specific IP
address to be used. If <port> is not defined, then either the
default port declared in [RFC5766] 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] 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 (Proto) 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
[RFC5766] 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.
Petit-Huguenin Standards Track [Page 5]
^L
RFC 5928 TURN Resolution August 2010
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 Straightforward
Naming Authority Pointer (S-NAPTR) algorithm defined in [RFC3958]
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] 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 (Proto),
<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 these 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
[RFC5766] 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.
4. Examples
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>=false, <host>="example.net", <port>=empty,
<transport>=empty) to the list of IP address, port, and protocol
tuples in Table 2.
Petit-Huguenin Standards Track [Page 6]
^L
RFC 5928 TURN Resolution August 2010
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
+-------+----------+------------+------+
| Order | Protocol | IP address | Port |
+-------+----------+------------+------+
| 1 | UDP | 192.0.2.1 | 3478 |
| 2 | TLS | 192.0.2.1 | 5349 |
| 3 | TCP | 192.0.2.1 | 5000 |
+-------+----------+------------+------+
Table 2
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 as in the previous example but with the <host> parameter
equal to "example.com" to the list of IP address, port, and protocol
tuples in Table 2.
example.com.
IN NAPTR 100 10 "" RELAY:turn.udp:turn.tcp:turn.tls "" example.net.
Figure 2
Petit-Huguenin Standards Track [Page 7]
^L
RFC 5928 TURN Resolution August 2010
4.3. Compatibility with TURN
In deployments where it is not possible to guarantee that all TURN
clients will support the resolution mechanism described in this
document, the DNS configuration should be done in a way that works
with both this resolution mechanism and the mechanism described in
[RFC5766]. The DNS RRs in Figure 3 can be used in conjunction with
the DNS RRs in Figures 1 and 2 for this purpose.
_turn._udp.example.com.
IN SRV 0 0 3478 a.example.net.
_turn._tcp.example.com.
IN SRV 0 0 5000 a.example.net.
_turns._tcp.example.com.
IN SRV 0 0 5349 a.example.net.
Figure 3
5. Security Considerations
Security considerations for TURN are discussed in [RFC5766].
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]. [RFC3958]
requests that an S-NAPTR application define 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 [RFC5766].
Additionally, the usage of TLS [RFC5246] 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] and by using the value of the <host>
parameter as the identity of the server to be verified.
An implication of this is that the server's certificate could need to
be changed when SRV or NAPTR records are added. For example, a
client using just A/AAAA records, and configured with
"turnserver.example.net", expects to find the name
"turnserver.example.net" in the certificate. If a second client uses
SRV records and is configured with <host> parameter "example.com", it
expects to find "example.com" in the certificate, even if the SRV
record at _turns._tcp.example.com points to turnserver.example.net.
Petit-Huguenin Standards Track [Page 8]
^L
RFC 5928 TURN Resolution August 2010
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]).
6.1. RELAY Application Service Tag Registration
Application Protocol Tag: RELAY
Intended usage: See Section 3.
Interoperability considerations: N/A
Security considerations: See Section 5.
Relevant publications: RFC 5928
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
6.2. turn.udp Application Protocol Tag Registration
Application Protocol Tag: turn.udp
Intended usage: See Section 3.
Interoperability considerations: N/A
Security considerations: See Section 5.
Relevant publications: RFC 5928
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
6.3. turn.tcp Application Protocol Tag Registration
Application Protocol Tag: turn.tcp
Intended usage: See Section 3.
Interoperability considerations: N/A
Security considerations: See Section 5.
Petit-Huguenin Standards Track [Page 9]
^L
RFC 5928 TURN Resolution August 2010
Relevant publications: RFC 5928
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
6.4. turn.tls Application Protocol Tag Registration
Application Protocol Tag: turn.tls
Intended usage: See Section 3.
Interoperability considerations: N/A
Security considerations: See Section 5.
Relevant publications: RFC 5928
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
7. Acknowledgements
Thanks to Cullen Jennings, Alexey Melnikov, Scott Bradner, Spencer
Dawkins, 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.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[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.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Petit-Huguenin Standards Track [Page 10]
^L
RFC 5928 TURN Resolution August 2010
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal
Using Relays around NAT (TURN): Relay Extensions to
Session Traversal Utilities for NAT (STUN)", RFC 5766,
April 2010.
8.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[TURN-URI] Petit-Huguenin, M., "Traversal Using Relays around NAT
(TURN) Uniform Resource Identifiers", Work in Progress,
January 2010.
[REF-IMPL] Petit-Huguenin, M., "Reference Implementation of TURN
resolver and TURN URI parser", January 2010, <http://
debian.implementers.org/stable/source/turnuri.tar.gz>.
Author's Address
Marc Petit-Huguenin
Unaffiliated
EMail: petithug@acm.org
Petit-Huguenin Standards Track [Page 11]
^L
|