Addressing the Vulnerabilities of VoLTE

VoLTE as a new primary voice solution
Mobile operators around the world are launching Voice service over their LTE infrastructure (VoLTE) as the primary voice solution for their LTE subscribers. Unlike traditional circuit-switched voice, VoLTE exclusively uses IP packets over the LTE core network. Also, per 3GPP standards, the SIP signaling and RTP media of a VoLTE call are carried in two separate data bearers; one for signaling, and the other as the dedicated bearer for media with guaranteed QoS. According to GSMA VoLTE operation guidelines, VoLTE signaling usage, regardless of whether the call is domestic, international or roaming, is free of charge to the end user. Such a collective operational decision among the GSMA community simplifies the process of billing and settlement among MNOs, however it introduces a vulnerability for exploitation from some adversaries.

Fraud methods exploiting VoLTE
As reported in several research papers and GSMA documents, one of the potential methods of fraud exploiting the free SIP signaling in VoLTE is to create a “SIP Signaling Tunnel” to carry non-SIP data. This type of fraud is commonly referred to as a “Free Data” attack to LTE/VoLTE MNOs.

For example, as indicated in the diagram below, a fraud app can be deployed in both involved mobile devices that have access to VoLTE signaling interfaces in the device. Unwarranted data can be injected in both the SIP header and SDP body to reach from a fraud caller to another fraud callee. The callee device receives the injected data, but rejects the SIP Invite, thereby enabling the caller to send another invite with more injected data and repeats the cycle until it has shared all the data they intend to exchange. Without further action on the IMS core, such fraud would be treated as a normal call setup failure. There would be no successful call record associated with the caller and the callee for any billable event to be charged.

Addressing the vulnerabilities and preventing the risks
It is important for an IPX to ensure that such vulnerability is addressed when providing VoLTE services to Mobile Operators. One countermeasure an IPX can use is a real-time packet engine along the paths for VoLTE roaming and Interworking, especially the signaling paths within IPX. As depicted in the following diagram, VoLTE Interworking signaling is coming in from the Interworking II-NNI. The VoLTE roaming signaling can come into IPX with two types of interfaces depending on the use of VoLTE roaming models. For LBO (Local BreakOut) VoLTE Roaming, VoLTE signaling is coming in via Roaming II-NNI, and for S8HR VoLTE roaming, the signaling is embedded in GTP traffic via S8 Interface.

volte-image-2

The packet engines function as a firewall with visibility to each session of data payload and actions against detected usage patterns, according to external policies and signatures. For the “Free Data” attack case, the engine can analyze the SIP signaling header and SDP body based on the given signature definition to monitor each call session and react accordingly. If a fraud session is detected, actions, such as drop, reject or alerting to the associated MNOs, can be taken, effectively preventing such fraud from affecting the IPX as well as the MNOs serving those calls via the IPX.

In this short blog post, we are only addressing one vulnerability in detail from the IPX perspective. In fact, there are many other reported vulnerabilities. As summarized in the following document, our IPX security measures can help MNOs address most of them.

Recommended Posts