Mobile Service Providers are missing a Key Security Issue - And it is not DNS
#MWC15 Barcelona is a great city, but with 100,000 people coming to the city for Mobile World Congress, it is expected that the criminals will come in force to prey upon these unwary travelers. When I travel, I am careful to protect myself from unsavory acts such as pickpocketing or physical attack. I avoid areas that may be dangerous and I take care to protect my personal belongings from theft such as keeping my wallet in my front pants pocket. But it is easy to become complacent and forget about possible ways to become a victim. When I am walking down a street, it is natural for me to have my phone out to look at the map for directions or use another service. My expensive smartphone is now out in the open for someone to run by and grab it. They will be gone before I even have a chance to react. Smartphone snatch and grab theft via The Times Mobile service providers are concerned about protecting their networks from DDoS attacks and intrusions that either degrade the performance of their network or expose sensitive information about them or their subscribers. One of the most common points of concern for the service providers is the DNS infrastructure. Every mobile operator has been hit by some DNS attack in the past, whether they are willing to admit it or not. Most service providers have implemented some level of protection against DNS attacks. But it is not only DNS that mobile service providers should be worried about. Many mobile operators have rolled out, or are rolling out Voice over LTE (VoLTE) services to deliver voice calls over the data network. To enable the VoLTE service, they need to have an IMS infrastructure in place to handle the SIP signaling to connect and monitor the VoLTE call status. Traditionally, before VoLTE, this IMS network has been closed and not accessible from the subscriber devices directly. Unfortunately, VoLTE changes that. VoLTE requires the smartphone to generate SIP messages to initiate a phone call. These SIP messages are sent to the IMS infrastructure intact. This means it is just a matter of time for malicious hacker to generate fake SIP messages that can reach the IMS services to deliver a DoS attack, obtain unauthorized services, or possibly even gain intelligence about the service provider’s subscribers or network configuration. Mobile service providers need to take a hard look at this portion of their network. They need to determine what needs to be in place in terms of security services such as an application-aware firewall, and/or DDoS protection solution to protect this newly exposed critical component of their infrastructure. Using a smartphone has changed my vulnerabilities and habits in the same way is VoLTE is forcing mobile service providers to re-inspect all aspects of their network as it changes the fundamental models that they have become accustomed to.
How Diameter routing for policy can become a differentiator when offering VoLTE services?
This blog post was written by Peter Nas, Senior Solution Architect, F5 In a discussion around the added-value of a Diameter Routing Agent (DRA) in a VoLTE deployment, I was asked the following questions and would like to share my response: How does the PCRF (Policy and Charging Rules Function) make decisions around policies? Are all policies defined per subscriber, or are some policies defined per bearer (e.g. default bearer, regardless of the identity of the subscriber)? Does the PCRF collect the subscriber-related policies from the subscriber’s HSS (Home Subscriber Server) record? PCRFs are very conducive to contain a combination of general policies and subscriber-specific policies, all depending on how an operator wants to use them (assuming these PCRFs are the kind that have wide flexibility). For example, you could have a default policy for a bearer, access-type (RAT is 3G, 4g, and onwards) location, or other parameters, plus the subscriber-specific parameters depending on the HSS profile (e.g. the services and options that the subscriber has opted for), and all on top of the subscriber’s quota or other variables. We have seen that OTT providers could register a certain subscriber as a premium user of their OTT video service (or any other service), which guarantees the subscriber the highest quality-of-service (QoS) possible. Obviously, this service level would be accompanied by the appropriate charging level when he/she wants to download or interact with a video or any other service from that OTT provider. A VoLTE scenario is perfect for this example. If you are a VoLTE subscriber, you deserve to receive the highest quality of voice. But what happens if during the VoLTE call, the same subscriber requests another IMS-based service? In that case, the operator may want to assign a dedicated bearer for that specific service, enforce session binding, and manage the QoS if the bearer is shared (this is the PCRF’s role). Otherwise, the quality of service of the VoLTE call would probably deteriorate. All of the above scenarios involve a mixture of PCRF profiles, in addition to information on the network state, type of access, type of device, in home network or roaming, if an OTT provider is involved, and other parameters. Obviously, there are many factors involved, both network related and subscriber specific which a Diameter Routing Agent (DRA) can manage and ensure that the information is transmitted to and from the PCRF assigned to the subscriber for the particular session. Finally, I believe more and more operators are beginning to use PCRFs to differentiate themselves from competitors, and not “just” for cost reduction. Ensuring that the PCRF receives the right information, and transmits the information back to the Policy and Charging Enforcement Function (PCEF) to apply the policies is the critical role of signaling (mainly Diameter signaling but not limited to). Therefore, a DRA with gateway functionalities, such as the F5 Traffix Signaling Delivery Controller (SDC) is the key enabler to benefit from cost reduction and competitive differentiation in many VoLTE scenarios.
