STIR/SHAKEN – how do I “tag” calls in my network?
In our last blog entry, we explained how and where to implement STIR/SHAKEN in a carrier network in accordance with FCC requirements.
The long and the short of that discussion was as follows.
- You need to ensure that SIP traffic you exchange with other carriers includes a valid SHAKEN PASSporT, conveying the required information and signed as your guarantee that it can be trusted.
- Traffic that does not leave your network does not need to be signed and verified, but it still needs to have those key information elements. This practice has been given the informal name “tagging”.
- Hence you need to put that information in at the earliest opportunity, but you can leave the cryptographic operations required to sign traffic at the edge of your network, at the point where it heads off to its destination or to your interconnect provider or wherever.
In this article, I’m going to go in more detail into how and where to tag traffic, and why doing so is not only required to satisfy the regulators but also essential for STIR/SHAKEN to deliver its promised trust in caller-ID.
What exactly is tagging?
It’s the information you need to sign the call – as simple as that.
A PASSporT takes key information about the call, packages it up into a standard form, and then attaches a digital signature using your private key so that the ultimate receiving network can be sure that it hasn’t been tampered with in transit. That key information is
- the called number
- the calling number
- the date and time the call was made
- the attestation level you are giving the call – i.e. how much you trust the caller-ID, where “A” or “full” attestation is the best
- the place in your network where the call originated.
The first three of these are already available as part of routine SIP signaling. “Tagging” consists of making sure the last two are present as well. To meet the FCC regulations, this should be added at the point where the call originates in or passes into the SIP-based part of your network.
Standards bodies have defined new SIP headers to contain them: Attestation-Info and Origination-Id respectively. In time, vendors will update their products to support these natively, so they can be inserted into the signaling flows in the right place and pass through intermediate hops in your network to reach the point of signing. As these product updates are released, you can make use of them.
But there are probably ways to get this information into the signaling using capabilities that your network elements already possess. Certainly that is the case for networks built using Metaswitch technology, in particular the Call Feature Server (CFS) and Perimeta SBC, where we have defined a design pattern that our customers can use to fulfill these requirements.
How do I set the value of the tags?
It’s all very well to have clever ways to get the information into the signaling. On the face of it, the harder problem is knowing what to signal in every case.
Actually, if you look at your network in the right way, it doesn’t have to be so hard. Basically, it comes down to this:
- identifying all the different places traffic can originate, and assigning an origination-ID to each
- determining what level of trust you have in the caller-ID of traffic originating in each of those places.
Let’s consider some examples.
- You have an end-office switch with some local subscribers homed on it. That switch is an origination point, and should get its own origination-ID. Those local subscribers all have their numbers assigned by your network equipment, so you can be sure that a call has the correct caller-ID, so calls from those local subscribers can get “A”, or “full”, attestation. That’s true whether they are consumer or business, and whether they are connected over SIP or a legacy TDM protocol: if you assign the number and put it in the signaling, that’s “A” attestation.
- You have a switch that has some customer PBXes, connected over SIP or TDM. For them, calls are originated at the PBXes themselves, so each should get its own origination-ID. Attestation needs more thought, though, and again it depends on what guarantees you can make about the number.
- If the PBX uses only numbers from ranges you own, and the caller-ID is “screened”, so that outgoing calls can only be signaled to be from one of those numbers, you can assign “A” attestation.
- On the other hand, if that PBX can make calls from numbers obtained from other providers, which you can’t verify it has the right to use, you have to assign “B”, or “partial” attestation.
(Of course, everyone, especially a business, wants “A” attestation, so the industry is looking at ways of being able to offer “A” where it’s legitimate. This is called Enterprise Attestation Elevation, and it’s a good topic for another blog post.)
- You have TDM traffic entering your network via media gateways. This again is easy: each separate source of such traffic should get its own origination-ID, and the traffic should be given “C”, or “gateway” attestation.
See the diagram below to illustrate this. The numbers in ovals stand for origination-IDs and the scrolls with letters represent attestation levels.
Having done all that, you then apply the appropriate configuration to your network elements to set up and pass through the tagging information. As I said above, we have well-defined standard ways to do that for Metaswitch-based networks.
Why bother with all this? Can’t I just generate the information from the caller-ID where I sign the call?
I have heard this view advanced. And it certainly looks simpler: why not just use the caller-ID to look up the tag values immediately before signing, rather than putting them in the signaling from the outset?
But you need only to do the following thought experiment to see why that’s a bad idea.
Let’s assume your signing service uses a database that means you just need to give it the calling number and it fills in the origination ID and attestation level. Then consider these two cases.
- A call is made by a subscriber on one of your local switches, from number 123-234-5678. The switch signals 123-234-5678 as the caller-ID. The call passes through your network to your egress SBC, and is sent off for signing. You own this number, and it belongs to one of your switches, so it gets assigned attestation “A” and the origination-ID belonging to the switch, and then the call is signed.
- A call enters your network over a trunk, maybe from another provider or possibly from a PBX, with caller-ID 123-234-5678. The call passes through your network to your egress SBC, and is sent off for signing. You own this number, and it belongs to one of your switches, so it gets assigned attestation “A” and the origination-ID belonging to the switch, and then the call is signed.
Once these calls leave your network, they are indistinguishable. Both are signed with the highest attestation, as if the subscriber had really made the call – in fact, you are guaranteeing that the subscriber made both calls. But one of them is spoofed. This is worse than having no STIR/SHAKEN at all.
This cannot happen if your network tags the call where it starts. Then the second call above would get a “B” or “C” attestation, and an origination-ID that tells you where it came from so you can trace back to the miscreant.
So it’s clear that a simplistic lookup based just on the caller-ID is a big problem. That doesn’t mean there is no place for logic at the point of signing to make intelligent choices of attestation and origination information, and some “originating policy” servers are emerging to do that. Consider the following examples, both far from such a simplistic approach.
- It’s possible that some parts of the network can’t pass through origination-ID and attestation levels explicitly, but can pass other information in the signaling that can reliably be used to determine them.
- Such an originating policy server could also be the place that performs elevation of “B” to “A” for calls made from PBXes, sensibly centralizing the logic to determine whether the number is being legitimately used.
I hope this article has helped with a couple of things.
First, that tagging is essential for the integrity of STIR/SHAKEN, and for restoring trust in the phone call.
And second, that actually doing it in your network is not so daunting as it might seem – it requires some logical analysis of where traffic can come from, and then some appropriate configuration to set it up. For Metaswitch customers, our Professional Services team are expert in this and on hand to help.