We’ve spent the last several years figuring out how to implement STIR/SHAKEN on IP networks, all while knowing that there was no agreement in place for how to do the same thing on TDM networks… a rather significant flaw in the plan.
The FCC’s position on this problem has been that
- service providers could have an extension to the deadline while they figured this out
- everyone needed to work together to agree on some industry standards for how STIR/SHAKEN over TDM could be implemented
- once there was both a standard and a commercially available implementation they would set a deadline for implementation.
On July 15 the ATIS Non-IP Call Authentication Task Force published two new standards and a technical report intended to address the second bullet. This is a stepping-stone towards a concrete plan – there are no actions required for you at this stage.
There’s a ton of information in these documents, but I will do my best to share the most important information as clearly as possible. Nevertheless, I’m going to split this up into (at least) two articles.
Extending STIR/SHAKEN over TDM – authentication using existing TDM interconnects
In this article I’ll look at ATIS-1000095, Extending STIR/SHAKEN over TDM, which is one of the two mechanisms they considered for providing caller ID authentication in non-IP networks. The other (SHAKEN Out-of-Band PASSporT Transmission Involving TDM networks) is coming in a future article.
Architecture – the big picture
At a high-level, the idea is that the originating service provider (SP) will define the attestation level for the call (typically Attestation A, meaning they can verify the caller ID), and then this attestation level is passed from one SP to the next over a trusted network of interconnects – whether SIP or TDM.
- On a SIP interconnect, standard STIR/SHAKEN can be used.
- On a TDM interconnect, the two SPs will agree a methodology for signaling the attestation level, and will agree that they trust each other.
In this way, the attestation level is passed from end-to-end over the PSTN, and since each SP trusts the previous SP in the chain, the terminating SP (and hence the called party) can trust the caller ID.
But you just skipped over the part where you signal STIR/SHAKEN over a TDM leg… That’s not possible!
Well… kinda. You see, this standard does not actually require that the full SHAKEN PASSporT (the Identity header with the certificate and all that) is sent over the TDM interconnect – just that the attestation level (A,B,C or none) is signaled.
It’s like this:
- With STIR/SHAKEN over SIP, I’d say to you,
“Hey! I’ve got this letter I’d like you to mail, but I put it in a special envelope, and if you try to open it, or change the sender’s address, or try any funny business, the envelope will turn purple and the word “CHEAT!” will appear below the address. Also I put a sworn affidavit in the envelope staking my reputation that the sender’s address is accurate. So be on your best behavior!” - With STIR/SHAKEN over TDM, I’d say to you,
“Hey! I’ve got this letter I’d like you to mail. I promise the sender’s address is accurate. You trust me, right?”
Of course, in reality the call will likely traverse many service providers before reaching its destination, so the conversation (for a TDM leg) goes more like this:
“Hey! I’ve got this letter I’d like you to mail. Some guy told me that some guy told him that some gal told him that the sender’s address was legit. I’m not going to tell you the names of any of the other guys and gals, but you can totally trust the sender’s address.”
Fundamentally, the idea is that the same idea of trust that the PSTN has assumed for decades. If we each trust each of the SPs that we are interconnected with, then the network as a whole is trustworthy – so all we need to do is pass the Attestation information along each leg.
You still didn’t say how the attestation level is signaled over TDM!
Ah, yes, good point. The standard suggests two mechanisms:
- The two SPs agree to use a particular ISUP parameter (e.g. ISUP Screening Indicator) to signal the Attestation Level.
- The two SPs set up multiple TGs with different meanings – e.g. TG #1 means Attestation A, TG #2 means Attestation B and TG #3 means no attestation available.
One good thing about this peer-to-peer architecture is that you don’t need to use the same method end-to-end. One leg can use SIP, one leg can use the ISUP parameter, the next can use different trunk groups… as long as the two interconnected parties agree, the attestation level can make it all the way to the called party.
(Note: the standard assumes that CDRs at each SP would contain enough information to allow a bad call to be traced back all the way to the originating SP.)
STIR/SHAKEN over TDM – is it viable?
At first glance, I have a LOT of concerns. For example:
- Are we really expecting upgrades to a bunch of old TDM switches in order to support changes to how we use ISUP parameters? That doesn’t seem plausible to me.
- If there was genuine end-to-end trust on the PSTN then we wouldn’t need STIR/SHAKEN in the first place, so an architecture that relies on transitive trust between service providers seems a little naïve.
- Given how hard it has been to implement STIR/SHAKEN on SIP connections, a new architecture that requires some kind of technical renegotiation of every TDM interconnect agreement in the PSTN seems an overwhelming mountain to climb.
But maybe I’m being too hasty. The above concerns are very reasonable if we view the PSTN is a huge jumble of randomly SIP/TDM interconnections between hundreds of different carriers.
But what if the problem only really lies at the edge? What if long distance interconnect is already overwhelmingly SIP, and hence already overwhelmingly handled by STIR/SHAKEN. (I don’t generally get involved in the “core” of the PSTN network, so I don’t know this for sure – but there are strong economic incentives for LD interconnect to be all over IP, so I assume that this is largely true already, and becoming even more true with each passing year.)
If we only need STIR/SHAKEN over TDM at the edge, then what would be required to implement it?
Let’s first think about it from the point-of-view of a small ILEC and what they would need to change.
- If a TDM-only SP wants to set Attestation A on all their calls (which is not unreasonable for a small ILEC where all DNs are assigned by the ILEC) then the SP would simply need to tell all of their interconnected SPs to assume Attestation A on all their trunks. No upgrades. Just a configuration change at the tandem to set Attestation A for all calls from that trunk.
- If an originating SP wants to be able to distinguish between Attestation A and B then I would set up two trunk groups or even use steering digits (rather than messing around with ISUP parameters) to signal the attestation to the next hop switch. You could use some kind of LCR engine or routing based on source-DN (file-based NV for Metaswitch users) to assign the trunk group.
What about those TDM-SIP gateways that are on the receiving end of this traffic?
- They should already have implemented STIR/SHAKEN and will presumably have software available that handles this for SIP.
- They’ll need to make configuration changes to assign calls from these TDM trunks to get the appropriate attestation levels, but that should be manageable through a combination of switch translations and STIR/SHAKEN software configuration.
What’s the bottom line?
Is this possible? Yes. If you have competent and motivated parties on both end of the trunk, it actually doesn’t sound too hard.
Do I have concerns? Absolutely. My biggest concern is that the major carriers and tandem operators (AT&T: I’m looking at you) won’t have the processes in place to allow small ILECs and CLECs to interoperate with them in this new way. If this path is chosen, the FCC is going to have to think about how to administer this change in such a way as to force the Tier 1 providers to play ball.
But remember! This isn’t the only option. ATIS also provided a standard for Out-of-Band authentication – another approach to this same problem – which I’ll be reviewing in my next article. Be sure to subscribe to our newsletter (if you haven’t already) so you receive that article when it’s published.
