From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7350.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc7350.txt (limited to 'doc/rfc/rfc7350.txt') diff --git a/doc/rfc/rfc7350.txt b/doc/rfc/rfc7350.txt new file mode 100644 index 0000000..c3685d1 --- /dev/null +++ b/doc/rfc/rfc7350.txt @@ -0,0 +1,899 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Petit-Huguenin +Request for Comments: 7350 Jive Communications +Updates: 5389, 5928 G. Salgueiro +Category: Standards Track Cisco Systems +ISSN: 2070-1721 August 2014 + + + Datagram Transport Layer Security (DTLS) as Transport + for Session Traversal Utilities for NAT (STUN) + +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 Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7350. + + + + + + + + + + + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 1] + +RFC 7350 STUN over DTLS August 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. DTLS as Transport for STUN . . . . . . . . . . . . . . . . . 3 + 4. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4.1. NAT Discovery Usage . . . . . . . . . . . . . . . . . . . 4 + 4.1.1. DTLS Support in STUN URIs . . . . . . . . . . . . . . 5 + 4.2. Connectivity Check Usage . . . . . . . . . . . . . . . . 5 + 4.3. Media Keep-Alive Usage . . . . . . . . . . . . . . . . . 5 + 4.4. SIP Keep-Alive Usage . . . . . . . . . . . . . . . . . . 6 + 4.5. NAT Behavior Discovery Usage . . . . . . . . . . . . . . 6 + 4.6. TURN Usage . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.6.1. DTLS Support in TURN URIs . . . . . . . . . . . . . . 7 + 4.6.2. Resolution Mechanism for TURN over DTLS . . . . . . . 7 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 6.1. S-NAPTR Application Protocol Tag . . . . . . . . . . . . 9 + 6.2. Service Name and Transport Protocol Port Number . . . . . 9 + 6.2.1. The "stuns" Service Name . . . . . . . . . . . . . . 10 + 6.2.2. The "turns" Service Name . . . . . . . . . . . . . . 11 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 + 8.2. Informative References . . . . . . . . . . . . . . . . . 13 + Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14 + + + + + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 2] + +RFC 7350 STUN over DTLS August 2014 + + +1. Introduction + + STUN [RFC5389] defines Transport Layer Security (TLS) over TCP + (simply referred to as TLS [RFC5246]) 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 [RFC6347]) + offers the same security advantages as TLS-over-TCP, but without the + undesirable concerns. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" + in this document are to be interpreted as described in [RFC2119] 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 RFC 2119 key words. + +3. DTLS as Transport for STUN + + STUN [RFC5389] 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 Section 7.2.1 of [RFC5389]). It MUST also use + the same rules that are described in Section 7.2.2 of [RFC5389] 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 Section 7.2.2 of [RFC5389] 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 Section 7.1 of + [RFC5389], 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. + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 3] + +RFC 7350 STUN over DTLS August 2014 + + + 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 Section 9 of + [RFC5389]). When using SRV records, the service name MUST be set to + "stuns" and the protocol name to "udp". + + Classic STUN [RFC3489] (which was obsoleted by [RFC5389]) defines + only UDP as a transport, and DTLS MUST NOT be used. Any STUN request + or indication without the magic cookie (see Section 6 of [RFC5389]) + over DTLS MUST always result in an error. + +4. STUN Usages + + Section 7.2 of [RFC5389] 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 Section 4.2.1 of [RFC6347] is mandatory. + +4.1. NAT Discovery Usage + + As stated by Section 13 of [RFC5389], "...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 + [RFC5766] with Interactive Connectivity Establishment (ICE) [RFC5245] + 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 + Section 4.2.1 of [RFC6347]. + + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 4] + +RFC 7350 STUN over DTLS August 2014 + + +4.1.1. DTLS Support in STUN URIs + + This document does not make any changes to the syntax of a STUN URI + [RFC7064]. As indicated in Section 3.2 of [RFC7064], secure + transports like STUN over TLS, and now STUN over DTLS, MUST use the + "stuns" URI scheme. + + The value MUST be used when using the rules in Section 7.2.2 + of [RFC5389] 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. + +4.2. Connectivity Check Usage + + 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 ([ICE-DTLS]) + 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. + +4.3. Media Keep-Alive Usage + + When STUN Binding Indications are being used for media keep-alive + (described in Section 10 of [RFC5245]), 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 [RFC5764] is used, but that would add overhead, + with minimal security benefit. + + STUN URIs are not used with this usage. + + + + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 5] + +RFC 7350 STUN over DTLS August 2014 + + +4.4. SIP Keep-Alive Usage + + The SIP keep-alive (described in [RFC5626]) runs inside a SIP flow. + This flow would be protected if a SIP over DTLS transport mechanism + is implemented (such as described in [SIP-DTLS]). + + STUN URIs are not used with this usage. + +4.5. NAT Behavior Discovery Usage + + 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 + (Section 4.1). + + 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 + Section 4.2.1 of [RFC6347]. + +4.6. TURN Usage + + TURN [RFC5766] 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 Section 4.2.1 of + [RFC6347]. + + [RFC6062] 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 Section 6 of [RFC5766]). When + using SRV records, the service name MUST be set to "turns" and the + protocol name to "udp". + + + + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 6] + +RFC 7350 STUN over DTLS August 2014 + + +4.6.1. DTLS Support in TURN URIs + + This document does not make any changes to the syntax of a TURN URI + [RFC7065]. As indicated in Section 3 of [RFC7065], 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 value MUST be used when using the rules in Section 7.2.2 + of [RFC5389] 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. + +4.6.2. Resolution Mechanism for TURN over DTLS + + This document defines a new Straightforward-Naming Authority Pointer + (S-NAPTR) application protocol tag: "turn.dtls". + + The component, as provisioned or resulting from the + parsing of a TURN URI, is passed without modification to the TURN + resolution mechanism defined in Section 3 of [RFC5928], 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 is true and 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 is true and 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. + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 7] + +RFC 7350 STUN over DTLS August 2014 + + + o Table 1 is modified to add the following line: + + +----------+-------------+----------------+ + | | | 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 [RFC5928] 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). + +5. Security Considerations + + STUN over DTLS as a STUN transport does not introduce any specific + security considerations beyond those for STUN over TLS detailed in + [RFC5389]. + + The usage of "udp" as a transport parameter with the "stuns" URI + scheme does not introduce any specific security issues beyond those + discussed in [RFC7064]. + + TURN over DTLS as a TURN transport does not introduce any specific + security considerations beyond those for TURN over TLS detailed in + [RFC5766]. + + The usage of "udp" as a transport parameter with the "turns" URI + scheme does not introduce any specific security issues beyond those + discussed in [RFC7065]. + + 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 [RFC5928] do not introduce any additional + security considerations beyond those outlined in [RFC5928]. + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 8] + +RFC 7350 STUN over DTLS August 2014 + + +6. IANA Considerations + +6.1. S-NAPTR Application Protocol Tag + + 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 [RFC3958]). + + Application Protocol Tag: turn.dtls + Intended Usage: See Section 4.6.2 + Interoperability considerations: N/A + Security considerations: See Section 5 + Relevant publications: This document + Contact information: Marc Petit-Huguenin + Author/Change controller: The IESG + +6.2. Service Name and Transport Protocol Port Number + + 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 [RFC6335]). + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 9] + +RFC 7350 STUN over DTLS August 2014 + + +6.2.1. The "stuns" Service Name + + 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: RFC 5389 + + So that it contains the following: + + Service Name: stuns + Port Number: 5349 + Transport Protocol: udp + Description: STUN over DTLS + Assignee: IESG + Contact: IETF Chair + Reference: RFC 7350 + Assignment Notes: This service name was initially created by + RFC 5389. + + + + + + + + + + + + + + + + + + + + + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 10] + +RFC 7350 STUN over DTLS August 2014 + + +6.2.2. The "turns" Service Name + + 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: RFC 5766 + + So that it contains the following: + + Service Name: turns + Port Number: 5349 + Transport Protocol: udp + Description: TURN over DTLS + Assignee: IESG + Contact: IETF Chair + Reference: RFC 7350 + Assignment Notes: This service name was initially created by + RFC 5766. + +7. Acknowledgements + + 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. + + + + + + + + + + + + + + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 11] + +RFC 7350 STUN over DTLS August 2014 + + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, + "STUN - Simple Traversal of User Datagram Protocol (UDP) + Through Network Address Translators (NATs)", RFC 3489, + March 2003. + + [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application + Service Location Using SRV RRs and the Dynamic Delegation + Discovery Service (DDDS)", RFC 3958, January 2005. + + [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment + (ICE): A Protocol for Network Address Translator (NAT) + Traversal for Offer/Answer Protocols", RFC 5245, April + 2010. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for NAT (STUN)", RFC 5389, + October 2008. + + [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- + Initiated Connections in the Session Initiation Protocol + (SIP)", RFC 5626, October 2009. + + [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer + Security (DTLS) Extension to Establish Keys for the Secure + Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. + + [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using + Relays around NAT (TURN): Relay Extensions to Session + Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. + + [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT + (TURN) Resolution Mechanism", RFC 5928, August 2010. + + [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays + around NAT (TURN) Extensions for TCP Allocations", RFC + 6062, November 2010. + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 12] + +RFC 7350 STUN over DTLS August 2014 + + + [RFC6335] 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", BCP 165, RFC + 6335, August 2011. + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, January 2012. + + [RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit- + Huguenin, "URI Scheme for the Session Traversal Utilities + for NAT (STUN) Protocol", RFC 7064, November 2013. + + [RFC7065] Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P. + Jones, "Traversal Using Relays around NAT (TURN) Uniform + Resource Identifiers", RFC 7065, November 2013. + +8.2. Informative References + + [ICE-DTLS] Thomson, M., "Using Datagram Transport Layer Security + (DTLS) For Interactivity Connectivity Establishment (ICE) + Connectivity Checking: ICE-DTLS", Work in Progress, March + 2012. + + [SIP-DTLS] Jennings, C. and N. Modadugu, "Session Initiation Protocol + (SIP) over Datagram Transport Layer Security (DTLS)", Work + in Progress, October 2007. + + + + + + + + + + + + + + + + + + + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 13] + +RFC 7350 STUN over DTLS August 2014 + + +Appendix A. Examples + + Table 1 shows how the , , and components + are populated for a TURN URI that uses DTLS as its transport. For + all these examples, the component is populated with + "example.net". + + +---------------------------------+----------+--------+-------------+ + | URI | | | | + +---------------------------------+----------+--------+-------------+ + | 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 + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 14] + +RFC 7350 STUN over DTLS August 2014 + + + +-------+----------+------------+------+ + | Order | Protocol | IP address | Port | + +-------+----------+------------+------+ + | 1 | DTLS | 192.0.2.1 | 5349 | + | 2 | TLS | 192.0.2.1 | 5349 | + +-------+----------+------------+------+ + + Table 2 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Petit-Huguenin & Salgueiro Standards Track [Page 15] + +RFC 7350 STUN over DTLS August 2014 + + +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] + -- cgit v1.2.3