Voice over IP (VoIP) vendors say they deliver scalability and security. And InteropLabs (iLabs) testing mostly proved them right in multivendor settings. But testing also revealed some implementation glitches in both of those areas, and pinpointed a few missing pieces when it comes to key exchange for securing VoIP traffic.
This year’s iLabs VoIP team focused on three areas:
– Scaling and prioritizing VoIP traffic over Wi-Fi links;
– Thwarting attacks against session initiation protocol (SIP) and real-time protocol (RTP) traffic using intrusion-detection and -prevention systems (IDS/IPSs); and,
– Protecting VoIP media traffic using secure RTP (SRTP).
Setting up the VoIP-over-Wi-Fi demonstrations at the hotstage event last month generated the biggest “gee-whiz” reactions among the engineers present because of its sheer size. Test instrument maker VeriWave supplied a massive amount of equipment to stage the scalability demo. In addition to its WaveTest traffic generator/analyzers, VeriWave also contributed 16 radio frequency (RF) chambers, each about 1 cubic foot, to house access points from seven vendors.
VeriWave also custom-developed software that displays two analog speedometer dials showing concurrent call count and R-value, a measure of voice quality. The display also uses a slider that will allow show attendees who visit the iLabs booth on the Interop show floor this week in Las Vega (No. 122) to trade off call volume and call quantity in real time.
The vendors contributing wireless gear were Aruba Networks, D-Link, Extreme Networks, HP, Juniper, Motorola and Trapeze Networks. During the hotstage, VeriWave engineers set up 500 calls through these vendors’ access points and planned to do more at the show.
This testing showed that 802.11a networks deliver higher call quality than 802.11b or 802.11g networks. While 802.11a is far less subject to interference than the 802.11b/g/n frequencies, the biggest difference in call quality turned out to be rate synchronization.
When 802.11a or 802.11g radios tried to communicate at different rates, R-values fell by around 10 points, enough to make a difference between excellent and barely acceptable sound quality. With the VeriWave and access point radios locked in at the same rate, 802.11a still scored higher than 802.11g, but only by a couple of R-value points.
The lessons for network managers are to seek out handsets that support 802.11a where possible, and regardless of radio type, choose equipment and network designs that keep rate adaptation to a minimum.
Securing VoIP VoIP security played a major role in this year’s iLabs testing. Because there’s currently no authentication or encryption in most multivendor VoIP networks, it’s simple to intercept VoIP conversations. The iLabs team demonstrates this point using the WildPackets OmniPeek analyzer to capture and replay conversations.
To demonstrate the risk of denial-of-service (DoS) and man-in-the-middle attacks, the team set up five “enterprises,” each subject to increasingly sophisticated intruders. The VoIP-aware intrusion detection/prevention systems at each “enterprise” came from Check Point’s UTM-1; Cisco IDS code on a 7204 router; Fortinet’s FortiGate appliance; Juniper’s IDS 200; and the open source Snort project. To simulate network conditions, the team used InterWorking Labs’ mini-Maxwell impairment generator and monitored conditions using Network Physics’ NP-2000 system.
In the simplest scenario, a remote attacker with no knowledge of the enterprise network used Mu Networks’ Mu-4000, Tenable Networks’ Nessus, and other attack tools to try to gain access. At worst, these attacks might succeed in causing a denial of service.
A DoS attack was also the goal of the second, slightly more sophisticated intruder. Here, the intruder was still remote but had some knowledge of the VoIP network, such as uniform resource identifiers (URIs) or phone extensions. This attack involved malformed packets generated by the Mu-4000 and open-source tools such as sipp, sipsak, and SipBomber.
Next up was a remote attacker with detailed knowledge of the target VoIP network. This attacker’s goal might be denial of service, or it could be to eavesdrop or redirect calls. The final two categories of attacks involved intruders with local access. In these scenarios the potential for mayhem was far more serious than simple DoS attacks.
In the first internal scenario, an attacker attempted to delete selected sounds from a media stream; for example, a disgruntled employee might delete or delay purchase orders. In the other scenario, an attack might insert selected words into a an RTP media stream; think of a CEO saying “buy company X” and then having an attacker alter the message to say “don’t buy company X.” The applications for corporate espionage are obvious.
Setting up these attack scenarios, yielded three lessons. First, IDS/IPS may be configured in “fail closed” mode, meaning they stop forwarding packets if real or perceived attacks outrun the ability of the IDS/IPS device to report on them. A shutdown may be desirable from a security standpoint, but network managers with high availability requirements might instead prefer a “fail open” configuration.
Second, IDS/IPS devices are useful in thwarting some classes of VoIP attacks but not others. For example, an IDS/IPS device should be able to block basic SIP flooding attacks or transmission of malformed packets. But attacks that mess with the media stream — such as the deletion and insertion attacks — look like benign traffic if they’re done properly. That raises the final lesson: Strong authentication and encryption of VoIP traffic would have prevented all these attacks. To that end, another group of engineers on this iLabs team focused on the available mechanisms for securing voice traffic.
Encrypting voice traffic The team’s adventures with encrypting VoIP traffic produced one of those good news/bad news stories. On the plus side, the team found very good interoperability among multiple vendors’ IP phones, proxies, and security gateways. In fact, team member
Craig Watkins of Transcend, Inc. says the team encountered “no reproducible problems” with the secure real-time transport protocol (SRTP), which adds encryption, message authentication, and integrity checking for voice and video traffic.
The vendors contributing to the successful SRTP interoperability demo included AudioCodes, Avaya (both for PBXs and phones), CounterPath, Grandstream, Ingate, and Snom. The team also used the open-source Asterisk PBX and SER SIP proxy.
On the downside, SRTP encrypts only media flows, not signaling traffic. Further, it doesn’t describe a method for exchanging the keys needed to set up an authenticated and encrypted session.
The team used the session description (SDES) method for key exchange because it’s simple, and it’s available today on a variety of equipment. However, the IETF is likely to adopt different key exchange methods for standardization work because of issues with SDES, some of which the team wrestled with at hotstage.
For example, since SDES involves the transfer of sensitive keys to set up an encrypted channel, the key exchange itself needs to be encrypted. The iLab team’s workaround was to use SER, an open source SIP proxy as a front end to Asterisk, and a heavily patched version of Asterisk to handle SRTP.
In building these demos, the iLabs team looked like regulars on the Mythbusters TV show, moving from small proof-of-concept models to full-blown tests. Unlike
