RFC 7350

Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)

📅 published August 2014, from ietf

📜 RFC 7350: DTLS as Transport for STUN 🎀

Okay bestie, this is RFC 7350, a Standards Track doc from August 2014 (ISSN 2070-1721) 💅. It's called Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN). M. Petit-Huguenin (Jive Communications) and G. Salgueiro (Cisco Systems) wrote it, and it updates RFCs 5389 and 5928 ✨. That's the main-character info, so now let's get into it 🫶.

Abstract 🦋

Okay so this doc is all about using DTLS (Datagram Transport Layer Security) as a transport protocol for STUN (Session Traversal Utilities for NAT) 💖. It gives guidance on when and how to use DTLS with the STUN usages that are already standardized. It also tweaks the STUN and TURN (Traversal Using Relay NAT) URIs and the TURN resolution mechanism, so STUN and TURN URIs can be resolved into the IP address and port of servers that support DTLS as a transport. This document updates RFCs 5389 and 5928 🌸.

Status of This Memo 📋

This is an Internet Standards Track document 💜.

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 🔥. For more on Internet Standards, check Section 2 of RFC 5741.

For the current status of this document, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7350 🧚.

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) as they're in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for 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 they come 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

1. Introduction ✨

Okay so STUN [RFC5389] picks Transport Layer Security (TLS) over TCP (just called TLS [RFC5246]) as its transport, because it's more secure than plain UDP or TCP 🔐. But TCP (and so TLS-over-TCP) isn't the best vibe when STUN is doing what it was originally built for, which is supporting multimedia sessions 🎶. Everyone knows and understands this transport limitation for real-time communications, so it's not a surprise 🙈.

DTLS-over-UDP (called plain DTLS [RFC6347] in this doc) gives you the same security perks as TLS-over-TCP, just without those annoying downsides 🦋💅.

2. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119] when they show up in ALL CAPS. When they're not in ALL CAPS (like "must" or "Must"), they just mean what they normally mean in English and aren't 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 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 in Section 7.1 of [RFC5389], if the path MTU is unknown, the actual STUN message needs to be adjusted to account for the size of the (13-byte) DTLS Record header, the MAC size, and the padding size 📏.

By default, STUN over DTLS MUST use port 5349, the same port number as STUN over TLS 🍓. But the Service Record (SRV) procedures can be implemented to use a different port (as described in Section 9 of [RFC5389]). When you use SRV records, the service name MUST be set to "stuns" and the protocol name to "udp" ✨.

Classic STUN [RFC3489] (which was obsoleted by [RFC5389]) only defines UDP as a transport, so DTLS MUST NOT be used there 🙅‍♀️. Any STUN request or indication without the magic cookie (see Section 6 of [RFC5389]) sent over DTLS MUST always result in an error 🚨.

4. STUN Usages 🧚

Section 7.2 of [RFC5389] says that STUN usages must specify which transport protocol is used 📋. The sections below talk about whether and how the existing STUN usages work with DTLS as the transport 💅. Future STUN usages MUST take DTLS into account as a transport and discuss its applicability 🔮. In all cases, new STUN usages MUST explicitly state whether implementing the denial-of-service countermeasure described in Section 4.2.1 of [RFC6347] is mandatory 🛡️.

4.1. NAT Discovery Usage 🔍

As Section 13 of [RFC5389] puts it, "...TLS provides minimal security benefits..." for this particular STUN usage 🤷‍♀️. DTLS will also offer only limited benefit, similarly. That's because the only mandatory attribute that TLS/DTLS protects is the XOR-MAPPED-ADDRESS, which an on-path attacker already knows, since it matches the source address and port of the STUN request 👀. On the other hand, using TLS/DTLS stops an active attacker from injecting XOR-MAPPED-ADDRESS into responses 🙅. The TLS/DTLS transport also protects the SOFTWARE attribute, which could be used to find vulnerabilities in STUN implementations 😬.

Honestly though, this usage is rarely used by itself, since using TURN [RFC5766] with Interactive Connectivity Establishment (ICE) [RFC5245] is basically indispensable 💖. TURN gives you the same NAT Discovery feature as part of creating an allocation. In fact, with ICE, the NAT Discovery usage only comes into play when the TURN server has no resources left for new allocations 🎀.

A STUN server that implements the NAT Discovery usage and uses DTLS MUST implement the denial-of-service countermeasure described in Section 4.2.1 of [RFC6347] 🛡️💜.

4.1.1. DTLS Support in STUN URIs 🌸

This document doesn't change the syntax of a STUN URI [RFC7064] 📎. As Section 3.2 of [RFC7064] says, secure transports like STUN over TLS, and now STUN over DTLS, MUST use the "stuns" URI scheme 🔐.

The <host> value MUST be used when following 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 was 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's only known by looking at the Session Description Protocol (SDP) that gets exchanged, an attacker who doesn't have access to that SDP can't inject a wrong XOR-MAPPED-ADDRESS, which would then get used as a peer reflexive candidate 🛑.

Adding DTLS on top of the connectivity check would delay the ICE process and therefore hurt it 🐢. Extra round trips to ICE are so undesirable that there's a proposal ([ICE-DTLS]) to use the DTLS handshake from WebRTC Secure Real-time Transport Protocol (SRTP) streams as a replacement for the connectivity checks ✨.

STUN URIs aren't used with this usage 🙅‍♀️.

4.3. Media Keep-Alive Usage 📡

When STUN Binding Indications are used for media keep-alive (described in Section 10 of [RFC5245]), they run alongside an RTP or RTP Control Protocol (RTCP) session 🎵. It's possible to send these media keep-alive packets inside a separately negotiated non-SRTP DTLS session if DTLS-SRTP [RFC5764] is used, but that adds overhead for minimal security benefit 🙄.

STUN URIs aren't used with this usage 🙅.

4.4. SIP Keep-Alive Usage 💌

The SIP keep-alive (described in [RFC5626]) runs inside a SIP flow 🌊. That flow would be protected if a SIP over DTLS transport mechanism is implemented (such as the one described in [SIP-DTLS]) 🔒.

STUN URIs aren't used with this usage 🙅‍♀️.

4.5. NAT Behavior Discovery Usage 🧪

The NAT Behavior Discovery usage is Experimental, and to date it has never been effectively deployed 🥲. Even so, using DTLS would add the same security properties as the NAT Discovery usage (Section 4.1) 💜.

The STUN URI can be used to get at the NAT Discovery feature of a NAT Behavior Discovery server. But getting to the full features would need a "stun-behaviors:" URI, and that's out of scope for this document 🚧.

A STUN server that implements the NAT Behavior Discovery usage and uses DTLS MUST implement the denial-of-service countermeasure described in Section 4.2.1 of [RFC6347] 🛡️🦋.

4.6. TURN Usage ✨

okay so TURN [RFC5766] already has three transport/allocation combos: UDP/UDP, TCP/UDP, and TLS/UDP. this doc adds DTLS/UDP as a valid combo 💖 and bestie, a TURN server using DTLS MUST implement the denial-of-service countermeasure described in Section 4.2.1 of [RFC6347] 🛡️

[RFC6062] says TCP allocations can't be obtained using a UDP association between client and server. since DTLS runs over UDP, 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 🔥 the SRV procedures can be set up to use a different port (see Section 6 of [RFC5766]). and when you're using SRV records, the service name MUST be set to "turns" and the protocol name to "udp" 🎀

4.6.1. DTLS Support in TURN URIs

this doc doesn't change the syntax of a TURN URI [RFC7065] 🙌 as Section 3 of [RFC7065] explains, secure transports like TURN over TLS (and now TURN over DTLS) MUST use the "turns" URI scheme. when you use "turns" to designate TURN over DTLS, the transport value of the TURN URI, if it's set, MUST be "udp" 💜

the <host> value MUST be used when you follow the rules in Section 7.2.2 of [RFC5389] to verify the server identity. and 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 doc defines a brand new Straightforward-Naming Authority Pointer (S-NAPTR) application protocol tag: "turn.dtls" 🧚

the <transport> component (either provisioned or pulled out of a TURN URI) gets passed as-is to the TURN resolution mechanism in Section 3 of [RFC5928]. the only changes are these:

  • the acceptable values for the transport name get "dtls" added to them 🌸
  • the ordered list of supported TURN transports gets "Datagram Transport Layer Security (DTLS)" added to it 💅
  • the resolution algorithm check rules list gets this extra 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.
  • the 5th rule of the resolution algorithm check rules list gets rewritten 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.
  • Table 1 gets one new line:
+----------+-------------+----------------+
| <secure> | <transport> | TURN Transport |
+----------+-------------+----------------+
| true     | "udp"       | DTLS           |
+----------+-------------+----------------+
  • in step 1 of the resolution algorithm, the default port for DTLS is 5349 🔢
  • in step 4 of the resolution algorithm, this gets added to the list of conversions between the filtered list of TURN transports and application protocol tags:
"turn.dtls" is used if the TURN transport is DTLS.

ngl the one thing to keep in mind is that using the resolution mechanism in [RFC5928] doesn't mean you'll need extra round trips to the DNS server. like, if the TURN URI has an IP address in it, the TURN client starts right away ⚡

5. Security Considerations 🔐

okay this part is SO important, so read it carefully 🫶

STUN over DTLS, as a STUN transport, doesn't add any specific security considerations beyond the ones for STUN over TLS in [RFC5389] 🔒

using "udp" as a transport parameter with the "stuns" URI scheme doesn't bring in any specific security issues beyond the ones discussed in [RFC7064] ✅

TURN over DTLS, as a TURN transport, doesn't add any specific security considerations beyond the ones for TURN over TLS in [RFC5766] 💖

using "udp" as a transport parameter with the "turns" URI scheme doesn't bring in any specific security issues beyond the ones discussed in [RFC7065] ✨

the new S-NAPTR application protocol tag defined here, plus the changes this doc makes to the TURN resolution mechanism in [RFC5928], don't add any security considerations beyond the ones already outlined in [RFC5928] 🛡️

6. IANA Considerations 📋

6.1. S-NAPTR Application Protocol Tag

this spec has the registration info for one S-NAPTR application protocol tag. it goes in the "Straightforward-NAPTR (S-NAPTR) Parameters" registry, under "S-NAPTR Application Protocol Tags" (following [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 <petithug@acm.org>
Author/Change controller:  The IESG

6.2. Service Name and Transport Protocol Port Number

this spec has the registration info 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 (following [RFC6335]) 🦋

6.2.1. The "stuns" Service Name

IANA has modified the following entry in the registry "Service Names and Transport Protocol Port Number/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 <chair@ietf.org>
Reference:  RFC 7350
Assignment Notes:  This service name was initially created by
   RFC 5389.

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 <chair@ietf.org>
Reference:  RFC 7350
Assignment Notes:  This service name was initially created by
   RFC 5766.

7. Acknowledgements 💜

huge 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 made this doc way better 🌈

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.

[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.

Appendix A. Examples ✨

okay so this is the fun part, bestie 🎀 we're going to walk through real examples of how a TURN URI gets turned into actual places to connect. no cap, the examples make everything click 🫶

Table 1 shows how the <secure>, <port>, and <transport> components get filled in for a TURN URI that uses DTLS as its transport. for all of these examples, the <host> component is set to "example.net" 💖

+---------------------------------+----------+--------+-------------+
| URI                             | <secure> | <port> | <transport> |
+---------------------------------+----------+--------+-------------+
| turns:example.net?transport=udp | true     |        | DTLS        |
+---------------------------------+----------+--------+-------------+

                              Table 1

so now the spicy bit 🌶️ we've got the DNS Resource Records (RRs) in Figure 1, and an ordered TURN transport list of {DTLS, TLS, TCP, UDP}. the resolution algorithm takes the TURN URI "turns:example.net" and converts it into the ordered list of IP address, port, and protocol tuples you see in Table 2. it's giving a whole map 🗺️✨

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
+-------+----------+------------+------+
| Order | Protocol | IP address | Port |
+-------+----------+------------+------+
| 1     | DTLS     | 192.0.2.1  | 5349 |
| 2     | TLS      | 192.0.2.1  | 5349 |
+-------+----------+------------+------+

                              Table 2

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

that's the whole thing, bestie 🌈💜 the authors put in the work, and we're officially done with RFC 7350! 👑

📦 where this page comes from