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
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
|
<pre>Internet Engineering Task Force (IETF) M. Petit-Huguenin
Request for Comments: 7350 Jive Communications
Updates: <a href="./rfc5389">5389</a>, <a href="./rfc5928">5928</a> G. Salgueiro
Category: Standards Track Cisco Systems
ISSN: 2070-1721 August 2014
<span class="h1">Datagram Transport Layer Security (DTLS) as Transport</span>
<span class="h1">for Session Traversal Utilities for NAT (STUN)</span>
Abstract
This document specifies the usage of Datagram Transport Layer
Security (DTLS) as a transport protocol for Session Traversal
Utilities for NAT (STUN). It provides guidance on when and how to
use DTLS with the currently standardized STUN usages. It also
specifies modifications to the STUN and Traversal Using Relay NAT
(TURN) URIs and to the TURN resolution mechanism to facilitate the
resolution of STUN and TURN URIs into the IP address and port of STUN
and TURN servers supporting DTLS as a transport protocol. This
document updates RFCs 5389 and 5928.
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 <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7350">http://www.rfc-editor.org/info/rfc7350</a>.
<span class="grey">Petit-Huguenin & Salgueiro Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7350">RFC 7350</a> STUN over DTLS August 2014</span>
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. DTLS as Transport for STUN . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-4">4</a>. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. NAT Discovery Usage . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4.1.1">4.1.1</a>. DTLS Support in STUN URIs . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.2">4.2</a>. Connectivity Check Usage . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.3">4.3</a>. Media Keep-Alive Usage . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.4">4.4</a>. SIP Keep-Alive Usage . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.5">4.5</a>. NAT Behavior Discovery Usage . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.6">4.6</a>. TURN Usage . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.6.1">4.6.1</a>. DTLS Support in TURN URIs . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.6.2">4.6.2</a>. Resolution Mechanism for TURN over DTLS . . . . . . . <a href="#page-7">7</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6">6</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6.1">6.1</a>. S-NAPTR Application Protocol Tag . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6.2">6.2</a>. Service Name and Transport Protocol Port Number . . . . . <a href="#page-9">9</a>
<a href="#section-6.2.1">6.2.1</a>. The "stuns" Service Name . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6.2.2">6.2.2</a>. The "turns" Service Name . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-7">7</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#appendix-A">Appendix A</a>. Examples . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<span class="grey">Petit-Huguenin & Salgueiro Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7350">RFC 7350</a> STUN over DTLS August 2014</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
STUN [<a href="./rfc5389" title=""Session Traversal Utilities for NAT (STUN)"">RFC5389</a>] defines Transport Layer Security (TLS) over TCP
(simply referred to as TLS [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>]) as the transport for STUN due
to additional security advantages it offers over plain UDP or TCP
transport. But, TCP (and thus TLS-over-TCP) is not an optimal
transport when STUN is used for its originally intended purpose,
which is to support multimedia sessions. This is a well documented
and understood transport limitation for real-time communications.
DTLS-over-UDP (referred to in this document as simply DTLS [<a href="./rfc6347" title=""Datagram Transport Layer Security Version 1.2"">RFC6347</a>])
offers the same security advantages as TLS-over-TCP, but without the
undesirable concerns.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] when
they appear in ALL CAPS. When these words are not in ALL CAPS (such
as "must" or "Must"), they have their usual English meanings, and are
not to be interpreted as <a href="./rfc2119">RFC 2119</a> key words.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. DTLS as Transport for STUN</span>
STUN [<a href="./rfc5389" title=""Session Traversal Utilities for NAT (STUN)"">RFC5389</a>] defines three transports: UDP, TCP, and TLS. This
document adds DTLS as a valid transport for STUN.
STUN over DTLS MUST use the same retransmission rules as STUN over
UDP (as described in <a href="./rfc5389#section-7.2.1">Section 7.2.1 of [RFC5389]</a>). It MUST also use
the same rules that are described in <a href="./rfc5389#section-7.2.2">Section 7.2.2 of [RFC5389]</a> to
verify the server identity. Instead of TLS_RSA_WITH_AES_128_CBC_SHA,
which is the default cipher suite for STUN over TLS, implementations
of STUN over DTLS, and deployed clients and servers, MUST support
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, and MAY support other cipher
suites. Perfect Forward Secrecy (PFS) cipher suites MUST be
preferred over non-PFS cipher suites. Cipher suites with known
weaknesses, such as those based on (single) DES and RC4, MUST NOT be
used. Implementations MUST disable TLS-level compression. The same
rules established in <a href="./rfc5389#section-7.2.2">Section 7.2.2 of [RFC5389]</a> for keeping open and
closing TCP/TLS connections MUST be used as well for DTLS
associations.
In addition to the path MTU rules described in <a href="./rfc5389#section-7.1">Section 7.1 of
[RFC5389]</a>, if the path MTU is unknown, the actual STUN message needs
to be adjusted to take into account the size of the (13-byte) DTLS
Record header, the MAC size, and the padding size.
<span class="grey">Petit-Huguenin & Salgueiro Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7350">RFC 7350</a> STUN over DTLS August 2014</span>
By default, STUN over DTLS MUST use port 5349, the same port number
as STUN over TLS. However, the Service Record (SRV) procedures can
be implemented to use a different port (as described in <a href="./rfc5389#section-9">Section 9 of
[RFC5389]</a>). When using SRV records, the service name MUST be set to
"stuns" and the protocol name to "udp".
Classic STUN [<a href="./rfc3489" title=""STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)"">RFC3489</a>] (which was obsoleted by [<a href="./rfc5389" title=""Session Traversal Utilities for NAT (STUN)"">RFC5389</a>]) defines
only UDP as a transport, and DTLS MUST NOT be used. Any STUN request
or indication without the magic cookie (see <a href="./rfc5389#section-6">Section 6 of [RFC5389]</a>)
over DTLS MUST always result in an error.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. STUN Usages</span>
<a href="./rfc5389#section-7.2">Section 7.2 of [RFC5389]</a> states that STUN usages must specify which
transport protocol is used. The following sections discuss if and
how the existing STUN usages are used with DTLS as the transport.
Future STUN usages MUST take into account DTLS as a transport and
discuss its applicability. In all cases, new STUN usages MUST
explicitly state if implementing the denial-of-service countermeasure
described in <a href="./rfc6347#section-4.2.1">Section 4.2.1 of [RFC6347]</a> is mandatory.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. NAT Discovery Usage</span>
As stated by <a href="./rfc5389#section-13">Section 13 of [RFC5389]</a>, "...TLS provides minimal
security benefits..." for this particular STUN usage. DTLS will also
similarly offer only limited benefit. This is because the only
mandatory attribute that is TLS/DTLS protected is the
XOR-MAPPED-ADDRESS, which is already known by an on-path attacker,
since it is the same as the source address and port of the STUN
request. On the other hand, using TLS/DTLS will prevent an active
attacker to inject XOR-MAPPED-ADDRESS in responses. The TLS/DTLS
transport will also protect the SOFTWARE attribute, which can be used
to find vulnerabilities in STUN implementations.
Regardless, this usage is rarely used by itself, since using TURN
[<a href="./rfc5766" title=""Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"">RFC5766</a>] with Interactive Connectivity Establishment (ICE) [<a href="./rfc5245" title=""Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols"">RFC5245</a>]
is generally indispensable, and TURN provides the same NAT Discovery
feature as part of an allocation creation. In fact, with ICE, the
NAT Discovery usage is only used when there is no longer any resource
available for new allocations in the TURN server.
A STUN server implementing the NAT Discovery usage and using DTLS
MUST implement the denial-of-service countermeasure described in
<a href="./rfc6347#section-4.2.1">Section 4.2.1 of [RFC6347]</a>.
<span class="grey">Petit-Huguenin & Salgueiro Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7350">RFC 7350</a> STUN over DTLS August 2014</span>
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. DTLS Support in STUN URIs</span>
This document does not make any changes to the syntax of a STUN URI
[<a href="./rfc7064" title=""URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol"">RFC7064</a>]. As indicated in <a href="./rfc7064#section-3.2">Section 3.2 of [RFC7064]</a>, secure
transports like STUN over TLS, and now STUN over DTLS, MUST use the
"stuns" URI scheme.
The <host> value MUST be used when using the rules in <a href="./rfc5389#section-7.2.2">Section 7.2.2
of [RFC5389]</a> to verify the server identity. A STUN URI containing an
IP address MUST be rejected, unless the domain name is provided by
the same mechanism that provided the STUN URI, and that domain name
can be passed to the verification code.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Connectivity Check Usage</span>
Using DTLS would hide the USERNAME, PRIORITY, USE-CANDIDATE,
ICE-CONTROLLED, and ICE-CONTROLLING attributes. But, because
MESSAGE-INTEGRITY protects the entire STUN response using a password
that is known only by looking at the Session Description Protocol
(SDP) exchanged, it is not possible for an attacker that does not
have access to this SDP to inject an incorrect XOR-MAPPED-ADDRESS,
which would subsequently be used as a peer reflexive candidate.
Adding DTLS on top of the connectivity check would delay, and
consequently impair, the ICE process. Adding additional round trips
to ICE is undesirable, so much that there is a proposal ([<a href="#ref-ICE-DTLS" title=""Using Datagram Transport Layer Security (DTLS) For Interactivity Connectivity Establishment (ICE) Connectivity Checking: ICE-DTLS"">ICE-DTLS</a>])
to use the DTLS handshake used by the WebRTC Secure Real-time
Transport Protocol (SRTP) streams as a replacement for the
connectivity checks.
STUN URIs are not used with this usage.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Media Keep-Alive Usage</span>
When STUN Binding Indications are being used for media keep-alive
(described in <a href="./rfc5245#section-10">Section 10 of [RFC5245]</a>), it runs alongside an RTP or
RTP Control Protocol (RTCP) session. It is possible to send these
media keep-alive packets inside a separately negotiated non-SRTP DTLS
session if DTLS-SRTP [<a href="./rfc5764" title=""Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)"">RFC5764</a>] is used, but that would add overhead,
with minimal security benefit.
STUN URIs are not used with this usage.
<span class="grey">Petit-Huguenin & Salgueiro Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7350">RFC 7350</a> STUN over DTLS August 2014</span>
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. SIP Keep-Alive Usage</span>
The SIP keep-alive (described in [<a href="./rfc5626" title=""Managing Client- Initiated Connections in the Session Initiation Protocol (SIP)"">RFC5626</a>]) runs inside a SIP flow.
This flow would be protected if a SIP over DTLS transport mechanism
is implemented (such as described in [<a href="#ref-SIP-DTLS" title=""Session Initiation Protocol (SIP) over Datagram Transport Layer Security (DTLS)"">SIP-DTLS</a>]).
STUN URIs are not used with this usage.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. NAT Behavior Discovery Usage</span>
The NAT Behavior Discovery usage is Experimental and to date has
never been effectively deployed. Despite this, using DTLS would add
the same security properties as for the NAT Discovery usage
(<a href="#section-4.1">Section 4.1</a>).
The STUN URI can be used to access the NAT Discovery feature of a NAT
Behavior Discovery server, but accessing the full features would
require definition of a "stun-behaviors:" URI, which is out of scope
for this document.
A STUN server implementing the NAT Behavior Discovery usage and using
DTLS MUST implement the denial-of-service countermeasure described in
<a href="./rfc6347#section-4.2.1">Section 4.2.1 of [RFC6347]</a>.
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. TURN Usage</span>
TURN [<a href="./rfc5766" title=""Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"">RFC5766</a>] defines three combinations of transports/allocations:
UDP/UDP, TCP/UDP, and TLS/UDP. This document adds DTLS/UDP as a
valid combination. A TURN server using DTLS MUST implement the
denial-of-service countermeasure described in <a href="./rfc6347#section-4.2.1">Section 4.2.1 of
[RFC6347]</a>.
[<a id="ref-RFC6062">RFC6062</a>] states that TCP allocations cannot be obtained using a UDP
association between client and server. The fact that DTLS uses UDP
implies that TCP allocations MUST NOT be obtained using a DTLS
association between client and server.
By default, TURN over DTLS uses port 5349, the same port number as
TURN over TLS. However, the SRV procedures can be implemented to use
a different port (as described in <a href="./rfc5766#section-6">Section 6 of [RFC5766]</a>). When
using SRV records, the service name MUST be set to "turns" and the
protocol name to "udp".
<span class="grey">Petit-Huguenin & Salgueiro Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7350">RFC 7350</a> STUN over DTLS August 2014</span>
<span class="h4"><a class="selflink" id="section-4.6.1" href="#section-4.6.1">4.6.1</a>. DTLS Support in TURN URIs</span>
This document does not make any changes to the syntax of a TURN URI
[<a href="./rfc7065" title=""Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers"">RFC7065</a>]. As indicated in <a href="./rfc7065#section-3">Section 3 of [RFC7065]</a>, secure transports
like TURN over TLS, and now TURN over DTLS, MUST use the "turns" URI
scheme. When using the "turns" URI scheme to designate TURN over
DTLS, the transport value of the TURN URI, if set, MUST be "udp".
The <host> value MUST be used when using the rules in <a href="./rfc5389#section-7.2.2">Section 7.2.2
of [RFC5389]</a> to verify the server identity. A TURN URI containing an
IP address MUST be rejected, unless the domain is provided by the
same mechanism that provided the TURN URI, and that domain name can
be passed to the verification code.
<span class="h4"><a class="selflink" id="section-4.6.2" href="#section-4.6.2">4.6.2</a>. Resolution Mechanism for TURN over DTLS</span>
This document defines a new Straightforward-Naming Authority Pointer
(S-NAPTR) application protocol tag: "turn.dtls".
The <transport> component, as provisioned or resulting from the
parsing of a TURN URI, is passed without modification to the TURN
resolution mechanism defined in <a href="./rfc5928#section-3">Section 3 of [RFC5928]</a>, but with the
following alterations to that algorithm:
o The acceptable values for the transport name are extended with the
addition of "dtls".
o The acceptable values in the ordered list of supported TURN
transports is extended with the addition of "Datagram Transport
Layer Security (DTLS)".
o The resolution algorithm check rules list is extended with the
addition of the following step:
If <secure> is true and <transport> is defined as "udp" but the
list of TURN transports supported by the application does not
contain DTLS, then the resolution MUST stop with an error.
o The 5th rule of the resolution algorithm check rules list is
modified to read like this:
If <secure> is true and <transport> is not defined but the list
of TURN transports supported by the application does not
contain TLS or DTLS, then the resolution MUST stop with an
error.
<span class="grey">Petit-Huguenin & Salgueiro Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7350">RFC 7350</a> STUN over DTLS August 2014</span>
o Table 1 is modified to add the following line:
+----------+-------------+----------------+
| <secure> | <transport> | TURN Transport |
+----------+-------------+----------------+
| true | "udp" | DTLS |
+----------+-------------+----------------+
o In step 1 of the resolution algorithm, the default port for DTLS
is 5349.
o In step 4 of the resolution algorithm, the following is added to
the list of conversions between the filtered list of TURN
transports supported by the application and application protocol
tags:
"turn.dtls" is used if the TURN transport is DTLS.
Note that using the resolution mechanism in [<a href="./rfc5928" title=""Traversal Using Relays around NAT (TURN) Resolution Mechanism"">RFC5928</a>] does not imply
that additional round trips to the DNS server will be needed (e.g.,
the TURN client will start immediately if the TURN URI contains an IP
address).
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
STUN over DTLS as a STUN transport does not introduce any specific
security considerations beyond those for STUN over TLS detailed in
[<a href="./rfc5389" title=""Session Traversal Utilities for NAT (STUN)"">RFC5389</a>].
The usage of "udp" as a transport parameter with the "stuns" URI
scheme does not introduce any specific security issues beyond those
discussed in [<a href="./rfc7064" title=""URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol"">RFC7064</a>].
TURN over DTLS as a TURN transport does not introduce any specific
security considerations beyond those for TURN over TLS detailed in
[<a href="./rfc5766" title=""Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"">RFC5766</a>].
The usage of "udp" as a transport parameter with the "turns" URI
scheme does not introduce any specific security issues beyond those
discussed in [<a href="./rfc7065" title=""Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers"">RFC7065</a>].
The new S-NAPTR application protocol tag defined in this document as
well as the modifications this document makes to the TURN resolution
mechanism described in [<a href="./rfc5928" title=""Traversal Using Relays around NAT (TURN) Resolution Mechanism"">RFC5928</a>] do not introduce any additional
security considerations beyond those outlined in [<a href="./rfc5928" title=""Traversal Using Relays around NAT (TURN) Resolution Mechanism"">RFC5928</a>].
<span class="grey">Petit-Huguenin & Salgueiro Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7350">RFC 7350</a> STUN over DTLS August 2014</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. S-NAPTR Application Protocol Tag</span>
This specification contains the registration information for one
S-NAPTR application protocol tag in the "Straightforward-NAPTR
(S-NAPTR) Parameters" registry under "S-NAPTR Application Protocol
Tags" (in accordance with [<a href="./rfc3958" title=""Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)"">RFC3958</a>]).
Application Protocol Tag: turn.dtls
Intended Usage: See <a href="#section-4.6.2">Section 4.6.2</a>
Interoperability considerations: N/A
Security considerations: See <a href="#section-5">Section 5</a>
Relevant publications: This document
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Service Name and Transport Protocol Port Number</span>
This specification contains the registration information for two
Service Name and Transport Protocol Port Numbers in the "Service
Names and Transport Protocol Port Numbers/Service Name and Transport
Protocol Port Number" registry (in accordance with [<a href="./rfc6335" title=""Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry"">RFC6335</a>]).
<span class="grey">Petit-Huguenin & Salgueiro Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7350">RFC 7350</a> STUN over DTLS August 2014</span>
<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>. The "stuns" Service Name</span>
IANA has modified the following entry in the registry "Service Names
and Transport Protocol Port Numbers/Service Name and Transport
Protocol Port Number":
Service Name: stuns
PortNumber: 5349
Transport Protocol: udp
Description: Reserved for a future enhancement of STUN
Assignee:
Contact:
Reference: <a href="./rfc5389">RFC 5389</a>
So that it contains the following:
Service Name: stuns
Port Number: 5349
Transport Protocol: udp
Description: STUN over DTLS
Assignee: IESG
Contact: IETF Chair <chair@ietf.org>
Reference: <a href="./rfc7350">RFC 7350</a>
Assignment Notes: This service name was initially created by
<a href="./rfc5389">RFC 5389</a>.
<span class="grey">Petit-Huguenin & Salgueiro Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7350">RFC 7350</a> STUN over DTLS August 2014</span>
<span class="h4"><a class="selflink" id="section-6.2.2" href="#section-6.2.2">6.2.2</a>. The "turns" Service Name</span>
IANA has modified the following entry in the registry "Service Names
and Transport Protocol Port Numbers/Service Name and Transport
Protocol Port Number":
Service Name: turns
Port Number: 5349
Transport Protocol: udp
Description: Reserved for a future enhancement of TURN
Assignee:
Contact:
Reference: <a href="./rfc5766">RFC 5766</a>
So that it contains the following:
Service Name: turns
Port Number: 5349
Transport Protocol: udp
Description: TURN over DTLS
Assignee: IESG
Contact: IETF Chair <chair@ietf.org>
Reference: <a href="./rfc7350">RFC 7350</a>
Assignment Notes: This service name was initially created by
<a href="./rfc5766">RFC 5766</a>.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
Thanks to Alan Johnston, Oleg Moskalenko, Simon Perreault, Thomas
Stach, Simon Josefsson, Roni Even, Kathleen Moriarty, Benoit Claise,
Martin Stiemerling, Jari Arkko, and Stephen Farrell for the comments,
suggestions, and questions that helped improve this document.
<span class="grey">Petit-Huguenin & Salgueiro Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7350">RFC 7350</a> STUN over DTLS August 2014</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3489">RFC3489</a>] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", <a href="./rfc3489">RFC 3489</a>,
March 2003.
[<a id="ref-RFC3958">RFC3958</a>] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", <a href="./rfc3958">RFC 3958</a>, January 2005.
[<a id="ref-RFC5245">RFC5245</a>] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", <a href="./rfc5245">RFC 5245</a>, April
2010.
[<a id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>, August 2008.
[<a id="ref-RFC5389">RFC5389</a>] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", <a href="./rfc5389">RFC 5389</a>,
October 2008.
[<a id="ref-RFC5626">RFC5626</a>] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", <a href="./rfc5626">RFC 5626</a>, October 2009.
[<a id="ref-RFC5764">RFC5764</a>] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", <a href="./rfc5764">RFC 5764</a>, May 2010.
[<a id="ref-RFC5766">RFC5766</a>] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", <a href="./rfc5766">RFC 5766</a>, April 2010.
[<a id="ref-RFC5928">RFC5928</a>] Petit-Huguenin, M., "Traversal Using Relays around NAT
(TURN) Resolution Mechanism", <a href="./rfc5928">RFC 5928</a>, August 2010.
[<a id="ref-RFC6062">RFC6062</a>] Perreault, S. and J. Rosenberg, "Traversal Using Relays
around NAT (TURN) Extensions for TCP Allocations", <a href="./rfc6062">RFC</a>
<a href="./rfc6062">6062</a>, November 2010.
<span class="grey">Petit-Huguenin & Salgueiro Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7350">RFC 7350</a> STUN over DTLS August 2014</span>
[<a id="ref-RFC6335">RFC6335</a>] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", <a href="https://www.rfc-editor.org/bcp/bcp165">BCP 165</a>, <a href="./rfc6335">RFC</a>
<a href="./rfc6335">6335</a>, August 2011.
[<a id="ref-RFC6347">RFC6347</a>] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", <a href="./rfc6347">RFC 6347</a>, January 2012.
[<a id="ref-RFC7064">RFC7064</a>] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit-
Huguenin, "URI Scheme for the Session Traversal Utilities
for NAT (STUN) Protocol", <a href="./rfc7064">RFC 7064</a>, November 2013.
[<a id="ref-RFC7065">RFC7065</a>] Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P.
Jones, "Traversal Using Relays around NAT (TURN) Uniform
Resource Identifiers", <a href="./rfc7065">RFC 7065</a>, November 2013.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-ICE-DTLS">ICE-DTLS</a>] Thomson, M., "Using Datagram Transport Layer Security
(DTLS) For Interactivity Connectivity Establishment (ICE)
Connectivity Checking: ICE-DTLS", Work in Progress, March
2012.
[<a id="ref-SIP-DTLS">SIP-DTLS</a>] Jennings, C. and N. Modadugu, "Session Initiation Protocol
(SIP) over Datagram Transport Layer Security (DTLS)", Work
in Progress, October 2007.
<span class="grey">Petit-Huguenin & Salgueiro Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7350">RFC 7350</a> STUN over DTLS August 2014</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Examples</span>
Table 1 shows how the <secure>, <port>, and <transport> components
are populated for a TURN URI that uses DTLS as its transport. For
all these examples, the <host> component is populated with
"example.net".
+---------------------------------+----------+--------+-------------+
| URI | <secure> | <port> | <transport> |
+---------------------------------+----------+--------+-------------+
| turns:example.net?transport=udp | true | | DTLS |
+---------------------------------+----------+--------+-------------+
Table 1
With the DNS Resource Records (RRs) in Figure 1 and an ordered TURN
transport list of {DTLS, TLS, TCP, UDP}, the resolution algorithm
will convert the TURN URI "turns:example.net" to the ordered list of
IP address, port, and protocol tuples in Table 2.
example.net.
IN NAPTR 100 10 "" RELAY:turn.udp:turn.dtls "" 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.
IN NAPTR 200 10 S RELAY:turn.dtls "" _turns._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.
_turns._udp.example.net.
IN SRV 0 0 5349 a.example.net.
a.example.net.
IN A 192.0.2.1
Figure 1
<span class="grey">Petit-Huguenin & Salgueiro Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7350">RFC 7350</a> STUN over DTLS August 2014</span>
+-------+----------+------------+------+
| Order | Protocol | IP address | Port |
+-------+----------+------------+------+
| 1 | DTLS | 192.0.2.1 | 5349 |
| 2 | TLS | 192.0.2.1 | 5349 |
+-------+----------+------------+------+
Table 2
<span class="grey">Petit-Huguenin & Salgueiro Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7350">RFC 7350</a> STUN over DTLS August 2014</span>
Authors' Addresses
Marc Petit-Huguenin
Jive Communications
1275 West 1600 North, Suite 100
Orem, UT 84057
USA
EMail: marcph@getjive.com
Gonzalo Salgueiro
Cisco Systems
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
USA
EMail: gsalguei@cisco.com
Petit-Huguenin & Salgueiro Standards Track [Page 16]
</pre>
|
