idnits 2.17.1 draft-petithuguenin-tram-stun-dtls-00.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). -- The document date (February 11, 2014) is 3724 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 (==), 3 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 Intended status: Standards Track G. Salgueiro 5 Expires: August 15, 2014 Cisco Systems 6 February 11, 2014 8 Datagram Transport Layer Security (DTLS) as Transport for Session 9 Traversal Utilities for NAT (STUN) 10 draft-petithuguenin-tram-stun-dtls-00 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. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 15, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. DTLS as Transport for STUN . . . . . . . . . . . . . . . . . 3 60 4. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. NAT Discovery Usage . . . . . . . . . . . . . . . . . . . 4 62 4.1.1. DTLS Support in STUN URIs . . . . . . . . . . . . . . 4 63 4.2. Connectivity Check Usage . . . . . . . . . . . . . . . . 4 64 4.3. Media Keep-Alive Usage . . . . . . . . . . . . . . . . . 5 65 4.4. SIP Keep-Alive Usage . . . . . . . . . . . . . . . . . . 5 66 4.5. NAT Behavior Discovery Usage . . . . . . . . . . . . . . 5 67 4.6. TURN Usage . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.6.1. DTLS Support in TURN URIs . . . . . . . . . . . . . . 6 69 4.6.2. Resolution Mechanism for TURN over DTLS . . . . . . . 6 70 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 71 5.1. turnuri . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 5.2. rfc5766-turn-server . . . . . . . . . . . . . . . . . . . 8 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 7.1. S-NAPTR application protocol tag . . . . . . . . . . . . 9 76 7.2. Service Name and Transport Protocol Port Number . . . . . 9 77 7.2.1. The stuns Service Name . . . . . . . . . . . . . . . 10 78 7.2.2. The turns Service Name . . . . . . . . . . . . . . . 10 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 9.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12 84 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 13 85 B.1. Modifications between petithuguenin-tram-turn-dtls-00 and 86 petithuguenin-tram-stun-dtls-00 . . . . . . . . . . . . . 13 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 STUN [RFC5389] defines Transport Layer Security (TLS) over TCP 92 (simply referred to as TLS [RFC5246]) as the transport for STUN due 93 to additional security advantages it offers over plain UDP or TCP 94 transport. But TLS-over-TCP is not an optimal transport when STUN is 95 used for its originally intended purpose, which is to support 96 multimedia sessions. This sub-optimality primarily stems from the 97 added latency incurred by the TCP-based head-of-line (HOL) blocking 98 problem coupled with additional TLS buffering (for integrity checks). 99 This is a well documented and understood transport limitation for 100 secure real-time communications. 102 TLS-over-UDP (referred to as DTLS [RFC6347]) offers the same security 103 advantages as TLS-over-TCP, but without the undesirable latency 104 concerns. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" 109 in this document are to be interpreted as described in [RFC2119] when 110 they appear in ALL CAPS. When these words are not in ALL CAPS (such 111 as "must" or "Must"), they have their usual English meanings, and are 112 not to be interpreted as RFC 2119 key words. 114 3. DTLS as Transport for STUN 116 STUN [RFC5389] defines three transports: UDP, TCP, and TLS. This 117 document adds DTLS as a valid transport for STUN. 119 STUN over DTLS MUST use the same retransmission rules as STUN over 120 UDP (as described in Section 7.2.1 of [RFC5389]). It MUST also use 121 the same rules that are described in Section 7.2.2 of [RFC5389] to 122 verify the server identity. STUN over DTLS MUST, at a minimum, 123 support TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [[TODO: What is the 124 recommendation these days?]]. The same rules established in 125 Section 7.2.2 of [RFC5389] for keeping open and closing TCP/TLS 126 connections MUST be used as well for DTLS associations. 128 In addition to the path MTU rules described in Section 7.1 of 129 [RFC5389], if the path MTU is unknown, the actual STUN message needs 130 to be adjusted to take into account the size of the (13-byte) DTLS 131 Record header, the MAC size, the padding size and the eventual 132 compression applied to the payload. 134 By default, STUN over DTLS MUST use port 5349, the same port as STUN 135 over TLS. However, the SRV procedures can be implemented to use a 136 different port (as described in Section 9 of [RFC5389]). When using 137 SRV records, the service name MUST be set to "stuns" and the 138 application name to "udp". 140 Classic STUN [RFC3489] defines only UDP as a transport and DTLS MUST 141 NOT be used. Any STUN request or indication without the magic cookie 142 over DTLS MUST always result in an error. [[TODO: Note that it is a 143 departure from RFC 5389, which does not explicitly state what to do 144 in that case. Are we OK with this?]] 146 4. STUN Usages 148 [RFC5389] Section 7.2 states that STUN usages must specify which 149 transport protocol is used. The following sections discuss if and 150 how the existing STUN usages are used with DTLS as the transport. 151 Future STUN usages MUST take into account DTLS as a transport and 152 discuss its applicability. [[TODO: Note that Section 14 of RFC 5389 153 ommitted to say that transport applicability MUST be discussed. Is 154 this a reasonable addition?]]. 156 4.1. NAT Discovery Usage 158 As stated by Section 13 of [RFC5389], "...TLS provides minimal 159 security benefits..." for this particular STUN usage. DTLS will also 160 similarly offer only limited benefit. This is because the only 161 mandatory attribute that is TLS/DTLS protected is the XOR-MAPPED- 162 ADDRESS, which is already known by an on-path attacker, since it is 163 the same as the source address and port of the STUN request. On the 164 other hand, using TLS/DTLS will prevent an active attacker to inject 165 XOR-MAPPED-ADDRESS in responses. The TLS/DTLS transport will also 166 protect the SOFTWARE attribute, which can be used to find 167 vulnerabilities in STUN implementations. 169 Regardless, this usage is rarely used by itself, since TURN [RFC5766] 170 is generally mandatory to use with ICE [RFC5245], and TURN provides 171 the same NAT Discovery feature as part of an Allocation creation. In 172 fact, with ICE, the NAT Discovery usage is only used when there is no 173 longer any resource available for new Allocations in the TURN server. 175 4.1.1. DTLS Support in STUN URIs 177 This document does not make any changes to the syntax of a STUN URI 178 [RFC7064]. As indicated in Section 3.2 of [RFC7064], secure 179 transports like STUN over TLS, and now STUN over DTLS, MUST use the 180 "stuns" URI scheme. 182 The value MUST be used when using the rules in Section 7.2.2 183 of [RFC5389] to verify the server identity. [[TODO: What happens if 184 an IP address is used in the URI? Should we forbid that?]] 186 4.2. Connectivity Check Usage 188 Using DTLS would hide the USERNAME, PRIORITY, USE-CANDIDATE, ICE- 189 CONTROLLED and ICE-CONTROLLING attributes. But because MESSAGE- 190 INTEGRITY protects the entire STUN response using a password that is 191 known only by looking at the SDP exchanged, it is not possible for an 192 attacker to inject an incorrect XOR-MAPPED-ADDRESS, which would 193 subsequently be used as a peer reflexive candidate. 195 Adding DTLS on top of the connectivity check would delay, and 196 consequently impair, the ICE process. There is, in fact, a proposal 197 ([I-D.thomson-rtcweb-ice-dtls]) to use the DTLS handshake used by the 198 WebRTC SRTP streams as a replacement for the connectivity checks, 199 proving that adding additional round-trips to ICE is undesirable. 201 This usage MUST NOT be used with a STUN URI. 203 4.3. Media Keep-Alive Usage 205 The media keep-alive (described in Section 20 of [RFC5245]) runs 206 inside an RTP or RTCP session, so it is already protected if the RTP 207 or RTCP session is also protected (i.e., SRTP/SRTCP). Adding DTLS 208 inside the SRTP/SRTCP session would add overhead, with minimal 209 security benefit. 211 This usage MUST NOT be used with a STUN URI. 213 4.4. SIP Keep-Alive Usage 215 The SIP keep-alive (described in [RFC5626]) runs inside a SIP flow. 216 This flow would be protected if a SIP over DTLS transport mechanism 217 is implemented (such as described in [I-D.jennings-sip-dtls]). 219 This usage MUST NOT be used with a STUN URI. 221 4.5. NAT Behavior Discovery Usage 223 The NAT Behavior Discovery usage is Experimental and to date has 224 never being effectively deployed. Despite this, using DTLS would add 225 the same security properties as for the NAT Discovery Usage 226 (Section 4.1). 228 The STUN URI can be used to access the NAT Discovery feature of a NAT 229 Behavior Discovery server, but accessing the full features would 230 require definition of a "stun-behaviors:" URI, which is out of scope 231 for this document. 233 4.6. TURN Usage 235 TURN [RFC5766] defines three combinations of transports/allocations: 236 UDP/UDP, TCP/UDP and TLS/UDP. This document adds DTLS/UDP as a valid 237 combination. A TURN server using DTLS MUST implement the denial-of- 238 service counter-measure described in Section 4.2.1 of [RFC6347]. 240 [RFC6062] states that TCP allocations cannot be obtained using a UDP 241 association between client and server. The fact that DTLS uses UDP 242 implies that TCP allocations MUST NOT be obtained using a DTLS 243 association between client and server. 245 By default, TURN over DTLS uses port 5349, the same port as TURN over 246 TLS. However, the SRV procedures can be implemented to use a 247 different port (as described in Section 6 of [RFC5766]. When using 248 SRV records, the service name MUST be set to "turns" and the 249 application name to "udp". 251 4.6.1. DTLS Support in TURN URIs 253 This document does not make any changes to the syntax of a TURN URI 254 [RFC7065]. As indicated in Section 3 of [RFC7065], secure transports 255 like TURN over TLS, and now TURN over DTLS, MUST use the "turns" URI 256 scheme. When using the "turns" URI scheme to designate TURN over 257 DTLS, the transport value of the TURN URI, if set, MUST be "udp". 259 4.6.2. Resolution Mechanism for TURN over DTLS 261 This document defines a new Straightforward Naming Authority Pointer 262 (S-NAPTR) application protocol tag: "turn.dtls". 264 The component, as provisioned or resulting from the 265 parsing of a TURN URI, is passed without modification to the TURN 266 resolution mechanism defined in Section 3 of [RFC5928], but with the 267 following alterations to that algorithm: 269 o The acceptable values for transport name are extended with the 270 addition of "dtls". 272 o The acceptable values in the ordered list of supported TURN 273 transports is extended with the addition of "Datagram Transport 274 Layer Security (DTLS)". 276 o The resolution algorithm ckeck rules list is extended with the 277 addition of the following step: 279 If is true and is defined as "udp" but the 280 list of TURN transports supported by the application does not 281 contain DTLS, then the resolution MUST stop with an error. 283 o The 5th rule of the resolution algorithm check rules list is 284 modified to read like this: 286 If is true and is not defined but the list 287 of TURN transports supported by the application does not 288 contain TLS or DTLS, then the resolution MUST stop with an 289 error. 291 o Table 1 is modified to add the following line: 293 +----------+-------------+----------------+ 294 | | | TURN Transport | 295 +----------+-------------+----------------+ 296 | true | "udp" | DTLS | 297 +----------+-------------+----------------+ 299 o In step 1 of the resolution algorithm the default port for DTLS is 300 5349. 302 o In step 4 of the resolution algorithm the following is added to 303 the list of conversions between the filtered list of TURN 304 transports supported by the application and application protocol 305 tags: 307 "turn.dtls" is used if the TURN transport is DTLS. 309 Note that using the [RFC5928] resolution mechanism does not imply 310 that additional round trips to the DNS server will be needed (e.g., 311 the TURN client will start immediately if the TURN URI contains an IP 312 address). 314 5. Implementation Status 316 [[Note to RFC Editor: Please remove this section and the reference to 317 [RFC6982] before publication.]] 319 This section records the status of known implementations of the 320 protocol defined by this specification at the time of posting of this 321 Internet-Draft, and is based on a proposal described in [RFC6982]. 322 The description of implementations in this section is intended to 323 assist the IETF in its decision processes in progressing drafts to 324 RFCs. Please note that the listing of any individual implementation 325 here does not imply endorsement by the IETF. Furthermore, no effort 326 has been spent to verify the information presented here that was 327 supplied by IETF contributors. This is not intended as, and must not 328 be construed to be, a catalog of available implementations or their 329 features. Readers are advised to note that other implementations may 330 exist. 332 According to [RFC6982], "this will allow reviewers and working groups 333 to assign due consideration to documents that have the benefit of 334 running code, which may serve as evidence of valuable experimentation 335 and feedback that have made the implemented protocols more mature. 337 It is up to the individual working groups to use this information as 338 they see fit". 340 5.1. turnuri 342 Organization: Impedance Mismatch 344 Name: turnuri 0.5.0 http://debian.implementers.org/stable/source/ 345 turnuri.tar.gz 347 Description: A reference implementation of the URI and resolution 348 mechanism defined in this document, RFC 7065 [RFC7065] and RFC 349 5928 [RFC5928]. 351 Level of maturity: Beta. 353 Coverage: Fully implements the URIs and resolution mechanism 354 defined in this specification, in RFC 7065 and in RFC 5928. 356 Licensing: AGPL3 358 Implementation experience: TBD 360 Contact: Marc Petit-Huguenin . 362 5.2. rfc5766-turn-server 364 Organization: This is a public project, the full list of authors 365 and contributors here: http://turnserver.open-sys.org/downloads/ 366 AUTHORS. 368 Name: http://code.google.com/p/rfc5766-turn-server/ 370 Description: A mature open-source TURN server specs implementation 371 (RFC 5766, RFC 6062, RFC 6156, etc) designed for high-performance 372 applications, especially geared for WebRTC. 374 Level of maturity: Production level. 376 Coverage: Fully implements DTLS with TURN protocol. 378 Licensing: BSD: http://turnserver.open-sys.org/downloads/LICENSE 380 Implementation experience: DTLS is recommended for secure media 381 applications. It has benefits of both UDP and TLS. 383 Contact: Oleg Moskalenko 385 6. Security Considerations 387 STUN over DTLS as a STUN transport does not introduce any specific 388 security considerations beyond those for STUN over TLS detailed in 389 [RFC5389]. 391 The usage of "udp" as a transport parameter with the "stuns" URI 392 scheme does not introduce any specific security issues beyond those 393 discussed in [RFC7064]. 395 TURN over DTLS as a TURN transport does not introduce any specific 396 security considerations beyond those for TURN over TLS detailed in 397 [RFC5766]. 399 The usage of "udp" as a transport parameter with the "turns" URI 400 scheme does not introduce any specific security issues beyond those 401 discussed in [RFC7065]. 403 The new S-NAPTR application protocol tag defined in this document as 404 well as the modifications this document makes to the TURN resolution 405 mechanism described in [RFC5928] do not introduce any additional 406 security considerations beyond those outlined in [RFC5928]. 408 7. IANA Considerations 410 7.1. S-NAPTR application protocol tag 412 This specification contains the registration information for one 413 S-NAPTR application protocol tag (in accordance with [RFC3958]). 415 Application Protocol Tag: turn.dtls 417 Intended Usage: See Section 4.6.2 419 Interoperability considerations: N/A 421 Security considerations: See Section 6 423 Relevant publications: This document 425 Contact information: Marc Petit-Huguenin 427 Author/Change controller: The IESG 429 7.2. Service Name and Transport Protocol Port Number 430 This specification contains the registration information for two 431 Service Name and Transport Protocol Port Numbers (in accordance with 432 [RFC6335]). 434 7.2.1. The stuns Service Name 436 Service Name: stuns 438 Transport Protocol(s): UDP 440 Assignee: IESG 442 Contact: Marc Petit-Huguenin 444 Description: STUN over DTLS 446 Reference: This document 448 Port Number: 5349 450 7.2.2. The turns Service Name 452 Service Name: turns 454 Transport Protocol(s): UDP 456 Assignee: IESG 458 Contact: Marc Petit-Huguenin 460 Description: TURN over DTLS 462 Reference: This document 464 Port Number: 5349 466 8. Acknowledgements 468 Thanks to Alan Johnston, Oleg Moskalenko, and Simon Perreault for the 469 comments, suggestions, and questions that helped improve this 470 document. 472 9. References 474 9.1. Normative References 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, March 1997. 479 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 480 "STUN - Simple Traversal of User Datagram Protocol (UDP) 481 Through Network Address Translators (NATs)", RFC 3489, 482 March 2003. 484 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 485 Service Location Using SRV RRs and the Dynamic Delegation 486 Discovery Service (DDDS)", RFC 3958, January 2005. 488 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 489 (ICE): A Protocol for Network Address Translator (NAT) 490 Traversal for Offer/Answer Protocols", RFC 5245, April 491 2010. 493 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 494 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 496 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 497 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 498 October 2008. 500 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 501 Initiated Connections in the Session Initiation Protocol 502 (SIP)", RFC 5626, October 2009. 504 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 505 Relays around NAT (TURN): Relay Extensions to Session 506 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 508 [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT 509 (TURN) Resolution Mechanism", RFC 5928, August 2010. 511 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 512 around NAT (TURN) Extensions for TCP Allocations", RFC 513 6062, November 2010. 515 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 516 Cheshire, "Internet Assigned Numbers Authority (IANA) 517 Procedures for the Management of the Service Name and 518 Transport Protocol Port Number Registry", BCP 165, RFC 519 6335, August 2011. 521 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 522 Security Version 1.2", RFC 6347, January 2012. 524 [RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit- 525 Huguenin, "URI Scheme for the Session Traversal Utilities 526 for NAT (STUN) Protocol", RFC 7064, November 2013. 528 [RFC7065] Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P. 529 Jones, "Traversal Using Relays around NAT (TURN) Uniform 530 Resource Identifiers", RFC 7065, November 2013. 532 9.2. Informative References 534 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 535 Code: The Implementation Status Section", RFC 6982, July 536 2013. 538 [I-D.thomson-rtcweb-ice-dtls] 539 Thomson, M., "Using Datagram Transport Layer Security 540 (DTLS) For Interactivity Connectivity Establishment (ICE) 541 Connectivity Checking: ICE-DTLS", draft-thomson-rtcweb- 542 ice-dtls-00 (work in progress), March 2012. 544 [I-D.jennings-sip-dtls] 545 Jennings, C. and N. Modadugu, "Using Interactive 546 Connectivity Establishment (ICE) in Web Real-Time 547 Communications (WebRTC)", draft-jennings-sip-dtls-05 (work 548 in progress), October 2007. 550 Appendix A. Examples 552 Table 1 shows how the , and components are 553 populated for a TURN URI that uses DTLS as its transport. For all 554 these examples, the component is populated with "example.net". 556 +---------------------------------+----------+--------+-------------+ 557 | URI | | | | 558 +---------------------------------+----------+--------+-------------+ 559 | turns:example.net?transport=udp | true | | DTLS | 560 +---------------------------------+----------+--------+-------------+ 562 Table 1 564 With the DNS RRs in Figure 1 and an ordered TURN transport list of 565 {DTLS, TLS, TCP, UDP}, the resolution algorithm will convert the TURN 566 URI "turns:example.net" to the ordered list of IP address, port, and 567 protocol tuples in Table 2. 569 example.net. 570 IN NAPTR 100 10 "" RELAY:turn.udp:turn.dtls "" datagram.example.net. 571 IN NAPTR 200 10 "" RELAY:turn.tcp:turn.tls "" stream.example.net. 573 datagram.example.net. 574 IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net. 575 IN NAPTR 100 10 S RELAY:turn.dtls "" _turns._udp.example.net. 577 stream.example.net. 578 IN NAPTR 100 10 S RELAY:turn.tcp "" _turn._tcp.example.net. 579 IN NAPTR 200 10 A RELAY:turn.tls "" a.example.net. 581 _turn._udp.example.net. 582 IN SRV 0 0 3478 a.example.net. 584 _turn._tcp.example.net. 585 IN SRV 0 0 5000 a.example.net. 587 _turns._udp.example.net. 588 IN SRV 0 0 5349 a.example.net. 590 a.example.net. 591 IN A 192.0.2.1 593 Figure 1 595 +-------+----------+------------+------+ 596 | Order | Protocol | IP address | Port | 597 +-------+----------+------------+------+ 598 | 1 | DTLS | 192.0.2.1 | 5349 | 599 | 2 | TLS | 192.0.2.1 | 5349 | 600 +-------+----------+------------+------+ 602 Table 2 604 Appendix B. Release notes 606 This section must be removed before publication as an RFC. 608 B.1. Modifications between petithuguenin-tram-turn-dtls-00 and 609 petithuguenin-tram-stun-dtls-00 611 o Add RFC 6982 information for rfc5766-turn-server project. 613 o Rename the draft as TURN is now just one of the usages. 615 o Remove the references in the abstract to make idnits happy. 617 o No longer updates other standard drafts. 619 o Rewrite from a STUN over DTLS point of view. The previous text 620 becomes section 4.6. 622 o Add IANA request for stuns port. 624 o Add acknowledgement section. 626 Authors' Addresses 628 Marc Petit-Huguenin 629 Jive Communications 630 1275 West 1600 North, Suite 100 631 Orem, UT 84057 632 USA 634 Email: marcph@getjive.com 636 Gonzalo Salgueiro 637 Cisco Systems 638 7200-12 Kit Creek Road 639 Research Triangle Park, NC 27709 640 US 642 Email: gsalguei@cisco.com