Results of testing by the VoIP team at InteropLabs, the experimental unit of the Interop show network, suggest new QoS mechanisms can work effectively, but security remains as tricky as ever to get right. Even though it's not a security mechanism, network address translation (NAT) also proved especially troublesome.
The team built a complex test bed connecting the VoIP phones of five enterprises across a vast armory of firewalls, IPsec and SSL VPN concentrators, and intrusion-detection systems.
The security-gear suppliers included Aventail, BorderWare, Check Point, Cisco, Juniper and Nokia. Some vendors shipped multiple security devices: for example, Juniper supplied a firewall, an intrusion-prevention system (IPS), two IPsec VPN concentrators - and three engineers to get everything working.
In addition to security boxes at the edge of each enterprise's network, the security apparatus included IPsec and SSL VPN clients for remote users. Corporate network managers planning VoIP rollouts will probably deploy similar setups, configuring IP phones and security devices and drop-shipping them to remote users.
All this equipment ensured tight security - in some cases, a little too tight. For example, BorderWare's SIPAssure offered detailed control over Session Initiation Protocol (SIP) but didn't provide the access controls needed in a general-purpose firewall. Conversely, InteropLabs engineers deployed an Aventail firewall and VPN concentrator at the perimeter of one enterprise but found the device did not proxy SIP traffic at all.
In both cases, the team redesigned the network by placing these devices alongside other firewalls; in Aventail's case, its device was repurposed as an SSL VPN concentrator; the BorderWare box became a VoIP session border controller alongside another BorderWare firewall.
The test bed also comprised numerous wireless LAN (WLAN) switches, access points and end-stations, all using the new 802.11e standards for QoS enforcement. Phones were equally diverse, ranging from softphones on PC and Mac clients to old analog handsets with SIP adapters and Wi-Fi and Ethernet SIP handsets.
The InteropLabs team standardized on the open source Asterisk SIP proxy for four of the enterprises. At the fifth were two proxies: an Asterisk box and the SpectraLink SIP proxy, which SpectraLink's new SIP-enabled handsets require. In general, however, the focus wasn't on the SIP proxy used but on the diversity of the equipment around it.
In all, around 20 vendors contributed equipment and engineering resources to the effort, making this among the largest VoIP test beds yet constructed by the InteropLabs team.
To NAT or not to NAT
One of the most difficult decisions in this testing demonstration was whether to use NAT. Network architect and team leader Jim Martin - his day job is distinguished architect at Netzwert - initially opposed its use on the grounds that NAT breaks the end-to-end principle of Internet communications and might also introduce interoperability issues. As it turned out, he was right on both counts.
Other team members argued that regardless of whether NAT is good or evil, it's in widespread use today and should be included in at least part of the test bed. The pro-NAT argument prevailed. Team engineers configured one of the five enterprises to use private net-10 addresses and enabled NAT on a Check Point firewall linking this enterprise to the rest of the test bed.
Enabling NAT proved to be troublesome from the start. Initially, neither inbound nor outbound calls reached their destinations. It took two hours of capturing traffic from various points and then an hour-long discussion in front of a whiteboard to lay out the various issues.