[May 1, 2001]

Cable Telephony Security And The PacketCable Initiative

BY LINDEN deCARMO

Although most are loathe to admit it, many cable telephony developers are concerned about the security of their packet voice calls -- and also the security measures incorporated into the PacketCable initiative. Some developers and providers are worried that the encryption protocols will devastate performance. Others are intimidated by the ominous size of the specification.

Are these fears justified? In this article, we'll examine why PacketCable security is necessary, discover what type of attacks it is intended to prevent, and reveal how the specification works.

Risky Business
Most cable telephony articles focus on the exciting applications made possible by this new medium. Unfortunately, these documents often gloss over the ugly reality of modern society: hackers will aggressively try to uncover and exploit security holes in this technology. If you don't secure your cable network, you're vulnerable to theft of service, privacy leaks, and service disruption.

Theft of service refers to techniques hackers use to siphon resources from a network without paying for them. The most popular types of attacks include rigging hardware devices to make it seem like the hacker is a paying subscriber, or subscribing to telephony service with bogus information (such as a fake credit card or an invalid address).

Privacy leaks are more insidious. These attacks involve tapping into a private conversation and monitoring it for illicit purposes. Even if the conversation is encrypted, recalcitrant hackers can capture the media stream and analyze it off-line until they break the encryption scheme. Other privacy attacks involve releasing confidential subscriber information such as telephone or credit card numbers.

The final danger is service disruption. These attacks may be caused by a grudge against another subscriber, disgust with the cable company (Multiple Service Operator, or MSO), or morbid curiosity. For example, a hacker who despises his neighbor could terminate specific calls at random points in time without the permission of the neighbor. By contrast, attacks against the MSO are intended to cripple network throughput by flooding it with bogus requests.

Who Do You Trust?
MSOs are counting on PacketCable specifications to establish an architectural structure that will fortify their networks against these attacks. Since PacketCable's charter is to establish realistic and deployable standards, they've published a focused security specification that attempts to solve specific problems.

The first draft of this specification revealed PacketCable's desire to minimize theft of service, privacy violation, and service disruption. The second draft provides the needed details to implement the system. Sitll, it does not address all service disruption attempts. For example, the specification considers certain Denial Of Service attacks (such as bombarding the network with invalid packets) outside the scope of the specification. These attacks require the MSO to implement conventional security techniques so that packet flooding can be detected and traced.

Follow The Data
The PacketCable security specification achieves its goals by dividing network entities into two broad categories: completely untrusted and partially trusted. Completely untrusted elements reside in consumer homes and are known as Multimedia Terminal Adaptors (MTAs). These devices have two critical responsibilities: establishing multimedia connections when you pick up the phone, and compressing/decompressing multimedia content as you talk. Since they exist outside the MSO's internal network, every packet they transmit has the potential of being hacked.

The Cable Modem Termination System (CMTS) is a gateway device that lets untrusted MTAs on the Hybrid Fiber Coaxial (HFC) network talk to devices on the MSO's highly secure Internet Protocol (IP) backbone. 

The CMTS allows HFC devices to access the IP network.

Once a CMTS receives a packet from the MTA, it must forward it to a server on the IP network. Although these servers are completely controlled by the MSO, a disgruntled employee or other insider could sabotage the servers and leave them vulnerable to attack. Consequently, these servers can only be partially trusted, and all packets transmitted to or from them must be encrypted.

The primary server that the CMTS talks to is the Call Management Server (CMS). When a user wants to place a call, the MTA sends a series of Media Gateway Control Protocol (MGCP) packets through the CMTS to the CMS. The CMS locates and connects the MTA to the destination device it wishes to call.

The CMTS connects MTAs to other devices. In this figure, MTA uses the CMS to connect to another MTA on a different HFC network.

The Call Management Server is also responsible for ensuring that users are billed for phone calls. When you pick up your phone, the CMS opens a communication gate (or hole where data flows) in the CMTS. When the destination party answers, the CMS notifies a Record Keeping Server (RKS) that the call has started. When you hang up, the CMS closes the gate in the CMTS and terminates the call record in the RKS.

How Does This Scale?
PacketCable relies on Baseline Privacy Interface Plus (or BPI+) to secure the HFC connection between the MTA and the CMTS (BPI+ is defined by Cablelabs' Data Over Cable System Interface Specification (or DOCSIS) 1.1). BPI+ makes it extremely difficult to impersonate a CMTS, so we can be assured that all HFC traffic that arrives at the CMTS is authentic (although we don't know if the packet contains a legitimate request until we interrogate it).

Once the packet hits the IP network, it is typically encrypted with Internet Protocol Security (IPsec). Before the MTA can use IPsec, it must obtain a Kerberos ticket from a Key Distribution Center (or KDC). These tickets are used to establish communication over IPsec to a CMS. Kerberos tickets are used for MTA/CMS communication because a given CMS may control hundreds of thousands of MTAs, and pre-shared keys would be a performance nightmare.

IPsec is used to encrypt packets between PacketCable servers. 
The MTA obtains a ticket from the KDC (A).
These tickets are used to establish communication with the CMS (B).
The CMS then opens secure IPsec sessions with the CMTS (C) and RKS (D).

By contrast, intra-server communication can be initialized with pre-shared keys or X.509 certificates without impacting performance since there are a limited number of servers on the IP network. Consequently, IPsec sessions between the CMS and CMTS and the CMS and RKS are established using pre-shared keys.

But not all IP packets are encrypted with IPsec. For instance, IPsec isn't feasible for audio packets since the processing overhead would impact audio quality. Therefore, the second version of the PacketCable specification requires that Real-Time Transport Protocol (RTP) packets be encrypted with ciphers.

Ready For Prime Time?
When the first revision of the security specification was released, it was virtually ignored by PacketCable hardware and software vendors. The primary reason these vendors disregarded the specification was that critical portions of the standard were unclear or incomplete. Furthermore, companies were trying to solve basic issues such as making calls -- more exotic features like security were pushed off into the future. Finally, since the protocols endorsed by the specification had to be implemented in software, there were grave concerns about the performance impact of a software-only implementation.

Fortunately, the second revision of the security specification clarified many of the unresolved issues in the first draft, and by then most vendors have solved the basic interoperability issues. Performance concerns have been dramatically lessened since numerous companies have now released hardware-accelerated IPsec chipsets and boards.

Conclusion
Cable networks attract a disproportionate share of hackers. These hackers will likely attempt to steal services, violate other user's privacy, and disrupt services on cable telephony networks. Consequently, PacketCable has released its security specification in an attempt to limit the exposure of MSOs to these unsavory individuals.

This security specification has two classifications: untrusted and partially trusted. Untrusted devices are in consumer's homes and must obtain Kerberos tickets before they can communicate with IPsec entities on the MSO's IP backbone. Partially trusted entities reside on the MSO's IP backbone and may use pre-shared keys, X.509 certificates, or Kerberos tickets.

Now that the specification has solidified and vendors are treating it seriously, it is likely that you will begin to see trials that leverage elements of the PacketCable security specification. Should these trials prove successful, security will become an integral element of any PacketCable-based telephony deployment.

Linden deCarmo is a member of Convergent Networks' PacketCable call agent team, where his responsibilities include implementing PacketCable security. He is also the author of Core Java Media Framework. Convergent Networks is a provider of carrier-class, broadband switching solutions that are enabling carriers to advance the delivery of innovative, integrated voice and data services. Convergent Networks' product family is a robust, packet-based switching and applications development platform that provides dramatically improved economics, scale and flexibility over traditional circuit switch equipment.

For more information on the PacketCable initiative, see the author's article "Solving Cable Telephony Bandwidth Blues."