Networking/NAT

From Snom User Wiki

Jump to: navigation, search

Contents

Overview

Network Address Translation (NAT) is a reality in today’s networks. Many countries save IP addresses by providing only one IP address for complete companies. Firewall manufacturers make NAT a feature by performing inspection of packets that go though NAT. Even for IPv6 networks, the fundamental problem will remain as there will also be a need for firewalls and private networks.

The Session Initiation Protocol (SIP) has neglected this problem in the beginning. However, in some recent RFC there have been useful proposals how to deal with the problem. This document shows how the snom 4S can be used to solve the problems and how the snom phones help making the problems as small as possible.

NAT

NAT is essentially a translation table that maps public IP address and ports combinations to private IP address and port combinations.

The translation table is implicitly set up when a packet is sent from the private network to the public network. The association is kept alive for a certain time and is refreshed every time a new packet is sent from the same origin. This fact is used by STUN (RFC 3489) to set up an association between a public IP address and a private IP address.

Symmetrical NAT

In symmetrical NAT, the router stores the address where the packet was sent. Only packets coming from this address are forwarded back to the private address. This algorithm increases the security as it is harder to guess the source IP and port for attackers.

Full Cone NAT

Full cone NAT does not perform this check. There are some mixed variants between full cone NAT and symmetrical NAT. Restricted port NAT works similar like symmetrical NAT, but uses only one port association. Hairpinning is the ability of the NAT to route packets coming from the private network addressed towards a public IP address binding back to the private network. Not all routers are supporting this feature.

NAT Detection

  • You can install this tool (STUN client for Windows/Linux) in order to detect your router's NAT type. Enter any STUN server URL (mostly provided by your ITSP) for checking if STUN can be used in your environment.
  • Example:
stun.1und1.de

According to this source the meaning of the output is:

Independent Mapping, Independent Filter = Fullcone NAT
Independent Mapping, Address Dependent Filter = Restricted Cone NAT
Independent Mapping, Port Dependent Filter = Port-Restricted Cone NAT
Dependent Mapping = Symmetric NAT

Symmetrical RTP

Symmetrical RTP is a trick to extend the number of cases when communication can be established. A SIP user agent that supports symmetrical RTP waits for the first RTP packet coming in and then sends its media stream back to the IP address from which it received that packet. Symmetrical RTP works always if the user agent that does symmetrical RTP is on a globally routable address. However, this algorithm can easily be cheated (port spraying) and therefore implies a certain security risk.

Signalling SIP

SIP traffic is relatively unproblematic because SIP typically is not as time critical as media. Usually, it is ok to route SIP packets through a longer path than media. In SIP it is legal to send from a different port than the receiving port. When this is being done, there is no way of supporting these devices behind NAT. However, some phones offer an option that disables this mechanism so that the sending port is the same as the receiving port. Typically, the SIP proxy will run on a public IP address where it is possible to deal with all kinds of NAT. Keep-Alive messages may keep the NAT binding open (for example, short registration periods or non-SIP messages).

Media RTP

Media is much more problematic than SIP because users are sensitive to delay in a voice conversation. When the delay is too long, the speakers need to be disciplined not to interrupt the other person when starting to speak. Also, the ear is much more sensitive to echo when the media delay becomes too long. The effect is known from intercontinental calls where the speed of light increases the delay for voice transmission. SIP was designed for peer-to-peer communication. That means the user agents (telephones) send the media directly to the other user agent. This approach is the best way to minimize the delay; however it becomes a problem when NAT is involved.

Classification of User Agents

From a proxy point of view, available user agents can be classified into the following categories:

Public IP devices

These devices operate on public IP addresses and don’t need any specific support regarding NAT. The true location of these devices may be in a private network, as they might have allocated a public identity using mechanisms like UPnP™ [3]. These devices are most welcome as they don’t cause any additional requirements.

STUN devices

Phones that operate behind full cone NAT and allocate public IP addresses themselves fall into this category. The only support that the proxy needs to give is a STUN server. Apart from that they act like public IP devices.

"Stupid" devices

These devices don’t attempt to check the NAT type or allocate a public IP address. Often, they are “legacy” devices that have been designed without having NAT in mind. These devices can register only for a short period of time, so that the REGISTER messages keep the port association open (the SIP messages are used to keep the port association). Also, these devices need a NAT-aware media server or other device that forward the RTP packets of these devices.

Symmetrical NAT devices

These devices may be NAT-aware; however, because they operate behind symmetrical NAT, there is little that they can do. They essentially behave like "stupid" SIP devices and hope for the support of the proxy.

Probing Media Paths

Interactive Communications Establishment (ICE) is a method that has been proposed recently in the IETF [4]. The algorithm is simple: A user agent that supports ICE lists the possible addresses where it could possibly be reached. These addresses may include the private address, an address allocated via STUN, one or more addresses allocated with the TURN protocol or an address allocated with UPnP. Because practically it is hard to predict which of these addresses are visible to the other user agent, all of the possible addresses are proposed to the other user agent. The other user agent sends test packets to the possible addresses. Picking the first reply on the test packet will establish a working media path and it will also probably be the fastest connection. STUN is being used for these test packets.

The Role of the NAT Filter

When a user agent is not able to allocate a globally routable address or it is not sure if it found enough possible addresses, a NAT Filter (NATF) can help out. Some vendors call this component Session Border Controller (SBC). However, we prefer the term “NAT Filter” because this component is not the end of a session, from a SIP perspective it is just a proxy in the signalling path.

Again, the way a NAT Filter works, is simple. For the signalling, the NAT Filter keeps the NAT alive with bogus messages (which can be SIP messages or other non-SIP message). It patches the messages in such a way, that other user agents will address the NAT Filter instead of the user agent when they want to deliver a message. The NAT Filter then forwards the message to the user agent using the connection which is kept open with the keep-alive messages.

When the NAT Filter sees a message that contains information about sending media (Session Description Protocol, SDP), it opens a local globally routable port on behalf of the user agent and patches these messages in a way that the destination will send media via this port. The NAT Filter will relay the media to the user agent like it relays SIP messages. Using symmetrical RTP, it can detect the user agents public media identity and reroute the packets to this destination.

While this approach has the huge advantage that it does work will all kinds of NAT, it has the disadvantage that it increases the media path significantly. For example, when a user A in Tokyo is registered with an operator in New York and wants to call his colleague B (which is registered to a service provider in Sydney and who is sitting in the same office in a private network), the media would have to flow first from Tokyo via New York then via Sydney and then back to Tokyo. Considering the speed of light, the delay would at least be around one second; practically it would be much higher although the user agents are located in the same network.

Unfortunately, it is not trivial to make the media path shorter. There have been some attempts to reduce the problem, but it is much easier to address the problem from the user agent. If the user agent uses ICE, it will try all addresses listed in the SDP attachment, including the port allocated by the NAT Filter. If there should be a shorter path, it will switch to this shorter path. If there is no other way of if the other side does not support ICE, it will fall back to the NAT Filter-allocated port which will work in all cases.

Optimizing the Media Path for Symmetrical NAT

In the case when both user agents are behind symmetrical NAT the NAT Filter approach will ensure that media will flow between the user agents. However, the Tokyo example shows that this might result in intolerable media delay. To address this problem, TURN [5] comes into play. The idea behind this approach is to allocate identities on several places in the Internet and to propose all of the allocated ports to the other user agent. If the ports are allocated on all continents, the other user agent will automatically pick the TURN server with the shortest delay. In the Tokyo example, a TURN server located in Japan will reduce the delay to a tolerable level (if there is not even a direct path between the user agents).

Conclusion

Using a NAT Filter and ICE-capable user agents, customers will enjoy two-way audio and short media delay in most cases. snom phones support ICE since version 2.04.

References

Personal tools
Interoperability