STUN Server - Everything You Need To Know

Definition

STUN, an acronym for Session Traversal Utilities for NAT, is a network protocol utilized primarily for NAT traversal. Its primary function is to permit a device operating behind a NAT to ascertain its public IP address and the type of NAT it's behind. The protocol achieves this by allowing the device to send a request to an external STUN server, which then responds with details about the public IP address and port from which the request was seen. This information aids in setting up peer-to-peer communication channels, especially in voice and video call applications where direct end-to-end data transfer is essential. STUN plays a pivotal role in various real-time communication protocols, including WebRTC, by assisting in the discovery of Network Endpoint Translation (NET) public addresses.

What does it mean?

Imagine you're in a massive hotel with thousands of rooms. You're in your room and you want to receive a special delivery, but the hotel has a unique policy: room numbers aren't shared with outsiders. So, when a delivery person arrives at the hotel, they don't know which room you're in.

To solve this, the hotel provides a concierge service. You can call the concierge and ask, "If someone from outside were to try and deliver something to me, how would they identify my room?" The concierge then gives you a unique identifier, not your actual room number, which you can share with the delivery person. The delivery arrives at the concierge with this identifier, and they can direct it to your room.

This hotel is like your home network, the room is your device, the concierge is STUN, and the unique identifier is the public IP and port you can share with others on the internet.

History of STUN

What was used before STUN?

Before STUN, achieving peer-to-peer (P2P) communication through NAT (Network Address Translation) was complex. The primary methods before STUN were:

• Application-Level Gateways (ALGs): ALGs were software components in a NAT device, designed for specific protocols like FTP or SIP. They would inspect packets and modify them, allowing the specific protocol to work through NAT.
• Manual Port Forwarding: This required users to manually configure their NAT device to forward incoming connections on specific ports to specific machines within the local network. It was not user-friendly and posed security risks.
• Relaying: When direct communication failed, servers in the middle (relays) were used to forward traffic between endpoints. While reliable, this method increased latency and imposed additional server costs and bandwidth usage.

What challenges did it face?

The challenges in achieving NAT traversal before STUN were:

• Variety of NAT Behaviors: Not all NAT devices behaved the same way. Some would maintain the internal source port while others would change it. Some would use different ports for different external destinations, known as "Symmetric NAT", which posed significant challenges for P2P communications.
• Dynamic Nature of NAT Bindings: NATs would often change the mapping of internal IP and port to an external one dynamically or based on a timer, making sustained communication tricky.
• Lack of Standardization: Without a standardized approach, every P2P application had to potentially devise its mechanism to work with NATs, leading to inefficiencies and compatibility issues.
• Security Concerns: Manual port forwarding exposed internal devices to potential external threats, as specific ports were always open.

How STUN is solving it?

STUN (Session Traversal Utilities for NAT) addressed these challenges by providing a standardized mechanism:

• Discovery of Public IP and Port: A device behind a NAT could send a request to a STUN server, which would respond with the device's public IP address and port number as seen from the server's perspective.
• NAT Behavior Detection: By making multiple requests to a STUN server and observing the responses, a device could deduce the type of NAT it's behind (e.g., Full Cone, Restricted Cone, Port Restricted, or Symmetric).
• Facilitation of P2P: Once a device knows its public IP and port, it can share this with other devices to establish direct P2P communication. In cases where direct P2P isn't possible (like with Symmetric NATs), at least the STUN process informs the device of the limitation, allowing it to seek alternative methods like TURN (Traversal Using Relays around NAT).
• Standardization: STUN provided a standardized protocol that software developers could rely on, ensuring consistent behavior across different applications and platforms.

How STUN Works

STUN (Session Traversal Utilities for NAT) is an integral protocol for facilitating peer-to-peer (P2P) and Voice over Internet Protocol (VoIP) communications, particularly within the context of WebRTC applications, by addressing the complexities of NAT traversal. In environments where multiple devices operate behind a single public IP address provided by a NAT, establishing direct end-to-end connections becomes problematic due to the NAT's port restrictions and the obscuring of individual device IPs.

The protocol's primary mechanism involves binding requests and responses: A STUN client sends a binding request to a STUN server on the internet, which responds with the public IP address and the port number that maps to the client's private IP and port. This information is essential for the device to share its connectivity details with external peers to enable direct communication.

STUN messages include various attributes for robust functionality. One such attribute is the XOR-MAPPED-ADDRESS, which reveals the public IP and port necessary for the communication. To ensure the messages are authentic and unaltered, the protocol also uses MESSAGE-INTEGRITY attributes, which incorporate HMAC-SHA1 hashes of the message contents.

In the specific case of WebRTC, STUN plays a pivotal role in the gathering of ICE (Interactive Connectivity Establishment) candidates, representing the potential network paths for two peers to connect. The STUN server is crucial in obtaining server-reflexive candidates, which is one type of ICE candidate necessary for establishing the connection.

However, STUN is not a one-size-fits-all solution to NAT traversal. Certain types of NATs, like symmetric NATs, dynamically assign ports for outbound traffic and are not easily handled by STUN alone. An alternative protocol such as TURN (Traversal Using Relays around NAT) is used in such instances. TURN facilitates connectivity by relaying traffic through an intermediary server, providing a reliable means of communication when STUN is unable to establish a direct path.

Frequently Asked Questions

Does Google have a STUN server?

Yes, Google provides a public STUN server which can be accessed at stun.l.google.com:19302

What is the full form of the STUN server?

The full form of the STUN server is the "Session Traversal Utilities for NAT" server.

Is the STUN server TCP or UDP?

STUN servers primarily use UDP (User Datagram Protocol) for client communication due to its lower latency than TCP (Transmission Control Protocol).

References:

• https://www.3cx.com/pbx/what-is-a-stun-server/
• https://en.wikipedia.org/wiki/STUN
• https://getstream.io/glossary/stun-server/
• https://bloggeek.me/webrtcglossary/stun/