In this section:
The proliferation of identity spoofing (potentially combined with robocalling) often leads to unsuspecting consumers falling victim to scams, such as IRS impersonation, offers of free travel, loan support, and software technical support. Identity spoofing and robocalls also devalue the real-time communications process and annoy customers. Well-intentioned, but spoofing techniques easily thwart flawed "blacklists" for anti-robocalling tools and applications. The SBC provides the solution based on industry-standards for securing VoIP call identity.
Secure Telephone Identify Revisited (STIR) defines core protocols and technologies for SIP and the certificate used for applying digital signatures to validate the telephone identity of the calling party. STIR provides an anti-spoofing SIP protocol specification to authenticate a SIP origination using a cryptographic signature which is placed in the Identity header that the terminating SIP element verifies. This identity header provides attribution to the signing carrier, and assurance that it is authorized to sign over the originating telephone number.
Signature-based Handling of Asserted Information Using Tokens (SHAKEN) defines the industry framework for using STIR technologies and how the service providers interwork VoIP-based calls.
Robocalls, spoofing calls, unwanted calls, and spam phone calls are the most significant source of consumer complaints. STIR and Signature-based Handling of Asserted Information Using Tokens is a framework that blocks these calls ensuring Calling Party Information is not spoofed. It authenticates the identity-related information in the call signaling, by generating and verifying the cryptographic signatures, and effectively blocking all Caller ID spoofing and illegal robocalling. SHAKEN/STIR is intended to eliminate the use of illegitimate spoofed numbers from the telephone system by establishing a trust-based system for authenticating legitimate numbers.
STIR/SHAKEN is intended to restore confidence in the authenticity of the origination within SIP interworking elements by providing information to the terminating network. This is used to communicate to the user with assurances that include whether the calling party is legitimate, such as the signature included in the SIP invite is valid and was created by an entity with authority to attest to the originating telephone number. STIR/SHAKEN implementation is one component in the overall strategy to provide customer value to address anti-spoofing and robocalling mitigation techniques. This deployment of STIR/SHAKEN may reduce timeframes and resources for traceback associated with identifying the source of illegal and unwanted robocalls.
The scope of STIR/SHAKEN planned deployments that include SIP capable networks include
The IETF STIR and ATIS/SHAKEN specifically support:
The SBC supports the following STIR/SHAKEN functionalities:
Support for SIP signaling enhancements: The SBC generates and parses new STI headers and supports passthrough/mapping of STIR related response codes.
STIR/SHAKEN Call Flows
During the initial processing of a message, the SBC is not aware of the STIR/SHAKEN procedures applied at the PSX. Hence, the SBC sends the following STI-related information elements, if received, to the PSX. The state of the stiProfile
associated with the trunk group has to be enabled for SBC to apply STI mechanisms.
SHAKEN always uses the full form of the Identity header; therefore the SBC supports only the full form of the Identity header. For signing and verification of the full form of the identity header, the PSX sends the current time determined by SBC and not the Date header information to the STI server. Hence, the SBC neither processes nor sends the Date header natively. If you need to pass the Date Header transparently, use the SBC’s Header Transparency feature.
Information received from PSX per route during signing:
Information received from PSX per route during verification:
Information received from the PSX per route during tagging:
The SBC generates and parses the following new headers:
New information sent over Gateway-Gateway signaling:
Error handling-related policy resides in the PSX for errors generated during interaction with Signing/Verification Server. The PSX conveys error handling decision in D+ reply, and the SBC follows the corresponding semantics as applicable. Error handling policy for SIP response codes is configured in the SBC. The SBC increments the 4XX statistics for SIP errors and logs the STI Service Type, STI Service Status, STI Reason Code and Origination ID in CDR fields.
When STI-AS/VS server is performing STIR/SHAKEN-related procedures in the context of relevant semantics, certain error conditions are encountered. These conditions are detected and reported by the server.
The SBC supports the following error conditions:
The SBC supports the following error conditions:
The PSX maps the error indication to a response code and reason text and communicates to the SBC in D+ response.
Handling of errors for STI-AS/VS procedures
The SBC treats the STIR-related SIP response codes as follows:
The SBC may also receive the response code if it uses a compact form of Identity header and the downstream entity performing verification expects the full form. Therefore, the request should be resent with full form Identity header.
In this phase, The SBC supports only the “SHAKEN” claim set for which the full form is mandated. The SBC always sends the Identity header in full form; therefore, this error response is not applicable. The SBC relays 438 error response to upstream entity.
If the SBC receives Identity header in compact form and full form is required, it generates 438 SIP error response to check if it requires the full form for a received identity header. STI-AS/VS determines its enforcement and the SBC generate 438 error response based on the verification result received from STI-AS/VS.
For each error response, either a “retry without Identity”, “fail the call”, “try next route” is configured, if applicable. The SBCapplies this configured behavior for 438 only after the special behavior of retry with full Identity header if available is executed, once the functionality for using compact form is supported (Deferred). SIP error response treatment policy is present in the SBC.
The proliferation of identity spoofing (potentially combined with robocalling) often leads to unsuspecting consumers falling victim to scams, such as IRS impersonation, offers of free travel, loan support and software technical support. Identity spoofing and robocalls also devalue the real-time communications process and annoy customers. Well-intentioned, but spoofing techniques easily thwart flawed "blacklists" for anti-robocalling tools and applications. The SBC provides the solution based on industry-standards for securing VoIP call identity.
For more information on PSX STIR/SHAKEN, refer to STIR/SHAKEN Functionality.