Security in PacketCable networks

One of the major functional areas addressed in PacketCable is security. Basically every component and every protocol in the PacketCable architecture has security requirements defined. However in many of today's deployments very few of these security requirements are actually implemented. Why not, you may ask? Well, probably the biggest reason is simplicity. Cable operators are often a bit overwhelmed initially when deploying out a new service, such as telephony, and any way in which they can make the deployment simpler is preferable. Security protocols such as those defined in the IETF IPSec specifications are complicated by nature and perhaps this increased complexity is too much when compared to the potential benefits. Another plausible reason is that at this point "hackers" have had a limited impact on today's cable VoIP deployments. Unfortunately, this is probably only temporary and cable MSO's might be better served taking a proactive approach to security rather than waiting for a problem to occur and being forced to take a reactive approach. In this, my final, blog entry I would like to briefly describe some of the security mechanisms defined in PacketCable and the benefits/trade-offs of implementing them.

Denial of service attacks and theft of service attacks are undoubtedly among the greatest concerns of any service provider. Theft of service attacks include "cloned" devices masquerading as legitimate ones in order to steal service as well as attempts to "listen in" on legitimate users in order to learn private information. In the case of a telephony network this private information could be the phone conversations themselves or information about the parties involved such as phone numbers. This information might then be passed along to telemarketers. Logically, a denial of service attack is where a malicious user attempts to prevent the service of legitimate users. This could be by overloading the network with traffic or by intercepting user traffic and re-routing it. As an example suppose someone is able to redirect all NCS signaling traffic intended for the MSO's call agent to a dummy one that "black holes" the traffic.

At the very minimum Baseline Privacy Plus (BPI+) for DOCSIS packets traversing the RF network between the CMTS and an embedded MTA should be implemented. Recall the DOCSIS network is a shared network so potentially a cable modem could be manipulated to see the traffic of another. BPI+ makes use of digital certificates on the cable modem to establish security associations between the modem and the CMTS. Without the keys to decrypt BPI+ encrypted packets a device will be unable to understand the traffic. It is strongly recommended to use BPI+ for all MTAs in your network. However, keep in mind that this encryption is only over the DOCSIS network. Once packets leave the CMTS this encryption is gone unless other mechanisms like IP Security for RTP and NCS packets are implemented.

There are three methods of provisioning MTAs defined by PacketCable: the secure method, the hybrid method, and the basic method. A number of vendor specific methods to provision MTAs not defined by PacketCable also exist. The PacketCable secure method is the only method that provides an adequate measure of security. In the secure method the Kerberos protocol is used to establish security keys that ensure other PacketCable functionality (i.e. SNMPv3 provisioning, NCS call signaling) are securely communicated. Similar to the BPI+ case, digital certificates are used on the MTA as well as other components (i.e. provisioning server, call agent). These certificates allow devices to be authenticated and security associations to be established preventing the possibility of cloning. If these security associations incorporate encryption algorithms then it is now nearly impossible for a 3rd party to decrypt the inter-device communication. Only the secure method uses SNMPv3 for provisioning MTAs which has the ability to encrypt sensitive information such as configuration file names and content. Additionally, since SNMPv3 uses security keys instead of clear text community stings it is extremely difficult for a 3rd party to masquerade as the provisioning entity.

In all three PacketCable methods of provisioning there are configuration file hash checks on both the DOCSIS cable modem file and the PacketCable MTA file. These checks verify files have not been tampered with and if these checks fail the MTA will not be allowed to communicate on the PacketCable network. If a non-PacketCable method of provisioning is used you run the risk of not having these hash checks available and you may be at risk.

The use of the COPS protocol in PacketCable DQoS provides security by protecting against both denial of service and theft of service attacks. A concept known as a "gate" is created and authorized on the CMTS before any QoS is setup for voice calls. An identifier for the gate must be included in the MTAs request for QoS before the CMTS will allow it. Consequently, any requests for QoS without legitimate gate identifiers will be rejected at the CMTS and no QoS will be provided for these "bad" requests. Additionally, the use of PacketCable gates ensures that a MTA will only get the amount of QoS required for the phone call and no more. In a deployment without COPS you must allow unauthorized QoS requests because you are unable to differentiate between "good" requests and "bad" ones. There is other functionality lost when not implementing COPS as well; such as the ability to differentiate emergency 911 phone calls, the ability to mark packets for QoS before being sent from the CMTS, and the ability to set an activity timer to protect against "hung" QoS sessions.

Many of the PacketCable security mechanisms are for the encryption and/or authentication of the protocols used between PacketCable components. The IETF IPSec architecture is used for this purpose. Specifically, the Encapsulation Security Payload (ESP) protocol is used to provide authentication and encryption to the IP payload of these protocols. End devices perform the encryption and decryption of packets so only the IP payload is encrypted and the original header is left intact. Security associations are established between devices either dynamically (if one of the devices is a MTA) or they are statically pre-configured. Personally, I'm not aware of IPSec in any current cable VoIP deployment; as mentioned before this is primarily due to the MSO choosing to live with the security risks in exchange for the reduced network complexity.

I hope this article and this blog in general has been useful and if you have any comments or questions I would like to hear them.

Thanks,
Jeff