Service Provider Networks / Convergence / Bleeding Edge:

Can we talk? VoIP's firewall challenges

By Daniel Briere and Beth Gage
The Edge, 06/11/02

One of the interesting nuggets from SuperComm 2002 was the lip service that large service providers are giving voice over IP. Under pressure from direct enterprise sales of VoIP platforms to their best customers, BellSouth and others are now offering or planning to offer managed VoIP services from platforms such as Cisco's AVVID equipment. Providers need to keep an eye out for pesky implementation problems that early adopters have discovered. One such issue is the treatment of VoIP in a secure enterprise environment.

At the crux of the problem is the basic enterprise firewall. VoIP problems occur on phone calls that originate in the outside world - a big problem when waiting for someone to call you back. Outgoing calls, originating from the user's desktop through the firewall, are generally handled by the firewall opening a pinhole through which replies can pass. The pinhole is closed eventually (after the call ends), and no further external packets are allowed through. However, with incoming calls from an external service provider, security issues arise. Until recently, the only way to allow inbound calls was to leave a permanent hole from the outside world to the user's IP phone. Obviously, this violates even the most basic firewall security policies. Compounding the problems with VoIP and firewalls is that VoIP doesn't really work well with network address translation (NAT) (sharing one external IP address among many internal computers). NAT is typically performed by the enterprise firewall, so a further tension exists between those trying to deploy VoIP and those responsible for security.

Much effort is being devoted to solving these problems, and service providers considering VoIP services should weigh alternate solutions carefully. Selecting the "wrong" approach can lead to calls not being completed or voice quality suffering. One approach is to deploy new voice-aware firewalls that can perform protocol "patches" needed to make VoIP work with NAT. There are two ways to adopt this approach: Discard the existing firewall and replace it with a voice-aware firewall, or deploy the new firewall in parallel with the original and pass all nonvoice traffic to the original for processing.

Another approach is to place an "application gateway" in the existing firewall's DMZ where it can process incoming and outgoing voice streams. In this approach, the application gateway can see both internal NAT address space as well as the global address space and can "patch" VoIP protocol fields as they pass from outside to inside. By adding some simple rules to the existing firewall, a new route can be opened from the outside world to the DMZ-based gateway so inbound calls can be handled. This particular approach, provided by companies such as Jasomi Networks and Acme Packet, is often called a "sidecar solution" because it sends VoIP packets into the DMZ. It is similar to the way enterprises cope with security issues involved with e-mail, FTP, DNS and other applications that cross from the inside to the outside world. The overall result of this type of deployment is that standards-based VoIP systems can use this application gateway and eliminate the need for direct communication between the outside world and each user's desktop phone, thus maintaining secure separation.

VoIP is coming into its own. Enterprises are gleaning functionality and cost improvements, and service providers that do not want to see more erosion of their existing enterprise customers will have to be versed on issues like this as managed VoIP solutions come to market.