On July 15, the ATIS Non-IP Call Authentication Task Force published two standards that could potentially solve the issue of STIR/SHAKEN in TDM networks.
In our previous article we looked at one of the options – STIR/SHAKEN over TDM – which finds ways to signal attestation information (one small but important part of STIR/SHAKEN) via existing TDM trunk groups.
In this article we’ll review the other alternative, described in ATIS-1000096, SHAKEN Out-of-Band PASSporT Transmission Involving TDM Networks.
What’s the big idea?
This standard describes an approach where all the information contained in a normal STIR/SHAKEN PASSporT is stored in a central database in the cloud – bypassing the limitations of the TDM transport legs of the call.
A simple call flow would look like this.
- Originating service provider invokes the STI Authentication Service (STI-AS) and signs the call, creating a SIP Identity header as normal.
- The call is initially routed over a SIP trunk with the Identity header intact.
- The call is routed over SIP until it arrives at the terminating tandem, which has ISUP trunks to the end-office of the destination subscriber.
- That terminating tandem communicates to a cloud-based Call Placement Service (STI-CPS) and stores the contents of the Identity header (the PASSporT) in the STI-CPS, using the calling and called party numbers to identify the call.
- The call is routed over ISUP to the terminating class 5 switch, without any STIR/SHAKEN information.
- This switch sends a query to the STI-CPS to ask if there is an Identity header for this call.
- The STI-CPS says yes, and provides the Identity header to the terminating switch.
- The terminating switch can then verify the information just like it would for a SIP call (using a STI Verification Service).
Don’t carry cash on a plane
This analogy doesn’t quite work, but it’s a bit like the way a bank stores your money for you.
- I want to go on vacation to Iowa, so I book a plane ticket.
- It’s expensive to visit Iowa, but I don’t want to carry all my money (the Identity header) in cash on the plane, so instead I put it in the bank (the cloud-based Call Placement Service).
- When I get off the plane, I go to the bank (STI-CPS) and ask for my money, which they give me.
So even though the money doesn’t travel on the plane (the Identity header doesn’t pass over a TDM trunk), it’s available at the far-end anyway because it was stored centrally (in the bank / STI-CPS) and can be accessed from anywhere.
Other SHAKEN Out-of-Band scenarios
The ATIS standard gives many different example call topologies – maybe the TDM trunk is in the middle of the call path, or maybe it’s at the beginning, or near the end, or maybe there are several TDM trunks along the way.
Regardless of the details, the key idea is that each time a call is converted from SIP to TDM, you send the Identity header (PASSporT) to the STI-CPS, and then each time a call is converted back from TDM to SIP you retrieve the information and put it back into the SIP INVITE.
How is the correct call identified?
Each call is identified by the combination of calling and called DNs (in a standard 1+10D format), and each call is only saved in the STI-CPS for 15 seconds.
This does potentially present an issue where two calls could be made in quick succession from one DN to another DN, in which case the wrong PASSporT could be inserted into a call, but that’s presumably not going to happen that often.
Is this secure?
Security is provided primarily by limiting access to the central database (STI-CPS) to those service providers who have been approved by the central STI Policy Administrator (iconectiv). So it’s assumed that none of these service providers are going to flood the database with false calls, and if they did, it would be easy to spot and sanction that service provider.
It’s unclear if that assumption is true, but even if it is, hackers have another option. If a hacker could learn about a genuine call that had been established in the last 15 seconds, and then duplicate it (create a new call over a TDM network to the same destination and spoof the caller ID to match the legitimate call) then that dummy call will be given the legitimate PASSporT from the STI-CPS the first time it’s converted from TDM to SIP.
Is there just one STI-CPS that everyone connects to?
The ATIS standard suggests that there would be multiple STI-CPSs, which are all approved by some central governance authority, and all of them replicate all information between themselves. This provides redundancy, and means each service provider would only need to connect to one of the STI-CPSs, but it does create extra complexity in terms of governance and replication of the information.
In particular, you would need to make sure that the call data is shared between the STI-CPSs faster than the calls themselves are routed over TDM trunks – because you need the terminating switch to be able to find the call in any STI-CPS when it’s converting back from TDM to SIP.
What are the pros and cons of this approach?
The big plus with SHAKEN Out-of-Band PASSporT Transmission Involving TDM Networks (we need a shorter name…) is that it maintains all the information from the PASSporT. This is great not only for validating caller ID, but also for future enhancements (like Rich Call Data, which is on the horizon).
It also provides a standard mechanism that must be followed by all TDM-SIP gateways, rather than requiring bilateral agreements for each trunk group (as with STIR over TDM).
However, as with STIR/SHAKEN over TDM, there are also some challenges with SHAKEN Out-of-Band .
- If the end-office switch (either originating or terminating) is TDM only, it’s not clear how that switch would be able to interact with an STI authentication or verification service to create or interpret the Identity headers. Most of the telcos in my audience operate VoIP-capable class 5 switches, so that’s not a huge issue for you, but for anyone with subscribers still on a DMS-100 this presents some difficulties.
- The idea that we’d have multiple STI-CPS databases, which then creates a requirement to replicate all the information throughout the mesh network faster than any call can be transmitted over a TDM trunk is potentially troubling. My guess is that you might need to pause to confirm replication before completing the initial PASSporT publication, but that’s not really defined. Personally I’m not sure why you wouldn’t have a single redundant STI-CPS service operated by the policy administrator (or someone who won a government contract to do it).
- As mentioned above, there are some security issues inherent in this approach.
What happens next?
I really don’t know. Both options presented by ATIS have issues, and would require a huge amount of work and coordination across the industry to implement. Getting STIR/SHAKEN implemented on IP networks was a huge hurdle, and even today surprisingly few calls are actually signed (83% unsigned in July 2021) – is industry adoption of SHAKEN Out-of-Band really going to be any easier?
Right now the FCC has extended the deadline for TDM networks to June 30, 2023, pending development and implementation of these ATIS standards (among other things). It’s hard to imagine that the industry hits that deadline, but is it really acceptable to the FCC to simply extend it indefinitely?
I’ve written about STIR/SHAKEN 19 times these past few years, but unfortunately there’s no end in sight, so probably we’ll still have more to discuss long after the June 2023 deadline has passed. For now, all I can suggest is to stay informed, and hopefully things will become clearer in due course.
