STIR/SHAKEN implementation and issues

STIR/SHAKEN implementation and issues

Using Netaxis Session Routing Engine for a STIR/SHAKEN implementation

Robocalls are a major issue in the United States of America. In 2018 the Federal Communications Commission (FCC) received 232,000 complaints concerning them. The issue has manifested itself with almost 15,000 victims suffering $72 million of known IRS fraud since 2013. The real number is likely to be a lot higher. Robocalls have also been used to generate Telephony Denial of Service attacks on emergency services making them clearly a high profile issue. In an attempt to stop the robocall nuisance the FCC is forcing telephony providers to implement technologies that clamp down on them. The tech chosen is STIR/SHAKEN and this is now being rolled out in the USA. This post discusses STIR/SHAKEN implementation and issues.

What exactly is STIR/SHAKEN? 

STIR/SHAKEN is a combination of IETF RFC protocols developed to authenticate Caller ID and address unlawful spoofing.  STIR/SHAKEN confirms that a call actually comes from the number indicated in the Caller ID, or at least that the call entered the US network through a particular voice service provider or gateway.

Essentially STIR/SHAKEN is a framework to provide assurance that certain information about the Caller ID transmitted with a particular call is accurate. STIR/SHAKEN makes extensive use of public/private keys to sign & verify  provided CLI information.

What does STIR/SHAKEN stand for?

STIR: Secure Telephony Identity Revisited  works by adding a digital certificate to the SIP information used to initiate and route VoIP calls. The originating VoIP service provider examines the caller ID and compares it to a known list of IDs they provide to that customer. An encrypted certificate is then attached to the SIP header with the service provider’s identity and a trust value. VoIP software at the far end checks the authenticity of the message by decrypting STIR using the originating provider’s public key.

SHAKEN: Signature-based Handling of Asserted information using toKENs (SHAKEN) is used for non VoIP calls where SS7 is used and where there is no SIP header. SHAKEN provides a suite of guidelines for PSTN indicating how to deal with calls that have incorrect or missing STIR information. Full details have not yet been finalized for SHAKEN.

How does STIR/SHAKEN work?

The diagram below shows the high level functionality of a STIR/SHAKEN system. Fundamentally it involves a Certificate Authority that provides the Verification Service with certificates and an Authentication Service providing partial or full attestation. Full attestation is only provided where the system is 100% sure who owns an originating CLI number.

how STIR?SHAKEN works

What does Netaxis offer in respect of STIR/SHAKEN implementation?

The Netaxis SRE is a modern API driven highly flexible Session Routing Engine that is ideal for use in networks needing to support STIR/SHAKEN implementation. GUI driven it is easy to set up and manage.

SRE acts as the interface between the customer/caller and the various elements required in a STIR/SHAKEN call: blacklist, whitelist, blocking settings and call barring service. Barring programmes provide a first filter with additional services coming via the blacklisting/whitelisting. SRE talks to Authentication and Validation Services via REST APIs and works easily with any Application Server.

Is  STIR/SHAKEN implementation nailed down or are there issues?

Good question. In the first instance the initiative for STIR/SHAKEN whilst IETF generated has come from the desire in the USA to legislate to clamp down on nuisance calls. This is laudable but does unearth challenges both technical and, if I can put it this way, geopolitical.

What if the originating party (ie the one best placed to do the call screening) did not attach any attestation  ie the certification? In this case a node further along the network would have to do it. How practical is that and what value could you attach to such an attestation?

Also what if the other party is not STIR/Shaken compliant? E.g. a PSTN network not running on SIP? How about calls coming from international destinations not subject to US law. What do you do with them? Do you label them all as valid or invalid?

The establishment of a certification vehicle in the USA to provide certificate services is certainly doable/is being done. This costs money but politically this is ok as worth it in order to stop the nuisance. What happens to calls coming from Europe (or the rest of the world). Who provides the certification here where there is no legal driver to do so. As an European based organisation Netaxis is not seeing any movement towards the adoption of STIR/SHAKEN, certainly not amongst out telco customers many of who are the Tier 1 operators likely to carry traffic to the USA. 

STIR/SHAKEN is still being discussed/considered outside the USA and now is a good time to involve Netaxis in your plans. If you want to chat about this please feel free to get in touch via our contact form and someone will be right back to you. For more articles on SRE check out the SRE blog posts.

PS Apologies if the phrase STIR/SHAKEN is somewhat repetitive in this post. Didn’t really see a way around it on this occasion (TD).