Initially, there were optimistic projections that STIR/SHAKEN would protect innocent end-users from the hostile spoofing of caller IDs (CLIs) and disruptive robocall practices. Over time, end-users have learned that they are still being targeted by scammers — sometimes more than before. In fact, the situation has worsened. Users now receive calls that appear to be from trusted sources based on the attestation information presented alongside the CLI, but they can no longer rely on the displayed number to accurately identify the caller. Scammers have found ways to bypass the entry points of the system, turning STIR/SHAKEN into a mechanism that suffers from ‘garbage in, garbage out’.
The situation described above highlights the shortcomings of STIR/SHAKEN, but it is important to note that even if 99% of incoming calls were properly secured and trustable, users must always remain vigilant for the 1% of calls that are not, as a single scam call can cause significant harm.
Some in the industry argue that STIR/SHAKEN attestation was never intended to distinguish between good and bad calls, but rather was developed as a traceback mechanism. However, this belief is based on a misunderstanding. If attestation is not meant to indicate the trustworthiness of a call, it should not be used to inform end-users about the reliability of the presented CLI. Such a reversal of history would be problematic, as regulators like the FCC have learned over time that, despite the disappointing results in combatting CLI spoofing and robocalling, STIR/SHAKEN still provides a valuable tool for tracing bad actors.
Although one could argue that STIR/SHAKEN, with its complexity and high cost, was not the perfect solution for traceback, the key question is whether adding even more complexity to the existing framework is the right approach to address the fundamental weaknesses of the STIR/SHAKEN mechanism. This concerns efforts within the IETF to standardize an extension to the STIR architecture through the introduction of a Personal Assertion Token (PASSporT), specifically with a new type called “VESPER” (VErifiable Sti PERsona). In simple terms, VESPER aims to add more information to the SIP signaling, allowing the receiving network to better assess the validity of the CLI.
However, there are challenges to this approach. For one, STIR/SHAKEN has so far been adopted in only a few countries — primarily the USA, Canada, and France — meaning the potential scope of VESPER would be similarly limited. Scammers, aware of these geographic limitations, could exploit this vulnerability to bypass the protections that VESPER offers, just as they have previously found ways to circumvent the entry points of STIR/SHAKEN.
Ultimately, the root cause of the problem is the lack of responsibility on the part of the originating operator for the Right to Use (RTU) of the CLI. To prevent fraudulent calls from entering the complex and extensive global telecom ecosystem, it is essential that the originating operator verifies the RTU of the CLI and implements robust Know Your Customer (KYC). This is to provide safeguards against calls with falsified CLIs that involve measures to authenticate and verify customer identities, conduct due diligence on their operations, compliance history, and other relevant factors crucial for assessing the risks of potential non-compliances and the associated liability for communications providers.
Each originating operator is principally only able to implement adequate RTU and KYC policies for its own end-users connected to its own network resources. In other words, they can only assure calls from direct landlines or the mobile calls of users who are not roaming. But the bypass risks associated with these RTU and KYC defenses also apply to other call scenarios, including, but not limited to the following.
Calls from Enterprise Networks
In such situations, the RTU of the CLI is split between the enterprise and the originating operator. Ideally, the enterprise should be allocated a specific number range, and the originating operator should validate the CLI of any incoming call to ensure it falls within that range. If the CLI is outside the allocated range, the call should be blocked. However, these checks become complex for large enterprises that have multiple number ranges and numerous entry points. Additionally, the originating operator may not always be aware of which numbers are active or inactive.
International Calls
Each operator in a given country is typically familiar with the specifics of the national numbering plan, enabling them to perform detailed consistency checks on the CLI of any call within that country. However, the situation becomes more complicated for international calls. As the call traverses multiple networks, the accuracy of these checks diminishes. This is due to the fact that mechanisms like STIR/SHAKEN, which help mitigate CLI manipulation, are local and do not work across networks in different countries, leaving international calls vulnerable to potential manipulation of the CLI.
Calls from Roaming Users
The vulnerability pertains to international incoming calls that display a local mobile number in the CLI. These calls typically originate from roaming users making calls on a legacy 2G/3G mobile network in a foreign country. This scenario is particularly attractive to fraudsters because international carriers are often unable to determine whether the call is legitimate or fraudulent. As outlined in my previous article for Commsrisk, this issue is unlikely to be resolved soon, given the widespread use of SS7 signaling for roaming support and the various scenarios in which mobile CLIs can be manipulated outside the control of mobile operators.
This creates a situation where operators in the terminating country must check each such call to verify whether the CLI corresponds to a legitimate roaming user. If not, the CLI is false and the call should be blocked. However, validation fails if the CLI is falsified and the user is actually roaming.
Conclusions
These scenarios demonstrate that VESPER will not address the shortcomings of STIR/SHAKEN. VESPER will not work for international calls. At best, VESPER offers additional detail for traceback purposes within the STIR/SHAKEN domains. Generally, the primary responsibility lies with the originating operator to prevent illegitimate calls, as the originating operator controls the RTU and holds the KYC data needed to validate the CLI. However, these checks become less effective and more cumbersome as you move further down the line.
In parallel, operators in the terminating country should implement robust checks to verify incoming calls with a mobile CLI, given the widespread abuse of this use case. Mobile CLIs can be manipulated through various means, often beyond the control of mobile operators.
