Table of Contents
If you’re in the communications industry, you’ve likely heard recent buzz about something called SHAKEN/STIR. What does it all mean and how will it impact your business? We’ll break that down for you in this FAQ.
Industry leaders have been developing new specifications coined SHAKEN and STIR for Internet Protocol-based traffic exchange in recent years. SHAKEN/STIR is fundamentally aimed at re-establishing trust in the communications ecosystem and a stronger stance against malicious robocalling. The FCC is also interested in protecting consumers against fraud and abuse in the form of robocalling (this was demonstrated by an official release in early November 2018 from FCC Chairman Ajit Pai imploring service providers to implement the SHAKEN/STIR framework as soon as possible). So, as you work with Bandwidth to advance your communications business needs, we want you to be aware of what our stance is and what we’re doing to implement SHAKEN/STIR standards.
Bandwidth is actively engaged in efforts to implement the most robust call authentication framework possible, while also working diligently to stop the transmission of illegal robocalling on our network holistically. In addition to advancing the adoption of SHAKEN/STIR, Bandwidth is also leading industry efforts and best practices, including a three-pronged operational approach (prevent, detect, and mitigate) to stopping illegal robocalls. Learn more about Bandwidth’s stance against fraud and robocalls in our support article.
While curbing illegal robocalling is a main objective of SHAKEN/STIR, the framework itself does not include a mandate to block robocalls. We'll explain what it does stipulate, and what that may mean for your business, in greater detail below.
What is SHAKEN/STIR?
SHAKEN (Secure Handling of Asserted information using toKENs) and STIR (Secure Telephone Identity Revisited) (or vice versa: STIR/SHAKEN) are Telecom industry standards designed to enable service providers to cryptographically sign calls in the SIP (Session Initiation Protocol) header. In simple terms, the STIR portion refers to the process of providing attestation that the call is legitimate, while the SHAKEN part is more about how to handle the calls one way or another.
The process uses a trusted public key infrastructure to enhance the integrity of the originating call identifying data sent across networks. With SHAKEN/STIR, SIP headers will contain a level of confidence indicator from the originating service provider to signal whether the party originating the call has the right to use the number via the attestation field. There are 3 levels of attestation that can be indicated by the originating service provider:
- Full Attestation - the service provider has authenticated their customer originating the call and they are authorized to use the calling number
- Partial Attestation - the service provider has authenticated their customer originating the call but cannot verify they are authorized to use the calling number
- Gateway Attestation - the service provider has authenticated from where it received the call, but cannot authenticate the call source (e.g., International Gateway call).
In addition to the attestation level, the originating service provider provides data in the header to facilitate traceback identifying where the call entered their network.
What is the driving force behind SHAKEN/STIR adoption?
Fraud and abuse in the form of robocalling and, in particular, illegally spoofed robocalling, is the number one consumer complaint to the Federal Communications Commission (FCC). The industry is seeking to combat the abuse through the adoption of SHAKEN/STIR as one tool that will help. In an effort to combat the rising number of malicious and illegal spoofing, Chairman Ajit Pai of the FCC issued an official release in early November 2018 imploring that service providers implement the SHAKEN/STIR framework. A copy of the release is available here.
It is worth noting that SHAKEN/STIR is not a technology that blocks calls per se, but rather a tool that may provide indications of when fraud is occurring. In addition to working on implementing SHAKEN/STIR, Bandwidth also has policies to block unlawful robocalls and other forms of fraud.
It is important to distinguish between fraudulent and legitimate robocalls. Bandwidth continues to implore regulators and the industry to work hard to ensure that legitimate calls do not get blocked in the flurry of effort to prevent abuse. Services that consumers want and demand, such as school closure notifications or prescription reminders, must continue to meet their needs and expectations. While SHAKEN/STIR does not block calls, the data produced by the verification of signed calls could be input into the analytics used to block calls.
What is the difference between STIR and SHAKEN?
STIR is a working group within the Internet Engineering Task Force (IETF), an open standards organization which develops and promotes Internet standards. As such, STIR produces internet standards that form the basis of what is referred to as SHAKEN/STIR. These include RFC 8224, RFC 8225 and RFC 8226, in addition to some draft standards currently being developed to address additional use cases beyond the scope of what is addressed by SHAKEN (ATIS 1000074). SHAKEN defines the extensions and industry framework for the deployment and interworking of the technology in service provider networks.
How does SHAKEN/STIR work in a call path?
When originating a call on the network, the originating service provider’s Secure Telephone Identity Authentication Service (STI-AS) creates an encrypted SIP Identity Header that includes the following data:
- Attestation level
- Date and Time
- Calling and Called Numbers
- Orig ID for analytics and/or traceback purposes among others
- Location of certificate repository
- Encryption algorithm
The SIP INVITE with the SIP Identity Header is sent by the originating service provider and received by the terminating service provider. The terminating service provider invokes a STI Verification Service (STI-VS) to decode the SIP Identity Header and perform verification of the data transmitted in the call. Depending on the results of the verification, information can be passed in a verification status or verstat parameter indicating the results of the verification step. The call is completed to the receiving party with potentially some optional treatment like a display that is dependent on the level of attestation and the resulting verification. For example, this could be “valid number” or green checkbox for a fully attested call, or labeled as “possible spam” for a gateway attested call without full attestation.
The following diagram shows the high-level call flow for SHAKEN calls:
- SIP INVITE is received by originating service provider who looks at call source (customer) and calling number to determine the level of attestation to provide for the call
- Originating service provider sends SIP INVITE to the authentication service
- Authentication service returns SIP INVITE with SIP Identity Header containing PASSporT header, PASSporT payload, PASSporT signature, encryption algorithm and location of certificate repository
- SIP INVITE with Identity Header is sent to terminating service provider
- Terminating service provider sends SIP INVITE with Identity Header to Verification Service
- Verification Service obtains the digital certificate with the public key, decodes the Identity Header and verifies that the originating service provider is authorized to originate calls for the calling number
- Verification results are returned to terminating service provider
- Terminating service provider completes the call to the called party
When will Bandwidth implement SHAKEN/STIR?
Bandwidth participates in the relevant industry forums (ATIS IP-NNI, NANC WG, etc.) and is actively implementing the SHAKEN/STIR specifications. We are working towards initial interoperability testing with leading carriers in the Fall of 2019. We are moving forward with SHAKEN implementation as defined in ATIS 1000074. However, Bandwidth is on record with the FCC that SHAKEN as written is not adequate for all uses cases.
One example of an outstanding use case is when a customer purchases a telephone number from one provider but originates a call with a different provider. Bandwidth continues to participate in ATIS IP-NNI with other interested parties to ensure that proposals such as "Certificate Delegation" or "TN Proof of Possession" are adopted to ensure all legitimate customer calls are treated equitably. Because of the existing gaps in current standards, Bandwidth expects to be implementing SHAKEN/STIR from its initial deployment in the Fall of 2019 well into 2020.
It is worth noting that SHAKEN/STIR validates that the telephone number (TN) of the call is valid. It also adds a mechanism for traceback of the call to the carrier that originated the call. It does not block calls.
Are you currently in production with SHAKEN/STIR interop with peering partner?
No. Our initial interoperability will commence the Fall of 2019.
What can I do now to prepare for SHAKEN/STIR deployments?
As a customer, you can consult with your equipment vendor to understand its readiness for receiving additional SIP headers that will result from SHAKEN/STIR. While discussions are ongoing in the ATIS IP-NNI forum regarding what to pass the customer, the current best practice proposal suggests passing both the verstat parameter as well as the full Identity Header to the customer. Verstat is the header containing the verification results produced by the STI-VS, while the Identity Header is the header added by the originating service provider calling the STI-AS and includes such things as the attestation level and Orig ID.
As previously mentioned, on the origination side there are use cases that ATIS 1000074 as defined does not address directly, such as when a customer buys telephone numbers from multiple carriers and originates calls with different carriers. Bandwidth continues to advocate with the industry and the FCC that these use cases need to be addressed to ensure fair and non-discriminatory treatment of traffic.
As a customer, you should stay abreast of these developments and, if possible, participate in industry forums and make your opinions known.
As a customer, will my network be expected to generate Identity Headers for traffic sent to Bandwidth?
Currently no. For SHAKEN, as it’s defined today in ATIS-1000074, the originating carrier will generate the Identity Header via an STI Authentication Function (STI-AS). As mentioned, there are some use cases in which SHAKEN as written needs to be augmented to address. One example of this is when a customer’s equipment diverts a call (forward or transfer), which makes verification of the original Identity Header difficult or impossible. Another case is when a customer gets a number from one carrier and originates a call on a different carrier. Both of these cases, among others, are being debated in the industry forums and may result in a customer needing to generate an Identity Header (or for Bandwidth or a third party to generate one on the customer’s behalf).
What is Bandwidth doing in relation to SHAKEN/STIR in the United States?
Bandwidth is actively engaged with the Federal Communications Commission (FCC), as well as with several SHAKEN/STIR working groups, to help shape and establish an industry solution for validating phone numbers and caller authenticity in an effort to reduce instances of robocalls and spoofing. We are working alongside other major service providers to develop and implement solutions that will best suit our customers’ wide variety of use cases.
Bandwidth will be actively updating our customers on major changes as they take place.
How will SHAKEN/STIR impact call forwarding use cases?
Call forwarding and otherwise “diverted” calls, such as call transfer, can result in the inability to verify the Identity Header added by the originating service provider because of the SIP header modifications that could occur. The ATIS IP-NNI forum is working on a standard specifically to handle these diversion cases, but it is still in draft status and being debated.
How will SHAKEN/STIR impact a call flow incorporating multiple carriers?
Authentication and signing of a call (STI-AS function) should be done by the originating service provider, and verification of a call (STI-VS function) should be done by the terminating service provider. The transit networks in between should pass the Identity Header without modification.
Was this article helpful?
3 out of 3 found this helpful