Out-of-Band SHAKEN revisions

Out-of-Band SHAKEN extends the STIR/SHAKEN framework to enable call authentication information to survive call paths using TDM. There are some interesting revisions to this method under discussion. Let’s have a look.

Out-of-Band SHAKEN review

ATIS-1000096, Out-of-Band PASSporT Transmission Involving TDM Networks, describes a method to publish PASSporTs for a call to an STI Call Placement Service (STI-CPS) as the call is being routed to a TDM segment in the call path.

Figure 1. Out-of-Band Publish to a Mesh Network of STI-CPSs

Figure 1 illustrates the publish method. A provider publishes PASSporTs to an STI-CPS while routing calls over a TDM connection. This prevents the STIR/SHAKEN information from being lost.

The STI-CPS in turn publishes these PASSporTs to every other STI-CPS in the national STIR/SHAKEN ecosystem. This mesh network design ensures that any downstream provider can retrieve PASSporTs from any STI-CPS in the national network.

PASSporTs are published to an STI-CPS using an HTTP POST. The first line in the message identifies the destination (called number) and origin (calling number). Here is an example for a call from +12013776051 to +19032469103:

POST /passports/19032469103/12013776051 HTTP/1.1

PASSporTs are retrieved from an STI-CPS using an HTTP GET. The first line in the message identifies the destination (called number) and origin (calling number):

GET /passports/19032469103/12013776051 HTTP/1.1

PASSporTs are retrieved in two situations:

1. By an intermediate provider who receives the call over TDM and will route it to a downstream provider over SIP. This intermediate provider puts the retrieved PASSporTs into the SIP signaling.
2. By a terminating provider who receives the call over TDM. The terminating provider uses the PASSporTs for STI verification.

For improved security and accountability, publish and retrieve requests sent to an STI-CPS must be digitally signed with a SHAKEN certificate.

Proposed revisions

The main change in the revised method is that STI-CPSs do not republish PASSporTs to each other. There is no mesh network.

Instead, each pair of providers exchanging calls over TDM agrees to exchange PASSporTs over an STI-CPS. The STI-CPS that they agree to use can be provided by a third party or one that either the upstream or downstream provider creates and maintains. The STI-CPS can be either public or private.

Figure 2. Out-of-Band Publish to a Single Agreed Upon STI-CPS

Figure 2 illustrates the revised publish method. It’s similar to the method illustrated in Figure 1, except that PASSporTs are not republished to a mesh network of STI-CPSs.

The publish and retrieve messages are slightly different in the revised method. In addition to the destination and origination phone numbers used in the current method, the first line includes the SPC of the provider that publishes the PASSporTs to the STI-CPS. In this example, the upstream publishing provider put its SPC, 1234, into the first line:

POST /passports/1234/19032469103/12013776051 HTTP/1.1

PASSporTs are retrieved by constructing an HTTP GET with the SPC of the upstream provider and the destination and origination numbers:

GET /passports/1234/19032469103/12013776051 HTTP/1.1

The publish and retrieve scenarios are simple:

1. A provider routing a call to a downstream provider over TDM publishes the PASSporTs to the STI-CPS that they agreed to use with that downstream provider.
2. A provider receiving a call from an upstream provider over TDM retrieves the PASSporTs from the STI-CPS they agreed to use with that upstream provider.

Implications

Why are these revisions under consideration? Because they remove some of the dependencies noted in ATIS-1000097 (Annex A.1):

• Doesn’t require PASSporT replication across an STI-CPS mesh network.
• No longer requires STI-CPS operators to have an STI certificate to publish PASSporTs to other STI-CPSs.
• Doesn’t require an STI-CPS discovery mechanism.
• Each pair of providers is likely to use an STI-CPS located and optimized for fast connectivity.
  • This enables the upstream provider to publish PASSporTs synchronously so they will always be available in the STI-CPS before the downstream provider retrieves them.
  • STI-CPSs can be configured to retain PASSporTs for a shorter duration (they only need to be held long enough for the call to make one more hop).

In addition, the revisions address some concerns noted in comments to the FCC’s inquiry on non-IP call authentication:

• PASSporTs for a provider’s calls are present only on STI-CPSs that they agreed to use, rather than all public STI-CPSs.
• PASSporT retrieval requires knowledge of the calling number, called number, and upstream provider’s SPC.

Standards developers (including TransNexus staff) are discussing these revisions and the next steps. We’ll let you know how this turns out.

TransNexus solutions

TransNexus is a leader in developing innovative software to manage and protect telecommunications networks. The company has over 25 years’ experience in providing telecom software solutions including toll fraud prevention, robocall mitigation and prevention, TDoS prevention, analytics, routing, billing support, STIR/SHAKEN and SHAKEN certificate services.

Contact us today to learn more.