STUN is a protocol that helps Internet endpoints dealing with NAT (Network Address Translation), a typical condition for hosts belonging to a private network and requiring to be accessed from another network, like the public Internet.
Why Use STUN?
Real Time Communication services use STUN in various ways, from helping discovering the public IP address and port associated to an endpoint behind NAT (the basic “STUN service”), helping establishing connection checks for ICE (RFC 8445), to working as a basis for relaying with TURN (RFC 8656) or as a keep-alive technique for SIP OUTBOUND (RFC 5626).
If you'd like to learn more about TURN, then feel free to take a look at my TURN 101 blog.
We will refer to transport addresses, which are just a combination of an IP address and a port.
STUN can be used as the basis for NAT traversal solutions, and provides three main features:
- an extensible packet format
- coverage for multiple transport protocols
- two authentication mechanisms
In order to use STUN, a NAT traversal solution must implement a so-called “usage”, which needs to define when STUN messages are exchanged, what optional attributes to use, what type of server is used, and the authentication mechanism or mechanisms.
ICE (RFC 8445), SIP OUTBOUND (RFC 5626) and NAT Behavior Discovery (RFC 5780) are all examples of a STUN usage.
Furthermore STUN can be extended with additional methods, responses and attributes, like it happens with TURN (RFC 8656).
How does STUN work?
STUN is a simple client/server protocol and defines two types of transactions: Request/Response and Indication (if you’re familiar with TURN, examples are Allocate Request/Response and Send/Data Indications; indications are not reliable and cannot be authenticated.
A client sends a Request, a server sends a Response. Both client and server can send an Indication. All transactions carry a 96 bit transaction ID.
All STUN messages have a fixed header with: Method (e.g. Binding), Class (Request, Success Response, Error Response, etc) and Transaction ID, followed by zero or more attributes, some of which may be optional or mandatory depending on the context. Optionally, a fingerprint is added.
The header is binary, in network order, big endian, with 20 Bytes for the fixed part: 2 Bytes for the message type, 2 Bytes for the message length, 4 Bytes for the Magic Cookie (0x2112A442 - used to distinguish a STUN from other types, but also to XOR the transport addresses) and 12 Bytes for the Transaction ID.
Binding Request
The simplest method is a Binding Request. A client sends a Binding Request to a server, and the server replies with a Binding Response containing the client’s server reflexive transport address, which is the IP address and port seen by the server as source of the request. The server reflexive transport address is returned, XOR’d, inside the XOR-MAPPED-ADDRESS attribute.
As STUN servers are typically located in the public internet, this is the easiest way for a client to discover its IP address and port on the outmost NAT.
Authentication Mechanisms
Two authentication mechanisms are defined: short-term and long-term credentials. The former is used in contexts like ICE, where endpoints exchange short-lived credentials to establish their identity during connectivity checks, while the latter is used in services like TURN, where the clients must authenticate before being allowed to create relay allocations.
With short-term credentials, authentication requires a USERNAME and MESSAGE-INTEGRITY attribute, while with long-term credentials, the client is first challenged with a Realm and Nonce attribute with a 401 Error Response (similarly to what happens with Digest Authentication in SIP), and then the client uses them with the credentials to compute the MESSAGE-INTEGRITY value leading to a successful authentication. The MESSAGE-INTEGRITY field is a HMAC-SHA1 of the message, with a key computed with just the password for short-term credentials, or with password, realm and nonce for long term credentials (again, similar to SIP).
It’s interesting to note that STUN messages can be multiplexed with other protocols, like it happens with RTP during WebRTC sessions.
As it happens with other services, STUN servers can be located using DNS SRV lookups, where the service type is stun for unencrypted UDP or TCP (default port: 3478) or stuns for encrypted connections (TLS, default port 5349).
STUN has also a redirect mechanism (similar to the one used for SIP, and the one actually used for TURN), which is based on a 300 Error Response with an ALTERNATE-SERVER attribute containing the transport address of an alternative server where the client is expected to redirect its requests.
As we saw, STUN attributes can optionally be present, and they have a Type-Length-Value structure: 2 Bytes for the type, 2 Bytes for the length, followed by the value (padded to multiple of 4 Bytes). Standard attributes are USERNAME, ERROR-CODE, REALM, NONCE, SOFTWARE, ALTERNATE-SERVER.
How to Dissect STUN Messages?
Wireshark is able to detect STUN messages and to dissect them for you, so you can use the ‘stun’ filter, or more sophisticated ones like ‘stun.type.method==0x0001’ to see all Binding Requests and Responses, or ‘stun.type.method==0x0001 and stun.type.class==0x0010’ to see all Binding Responses.
Here’s an example of Wireshark dissecting a STUN Binding Request:
Subspace Provides a Managed WebRTC Network
Subspace is the only managed WebRTC network service for high-quality connectivity on the world’s only optimized, dedicated network for today’s real-time applications.
Subspace has reimagined NAT traversal by making it an inherent part of the network rather than an add-on. We use the TURN protocol to bring traffic onto Subspace without the need for traditional TURN servers, while improving performance for all WebRTC traffic. With Subspace WebRTC-CDN, you get seamless and performant NAT traversal without deploying your own TURN servers.
Subspace’s network includes real-time internet weather mapping to ensure your packets are routed on the most optimal path. Our patented Dynamic Packet Routing can reduce latency by more than 80% (depending on your traffic's origination and destination) and virtually eliminates jitter and packet loss.
Giacomo Vacca is a Senior Voice Engineer at Subspace and a real-time communications expert with more than 20 years of experience building and scaling VoIP, IM, and WebRTC solutions. Follow him on Twitter @giavac.