As a software developer, how do you get around the limitations of NAT? STUN - Session Traversal Utilities for NAT (RFC5389) - provides a simple tool for just this purpose. STUN servers and clients are commonplace today, but how do they work? Why do we use them? And what does the average developer need to know?
Prerequisite: NAT Primer or a basic understanding of NAT
Given a decent understanding of NAT, we know that a client behind a NAT device cannot receive inbound packets unless a binding has been established. In the context of UDP, bindings are created by first sending an outbound UDP packet from client to server. This initial packet sets up some state on the NAT device thus allowing subsequent traffic from server to client to proceed unhindered. STUN Binding requests serve this very purpose and more.
For example, suppose a video player client wishes to receive a stream of video packets. The client has somehow learned the video server's source IP and port number (perhaps via RTSP). Two problems must be resolved before video can flow from server to client:
Step two is a little more difficult. The client needs to learn the dynamic mapping that the NAT device created for the first outgoing UDP packet. For example, the client may have sent an empty packet from its internal IP address (192.168.1.100:12345) to the server's public IP address (64.1.2.3:45678). Now, any incoming packets which reach the NAT on the port mapped for 192.168.1.100:12345 will forwarded accordingly. So what is the mapped port? STUN provides the answer.
Using STUN accomplishes step one and easily facilitates step two. Here's how it works: First the video server listens for STUN packets on the port it will be using for video traffic. The client sends a STUN packet to that port on the video server. For the sake of this explanation, assume the STUN packet is just an empty UDP packet with a few attributes used to distinguish it (explained later). Once the server receives this STUN packet, it generates a response. In the response's body, the server will include the source IP and port of the original incoming packet. This address is actually an external ip:port of the NAT device which was dynamically bound to the client's internal address and port earlier (by the first outgoing STUN packet). Once generated, the response is sent back to the NAT device, the NAT device forwards it to the client, and the client receives it. Finally, the client interprets the response's contents and learns its own external address. The client may use this information to refer services. For example, the video server can be told the address and port that it should use for sending video traffic.
One benefit of STUN, over other NAT traversal utilities, is its ability to cope with a complex hierarchy of NAT devices. Protocols such as UPnP lack this ability.
STUN also offers security. Each STUN packet contains a number of key-value attributes. MESSAGE-INTEGRITY is one such field. It provides an encrypted hash of the packet. The server knows the client's encryption key by some other means and it may use that key to authenticate the inbound STUN packet.
Other attributes include the following (refer to RFC5389 for a complete list):
The STUN RFC (5389) is short and certainly a worthwhile read. Note that STUN is not a complete NAT traversal solution. It is merely a NAT traversal "utility." In a future post, I will discuss ICE, Interactive Connectivity Establishment, which puts STUN to work in a complete NAT traversal solution.
If you're looking to get started with STUN and NAT traversal right away, but don't want to spend time implementing your own stack, check out the following:Note that most existing STUN implementations are RFC3489 compliant (which was replaced by RFC5389). If you know of a good RFC5389 implementation, please leave a link in the comments or send me an email and I will add it to this post.
Prerequisite: NAT Primer or a basic understanding of NAT
Given a decent understanding of NAT, we know that a client behind a NAT device cannot receive inbound packets unless a binding has been established. In the context of UDP, bindings are created by first sending an outbound UDP packet from client to server. This initial packet sets up some state on the NAT device thus allowing subsequent traffic from server to client to proceed unhindered. STUN Binding requests serve this very purpose and more.
For example, suppose a video player client wishes to receive a stream of video packets. The client has somehow learned the video server's source IP and port number (perhaps via RTSP). Two problems must be resolved before video can flow from server to client:
- Open a binding on the NAT device
- Inform the server of the client's public IP address
Step two is a little more difficult. The client needs to learn the dynamic mapping that the NAT device created for the first outgoing UDP packet. For example, the client may have sent an empty packet from its internal IP address (192.168.1.100:12345) to the server's public IP address (64.1.2.3:45678). Now, any incoming packets which reach the NAT on the port mapped for 192.168.1.100:12345 will forwarded accordingly. So what is the mapped port? STUN provides the answer.
Using STUN accomplishes step one and easily facilitates step two. Here's how it works: First the video server listens for STUN packets on the port it will be using for video traffic. The client sends a STUN packet to that port on the video server. For the sake of this explanation, assume the STUN packet is just an empty UDP packet with a few attributes used to distinguish it (explained later). Once the server receives this STUN packet, it generates a response. In the response's body, the server will include the source IP and port of the original incoming packet. This address is actually an external ip:port of the NAT device which was dynamically bound to the client's internal address and port earlier (by the first outgoing STUN packet). Once generated, the response is sent back to the NAT device, the NAT device forwards it to the client, and the client receives it. Finally, the client interprets the response's contents and learns its own external address. The client may use this information to refer services. For example, the video server can be told the address and port that it should use for sending video traffic.
One benefit of STUN, over other NAT traversal utilities, is its ability to cope with a complex hierarchy of NAT devices. Protocols such as UPnP lack this ability.
STUN also offers security. Each STUN packet contains a number of key-value attributes. MESSAGE-INTEGRITY is one such field. It provides an encrypted hash of the packet. The server knows the client's encryption key by some other means and it may use that key to authenticate the inbound STUN packet.
Other attributes include the following (refer to RFC5389 for a complete list):
| MAPPED-ADDRESS | Returned by the server in its response to convey the observed source IP and port of the client. |
| MESSAGE-INTEGRITY | Explained above, used for authentication. |
| FINGERPRINT | Useful for distinguishing STUN packets from other packet types. |
| SOFTWARE | Textual description of the software application being used by the agents. |
| ALTERNATE-SERVER | Instructs client to use a different STUN server. |
The STUN RFC (5389) is short and certainly a worthwhile read. Note that STUN is not a complete NAT traversal solution. It is merely a NAT traversal "utility." In a future post, I will discuss ICE, Interactive Connectivity Establishment, which puts STUN to work in a complete NAT traversal solution.
If you're looking to get started with STUN and NAT traversal right away, but don't want to spend time implementing your own stack, check out the following:Note that most existing STUN implementations are RFC3489 compliant (which was replaced by RFC5389). If you know of a good RFC5389 implementation, please leave a link in the comments or send me an email and I will add it to this post.
Posts
