IP Telephony Security, Part II: Threats to Operators
David Piscitello Core Competence, Inc.
In Part I of this series, I explained how IP networks are now used to handle an increasing number of voice calls. As products are commoditized, new applications appear, and more public IPT "carriers" come online, even broader adoption is inevitable. I also called attention to the dark side of the convergence of voice, IP, and wireless networking: the combined attack targets and vectors present formidable threats, not only to IPT users but also to operators, public and private.
IPT operators should anticipate the same kinds of attacks that we have seen on cellular and landline phones. These include toll fraud, identity and information theft, and service disruption. They should also anticipate attacks against computer systems that comprise IPT operations systems and infrastructure. Call managers, IP telephony switches, routers, and IPT-to-PSTN gateways must be protected from unauthorized access, privilege escalation and system misuse, viruses and worms, and denial of service attacks. IPT operators who offer online payment and service plan management must defend against attackers seeking to compromise accounts and databases using a variety of web attacks. These attacks are not IPT specific but a common problem for all telephony carriers.
IPT operators must contend with concerns that public IPT infrastructures will be no less a target for politically motivated attackers (terrorists) than the PSTN, and related concerns that operating IP Telephony "securely" encumbers electronic surveillance by law enforcement agencies (CALEA). When VPN tunnels are used to protect (SIP) call control packets and voice/media streams, law enforcement must have access to encryption and authentication keys or they will be unable to conduct lawful intercept/wiretap. The solutions are technically complex, and include methods for disclosing keys to law enforcement that work irrespective of the type of VPN used to protect IPT: IPsec, SSH, SRTP, SSL or proprietary encrypted tunnels. Moreover, for every possible VPN protocol, intercept equipment must be able to deal with a variety of configuration options: IPsec alone has a tunnel and transport mode, multiple ways to identify and authenticate IKE endpoints, and multiple bulk encryption and integrity methods.
IPT operators must also deal with concerns that it's difficult to support Emergency Telecommunications Services in the face of disaster events. Some IPT operators (e.g., Calleveryone.com) expressly state they do not provide E911 and are not a lifelinet service. Some recommend that subscribers have cellular service if IPT is their only land line phone service. Vonage, Broadvoice, and others support a "nearly 911" service they expressly state is not the same as E911. The subscriber must activate 911-type service; when used, the 911 call is routed to the Public Safety Answering Point (PSAP) or "local emergency service personnel designated for the address that you listed at the time of activation". Packet8 claims to be the first IPT carrier to support true E911, where the 911 call is labeled and routed as emergency traffic and E911 caller information accompanies the call request. Standards bodies are now investigating Emergency Telecommunication Service (ETS) requirements, which include support of SS7-like mechanisms to distinguish emergency from normal calls and methods to assure such labels can be conveyed across hybrid (packet and PSTN) networks. Measures are also needed to assure sufficient accounting information is available to detect abuse. Until these and similar concerns are addressed, IP Telephony may only be suitable for second line service or limited (e.g., intra-organizational) private network deployments.
Many vulnerabilities associated IPT's call signaling (SIP), voice message delivery (RTP), and control protocols (RTCP) can be used against operators as well as their subscribers. Like IPT phones, IPT call servers can be flooded with unauthenticated call control packets. Attackers can launch the full spectrum of denial of service attacks against IPT operators' underlying networks and Internet protocols. IPT applications such as voicemail and short messaging services can be targets of message flooding attacks. Such attacks may prevent legitimate attempts to leave a subscriber a message.
Floods, subscriber impersonation, and rogue IPT phone connections create nightmarish customer care scenarios for operators. Resolving disputes with customers who are victims of subscriber impersonation, call hijacking, and rogue phone connections, or billed for thousands of unsolicited flood messages is a resource and revenue drain.
Assuming they can mitigate service disruption threats and maintain acceptable call quality, IPT operators must consider the adverse effect that "security incidents" may have on user (consumer) confidence. A public IPT phone service or privately operated IP PBX that is susceptible to call integrity compromise, call redirection (hijacking), and call information theft (eavesdropping) isn't going to draw business subscribers from the PSTN.
That IPT deployment is no slam-dunk shouldn't come as a surprise to anyone. The problems operators must contend with as they deploy packet voice networks are considerable. So, too, are the potential benefits of deploying IP telephony. I've presented a blanket treatment of noteworthy security issues common to public and private IPT operation, and some insight into problems specific to public IPT services. If you are a prospective public IPT operator, I recommend you look for additional (regulatory) information at such sites as fcc.gov, telephonyonline.com, and the Washington Internet Project's Cybertelecom.