Out-of-Band SHAKEN

Out-of-Band SHAKEN extends the current SHAKEN framework to include service providers using TDM. This enables widespread participation in the SHAKEN ecosystem, which makes it much more effective for everyone.

Out-of-Band SHAKEN places no new requirements on service providers using the current SHAKEN framework with only SIP networks and interconnections.

Out-of-Band SHAKEN is a new specification. It is significantly better than previous versions known as Out-of-Band STIR. Unlike previous versions, Out-of-Band SHAKEN:

• Is much simpler to implement and use
• Is more secure
• Facilitates traceback and accountability
• Places no burdens whatsoever on service providers that only use SIP networks and interconnections.

In this whitepaper, we will summarize the new specification and explain how it delivers these benefits.

The Out-of-Band SHAKEN specification was developed by the ATIS PTSC (Packet Technologies and Systems Committee). TransNexus is a member of this committee and participated in developing the Out-of-Band SHAKEN specification ATIS-1000096.

SHAKEN call authentication goals

SHAKEN enables an originating voice service provider to show that the caller is authorized to use the calling telephone number. This information can be verified by the terminating service provider and presented to the called person. This reassures the called person that the calling number wasn’t spoofed—a common tactic used with illegal scam robocalls.

In the current SHAKEN framework, call authentication information is added to SIP signaling by the originating service provider and retrieved from the SIP signaling by the terminating service provider.

SHAKEN reference architecture

In the reference architecture above, a SHAKEN PASSporT is generated by the Authentication Service (STI-AS) and added to SIP signaling. It stays with the call across the call path (step 7). It is used by the terminating provider’s Verification Service (STI-VS) and possibly by Call Validation Treatment (CVT).

In today’s telephone network, many calls are routed over call paths that are not SIP from end to end. The SHAKEN reference architecture described above will not work for such calls. This causes the following problems:

• Some service providers do not have SIP network capabilities and cannot participate in SHAKEN.
• Many service providers have SIP network capabilities but rely on TDM interconnections that they do not own or control.
• Even service providers that have SIP networks and interconnections may find that their calls cross a non-SIP segment along the downstream call path. Their SHAKEN investment and effort is wasted for such calls, and there is nothing they can do about it.
• All of these circumstances represent a failure to achieve SHAKEN goals.

Out-of-Band SHAKEN benefits

Out-of-Band SHAKEN provides a way to send SHAKEN information around non-SIP segments of the call path. This provides the following benefits:

• SHAKEN call authentication becomes much more widespread. The more SHAKEN is used, the more effective it becomes.
• Out-of-Band SHAKEN deployment is fair. Only those providers that need it would deploy it.
  • Service providers sending or receiving calls across a non-SIP call segment would deploy Out-of-Band SHAKEN.
  • Those with all-SIP networks and interconnects would continue to use SHAKEN as-is.
• SHAKEN participation would not place an undue burden on service providers.
  • The telephone network can continue to evolve to an all-IP network at a pace that service providers can manage.

Out-of-Band SHAKEN elements

Out-of-Band SHAKEN is a small addition to the SHAKEN reference architecture described above. Out-of-Band SHAKEN cannot work without the standard SHAKEN framework.

Out-of-Band SHAKEN uses the following elements.

STI-CPS (Call Placement Service)

The STI-CPS is service that can receive a PASSporT from a service provider for retrieval by another service provider.

The STI-CPS can exist anywhere. Typically, it will be outside of the service provider’s network. For example, an STI-CPS could be provisioned by an STI Certificate Authority (STI-CA). (TransNexus is an STI-CA, and we also provide an STI-CPS free of charge that can be used by any SHAKEN-authorized service provider.)

An STI-CPS is part of a network of STI-CPSs that immediately replicate new PASSporTs with each other. This enables service providers to interact with any STI-CPS.

Alternatively, a service provider could set up a private STI-CPS for use exclusively within their network. A service provider with a large heterogeneous network might want to do this to move SHAKEN PASSporTs around non-IP portions of their network. A private STI-CPS would use the same techniques described in the standards. The only difference is that a private STI-CPS would not exchange PASSporTs with the STI-CPS network used by other SHAKEN-authorized service providers to exchange PASSporTs with each other.

STI-OOBS (Out-of-Band Service)

The STI-OOBS publishes PASSporTs to an STI-CPS and retrieves PASSporTs from an STI-CPS. It can also periodically check the health of the STI-CPS.

An STI-OOBS is deployed within a service provider‘s network. It‘s an essential element in Out-of-Band SHAKEN. It is typically incorporated into the STI-AS/STI-VS.

STI-IWF (InterWorking Function)

The STI-IWF is an optional component. It is a TDM-to-SIP gateway. The STI-IWF translates TDM signaling to SIP signaling and vice versa so the TDM switch can communicate with the STI-OOBS, STI-AS and STI-VS.

Out-of-Band SHAKEN interactions

The following figures illustrate the interaction of these Out-of-Band SHAKEN elements. In these illustrations, the SHAKEN System and Network Element are simplified depictions of the SHAKEN reference architecture described above.

The Network Element is typically a Session Border Controller (SBC) or softswitch that serves as the integration point with the SHAKEN System. Using Out-of-Band SHAKEN, the Network Element could also be a TDM switch.

The green boxes are the new Out-of-Band SHAKEN elements described above.

Network element supports both SIP and TDM

If the Network Element supports both SIP and TDM signaling, then it can communicate directly with the SHAKEN System and the STI-OOBS. The STI-IWF is not used. For example, some service providers have SIP-enabled networks but must send and receive calls using TDM interconnections. Depending on their network capabilities, they might not need an STI-IWF.

Network element supports TDM only

However, if the Network Element only supports TDM signaling, then the STI-IWF is used to translate between TDM and SIP signaling to enable communication with the SHAKEN System and the STI-OOBS. This would be the case if the service provider’s Network Element is a TDM switch.

Use cases

Out-of-Band SHAKEN is used when a service provider wants to use STIR/SHAKEN for a call sent or received across a non-SIP network segment.

For example, Out-of-Band SHAKEN would be used in the following situations:

1. A service provider originating a call using TDM signaling would generate the applicable PASSporTs using their STI-AS and publish them to an STI-CPS.
2. An Intermediate Service Provider converting a call from SIP to TDM would publish all PASSporTs received in SIP signaling for that call to an STI-CPS.
3. An Intermediate Service Provider converting a call from TDM to SIP would retrieve all PASSporTs for that call from an STI-CPS and insert them into the SIP signaling for that call.
4. A service provider terminating a call using TDM signaling would retrieve all PASSporTs for that call from an STI-CPS and verify the call using their STI-VS.

Notice that service providers originating, transiting, or terminating calls using only SIP signaling would not use Out-of-Band SHAKEN. Instead, they would use PASSporTs in SIP signaling.

Intermediate providers transiting calls with TDM signaling only would not use Out-of-Band SHAKEN. An upstream provider would have already published PASSporTs for those calls to an STI-CPS. There would be no need for an all-TDM intermediate provider to do anything.

The Out-of-Band SHAKEN specifications describe nine call scenario examples using combinations of the four use case situations described above. We have listed these scenarios in an appendix to this whitepaper.

CPS functionality details

The following sections describe the functionality of the STI-CPS in more detail.

The STI-CPS provides three API endpoints:

1. Health check
2. Publish
3. Retrieve

Health check

The health check API endpoint is accessible by an HTTP GET. It is used by service provider STI-OOBSs and other STI-CPSs to check that this STI-CPS is up and running. It returns a standard HTTP 200 status if it can publish and retrieve. It returns standard HTTP error response codes if it is not healthy.

Publish

The publish API endpoint is accessible by an HTTP POST. It is used to publish PASSporTs to the STI-CPS. The publish request includes the following:

• Calling and called number
• Authorization header with a bearer token signed by a valid, unrevoked STI certificate
• String array of PASSporTs
• Datetime stamp
• Service provider code of the service provider making the request
• Fully qualified domain name of the STI-CPS
• Action keyword that describes the action to be performed, e.g., “publish” or “republish”
• A Universally Unique Identifier (UUID)

The STI-CPS will respond to publish requests with an HTTP 201 response if successful or a standard HTTP error response code if not published.

Notice that the publish request must be signed with an STI certificate. This means that only authorized service providers can use the STI-CPS network. This is a powerful new feature for improved security and privacy.

Retrieve

The retrieve API endpoint is accessible by an HTTP GET. It is used to retrieve PASSporTs from the STI-CPS.

The retrieve request is identical to the publish request, except the action keyword is “retrieve.” It also must contain a signed authorization header, so only authorized service providers can use it.

A successful response returns an HTTP 200 response. A successful response also includes the following:

• A string array of tokens. Tokens are JSON Web Tokens used by the service provider to publish the PASSporTs.
• A string array of PASSporTs. These would be used by the terminating provider in their STI-VS. An intermediate provider could insert the PASSporTs into SIP signaling per the SHAKEN standards.

Notice that the tokens used to publish the PASSporTs could be logged by the service provider retrieving the PASSporTs for the purpose of traceback. This is a powerful new feature for improved accountability.

If a retrieve is unsuccessful, the STI-CPS will return a standard HTTP response error code.

Compatibility with new and emerging SHAKEN capabilities

Out-of-Band SHAKEN supports many new and emerging SHAKEN capabilities:

• All PASSporT types are supported, including SHAKEN, base, RCD, and DIV.
• Delegate certificates can be used.
• Cross-border SHAKEN is supported. An international boundary would be treated the same as a SIP/TDM boundary.
• Centralized SHAKEN is supported.

TransNexus solutions

• We offer STIR/SHAKEN and robocall mitigation solutions in our ClearIP and NexOSS software platforms.
  • These platforms fully support Out-of-Band SHAKEN.
• We provide SHAKEN certificates to SHAKEN-authorized service providers.
• We host an STI-CPS (Call Placement Service) for Out-of-Band SHAKEN.
  • It is completely free and can be used by any SHAKEN-authorized service provider in the U.S. or Canada.
• We can help with all aspects of STIR/SHAKEN deployment, including registering with the Policy Administrator and filing your Robocall Mitigation certification with regulators.

Contact us today to learn more.

Appendix — Call scenario examples

To illustrate how Out-of-Band SHAKEN would be used, we have constructed a hypothetical call path with five service providers: the originating service provider, the terminating service provider, and three transit providers.

The following nine call scenarios show how Out-of-Band SHAKEN would be used assuming various combinations of TDM and SIP networks along the call path. These examples illustrate the principles described in the use cases explained above.

1. Transit Provider Publish — Transit Provider Retrieve

In this scenario, four of the providers use SIP; only Transit Provider C uses TDM.

• Transit Provider B converts the call from SIP to TDM and publishes the PASSporT to an STI-CPS.
• Transit Provider D converts the call from TDM to SIP, retrieves the PASSporT from an STI-CPS and puts it in the SIP signaling.

Notice that neither the OSP nor the TSP used Out-of-Band SHAKEN. They get the benefits of Out-of-Band SHAKEN but don‘t have to add it to their systems.

Back to examples

2. Transit Provider Publish — VoIP Service Provider Retrieve

In this scenario, Transit Providers C and D both use TDM, and the other providers use SIP.

• Transit Provider B converts the call from SIP to TDM and publishes the PASSporT to an STI-CPS.
• Terminating Provider E converts the call from TDM to SIP, retrieves the PASSporT from an STI-CPS and uses it to verify the call with their STI-VS.

Back to examples

3. Transit Provider Publish — TDM Switch Retrieve

In this scenario, the first two providers use SIP, while the remaining downstream providers all use TDM.

• Transit Provider B converts the call from SIP to TDM and publishes the PASSporT to an STI-CPS.
• Terminating Provider E retrieves the PASSporT from an STI-CPS and uses it to verify the call with their STI-VS.

Back to examples

4. VoIP Service Provider Publish — Transit Provider Retrieve

In this scenario, Transit Providers B and C use TDM; all other providers use SIP.

• Originating Provider A performs authentication, publishes the PASSporT to an STI-CPS and converts the call to TDM.
• Transit Provider D converts the call from TDM to SIP, retrieves the PASSporT from an STI-CPS and puts it in the SIP signaling.

Back to examples

5. VoIP Service Provider Publish — VoIP Service Provider Retrieve

In this scenario, only the OSP and TSP use SIP. All transit providers use TDM.

• Originating Provider A performs authentication, publishes the PASSporT to an STI-CPS and converts the call to TDM.
• Terminating Provider E converts the call from TDM to SIP, retrieves the PASSporT from an STI-CPS and uses it to verify the call with their STI-VS.

Back to examples

6. VoIP Service Provider Publish — TDM Switch Retrieve

In this scenario, only the OSP uses SIP; the others use TDM.

• Originating Provider A performs authentication, publishes the PASSporT to an STI-CPS and converts the call to TDM.
• Terminating Provider E retrieves the PASSporT from an STI-CPS and uses it to verify the call with their STI-VS.

Back to examples

7. TDM Switch Publish — Transit Provider Retrieve

In this scenario, the first three providers use TDM, while the last two use SIP.

• Originating Provider A performs authentication and publishes the PASSporT to an STI-CPS.
• Transit Provider D converts the call from TDM to SIP, retrieves the PASSporT from an STI-CPS and puts it in the SIP signaling.

Back to examples

8. TDM Switch Publish — VoIP Service Provider Retrieve

In this scenario, only the Terminating Provider E uses SIP; all others use TDM.

• Originating Provider A performs authentication and publishes the PASSporT to an STI-CPS.
• Terminating Provider E converts the call from TDM to SIP, retrieves the PASSporT from an STI-CPS and uses it to verify the call with their STI-VS.

Back to examples

9. TDM Switch Publish — TDM Switch Retrieve

In this scenario, all providers use TDM.

• Originating Provider A performs authentication and publishes the PASSporT to an STI-CPS.
• Terminating Provider E retrieves the PASSporT from an STI-CPS and uses it to verify the call with their STI-VS.

Back to examples