idnits 2.17.00 (12 Aug 2021) /tmp/idnits2038/draft-ietf-tram-stun-dtls-05.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-RFC2606-compliant FQDNs in the document. -- 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC5389, updated by this document, for RFC5378 checks: 2004-10-18) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 27, 2014) is 2878 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) ** Obsolete normative reference: RFC 3489 (Obsoleted by RFC 5389) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM M. Petit-Huguenin 3 Internet-Draft Jive Communications 4 Updates: 5389, 5928 (if approved) G. Salgueiro 5 Intended status: Standards Track Cisco Systems 6 Expires: December 29, 2014 June 27, 2014 8 Datagram Transport Layer Security (DTLS) as Transport for Session 9 Traversal Utilities for NAT (STUN) 10 draft-ietf-tram-stun-dtls-05 12 Abstract 14 This document specifies the usage of Datagram Transport Layer 15 Security (DTLS) as a transport protocol for Session Traversal 16 Utilities for NAT (STUN). It provides guidances on when and how to 17 use DTLS with the currently standardized STUN Usages. It also 18 specifies modifications to the STUN URIs and TURN URIs and to the 19 TURN resolution mechanism to facilitate the resolution of STUN URIs 20 and TURN URIs into the IP address and port of STUN and TURN servers 21 supporting DTLS as a transport protocol. This document updates RFC 22 5389 and RFC 5928. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 29, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. DTLS as Transport for STUN . . . . . . . . . . . . . . . . . 3 61 4. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. NAT Discovery Usage . . . . . . . . . . . . . . . . . . . 4 63 4.1.1. DTLS Support in STUN URIs . . . . . . . . . . . . . . 5 64 4.2. Connectivity Check Usage . . . . . . . . . . . . . . . . 5 65 4.3. Media Keep-Alive Usage . . . . . . . . . . . . . . . . . 5 66 4.4. SIP Keep-Alive Usage . . . . . . . . . . . . . . . . . . 6 67 4.5. NAT Behavior Discovery Usage . . . . . . . . . . . . . . 6 68 4.6. TURN Usage . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.6.1. DTLS Support in TURN URIs . . . . . . . . . . . . . . 6 70 4.6.2. Resolution Mechanism for TURN over DTLS . . . . . . . 7 71 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 72 5.1. turnuri . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 5.2. rfc5766-turn-server . . . . . . . . . . . . . . . . . . . 9 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 7.1. S-NAPTR application protocol tag . . . . . . . . . . . . 10 77 7.2. Service Name and Transport Protocol Port Number . . . . . 10 78 7.2.1. The stuns Service Name . . . . . . . . . . . . . . . 10 79 7.2.2. The turns Service Name . . . . . . . . . . . . . . . 11 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 9.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14 85 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 15 86 B.1. Modifications between ietf-tram-stun-dtls-04 and ietf- 87 tram-stun-dtls-05 . . . . . . . . . . . . . . . . . . . . 15 88 B.2. Modifications between ietf-tram-stun-dtls-03 and ietf- 89 tram-stun-dtls-04 . . . . . . . . . . . . . . . . . . . . 16 90 B.3. Modifications between ietf-tram-stun-dtls-02 and ietf- 91 tram-stun-dtls-03 . . . . . . . . . . . . . . . . . . . . 16 92 B.4. Modifications between ietf-tram-stun-dtls-01 and ietf- 93 tram-stun-dtls-02 . . . . . . . . . . . . . . . . . . . . 17 94 B.5. Modifications between ietf-tram-stun-dtls-00 and ietf- 95 tram-stun-dtls-01 . . . . . . . . . . . . . . . . . . . . 17 96 B.6. Modifications between petithuguenin-tram-stun-dtls-00 and 97 ietf-tram-stun-dtls-00 . . . . . . . . . . . . . . . . . 17 98 B.7. Modifications between petithuguenin-tram-turn-dtls-00 and 99 petithuguenin-tram-stun-dtls-00 . . . . . . . . . . . . . 17 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 102 1. Introduction 104 STUN [RFC5389] defines Transport Layer Security (TLS) over TCP 105 (simply referred to as TLS [RFC5246]) as the transport for STUN due 106 to additional security advantages it offers over plain UDP or TCP 107 transport. But TCP (and thus TLS-over-TCP) is not an optimal 108 transport when STUN is used for its originally intended purpose, 109 which is to support multimedia sessions. This is a well documented 110 and understood transport limitation for real-time communications. 112 DTLS-over-UDP (referred to in this document as simply DTLS [RFC6347]) 113 offers the same security advantages as TLS-over-TCP, but without the 114 undesirable concerns. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" 119 in this document are to be interpreted as described in [RFC2119] when 120 they appear in ALL CAPS. When these words are not in ALL CAPS (such 121 as "must" or "Must"), they have their usual English meanings, and are 122 not to be interpreted as RFC 2119 key words. 124 3. DTLS as Transport for STUN 126 STUN [RFC5389] defines three transports: UDP, TCP, and TLS. This 127 document adds DTLS as a valid transport for STUN. 129 STUN over DTLS MUST use the same retransmission rules as STUN over 130 UDP (as described in Section 7.2.1 of [RFC5389]). It MUST also use 131 the same rules that are described in Section 7.2.2 of [RFC5389] to 132 verify the server identity. Instead of TLS_RSA_WITH_AES_128_CBC_SHA, 133 which is the default cipher suite for STUN over TLS, implementations 134 of STUN over DTLS, and deployed clients and servers, MUST support 135 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and 136 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, and MAY support other 137 ciphersuites. Perfect Forward Secrecy (PFS) cipher suites MUST be 138 preferred over non-PFS cipher suites. Cipher suites with known 139 weaknesses, such as those based on (single) DES and RC4, MUST NOT be 140 used. Implementations MUST disable TLS-level compression. The same 141 rules established in Section 7.2.2 of [RFC5389] for keeping open and 142 closing TCP/TLS connections MUST be used as well for DTLS 143 associations. 145 In addition to the path MTU rules described in Section 7.1 of 146 [RFC5389], if the path MTU is unknown, the actual STUN message needs 147 to be adjusted to take into account the size of the (13-byte) DTLS 148 Record header, the MAC size, and the padding size. 150 By default, STUN over DTLS MUST use port 5349, the same port number 151 as STUN over TLS. However, the SRV procedures can be implemented to 152 use a different port (as described in Section 9 of [RFC5389]). When 153 using SRV records, the service name MUST be set to "stuns" and the 154 protocol name to "udp". 156 Classic STUN [RFC3489] defines only UDP as a transport and DTLS MUST 157 NOT be used. Any STUN request or indication without the magic cookie 158 (see Section 6 of [RFC5389]) over DTLS MUST always result in an 159 error. 161 4. STUN Usages 163 [RFC5389] Section 7.2 states that STUN usages must specify which 164 transport protocol is used. The following sections discuss if and 165 how the existing STUN usages are used with DTLS as the transport. 166 Future STUN usages MUST take into account DTLS as a transport and 167 discuss its applicability. In all cases, new STUN usages MUST 168 explicitly state if implementing the denial-of-service counter- 169 measure described in Section 4.2.1 of [RFC6347] is mandatory. 171 4.1. NAT Discovery Usage 173 As stated by Section 13 of [RFC5389], "...TLS provides minimal 174 security benefits..." for this particular STUN usage. DTLS will also 175 similarly offer only limited benefit. This is because the only 176 mandatory attribute that is TLS/DTLS protected is the XOR-MAPPED- 177 ADDRESS, which is already known by an on-path attacker, since it is 178 the same as the source address and port of the STUN request. On the 179 other hand, using TLS/DTLS will prevent an active attacker to inject 180 XOR-MAPPED-ADDRESS in responses. The TLS/DTLS transport will also 181 protect the SOFTWARE attribute, which can be used to find 182 vulnerabilities in STUN implementations. 184 Regardless, this usage is rarely used by itself, since using TURN 185 [RFC5766] with ICE [RFC5245] is generally indispensable, and TURN 186 provides the same NAT Discovery feature as part of an Allocation 187 creation. In fact, with ICE, the NAT Discovery usage is only used 188 when there is no longer any resource available for new Allocations in 189 the TURN server. 191 A STUN server implementing the NAT Discovery Usage and using DTLS 192 MUST implement the denial-of-service counter-measure described in 193 Section 4.2.1 of [RFC6347]. 195 4.1.1. DTLS Support in STUN URIs 197 This document does not make any changes to the syntax of a STUN URI 198 [RFC7064]. As indicated in Section 3.2 of [RFC7064], secure 199 transports like STUN over TLS, and now STUN over DTLS, MUST use the 200 "stuns" URI scheme. 202 The value MUST be used when using the rules in Section 7.2.2 203 of [RFC5389] to verify the server identity. A STUN URI containing an 204 IP address MUST be rejected, unless the domain name is provided by 205 the same mechanism that provided the STUN URI, and that this domain 206 name can be passed to the verification code. 208 4.2. Connectivity Check Usage 210 Using DTLS would hide the USERNAME, PRIORITY, USE-CANDIDATE, ICE- 211 CONTROLLED and ICE-CONTROLLING attributes. But because MESSAGE- 212 INTEGRITY protects the entire STUN response using a password that is 213 known only by looking at the SDP exchanged, it is not possible for an 214 attacker that does not have access to this SDP to inject an incorrect 215 XOR-MAPPED-ADDRESS, XOR-MAPPED-ADDRESS which would subsequently be 216 used as a peer reflexive candidate. 218 Adding DTLS on top of the connectivity check would delay, and 219 consequently impair, the ICE process. Adding additional round-trips 220 to ICE is undesirable, so much that there is a proposal 221 ([I-D.thomson-rtcweb-ice-dtls]) to use the DTLS handshake used by the 222 WebRTC SRTP streams as a replacement for the connectivity checks. 224 STUN URIs are not used with this usage. 226 4.3. Media Keep-Alive Usage 228 When STUN Binding Indications are being used for media keep-alive 229 (described in Section 10 of [RFC5245]), it runs alongside an RTP or 230 RTCP session. It is possible to send these media keep-alive packets 231 inside a separately negotiated non-SRTP DTLS session if DTLS-SRTP 232 [RFC5764] is used, but that would add overhead, with minimal security 233 benefit. 235 STUN URIs are not used with this usage. 237 4.4. SIP Keep-Alive Usage 239 The SIP keep-alive (described in [RFC5626]) runs inside a SIP flow. 240 This flow would be protected if a SIP over DTLS transport mechanism 241 is implemented (such as described in [I-D.jennings-sip-dtls]). 243 STUN URIs are not used with this usage. 245 4.5. NAT Behavior Discovery Usage 247 The NAT Behavior Discovery usage is Experimental and to date has 248 never being effectively deployed. Despite this, using DTLS would add 249 the same security properties as for the NAT Discovery Usage 250 (Section 4.1). 252 The STUN URI can be used to access the NAT Discovery feature of a NAT 253 Behavior Discovery server, but accessing the full features would 254 require definition of a "stun-behaviors:" URI, which is out of scope 255 for this document. 257 A STUN server implementing the NAT Behavior Discovery Usage and using 258 DTLS MUST implement the denial-of-service counter-measure described 259 in Section 4.2.1 of [RFC6347]. 261 4.6. TURN Usage 263 TURN [RFC5766] defines three combinations of transports/allocations: 264 UDP/UDP, TCP/UDP and TLS/UDP. This document adds DTLS/UDP as a valid 265 combination. A TURN server using DTLS MUST implement the denial-of- 266 service counter-measure described in Section 4.2.1 of [RFC6347]. 268 [RFC6062] states that TCP allocations cannot be obtained using a UDP 269 association between client and server. The fact that DTLS uses UDP 270 implies that TCP allocations MUST NOT be obtained using a DTLS 271 association between client and server. 273 By default, TURN over DTLS uses port 5349, the same port number as 274 TURN over TLS. However, the SRV procedures can be implemented to use 275 a different port (as described in Section 6 of [RFC5766]. When using 276 SRV records, the service name MUST be set to "turns" and the protocol 277 name to "udp". 279 4.6.1. DTLS Support in TURN URIs 281 This document does not make any changes to the syntax of a TURN URI 282 [RFC7065]. As indicated in Section 3 of [RFC7065], secure transports 283 like TURN over TLS, and now TURN over DTLS, MUST use the "turns" URI 284 scheme. When using the "turns" URI scheme to designate TURN over 285 DTLS, the transport value of the TURN URI, if set, MUST be "udp". 287 The value MUST be used when using the rules in Section 7.2.2 288 of [RFC5389] to verify the server identity. A TURN URI containing an 289 IP address MUST be rejected, unless the domain is provided by the 290 same mechanism that provided the TURN URI, and that this domain name 291 can be passed to the verification code. 293 4.6.2. Resolution Mechanism for TURN over DTLS 295 This document defines a new Straightforward Naming Authority Pointer 296 (S-NAPTR) application protocol tag: "turn.dtls". 298 The component, as provisioned or resulting from the 299 parsing of a TURN URI, is passed without modification to the TURN 300 resolution mechanism defined in Section 3 of [RFC5928], but with the 301 following alterations to that algorithm: 303 o The acceptable values for transport name are extended with the 304 addition of "dtls". 306 o The acceptable values in the ordered list of supported TURN 307 transports is extended with the addition of "Datagram Transport 308 Layer Security (DTLS)". 310 o The resolution algorithm check rules list is extended with the 311 addition of the following step: 313 If is true and is defined as "udp" but the 314 list of TURN transports supported by the application does not 315 contain DTLS, then the resolution MUST stop with an error. 317 o The 5th rule of the resolution algorithm check rules list is 318 modified to read like this: 320 If is true and is not defined but the list 321 of TURN transports supported by the application does not 322 contain TLS or DTLS, then the resolution MUST stop with an 323 error. 325 o Table 1 is modified to add the following line: 327 +----------+-------------+----------------+ 328 | | | TURN Transport | 329 +----------+-------------+----------------+ 330 | true | "udp" | DTLS | 331 +----------+-------------+----------------+ 333 o In step 1 of the resolution algorithm the default port for DTLS is 334 5349. 336 o In step 4 of the resolution algorithm the following is added to 337 the list of conversions between the filtered list of TURN 338 transports supported by the application and application protocol 339 tags: 341 "turn.dtls" is used if the TURN transport is DTLS. 343 Note that using the [RFC5928] resolution mechanism does not imply 344 that additional round trips to the DNS server will be needed (e.g., 345 the TURN client will start immediately if the TURN URI contains an IP 346 address). 348 5. Implementation Status 350 [[Note to RFC Editor: Please remove this section and the reference to 351 [RFC6982] before publication.]] 353 This section records the status of known implementations of the 354 protocol defined by this specification at the time of posting of this 355 Internet-Draft, and is based on a proposal described in [RFC6982]. 356 The description of implementations in this section is intended to 357 assist the IETF in its decision processes in progressing drafts to 358 RFCs. Please note that the listing of any individual implementation 359 here does not imply endorsement by the IETF. Furthermore, no effort 360 has been spent to verify the information presented here that was 361 supplied by IETF contributors. This is not intended as, and must not 362 be construed to be, a catalog of available implementations or their 363 features. Readers are advised to note that other implementations may 364 exist. 366 According to [RFC6982], "this will allow reviewers and working groups 367 to assign due consideration to documents that have the benefit of 368 running code, which may serve as evidence of valuable experimentation 369 and feedback that have made the implemented protocols more mature. 370 It is up to the individual working groups to use this information as 371 they see fit". 373 5.1. turnuri 375 Organization: Impedance Mismatch 377 Name: turnuri 0.5.0 http://debian.implementers.org/stable/source/ 378 turnuri.tar.gz 380 Description: A reference implementation of the URI and resolution 381 mechanism defined in this document, RFC 7065 [RFC7065] and RFC 382 5928 [RFC5928]. 384 Level of maturity: Beta. 386 Coverage: Fully implements the URIs and resolution mechanism 387 defined in this specification, in RFC 7065 and in RFC 5928. 389 Licensing: AGPL3 391 Implementation experience: TBD 393 Contact: Marc Petit-Huguenin . 395 5.2. rfc5766-turn-server 397 Organization: This is a public project, the full list of authors 398 and contributors here: http://turnserver.open-sys.org/downloads/ 399 AUTHORS. 401 Name: http://code.google.com/p/rfc5766-turn-server/ 403 Description: A mature open-source TURN server specs implementation 404 (RFC 5766, RFC 6062, RFC 6156, etc) designed for high-performance 405 applications, especially geared for WebRTC. 407 Level of maturity: Production level. 409 Coverage: Fully implements DTLS with TURN protocol. 411 Licensing: BSD: http://turnserver.open-sys.org/downloads/LICENSE 413 Implementation experience: DTLS is recommended for secure media 414 applications. It has benefits of both UDP and TLS. 416 Contact: Oleg Moskalenko 418 6. Security Considerations 420 STUN over DTLS as a STUN transport does not introduce any specific 421 security considerations beyond those for STUN over TLS detailed in 422 [RFC5389]. 424 The usage of "udp" as a transport parameter with the "stuns" URI 425 scheme does not introduce any specific security issues beyond those 426 discussed in [RFC7064]. 428 TURN over DTLS as a TURN transport does not introduce any specific 429 security considerations beyond those for TURN over TLS detailed in 430 [RFC5766]. 432 The usage of "udp" as a transport parameter with the "turns" URI 433 scheme does not introduce any specific security issues beyond those 434 discussed in [RFC7065]. 436 The new S-NAPTR application protocol tag defined in this document as 437 well as the modifications this document makes to the TURN resolution 438 mechanism described in [RFC5928] do not introduce any additional 439 security considerations beyond those outlined in [RFC5928]. 441 7. IANA Considerations 443 7.1. S-NAPTR application protocol tag 445 This specification contains the registration information for one 446 S-NAPTR application protocol tag in the "Straightforward-NAPTR 447 (S-NAPTR) Parameters/S-NAPTR Application Protocol Tags" registry (in 448 accordance with [RFC3958]). 450 Application Protocol Tag: turn.dtls 452 Intended Usage: See Section 4.6.2 454 Interoperability considerations: N/A 456 Security considerations: See Section 6 458 Relevant publications: This document 460 Contact information: Marc Petit-Huguenin 462 Author/Change controller: The IESG 464 7.2. Service Name and Transport Protocol Port Number 466 This specification contains the registration information for two 467 Service Name and Transport Protocol Port Numbers in the "Service 468 Names and Transport Protocol Port Numbers/Service Name and Transport 469 Protocol Port Number" registry (in accordance with [RFC6335]). 471 7.2.1. The stuns Service Name 473 IANA is requested to modify the following entry in the registry 474 "Service Names and Transport Protocol Port Numbers/Service Name and 475 Transport Protocol Port Number": 477 Service Name: stuns 479 Transport Protocol(s): UDP 481 Assignee: 483 Contact: 485 Description: Reserved for a future enhancement of STUN 487 Reference: RFC5389 489 Port Number: 5349 491 Such as it contains the following: 493 Service Name: stuns 495 Transport Protocol(s): UDP 497 Assignee: IESG 499 Contact: IETF Chair 501 Description: STUN over DTLS 503 Reference: RFC-to-be 505 Port Number: 5349 507 Assignment Notes: This service name was initially created by RFC 508 5389 510 7.2.2. The turns Service Name 512 IANA is requested to modify the following entry in the registry 513 "Service Names and Transport Protocol Port Numbers/Service Name and 514 Transport Protocol Port Number": 516 Service Name: turns 518 Transport Protocol(s): UDP 520 Assignee: 522 Contact: 524 Description: Reserved for a future enhancement of TURN 526 Reference: RFC5766 528 Port Number: 5349 530 Such as it contains the following: 532 Service Name: turns 534 Transport Protocol(s): UDP 536 Assignee: IESG 538 Contact: IETF Chair 540 Description: TURN over DTLS 542 Reference: RFC-to-be 544 Port Number: 5349 546 Assignment Notes: This service name was initially created by RFC 547 5766 549 8. Acknowledgements 551 Thanks to Alan Johnston, Oleg Moskalenko, Simon Perreault, Thomas 552 Stach, Simon Josefsson, Roni Even, Kathleen Moriarty, Benoit Claise, 553 Martin Stiemerling, Jari Arkko, and Stephen Farrell for the comments, 554 suggestions, and questions that helped improve this document. 556 9. References 558 9.1. Normative References 560 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 561 Requirement Levels", BCP 14, RFC 2119, March 1997. 563 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 564 "STUN - Simple Traversal of User Datagram Protocol (UDP) 565 Through Network Address Translators (NATs)", RFC 3489, 566 March 2003. 568 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 569 Service Location Using SRV RRs and the Dynamic Delegation 570 Discovery Service (DDDS)", RFC 3958, January 2005. 572 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 573 (ICE): A Protocol for Network Address Translator (NAT) 574 Traversal for Offer/Answer Protocols", RFC 5245, April 575 2010. 577 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 578 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 580 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 581 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 582 October 2008. 584 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 585 Initiated Connections in the Session Initiation Protocol 586 (SIP)", RFC 5626, October 2009. 588 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 589 Security (DTLS) Extension to Establish Keys for the Secure 590 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 592 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 593 Relays around NAT (TURN): Relay Extensions to Session 594 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 596 [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT 597 (TURN) Resolution Mechanism", RFC 5928, August 2010. 599 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 600 around NAT (TURN) Extensions for TCP Allocations", RFC 601 6062, November 2010. 603 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 604 Cheshire, "Internet Assigned Numbers Authority (IANA) 605 Procedures for the Management of the Service Name and 606 Transport Protocol Port Number Registry", BCP 165, RFC 607 6335, August 2011. 609 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 610 Security Version 1.2", RFC 6347, January 2012. 612 [RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit- 613 Huguenin, "URI Scheme for the Session Traversal Utilities 614 for NAT (STUN) Protocol", RFC 7064, November 2013. 616 [RFC7065] Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P. 617 Jones, "Traversal Using Relays around NAT (TURN) Uniform 618 Resource Identifiers", RFC 7065, November 2013. 620 9.2. Informative References 622 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 623 Code: The Implementation Status Section", RFC 6982, July 624 2013. 626 [I-D.thomson-rtcweb-ice-dtls] 627 Thomson, M., "Using Datagram Transport Layer Security 628 (DTLS) For Interactivity Connectivity Establishment (ICE) 629 Connectivity Checking: ICE-DTLS", draft-thomson-rtcweb- 630 ice-dtls-00 (work in progress), March 2012. 632 [I-D.jennings-sip-dtls] 633 Jennings, C. and N. Modadugu, "Using Interactive 634 Connectivity Establishment (ICE) in Web Real-Time 635 Communications (WebRTC)", draft-jennings-sip-dtls-05 (work 636 in progress), October 2007. 638 Appendix A. Examples 640 Table 1 shows how the , and components are 641 populated for a TURN URI that uses DTLS as its transport. For all 642 these examples, the component is populated with "example.net". 644 +---------------------------------+----------+--------+-------------+ 645 | URI | | | | 646 +---------------------------------+----------+--------+-------------+ 647 | turns:example.net?transport=udp | true | | DTLS | 648 +---------------------------------+----------+--------+-------------+ 650 Table 1 652 With the DNS RRs in Figure 1 and an ordered TURN transport list of 653 {DTLS, TLS, TCP, UDP}, the resolution algorithm will convert the TURN 654 URI "turns:example.net" to the ordered list of IP address, port, and 655 protocol tuples in Table 2. 657 example.net. 658 IN NAPTR 100 10 "" RELAY:turn.udp:turn.dtls "" datagram.example.net. 659 IN NAPTR 200 10 "" RELAY:turn.tcp:turn.tls "" stream.example.net. 661 datagram.example.net. 662 IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net. 663 IN NAPTR 200 10 S RELAY:turn.dtls "" _turns._udp.example.net. 665 stream.example.net. 666 IN NAPTR 100 10 S RELAY:turn.tcp "" _turn._tcp.example.net. 667 IN NAPTR 200 10 A RELAY:turn.tls "" a.example.net. 669 _turn._udp.example.net. 670 IN SRV 0 0 3478 a.example.net. 672 _turn._tcp.example.net. 673 IN SRV 0 0 5000 a.example.net. 675 _turns._udp.example.net. 676 IN SRV 0 0 5349 a.example.net. 678 a.example.net. 679 IN A 192.0.2.1 681 Figure 1 683 +-------+----------+------------+------+ 684 | Order | Protocol | IP address | Port | 685 +-------+----------+------------+------+ 686 | 1 | DTLS | 192.0.2.1 | 5349 | 687 | 2 | TLS | 192.0.2.1 | 5349 | 688 +-------+----------+------------+------+ 690 Table 2 692 Appendix B. Release notes 694 This section must be removed before publication as an RFC. 696 B.1. Modifications between ietf-tram-stun-dtls-04 and ietf-tram-stun- 697 dtls-05 699 o Resolve nits: Updates RFC in abstract. 701 o Update short title to reflect long title 703 o Simplify the introduction to simply states that TCP is not optimal 704 for realtime communications. 706 o Add refereence to RFC 5389 section 6 for the magic cookie. 708 o s/domain/domain name/ 710 o Make clear that knowledge of the SDP is needed to be able to 711 inject a false XOR-MAPPED-ADDRESS. 713 o Invert the sentence about ICE round-trips to make clear that the 714 cited draft is just an evidence, not an advice. 716 o Rewrite of the IANA templates for Port numbers. 718 o Remove compression from the list of element to take in accoutn to 719 adjust the PMTU size, as it is now forbidden. 721 B.2. Modifications between ietf-tram-stun-dtls-03 and ietf-tram-stun- 722 dtls-04 724 o Add text to disable TLS compression. 726 o Add text to require usage of the DTLS cookie for NAT discovery and 727 NAT behavior discovery. 729 o Add text to so new usages talk about cookie usage. 731 o Change TLS-over-UDP to DTLS-over-UDP and use DTLS as alias for 732 DTLS over UDP.. 734 o Use new text proposed by Simon Josefsson for the cipher suites. 736 o s/the same port/the same port number/ 738 o s/application name/protocol name/ 740 o Make clear that section 4.3 is only about the STUN Indication 741 method of media keep-alive. 743 o Changed contact information to IETF Chair in Port number template. 745 o Added email addresses in IANA templates. 747 B.3. Modifications between ietf-tram-stun-dtls-02 and ietf-tram-stun- 748 dtls-03 750 o Make it clear that both cipher suites are mandatory. 752 o Clarify that the ciphers suites listed are replacing the TLS 753 cipher suites. 755 o Change text so "mandatory" is not understood as compliance. 757 o Clarify that STUN URI are not to be used with some usages. 759 o Fix incorrect interpretation of ICE media keep-alive (and fixed 760 section #). 762 o Explain that sending media keep-alive inside DTLS is possible if 763 RFC 5764 is used. 765 o Added title/subtitle of IANA registries. 767 o Change to normatively update RFC 5389 and RFC 5928. 769 B.4. Modifications between ietf-tram-stun-dtls-01 and ietf-tram-stun- 770 dtls-02 772 o Add text saying that PFS is preferred over non-PFS, to be in sync 773 with the decision in the rtcweb session in London. 775 o Add text about IP address in STUN/TURN URIs. 777 o Nits 779 B.5. Modifications between ietf-tram-stun-dtls-00 and ietf-tram-stun- 780 dtls-01 782 o Update the mandatory cipher suites. 784 o Add a new open item to determine if we want to specify favoring 785 cipher suites which support PFS over non-PFS cipher suites. 787 o Close remaining opening items from previous draft. 789 B.6. Modifications between petithuguenin-tram-stun-dtls-00 and ietf- 790 tram-stun-dtls-00 792 o Draft renamed after WG adoption. 794 B.7. Modifications between petithuguenin-tram-turn-dtls-00 and 795 petithuguenin-tram-stun-dtls-00 797 o Add RFC 6982 information for rfc5766-turn-server project. 799 o Rename the draft as TURN is now just one of the usages. 801 o Remove the references in the abstract to make idnits happy. 803 o No longer updates other standard drafts. 805 o Rewrite from a STUN over DTLS point of view. The previous text 806 becomes section 4.6. 808 o Add IANA request for stuns port. 810 o Add acknowledgement section. 812 Authors' Addresses 814 Marc Petit-Huguenin 815 Jive Communications 816 1275 West 1600 North, Suite 100 817 Orem, UT 84057 818 USA 820 Email: marcph@getjive.com 822 Gonzalo Salgueiro 823 Cisco Systems 824 7200-12 Kit Creek Road 825 Research Triangle Park, NC 27709 826 US 828 Email: gsalguei@cisco.com