Insights & Resources

Robocalling Problem Part II: Phone Network Limitations

There are still several limitations preventing STIR/SHAKEN from being a truly effective solution to illegal robocalling.

Tarek Wiley
Robocalling Blog 2_banner
We’ve had enough of illegal robocalls. They are annoying, intrusive and dangerously effective. According to the Federal Trade Commission (FTC), fraud from these unwanted calls costs consumers around $9.5 billion each year.
And with sophisticated methods like spoofing to falsify the caller ID information, the illegal robocalling problem is only getting worse. The telecommunications industry needs a way to authenticate callers and stop robocalls from reaching the terminating number without verification.
The protocols and framework established by STIR (Secure Telephony Identity Revisited) and SHAKEN (Secure Handling of Asserted information using toKENs) will make it possible for providers to confirm the identity and legitimacy of the caller ID using signed tokens.
However, there are still several limitations preventing STIR/SHAKEN from being a truly effective solution to illegal robocalling — the biggest being the phone networks themselves.

Network Limitations

STIR/SHAKEN may be the solution we’ve been waiting for, but it requires widespread provider adoption to become truly effective.
Some major carriers have already begun the implementation and testing processes, but until there is mass compliance, robocalls will still get through without validation if they originate on a provider network that is not employing STIR/SHAKEN.

IP Networks Only

In its current form, STIR/SHAKEN will only work between IP networks — it can’t authenticate calls that traverse the public switched telephone network (PSTN). So if a call transfers to TDM interconnect at any time, the signed token will be lost along with the ability to authenticate the caller ID. This means that even legitimate calls won’t be verified.
Robocalls that originate on VoIP networks often end up traversing the PSTN, as providers are typically limited to interconnects between large carriers. Until all call traffic can be sent over IP networks, there will always be gaps to exploit.

Large Identity Headers

Depending on their network configuration and SIP stack implementation, some providers may run into problems when implementing STIR/SHAKEN. The identity headers containing the signed tokens are large — full headers can run well over 300 bytes. As the message size increases, so does the risk for packet fragmentation.
Because most providers are still using User Datagram Protocol (UDP) to connect calls, packet size could become a problem. Though identity headers will still fit within the SIP INVITE for UDP, providers are encouraged to move to Transmission Control Protocol (TCP) to better handle the large identity headers.

Number Ownership

The originating provider is responsible for checking that the caller ID is legitimate and the caller is authorized to use it. The association between the caller and phone number can be easily verified if the number is owned or managed by the service provider, and a signed token can be generated with full attestation.
But this is often not the case. Many organizations use least cost routing (LCR) to find the most inexpensive path for their voice traffic. With LCR, the originating service provider selected to handle the phone call could be different from the service provider that owns or manages the number. As a result, the originating provider is unable to verify that the caller is authorized to use the specified phone number.
If the originating service provider isn’t fully confident in a caller’s authority to use a number, only partial attestation (at best) can be assigned to the token. The call will be viewed as more suspicious because it isn’t fully attested.
One solution to this problem suggests using service provider certificates to generate limited-scope “child” certificates that can be issued to the callers themselves. The calling entity would collect certificates from all relevant service providers to cover numbers in its inventory, securely storing and managing them in a key management server (KMS). When initiating a phone call, the caller would select the appropriate certificate from the KMS to generate a signed token.
However, this coupling of phone numbers and certificates comes with its own problems. Because organizations often use multiple phone numbers in their day-to-day business operations, managing certificates for each number would be a large undertaking. And as number ownership changes when users switch providers, it becomes even more difficult to keep certificates up-to-date.

Pushing Forward

The only way STIR/SHAKEN will be a success is if the voice providers work together to ensure widespread adoption. And because STIR/SHAKEN will only work on IP-based networks, we need to push for an IP interconnect framework to keep calls off the PSTN.
There is also a problem of added costs for the carriers. Smaller providers may not have the resources to allocate for implementation. As big carriers continue implementing STIR/SHAKEN and more people block unverified calls, these small operators will have trouble keeping up.
Large carriers must help smaller ones make strides toward STIR/SHAKEN compliance if caller ID authentication is to be implemented across all provider networks. This includes helping them transition to IP-based calling and creating more interconnects between providers.
Check out the next post in our robocalling blog series to see what steps are being taken to ensure STIR/SHAKEN compliance.
Find out more in Solving the Robocalling Threat, Part III: The Roadmap to STIR/SHAKEN Compliance.

Can't wait for the next post in our robocalling series? Check out our on-demand robocalling webinar for additional insights.
Share on Social

Get Started for Free!

Create a free account to set up voice, messaging, IoT, video & more.