In a previous blog The Anatomy of STIR/SHAKEN and Its Preconditions, we discussed the architecture and preconditions that must be in place before a call can transit the network inside the STIR/SHAKEN wall of trust.
The above glibly states “the call, now attested and signed, is routed onwards to its destination”. It carries with it the all-important Identity Header upon which all of STIR/SHAKEN depends.
But what if…
- What if the call signaling path between the originating service provider and the terminating service provider is not capable of faithfully transporting the Identity Header because either it is SS7 or contains SS7 segments, instead of being purely SIP?
- What if one or both of the originating and/or terminating service providers runs a TDM voice core, not an IP voice core?
In both of these cases, signed Identity Headers would be lost in transit (as SS7 cannot transport them) or not generated at all (a TDM core is unlikely to be natively able to interact with STIR/SHAKEN at this point in time). STIR/SHAKEN would fail to operate.
Considering TDM
The FCC has also sent clear signals that it is carefully considering the TDM/SS7 problem now. In response to this challenge, the ATIS STIR/SHAKEN standards working group has been exploring solutions for including TDM networks into the STIR/SHAKEN framework. A key focus has been the resolution of the fundamental issue of transporting signed Identity Headers from origination to termination in the absence of SIP signaling.
Two new pieces of technology are required to accomplish this:
1. A new TDM/SS7 network element, or a new function embedded within an existing network element, that is able to intercept ISUP IAM messages and engage in interactions with a STIR/SHAKEN implementation to generate signed Identity Headers for TDM originated calls.
2. An out-of-band repository that originating service providers can store signed Identity Headers into and that terminating service providers can retrieve them from.
Extending the STIR/SHAKEN trust network into the TDM/SS7 domain
The first of these two can be accomplished by:
- A new purpose-built drop in network element or
- Changes to an existing in-network SS7 signaling element to enable it for STIR/SHAKEN interaction.
Some vendors are providing a hybrid of these two, deploying a new instance of an existing network element augmented for STIR/SHAKEN processing.
Standards forums have anticipated the TDM/SS7 problem and guided by their deliberations, the out-of-band repository has taken the form of a cloud-based CPS (Call Placement Service) element. This element is fundamentally an internet-accessible database into which originating service providers can place signed Identity Headers for outgoing calls, and from which terminating service providers can retrieve those headers when they receive the calls. Use of a CPS to accomplish this result is known as TDM-SHAKEN.
Taken together, a new SS7-based network element that can interact with (or directly accomplish) STIR/SHAKEN processing and the use of TDM-SHAKEN to transport the result from origination to termination fully resolves the TDM/SS7 problem, extending the previously IP only STIR/SHAKEN trust network into the TDM/SS7 domain. The “price” for this extension is at least one new network element and one new cloud element (the CPS).
Attestation and Call Traceback
Two elements of the call origination flow described above deserve additional examination at this point – the Attestation level and the OrigID. Both of these are provided by the requesting session control element to the STI-AS service.
The fundamental principle behind STIR/SHAKEN is to separate the calls of known trusted callers from the remainder of the calls on the network. Setting of the Attestation level is where this happens – where the service provider gets to attest to how trusted the caller is.
There are three possible attestation selections, shown in the table below:
“A” Attestation
The most valuable of the possible attestation levels is “A”, which indicates that the service provider knows the identity of the calling party, and that the calling party is known to have the right to use the calling TN. An “A” attestation is the gold standard; it tells the terminating service provider that the received caller ID can be fully trusted.
“B” Attestation
This attestation level indicates that the service provider knows the identity of the calling party, but does not have direct knowledge of the calling party’s right to use the presented caller ID. In this case, the terminating service provider cannot present this call to the recipient as “trusted”. While of little value to the call recipient, “B” attestation remains of value to the terminating service provider, particularly in the event that the need should arise to trace a call back to its source. “B” attestation makes it clear that the originating service provider at least knew the calling party.
“C” Attestation
The least valuable of the attestation levels is the “C” attestation. This simply states that the service provider does not know the identity of the calling party and has no knowledge of their right to use the presented calling telephone number.
The Role of OrigID
In addition to attestation, the other item mentioned above that deserves additional examination is the OrigID. The OrigID is one of the lesser discussed aspects of the STIR/SHAKEN infrastructure but is a highly important one in maintaining the integrity of the trust network. When an originating service provider makes an “A” attestation regarding a call, and that attestation turns out to be in error (for example, the caller was actually a fraudster), the party receiving the call can complain to their service provider, and through them, ultimately to the STI-PA.
The call records for such calls will reveal their OrigID, and that OrigID can be used to “walk back” the calls to their originating service provider, and to whatever level of calling party granularity that service provider encoded into their OrigID values. The minimum requirement of an OrigID is that it must be a UUID (Universally Unique IDentifier). However, a service provider can encode into the value any level of traceback granularity that they wish. The more granular the OrigID is, the easier it is to identify and turn off the fraudulent call source. If the OrigID identifies only the carrier itself, and not the call source within the carrier, that carrier may find itself excluded from the STIR/SHAKEN trust network until it can demonstrate to the satisfaction of the STI-PA that it has completely resolved the underlying problem.
STIR/SHAKEN Termination Processing
Returning to our call traversing the network inside the STIR/SHAKEN trust network, it arrives at the terminating service provider and in due course is recognized by a session control element as being a signed call that requires validation. It extracts the signed PASSporT from the call’s Identity Header and sends it up to the STI-VS (Verification Service), requesting validation.
There, the STI-VS reaches across the internet to the originating service provider’s STI-CR and pulls back the STI-CA-signed public key certificate. It first verifies the STI-CA signature on the certificate itself and then moves on to verifying the call signature from the PASSporT. All of these verifications are cryptographic operations whereby the public key of the signing entity is used to mathematically process the signature being verified. If the signature was generated using the paired private key, this operation returns a binary “true” result. If verification fails, it returns a binary “false” result.
While this is the most direct approach, reaching across the internet to the originating service provider’s STI-CR each time a signed call is received from that service provider is typically an unnecessary exercise that only results in increased post dial delay. A better approach is for the terminating service provider to maintain a local cache of public certificates from all of the originating service providers it has received calls from. This is far more efficient than retrieving the same certificates over and over again. This implementation decision is left up to each STIR/SHAKEN solution vendor, but STI-VS certificate caches are often provided as part of a vendor solution, in the form of a CRc (Certificate Repository cache) element. This optimization eliminates unnecessary internet messaging and improves post dial delay.
At this point in STI-VS processing, an optional side trip can be taken. If the STIR/SHAKEN implementation includes a CVT (Call Validation Treatment) element, the signed PASSporT can be handed off from STI-VS to the CVT for further validation. What CVT does with this information can be widely variable – it is a custom implementation per network. However, a common task it will accomplish is to check the calling number against a (typically external) scam/nuisance database, and return a scam score back to the STI-VS. If the scam score is high enough (i.e. the caller is probably a fraudster), this information is included in the results returned to the requesting session control element.
No matter what the validation results are, they are returned to the requesting session control element. That element then evaluates the results and translates the total set of available information into one of three values:
- The call validated successfully
- The call failed validation
- There was no signature to validate
This result is loaded into the verstat parameter of the call’s SIP Invite and this is then dispatched for final termination to the end device.
Displaying the STIR/SHAKEN Verification Result
Displaying the verstat result on the terminating device is an art form all of its own and is exclusively the province of the terminating service provider and their device suppliers. There are multiple options, from “high tech” to “low tech”.
At the “high tech” end, and particularly in the context of mobile devices, the terminating service provider may sell devices that are capable of translating the verstat value into an onscreen display, such as a green check mark or a green shield. This is the case for most of the large mobile service providers and their handset suppliers. By definition, this is limited to 4G and 5G calling, as direct SIP connectivity to the terminating device (i.e. VoLTE) is required.
In the “mid tech” area, including 2.5G and 3G mobile devices, along with any landline device that has a calling name display capability, the terminating service provider may choose to append extra letters, such as “[V]” (indicating successful verification) or “[U]” (indicating an unverified call) to the calling name.
In the “low tech” space, including so called “feature phone” mobile devices and simple landline devices without any display capability, unverified calls may be pushed directly to voicemail, or an IVR may be bridged into the call delivery flow to offer the recipient the option to accept or reject suspected scam calls.
STIR/SHAKEN – Complexity and Simplicity
The problem of fraudulent robocalling is a deeply entrenched and vexing one, annoying and defrauding American consumers to the tune of over $10B per year. IETF and ATIS have together defined STIR/SHAKEN, a set of technologies that enable easy separation of trusted calls from untrusted (and likely fraudulent) calls, dramatically curtailing the answer rate for those calls. Once widely in service, STIR/SHAKEN has the potential to restore consumer trust in the integrity of the caller ID information presented by the public telephone network.
While the result of STIR/SHAKEN in action is easy separation of good calls from bad, implementing STIR/SHAKEN is anything but easy for the service providers who are required by the FCC to bear the burden of doing so. The STIR/SHAKEN ecosystem is complex, resource intensive and costly to implement. The chasm between present state and full STIR/SHAKEN compliance is deep and wide.
At this point, we have examined the fraudulent robocalling problem, identified CLI Spoofing as a key contributor to it, and detailed the intended operation of a STIR/SHAKEN based network implementation through the lens of a call traversing the network side the STIR/SHAKEN trust network.
In this short blog series, we have seen that the STIR/SHAKEN architecture requires service providers to implement a minimum of five, and potentially up to seven, new network functions/elements to achieve compliance with the FCC requirements. Stated simply, STIR/SHAKEN compliance can be complex, resource intensive and expensive.
What is needed is a way to simplify a service provider’s path to compliance. NetNumber bridges the chasm with Guaranteed Caller™, a family of standard compliant STIR/SHAKEN solutions designed with one overriding objective in mind – simplifying the service provider journey from today’s state to full STIR/SHAKEN compliance.
Guaranteed Caller™ – NetNumber’s Simple STIR/SHAKEN Solution
NetNumber’s Guaranteed Caller™ is a family of standards-compliant STIR/SHAKEN solutions that address all of the common trusted call scenarios, so that legitimate callers can participate in the STIR/SHAKEN trust network, while fraudsters are locked out.
Guaranteed Caller™ was built with one overriding goal in mind – simplifying the journey to STIR/SHAKEN compliance for service providers.
To accomplish this, no stone is left unturned. Everything is in the cloud. The TDM-SHAKEN CPS element is included with every solution sold. SS7 <-> STIR/SHAKEN interfacing is accomplished by Guaranteed Caller’s Cloud Connect node, a lightweight, low touch and surprisingly low cost in-network element. STI-PA/CTI-CA signup and onboarding is available as a NetNumber professional service. As an approved STI-CA, NetNumber can even take care of providing the requisite SHAKEN certificates.
As if this wasn’t enough however, Guaranteed Caller™ goes further, and can help service providers to monetize the necessary cost of STIR/SHAKEN compliance by reselling Guaranteed Caller™ call signing services to their enterprise customers.
Guaranteed Caller™ provides a one-stop fully turnkey solution to a service provider’s STIR/SHAKEN compliance problem. Install Cloud Connect and leave the rest to NetNumber.
Stream the Capacity Media webinar “Restoring Trust to the Public Phone Network” featuring some of the leading minds behind STIR/SHAKEN from NetNumber and Comcast.
