Does Your Network Speak My VoIP?

Connecting networks always has been a challenge. I remember that one of my first engineering assignments (way before the Bell System broke up) was to connect an operator services trunk from our lab in Cicero, Ill., to a remote lab in Holmdel, N.J. By the time I sorted through signaling, service orders and coordination of three operating telephone companies, it was several weeks to implementation. The more I work with voice over Internet protocol (VoIP), I’m finding some things haven’t changed all that much! Interconnection in the VoIP world has several dimensions and still is not a finished item. There are, for example, some unresolved security issues, which we will discuss in a couple of paragraphs. To set the stage, let’s review the architecture of interconnecting PacketCable VoIP to the public switched telephone network (PSTN). Interconnect architecture We can, of course, connect from a PacketCable 1.0 media gateway to a time division multiplexing (TDM) switch in the PSTN. In this case, we control the entire Internet protocol (IP) part of the call and are as compliant as our internal design. Another scenario is when we use an IP interconnect service provider for a native IP connection between our PacketCable network and a remote point of presence (PoP) to the PSTN. In July 2004, this column reviewed some IP network providers who offered solutions for VoIP call completion in this manner. Gateways at these providers’ PoPs provide the means for a VoIP call to be connected to existing telephone subscribers. There are lots of flavors of gateways, and not all are PacketCable compliant. I asked Doc Evans, an Arris architect who is participating actively in several PacketCable specification groups, what might be the differences in call handling when the gateway to the PSTN is on the other side of an interconnecting IP network, rather than within the operator’s managed IP network. "The biggest issues that could be concerns are security and CALEA [Communications Assistance to Law Enforcement Act] conformance," noted Evans. "Voice encryption/decryption can only be guaranteed if the gateways conform to PacketCable, and not all gateway vendors can meet all the CALEA requirements." Whether these issues are showstoppers depends on how an operator wants to offer telephony. The security specification of PacketCable 1.0 defines how to provide security for voice traffic. It states: "The Media stream between MTAs [multimedia terminal adapters] and/or MGs [media gateways] should be encrypted for privacy. Without encryption, the stream is vulnerable to eavesdropping at any point in the network." Encrypted voice packets can be passed across interconnecting IP networks, and the keys needed to decrypt also can be passed. PacketCable embeds the keys in signaling information to ensure that the communication was established with a valid subscriber and with valid signaling procedures. Security issues Three security-related issues surface: First, does each remote gateway to the PSTN need to be PacketCable-compliant in order to decrypt the content prior to handoff to the PSTN? Second, how secure is the signaling path that passes the keys across network boundaries? And third, is it mandatory and necessary to turn on encryption for voice conversations? Understanding the first issue requires looking at how encryption works in the world of PacketCable VoIP. Unlike the telephone company, our access network is essentially a shared local area network (LAN). To alleviate concerns about privacy, we have therefore built in two levels of security. Tom Cloonan, Arris CTO, walked me through the process used by PacketCable to protect VoIP bearer content. "The MTA applies the AES [advanced encryption standard] algorithm, and the cable modem applies the DES [data encryption standard] algorithm. Before packets leave the operator’s network, the CMTS [cable modem termination system] strips off DES, but leaves AES encryption intact." As I mentioned earlier, the keys needed for decryption are embedded in signaling information, so theoretically a network element on the remote side of a receiving IP network could decrypt the voice packets if the keys within the signaling path can be communicated to it; however, that network element also would need to know how PacketCable applies the AES algorithm. If the PoP for an interconnecting IP network contained a PacketCable gateway, this would be possible. Otherwise, the voice information could not be decrypted as it transitions to the PSTN. Completing an encrypted PacketCable VoIP voice conversation to a terminating point on the PSTN therefore requires both a remote end "decrypter" and the availability of the AES key. But there is another security issue besides encryption of content, and that is whether there is sufficient protection for the keys as they are transmitted on the signaling path. Answering this concern requires knowing a bit about the architectures involved in native IP network interconnection. PacketCable 1.2 defines this architecture. At the interconnection of IP networks, there is an exterior border proxy (EBP) that manages signaling between the networks. The commercial implementation of an EBP is a session border controller (SBC). Because PacketCable is not the first or only application of IP network interconnect, there are already a number of SBC vendors in the marketplace, including Acme Packets and Netrake. Jim Hourihan, Acme Packets VP of marketing and product management, explained, "SBCs provide network-level security by protecting CMSs [call management servers] and feature servers from attacks such as denial of service and TCP [transmission control protocol] attacks." Micaela Giuhat, Netrake AVP of global alliances, elaborated on the SBC security functions: "An SBC will monitor both source and destination of voice packets and will be aware of anomalies such as rogue RTP [real-time protocol] connections, where a call has terminated, but the path has not been torn down properly. It makes sure that voice only goes from authorized sources to authorized destinations." In addition to providing security for signaling information, SBCs provide legitimate firewall transversal for VoIP calls and serve as a demarcation point by hiding IP address information from parties on a connecting network. An SBC also helps CALEA conformance. Giuhat informed me that SBCs are part of the process that duplicates signaling and media for lawful intercept. One function that is beyond the SBC role now, however, is encryption. Although this network element is well-positioned architecturally to fill the void where a remote IP network cannot decrypt the AES, voice bearer content is not its concern. Both Hourihan and Giuhat agreed that encryption/decryption needs to be done at IP network endpoints. Which brings us to the third security issue of whether encryption is necessary across all interconnecting IP networks. If AES is turned off at the MTA, no encryption remains after the DES is removed at the CMTS, and the problem of decrypting at a remote PSTN PoP goes away. Although this is not end-to-end encryption, the PSTN typically does not encrypt voice traffic anyway. What we have lost, however, is the enhanced security provided by AES. Part of a solution At least part of a solution may be emerging from Verisign, one of the better-known domain name registrars in the Internet world. Recently, Verisign began marketing an interconnect service that will complete VoIP calls entirely in native IP mode, end to end. The service works by searching a database for IP addresses associated with called PSTN numbers and using the Verisign Signaling System 7 (SS7) network to create a path solely over IP networks to the IP address at the remote end, instead of hopping off to the PSTN at a PoP. Considering that each MTA has an IP address, for calls between cable operator VoIP systems, such a service could facilitate using the remote MTA to do the AES decryption. Most of the information in this month’s column came from vendors working the leading edge of implementations. If an operator would like to add some field experience to this story, I’ll be happy to publish an addendum. Justin Junkus is president of KnowledgeLink and telephony editor for Communications Technology. Reach him at [email protected].