PacketCable Security
Today’s PacketCable networks are highly reliable and well-defined platforms delivering voice over Internet protocol (VoIP) products vital to the ongoing success for the cable marketplace. These networks are built with elements we have come to know well: the call management server (CMS) or softswitch, media gateway controller (MGC) and at the customer premise a multimedia terminal adapter (MTA). The architecture of the elements makes them seem as traditional telephone devices, but in the context of VoIP, they implement true IP applications. These IP applications suffer from the same security issues as others in the IP network today. Securing the core Within the PacketCable architecture, the call agent for processing calls is present within the CMS. Different call types that are processed are on-net and off-net. On-net calls originate and terminate on lines locally served by the CMS. Off-net calls are inter-worked via an MGC, where one end of the call is on the public switched telephone network (PSTN).
Both lines and trunks communicate with the CMS via protocols on user datagram protocol (UDP). Lines employ network control signaling (NCS) media gateway control protocol (MGCP) profile. Trunks employ trunking gateway call signaling protocol (TGCP) MGCP profile.
MGCP and its associated profiles implement few internal security methods. UDP, being connectionless, offers no network layer integrity. The CMS is concerned primarily with the connection identifier used by an endpoint. These are typically endpoint@realm identified such as aaln/[email protected] for a PacketCable VoIP phone line or [email protected] for a trunk; the trunk identifier also goes on to specify the channel of the trunk. The CMS trusts that the IP address sending the traffic is the IP of the endpoint. For this reason, we need to leverage IP network tools such as access control lists (ACLs) or isolation of the VoIP core network from the rest of the IP data network servicing access network subscribers. Ideally in the IP network design, all PacketCable elements including embedded MTAs (EMTAs) have been allocated space in a contiguous network. This enables routers in front of the PacketCable core elements to apply ACLs based on a summarized source IP range 10.30.0.0, 0.0.255.255 and equal to UDP ports 2427 or 2727, and thus permits any device from any EMTA subnet via a cable modem termination system (CMTS) to originate NCS signaling with the CMS. When combined with provisioning to ensure that only PacketCable devices are on these subnets, this simple step offers considerable protection against denial of service (DoS) attacks. Additional ACLs may need to be added for maintenance and monitoring of the CMS. (See Figure 1.) Securing QoS At the heart of the PacketCable service architecture is an end-to-end quality of service (QoS) guarantee per VoIP call.
In PacketCable networks, quality is signaled per call using common open policy service (COPS) protocol. This protocol is based upon a relationship between a policy decision point (PDP) and a policy enforcement point (PEP). For PacketCable voice networks, the PDP is the CMS, and the PEP is the CMTS.
A PDP is actively listening for transmission control protocol (TCP) requests on port 2126. This well-known port for COPS is easily identified in the network. It may be difficult, but certainly not impossible, to generate the client handle required by COPS and used by the CMTS to uniquely identify per client session. The CMS will have its own table of CMTS policy participants. There should also be access controls within the aggregating IP network or the VoIP core network to isolate COPS client requests to the source IPs of the CMTS network side interfaces. This ensures that only a CMTS may negotiate for session quality as well as limit exposure to land-based attacks against the CMS QoS listener. (See Figure 2.) Achieving theft of PacketCable service is extremely difficult. Provided MGCP originating devices are properly restricted, PacketCable signaling is both efficient and secure. NCS control plane is more often signaled on its own DOCSIS service flow from the EMTA. This service flow must be either pre-authorized by the terminating CMTS or using a policy decision based on the presence of PacketCable authorization block in the message from the EMTA. In addition, the identification of a line appearance with the CMS has an associated endpoint ID, which could be IP address, fully qualified domain name (FQDN), or other means of unique association of line on CMS to physical EMTA endpoint in the network. Securing the modem The cable modem provisioning file is the first sentry in the security of the cable IP network and all of its services. Within the DOCSIS 1.1 standard configuration file are some powerful network filters we should all be using to restrict source and destination IP traffic.
In a DOCSIS 1.1 configuration file, we can filter on many combined values. We can filter by protocol including UDP and TCP, source and destination address, as well as source and destination ports.
Many operators today define restrictions of common source ports such as 25 for simple mail transfer protocol (SMTP), 80 for hypertext transfer protocol (HTTP) and 443 for HTTP secure (HTTPS). The definition of these filters in the provisioning file has the obvious benefit of filtering destination traffic to the customer premise equipment (CPE), preventing users from operating services on the local area network (LAN) side of the modem. These filters are also used to prevent origination of traffic on the access network; services such as NetBIOS on port 137 should not be allowed on the LAN side of the cable modem. (See Figure 3.) We need to also consider destination filter for PacketCable protocols. Specifically, we want to filter a cable modem LAN side attached device from initiating PacketCable COPS on port 2126 and MGCP on 2427 or 2727 with any destination. By implementing these basic filter conditions, the cable modem now stands guard for DoS attempts against the CMS QoS services, as well as line operations PacketCable carries within MGCP including restart-in-progress (RSIP) messages capable of disrupting call service.
If your PacketCable network is deployed in contiguous network blocks, the DOCSIS access filters are simplified; they should deny any traffic destined to the PacketCable network blocks for non-EMTA devices.
These filters would obviously be different when the DOCSIS 1.1 cable modem is an embedded cable modem. For embedded modems declaring themselves as PacketCable 1.x capable endpoints, the DOCSIS filters would permit the MGCP protocol destined for the VoIP service network containing the CMS. Securing the MTA PacketCable 1.5 has taken a balanced approach to the ability to offer VoIP services within the largest range of compliant EMTA devices alongside the security of the VoIP service within the EMTA.
MTA provisioning occurs within a "flow" or a "provisioning sequence." There are three flows identified by PacketCable: secure, basic and hybrid. The basic flow represents an MTA being instructed by dynamic host configuration protocol (DHCP) with option 122 sub-option 6 "BASIC.x," and the MTA is advertising its capability via Option 60 as PacketCable 1.x. (See Figure 4.) This is enough to tell the provisioning system that a PacketCable compliant MTA is requesting provisioning. In turn, the provisioning service has determined that this MTA shall provision via BASIC.1/.2 flow. Thus a DHCP offer is generated to provision an IP address, domain name system (DNS) server, trivial file transfer protocol (TFTP) options, and FQDN to the MTA. The process is unencrypted, and the simple network management protocol (SNMP) notifications are in SNMPv2 mode.
Hybrid mode introduces SNMP-based provisioning to the MTA. Where BASIC mode MTA devices were sent only a configuration file from DHCP options, hybrid flow requires that the MTA be provisioned via SNMPv2c from the PacketCable provisioning server. That is, a configuration file is still required, but the location and name of the file is exchanged only via SNMPv2c. This is a significant step toward securing the MTA activation because the MTA must be known to the PacketCable provisioning server. In turn, the MTA is told its read and write community, then sent a configuration file location based on its capabilities. The MTA proceeds to download the configuration file instructed to it within the SNMPv2c conversation, which is normally built dynamically by the PacketCable provisioning server process in conjunction with the TFTP services.
Secure PacketCable was the first provisioning flow available for MTA configuration. Secure PacketCable introduced Kerberos encryption and a DNS-based discovery of the Kerberos encryption Realm.
Kerberos encryption contains several elements: a ticket granting server (TGS), authentication server (AS), service server (SS) and ticket granting ticket (TGT). A PacketCable EMTA will first authenticate to the Kerberos server using a pre-shared secret key and request service. Kerberos grants the EMTA a ticket from the authentication service equivalent to the client ticket session key encrypted using the client secret key. The EMTA in turn uses this session key to decrypt the subsequent message sent to it, which is the TGT, which is only understood after applying its session key to the TGT to learn the secret key, now valid for a time interval. This key, established in an ongoing manner for the lifetime of the EMTA service on the network, is used in Secure PacketCable for all SNMPv3 events. Any element not able to authorize with the EMTA using this key will not be established to the EMTA.
Secure flow requires SNMPv3 for all operations. Should DNS fail to resolve the Kerberos realm, should SNMPv3 fail to authenticate, or should TGS fail to respond to the MTA in time, the secure flow will fail and cause the device to reset.
It is important to consider the impacts of this PacketCable flow with "in rush" or "avalanche" scenarios. An example might be a CMTS maintenance event that causes 15,000 EMTAs to re-associate and provision to the network simultaneously. Secure PacketCable provisioning would introduce considerable delays per EMTA while the provisioning system waits for Kerberos processing.
For many reasons – processing overhead, Kerberos server single point of failure, and the high number of dependencies to complete the provisioning flow – Secure PacketCable is often not implemented in favor of hybrid mode when the configuration file name to the MTA requesting the file can be controlled.
In all provisioning cases, SNMP is used for ongoing control of the MTA. DOCSIS 1.1 filters for SNMP UDP ports 161 and 162 should also be considered for the protection of ongoing EMTA provisioning operations such as adding or removing a PacketCable line appearance. Additional DOCSIS 1.1 filtering should be done if your MTA supports HTTP or telnet for troubleshooting purposes.
If not using Secure PacketCable, implementation of Baseline Privacy is a must. DOCSIS Baseline Privacy (BPI+) enables privacy across the HFC network by encrypting traffic flows between the modem and the CMTS. BPI+ security services are a set of extended services within the DOCSIS media access control (MAC) sublayer based on a modem identified by its HFC MAC address and embedded X.509 digital certificate, obtaining a unique key for its authorized services with the CMTS. This has an immediate benefit of safeguarding the network from cloned modems.
BPI+ security association uses three states: primary, static and dynamic. Primary is likely passing any traffic destined for CPE LAN-side devices of the stand-alone or embedded modem. For PacketCable service, it is likely BPI+ dynamic security association (DSA) employed given association to alternate service flow for NCS signaling and voice bearer. Thus PacketCable EMTA-to-CMTS calls within BPI+ environments are encrypted and separate from CPE LAN-side traffic. Qualified for the job The CMS is looking to register PacketCable line endpoints with an association to FQDN. Additionally, secure and hybrid PacketCable provisioning flows both employ DNS to complete. A dynamic DNS (DDNS) update is needed for most all cases where PacketCable VoIP endpoints exist. DNS itself has many security exposures. From a PacketCable standpoint, DNS services for the PacketCable network should be independent from those of the general CPE LAN-side DNS services for Internet access. Further PacketCable DNS service should only process DDNS updates from a restrictive list of trusted sources such as the PacketCable provisioning services. Conclusion From the provisioning side of PacketCable devices, the BASIC flow is certainly the most insecure method of provisioning PacketCable VoIP devices today. This flow leaves itself open to device spoofing attempts to attain the provisioning file. Secure PacketCable flow is certainly the most rigorous and stringent of the flows for provisioning PacketCable VoIP; however, it is often a trade-off between security and performance of the Kerberos encryption, making secure flow sometimes not desirable to large operators. Hybrid flow offers a reasonable balance of security and performance for PacketCable VoIP device provisioning.
Overall, the importance of network-wide rules for protocol filtering cannot be ignored. Aggregation IP routers offer the ability to manage and restrict subnet-wide access to services. BPI+ enables encryption within the access network itself. Perhaps the best defense exists in the DOCSIS 1.1 cable modem where proper definition of IP filters often prevents malicious traffic before it enters the access network. As with many IP service networks, it is not one but a set of tools used to ensure and secure services from end to end.
Craig Lien is a network engineer for Midcontinent Communications. Reach him at [email protected]. Chris Busch is VP broadband technology for Incognito Software. Reach him at [email protected].
