URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol
Extracted elements (12)
Following RFC 4395 Section 2.2, the STUN URI is opaque (non-hierarchical) because it does not describe a hierarchical structure, despite borrowing host/port syntax from RFC 3986.
The 's' suffix approach (stun/stuns) was chosen over a URI parameter (e.g., ';proto=tls') because the need for such a parameter could not be sufficiently explained, supporting it would render an incomplete specification, and the suffix maintains symmetry with the TURN URI scheme.
For the optional DNS SRV discovery procedure (RFC 5389 Section 9), the 'stun' URI scheme implies UDP as the transport protocol for SRV lookup, while 'stuns' indicates TCP as the transport protocol.
Developers MUST NOT use a generic hierarchical URI parser to parse a 'stun' or 'stuns' URI, because despite using RFC 3986 host/port productions, the schemes are not hierarchical URIs.
The 'stuns' URI scheme MUST be used when STUN is run over TLS-over-TCP (or in the future DTLS-over-UDP); the 'stun' scheme MUST be used otherwise.
The default port for both UDP and TCP STUN is 3478. The default port for STUN over TLS (stuns scheme) is 5349, as defined in Section 9 of RFC 5389.
The 'stun' and 'stuns' URI schemes designate a stand-alone STUN server or any Internet host performing STUN server operations in the context of STUN usages (RFC 5389 Section 14). The STUN protocol supports UDP, TCP, or TLS-over-TCP.
The 'stun' and 'stuns' URI schemes have ABNF syntax: stunURI = scheme ":" host [ ":" port ], where scheme = "stun" / "stuns". The <host> and <port> components follow RFC 3986.
Permanent IANA registration of the 'stun' URI scheme for use by applications identifying a STUN server for NAT traversal. Registered per RFC 4395 with the IESG as change controller.
Permanent IANA registration of the 'stuns' URI scheme for use by applications identifying a STUN server for NAT traversal over a secure (TLS) connection. Registered per RFC 4395 with the IESG as change controller.
A STUN client MUST ensure that the username, password, 'stuns' URI, and any other security-relevant parameters are received with equivalent security before using the 'stuns' URI. Receiving those parameters over a TLS session with commensurate ciphersuites is one appropriate mechanism.
In WebRTC environments, credentials (username and password) are often provisioned remotely at the same time as a 'stuns' URI. If credentials are received in the clear, using a 'stuns' URI provides little or no security benefit, making secure credential delivery essential.