Today, IMS is God in terms of the service architecture for the next-gen IP network. Almost everyone — vendors, service providers, trade publications and conference organizers — is bowing down and dogmatically embracing it — or one of its derivative architectures such as ETSI TISPAN Release 1, Multiservice Forum Release 3 or PacketCable 2 — as their savior. But how perfect is IMS? Is IMS perfect in every dimension — vision, functions, technology selection, ease of implementation?In the area of security, IMS stands for Is Missing Security. How is that even possible you wonder? This is not heresy since IMS is simply an architectural blueprint of functional elements that work together to deliver interactive communications services and applications. It does not provide any guidance in terms of the products you should buy to implement it or how to physically deploy them. Consequently, IMS security is highly dependent upon the products you select and how you deploy them.
This is somewhat analogous to the design and construction of most homes. An architect is responsible for the design of the house it terms of its functional elements and their relationships — kitchen, living room, bedrooms, etc. The builder selects the actual materials used to construct the house — cement for the foundation, lumber for the frame, roofing materials, paint, etc. Security is an afterthought, an add-on tacked on by some specialist. Only in high-end homes will the architect, builder and security specialist collaborate in the design phase.
If you want a secure IMS network, you should approach the task as if you were building your dream house. Otherwise, you could have real nightmares!
Mapping Security Threats and Requirements
to IMS Functions
There are a number of real security threats for IMS networks and their subscribers. They include denial of service (DoS/DDoS) attacks, non-malicious overloads, viruses and malware, service fraud, identity theft, eavesdropping, and SPIT (SPam for Internet Telephony). The impact and probability of these threats in an IMS environment is assessed in Table 1.
Compared to free Internet telephony services used by anonymous subscribers, the probability of these threats in an IMS environment is somewhat less since subscribers are known, not anonymous, and will have a financial relationship with the service provider. However, the impact of these threats considering the money and relationships at stake could be much more damaging in terms of lost revenue, subscribers, subscriber assets and perhaps even human lives if E911 services were impacted.
The security features required to mitigate these various threats are mapped to supporting IMS functions and features in Table 2 using color codes. Green indicates the requirement is satisfied, red means the requirement is not addressed, yellow means the requirement is partially addressed.
IMS does satisfy a number of security feature requirements such as:
• Topology hiding at interconnect borders
• Subscriber authentication
• Subscriber authorization
• Signaling encryption
• Admission control based upon network bandwidth availability
However, it is also apparent from the bleeding red ink that numerous security requirements are not addressed by IMS and thus are left to specific product implementations and deployment strategies. This article, we will analyze the requirements for protecting against DoS/DDoS attacks and non-malicious overloads.
DoS & DDoS Attacks
Protection from both malicious Denial-of-Service (DoS) and distributed DoS (DDoS) attacks is a security requirement absent from IMS. While IMS defines mechanisms for subscriber authentication using IPsec and SIP Digest, and subscriber service authorization via the HSS, legitimate subscribers could still generate attacks on the IMS service infrastructure. Attack protection is also not a one-way street. Disgruntled service provider employees (remember Milton in Office Space when he was deprived of his stapler) could also generate attacks on the IP PBXs and endpoints used by subscribers. Lastly, these attacks could be SIP signaling-based, RTP media-based or both.
Protection against these attacks could be implemented by every IMS network element. However, the cost of “hardening” every element is probably financially prohibitive considering the hardware requirements that will be discussed below. Alternatively, the focus should be on the IMS border elements highlighted in Figure 1 (see on opposite page). These would include the P-CSCF and A-BGF, located on the access border between a subscriber’s User Equipment and the IMS core, and the I-BCF and I-BGF, located on the interconnect border between other service provider networks and the IMS core. These border elements need to perform two tasks: 1) protect The cost of security is analogous to insurance. It needs to be weighed in the context of the risk taken and its probability.themselves against DoS/DDoS attacks, and 2) prevent these attacks from infiltrating the IMS core or customer/supplier networks.
To provide self-protection against DoS/DDoS attacks, these elements must quickly detect the attack and block its source while continuing to provide service to other subscribers. As detailed in Table 2, this would require monitoring SIP signaling rates and message formats for mutation combined with the ability to create dynamic, real-time “deny” access control lists by IP address for attacking endpoints. In product implementation, this would require separate trusted and untrusted hardware paths for processing signaling messages, separate queues that are policed internally within the product and network processor-based ACLs for performance scalability.
Preventing attacks from infiltrating the IMS core or customer/supplier networks requires a number of security features. Topology hiding, using NAPT to hide the IP addresses of the IMS elements, is one sub-function defined by IMS for this purpose.
However, this sub-function is only defined for the I-BCF at the interconnect border to other service provider networks. IMS somewhat naively assumes that this sub-function is not required for the P-CSCF at the access border since “closed” endpoints like your wireless phone will never be allowed by the service provider to generate a DoS attack. However, it has been proven that an ordinary laptop PC can cripple any softswitch using a flood of SIP REGISTER or INVITE messages. Insert a 3G or 4G wireless card and that laptop becomes a potential weapon of mass destruction.
High volumes of legitimate traffic can have the same impact as a DoS/DDoS attack. For example, a flood of registration messages after a city power failure could adversely disrupt all services. The same mechanisms that protect against DoS/DDoS attacks are also applicable here.
Contrary to popular opinion in certain circles, there is no such thing as unlimited bandwidth and CSCF hardware resources. Admission control based upon network bandwidth availability is supported by the PDF/RACS function within IMS. However, mechanisms for preventing overloads on S- and I-CSCF functions are also missing from IMS. Service providers will require a border element to perform call rate limiting or code gaping for each CSCF based upon the number of sessions or session establishment rate. Selective admission control based upon destination or source telephone numbers to ensure valuable enterprise calls are always accommodated even in the presence of high-volume, low-value consumer televoting, such as for American Idol, is also crucial.
An IMS-compliant network could be implemented by buying just one product that supports all functional elements in one “box.” Alternatively, each separate functional element could be implemented by separate individual products. The trade-offs associated with the optimal deployment include complexity, cost, scalability and security.
From a security perspective, the border signaling elements, the P-CSCF and I-BCF, provide access to the IMS core. These elements should be physically isolated from more centrally located I/S-CSCF in much the same way that our immigration check points are located not at the White House, but at the many physical entry points to the United States. There should be multiple P-CSCFs at access network borders and in each “visited” network to prevent DoS/DDoS attack infiltration into the transport core network and to minimize the impact of site disasters such as earthquakes and hurricanes. Separation of the P-CSCF and IBCF from I/S-CSCF provides an opportunity to offload compute-intensive tasks such as IPsec termination, topology hiding, etc. to increase the signaling capacity and scalability of these core I/S-CSCF elements.
Unfortunately, many vendors’ CSCF products today cannot be physically decomposed. While this is viable for IMS functionality testing in a lab environment, it is unacceptable for large IMS deployments.
Security — at what cost?
The cost of security is analogous to insurance. It needs to be weighed in the context of the risk taken and its probability. Protection against DoS/DDoS attacks and the effects of legitimate traffic overloads for some providers is as necessary as life insurance.Protection against DoS/DDoS attacks and the effects of legitimate traffic overloads for some providers is as necessary as life insurance. The resulting loss of service from successful attacks and unexpected overloads could result in lost customers and revenues. In a future article we will cover the issues associated with a variety of other threats ranging from viruses and malware to SPIT.
Seamus Hourihan is Vice President, Product Management & Marketing at Acme Packet (News - Alert). For more information, please visit the company online at www.acmepacket.com.