Solving the Firewall and NAT Traversal Issues for Multimedia over IP Services
Simple Traversal of UDP Through Network Address Translators (STUN)
The STUN protocol enables a SIP client to discover whether it is behind a NAT, and to determine the type of NAT. STUN has received a lot of attention as a technique in the IETF, but suffers from a flaw, which means that it will only work with some NATs. In fact, STUN does not work with the type most commonly found in corporate networks - the symmetric NAT.
The IETF Midcom Working Group has undertaken an investigation of residential NAT devices. This indicates that some NATs will not work with STUN.
Also, STUN does not address the need to support TCP based SIP devices. As SIP User Agents and Call Agents become more complex, the use of TCP will increase. In fact, support of TCP is mandatory in the SIP RFC3261.
The STUN proposal defines a special STUN server in the public address space to inform the STUN-enabled SIP client in the corporate (private) address space of the Public NAT IP address and port being used for that particular session. Having to use STUN-enabled clients, or upgrade existing clients to support STUN, makes this method unpopular. In fact, very few vendors have announced support for STUN enabled clients.
Figure 4 STUN
STUN identifies the public side NAT details by inspecting exploratory STUN messages that arrive at the STUN server. The STUN-enabled client sends an exploratory message to the external STUN server to determine the transmit and receive ports to use. The STUN server examines the incoming message and informs the client which public IP address and ports were used by the NAT. These are then used in the call establishment messages sent to the SIP server. Note that the STUN server does not sit in the signalling or media data flows.
As mentioned previously, however, there is a problem with this approach. Most NATs in use today are symmetric. This means that they create a mapping based on source IP address and port number as well as the destination IP address and port number.
The destination VoIP client address is different from that of the STUN server. This means that the NAT will create a new mapping using a different port for outgoing traffic, which in turn means that the information contained in the call establishment messages is incorrect and the call attempt will fail. The same problem occurs for incoming traffic.
Therefore, STUN relies on the fact that once the outgoing port has been mapped for the STUN server traffic, any traffic appearing from any part of the network, with any source IP address, will be able to use the mapping in the reverse direction and so reach the receive port on the client.
NATs that do work in this way are susceptible to port scan attacks and create security concerns. This method, therefore, fails to solve the 'Firewall problem' because it introduces additional security risks that are unacceptable to communication managers. STUN is included in the ICE framework discussed later.
TURN - Traversal Using Relay NAT
The IETF have proposed an additional mechanism - TURN - that is designed to solve the media traversal issue for symmetric NATs.
Figure 5 TURN
TURN relies on a server that is inserted in the media and signalling path. This TURN server is located either in the customers DMZ or in the Service Provider network. The TURN-enabled SIP client sends an exploratory packet to the TURN server, which responds with the public IP address and port used by the NAT to be used for this session. This information is used in the SIP call establishment messages and for subsequent media streams. The advantage of this approach is that there is no change in the destination address seen by the NAT and, thus, symmetric NAT can be used. TURN has recently been extended to address some serious security issues associated with TURN, which may have held back its acceptance - It is still at draft status. TURN is also part of the ICE framework discussed later.
Many Service Providers expect to be able to manipulate QoS information and provide enhanced security at the entry point to the network. TURN does not support this requirement, because details of the SIP session are not revealed to the TURN server through the TURN protocol, so its acceptance by the Service Provider community is not certain at this stage.
Both these methods add significant complexity to the CPE installation and TURN, like STUN, requires SIP clients (such as SoftPhones or IP telephones) to be upgraded. There is considerable reluctance by client vendors to undertake this work, making STUN and TURN non-ideal solutions. SNOM are clearly an exception to this reluctant attitude.
|
IPsec and VoIP
