TMCnet
ITEXPO begins in:   New Coverage :  Asterisk  |  Fax Software  |  SIP Phones  |  Small Cells
 
May 2006
Volume 1 / Number 3
 

 

The market growth of real-time IP communications is expected to be the next big wave of Internet usage after e-mail and the Web. SIP has quickly become the standard signaling protocol for this traffic, including VoIP. However, SIP-based communications cannot reach users behind firewalls and Network Address Translation (NAT). Firewalls are designed to prevent inbound unknown communications, while NAT hides the private IP addresses on the LAN, stopping users on the LAN from being addressed from the outside. Very few, if any, communications are received directly from outside our local-area networks. This provides us with comfort in knowing that only authorized users can gain access to our networks and the valuable information stored on our local servers and computers.

The NAT created on the firewall or by routers is also a part of the security fabric. NATs are necessary primarily because the Internet IPv4 standard does not support enough unique IP addresses to allow all of the devices connected to the Internet to have their own distinctive IP address. With Network Address Translation, only the firewall or router is given a publicly routable IP address. Each device on the inside is then assigned a private IP address that is only known inside the firewall-protected space. This architecture prevents inbound communications from reaching the intended recipient behind the firewall because the IP address of the client device is unknown and not routable.

Finally, most firewalls do not support SIP. Just as with all other protocol types, the firewall must recognize the format of the signaling in order to admit it to the network. Since most firewalls installed today do not support SIP, the inbound traffic will be stopped for this reason alone.




But why is this important?

The vision of true Global Connectivity over the Internet is for SIP to become a universal protocol supported on all devices — from computers to phones — and that we will be able to use those devices to reach anyone, anytime, wherever they may be located at that moment. And it’s not just voice. When SIP is widely deployed, the interaction will become more collaborative, with partners, vendors, employees, and even customers using the most effective tool for every occasion whether it is Instant Messaging, presence, voice, video, application sharing, whiteboarding, or file sharing.

The SIP servers providing these functions are often placed on the LAN, but for these to communicate over IP with the outside world they must traverse the firewall. Eventually, all firewalls will need to be SIP capable in order to support the widescale deployment of real-time communications. In the interim, several solutions have been proposed to work around the firewall/NAT traversal issues that limit the SIP communication.

SIP-Capable Firewalls, SBCs and Edge Devices

SIP ALG-Based SIP-Capable Firewalls
The majority of all SIP-capable firewalls today use the SIP Application Level Gateway (ALG) architecture, which solves firewall traversal by “taking care of the SIP packets on-the-fly,” making sure that they reach the right destination on the LAN. It does not provide the full protection and flexible functionality necessary for today’s secure enterprise.

SIP Proxy-Based SIP-Capable Firewalls or SIPEnabling Edge Devices
The SIP proxy is designed to briefly stop the signaling packets so that each one can be inspected before the header information is rewritten and the packets are delivered to the appropriate endpoints. This provides the enterprise with a complete, flexible, controlled implementation of SIP-based communications.

The SIP proxy can offer benefits not available with the ALG architecture:

  • Far-end-NAT traversal (FENT) to support remote users;
  • Encrypted SIP signaling (TLS) and media (SRTP);
  • Authentication;
  • Advanced filtering;
  • Advanced routing and control features; and
  • Intelligence to enable the firewall to act as a backup for a hosted or centralized IP-PBX.

SBCs at the Service Provider Edge
Session border controllers (SBCs) control a firewall from a distance. All SBCs share the same basic feature in that they create pinholes in the NAT/firewall through which SIP signaling and media can pass through. Typically this far-end NAT traversal solution is implemented by continuously sending dummy packets through the firewall to keep pinholes open for the media to cross, or by asking the client to re-register in short intervals to keep those ports available.

SBCs are popular with service providers for their far-end NAT traversal ability. SBCs leverage FENT by creating special VoIP networks within their IP network. Traversing an enterprise firewall with a tight security policy is a far different challenge. FENT solutions remove control from the firewall, and require the firewall to be accessed from the inside. Also, security-conscious enterprises will not typically allow open ports. The SBC’s centralized approach also provides a single point of failure.

Customer Premise SBC
Many enterprise customers are reluctant to replace their existing firewalls with new SIP-capable firewalls because they’ve already set up security policies and trust the equipment that they have. Yet, many enterprises need to overcome the limitations of their existing firewalls whether they have firewalls with no SIP functionality or SIP ALG firewalls with limited SIP functionality. This has triggered the development of a new type of product: the “customer premise Session Border Controller” or “SIP-enabling edge device. Essentially the SIP-enabling edge device assumes control of SIP traffic without involving the existing firewall in the process.

STUN, TURN, ICE
STUN (Simple Traversal of UDP through NATs) requires a STUN client on the phone or other endpoint device, which sends packets to a STUN server on the Internet. The STUN server replies with information about the IP address and ports from which the packets were received and detects the type of NAT device through which the packets were sent. The STUN client at the endpoint uses this information in constructing headers so that external contacts can reach them without the need for any other device or technique.

STUN requires that the NAT device accept all traffic that is directed to a particular port, and forward that traffic to the client on the inside. This means that STUN only works with less secure NATs, so called, “full-cone NATs.” This also means the internal client will be exposed to an attack from anyone who can capture the STUN traffic. STUN is not generally considered a viable solution for enterprises. Additionally, STUN cannot be used with symmetric NATs. This may be a drawback in many situations as most enterprise-grade firewalls are symmetric.

TURN (Traversal Using Relay NAT) allows an endpoint behind a firewall to receive SIP traffic on either TCP or UDP ports. This solves the problems of clients behind symmetric NATs which cannot rely on STUN to solve NAT traversal. TURN connects clients behind a NAT to a single peer to provide the same protection as that created by symmetric NATs and firewalls. The TURN server acts as a relay, any data received is forwarded. The client on the inside can then be on the receiving end, rather than the sending end, of a connection that is requested by the client on the inside.

This method is appropriate in some situations, but since it essentially allows inbound traffic through a firewall, controlled only by the client, it has limited applicability for enterprise environments. It also scales poorly since the media must go through the TURN server. ICE (Interactive Connectivity Establishment) uses STUN, TURN and other methods to solve the NAT traversal issue. ICE allows endpoints to discover other peers and then establish a connection. ICE is a complex solution to the problem of NAT traversal, relies on client/server-based approaches, and removes control from the enterprise.

Universal Plug-and-Play (UPnP)
UPnP lets the Windows client control the firewall. The concept of allowing a software client to control the firewall is risky from a security standpoint. This technique is appropriate only for users with complete confidence in the LAN.

Conclusion
Although firewall/NAT traversal is still an impediment to widespread adoption of SIP, many companies today are looking for the right solution to bring the benefits of converged communications to their network.

Several solutions exist today, all of which have a place in the convergence toolbox. Some of the options are useful in situations where security demands are light and where there are no SIP servers on the LAN. But in those cases where security concerns are greater, and in situations where tight corporate firewall environments prevent the use of some of these simpler solutions, a more robust technique should be employed.

Whichever solution is chosen, the resulting advantages that come from adopting SIP-based real-time global communications offers productivity benefits to every company.

Olle Westerberg is Chief Executive Officer at Ingate Systems. For more information, please visit the company online at http://www.ingate.com. (news - alert)

 

Return to Table Contents


Today @ TMC
Upcoming Events
ITEXPO West 2012
October 2- 5, 2012
The Austin Convention Center
Austin, Texas
MSPWorld
The World's Premier Managed Services and Cloud Computing Event
Click for Dates and Locations
Mobility Tech Conference & Expo
October 3- 5, 2012
The Austin Convention Center
Austin, Texas
Cloud Communications Summit
October 3- 5, 2012
The Austin Convention Center
Austin, Texas