Out-of-Band STIR
By authenticating and verifying caller ID, STIR/SHAKEN offers relief from spam robocalls with fake caller ID. But the effectiveness of this approach depends on whether caller ID authentication information survives transit over the telephone network.
There are real-world issues that can prevent successful transit of this information across today’s telephone network. These issues limit the effectiveness of STIR/SHAKEN. This whitepaper describes these issues and a solution to overcome them: Out-of-Band STIR.
STIR/SHAKEN methodology
STIR/SHAKEN requires the originating service provider to create an Identity token, called a PASSporT, for each call they put on the network. In addition to call information, the Identity token includes an attestation level and a unique orig ID for traceback. This information is signed using PKI techniques to prevent tampering or replay attacks.
The token is placed in the SIP INVITE message used to set up the call on the SIP network. Ideally, this Identity token should accompany the call through the entire network until it reaches the terminating service provider, who then uses it to verify caller ID information and present verification status to the called party.
STIR/SHAKEN call flow
It’s a brilliant solution. But there are pitfalls using it across the telephone network today.
Call routing issues across the telephone network
Calls are typically routed across many segments of the telephone network.
A Typical Segment of the Telephone Network
Service providers negotiate network interconnect agreements among themselves that describe the price they will pay to have their calls sent through the network. They use least cost routing software to select available routes based upon quality and price. This leads to extended call paths as calls travel from one carrier to the next. With extended call paths comes increased risk that the Identity token may be lost in transit. Here are three ways that the PASSporT can be lost:
- Call path segments in the telephone network today are not all SIP. Legacy network technology is still in widespread use. The old networks cannot transmit SIP messages. When an authenticated call reaches one of these segments, the STIR/SHAKEN information is lost.
- Some SIP network software removes the Identity token from the SIP header. Carriers must upgrade their SIP software to enable their network to retain the Identity tokens in calls that transit their network.
- Some SIP networks use UDP network technology, which does not provide flow control and retransmission. Because of this, UDP is prone to packet fragmentation and packet loss—a serious problem when sending Identity tokens, which must be delivered perfectly intact, else they cannot be verified. SIP over TCP, which provides flow control and retransmission, delivers Identity tokens much more reliably than UDP.
These issues create obstacles where the original authentication information is lost.
Other segments further down the call path might use SIP and have equipment and software capable of STIR/SHAKEN. Carriers are expected to sign and authenticate calls they put back on the SIP network. So even if the original PASSporT were lost, the call might get another one further down the call path.
But intermediate and terminating carriers don’t know the calling party like the originating provider does, and therefore can’t provide the same level of attestation or traceback. Subsequent tokens aren’t as useful as the original.
Why not just convert everything to SIP?
The ideal solution to this problem would be to replace all legacy technology throughout the entire telephone network with the latest SIP-capable equipment and software running over TCP networks. This would allow STIR/SHAKEN Identity tokens to be exchanged from one end of the network to the other.
The telephone network has been evolving toward SIP for decades. But such changes are costly and take time. And the economics of carrier compensation access fees is, for some providers, a huge financial disincentive to convert from legacy technology to SIP.
The demand for robocall relief requires widespread STIR/SHAKEN deployment long before the transition to an all-SIP network can be completed.
Consumers need spam robocall relief now. And service providers need practical options to provide it.
Solution: Out-of-band STIR
There is a way to enable STIR/SHAKEN for all calls across the current network, and it’s feasible today: Out-of-band STIR. The process is very similar to the one described above, except the Identity token is sent across the internet, out-of-band from the call path, through a Call Placement Service, as shown in this illustration:
Out-of-band STIR
The steps are very similar to standard STIR/SHAKEN processing, with a few exceptions:
- STI-AS authentication is performed by the originating or gateway service provider as usual.
- The originating service provider encrypts the Identity token with the terminating service provider’s public key and sends the encrypted token separately, out-of-band, across the internet to the terminating service provider’s Call Placement Service (CPS).
- The call is routed through the telephone network as usual. It doesn’t matter whether the call is routed over SIP or legacy networks, or a combination of both.
- When the terminating service provider receives the call, they check their CPS for tokens associated with the called number.
- Having found and decrypted the Identity token in their CPS, the terminating service provider performs STI-VS verification as usual.
Out-of-Band STIR benefits
There are several compelling advantages of using out-of-band transmission of Identity tokens:
- It does not matter what kind of network segments are used to route the call.
- There are no concerns about whether any of the network equipment or software along the call path might strip the Identity token from the call.
- There are no problems with tokens being corrupted by packet loss or fragmentation.
- Since the Identity tokens are secured using asymmetric encryption, there are no security risks or privacy concerns. Nobody can read the tokens except the terminating service providers.
- Apart from encrypting and decrypting the Identity token, the STI-AS and STI-VS processes are unchanged whether Identity tokens are transmitted either in-band or out-of-band.
At TransNexus, we welcome innovative ways to solve problems. Network issues that prevent end-to-end transmission of Identity tokens are a serious threat to the success of STIR/SHAKEN. We believe Out-of-Band STIR is a viable solution, and so we have implemented both In-Band and Out-of-Band STIR in our software. These options enable TransNexus customers to authenticate and verify caller ID today, undeterred by the network issues described above.
TransNexus solutions
We have comprehensive STIR/SHAKEN solutions, including both in-band and out-of-band capabilities, available in our ClearIP and NexOSS software products. Contact us today to learn how we can help you with your STIR/SHAKEN deployment.
More on TransNexus.com
October 1, 2019
California enacts law to mandate STIR/SHAKEN
October 1, 2019
FCC filings calling for Out-of-Band STIR
September 9, 2019
Hiya 2019 Half-year Robocall Report
September 6, 2019
How STIR/SHAKEN can help defend against AI voice fraud attacks
August 27, 2019
Industry replies to proposed FCC rule changes on robocall blocking
August 22, 2019
Coalition of 12 telephone companies agree to fight robocalls
August 16, 2019
FCC Chairman Pai statement on SHAKEN/STIR progress and expectations
August 15, 2019
ClearIP now supports Rich Call Data in STIR/SHAKEN
August 15, 2019
AT&T and T-Mobile begin cross-network STIR/SHAKEN
July 29, 2019
TransNexus comments on FCC robocall blocking notice
July 15, 2019
June 20, 2019
Webinar recording available – Effective STIR/SHAKEN and Robocall Solutions that Work Today
May 15, 2019
FCC proposes rule to permit robocall blocking by default
May 13, 2019
TransNexus expands STIR/SHAKEN offer
April 29, 2019
Several stakeholders and interested parties have encouraged the FCC to support out-of-band STIR. Here’s an article that lists a few, and their reasons.