STI-AS Attestation Policy Options

Introduction

NSS uses SBC (originating switch/IP), OTG (originating trunk group), and ANI as the elements that determine the attestation level of a call.  These rules are defined within the Policies tab under STI-AS > Policies (formerly Authorized ANI).

SBC is the originating device. This can be a single IP address or many IPs to represent a group of SBC. If your SBC is a VSXi NSS' SBC IP corresponds to the VSXi STI-AS Service Port.

OTG is the originating trunk group. STI-AS queries from the VSXi carry the otg parameter as illustrated. For non VSXi systems, NSS' SIP Message Conversion engine can take a different parameter or SIP header value and use OTG as a key to determining attestation.

ANI is the originating phone number in the P-Asserted-Identity, Remote-Party-ID, From, P-Chare-Info, or JIP header.

Guidelines

Before we expand on the use cases it is worth describing the guidelines defined in ATIS-100008.

From ATIS 1000088 document

The SHAKEN Identity header does not convey a customer identity or end-user identity other than calling TN which may or may not uniquely identify the customer or end-user, nor does it convey authentication credentials for the customer entity that originated the call into the VoIP-based SP network. Instead, it contains an “attestation indicator” (the “attest” claim) which encodes the extent to which the originating SP has itself identified and authenticated its customer and determined the customer’s “association” to the calling party telephone number. The initial set of attestation values are “A,” “B,” or “C” defined as follows (as excerpted from ATIS-1000074-E [Ref 1], Clause 5.2.3):

A. Full Attestation: The signing provider shall satisfy all of the following conditions:

• Is responsible for the origination of the call onto the IP-based service provider voice network.
• Has a direct authenticated relationship with the customer and can identify the customer.
• Has established a verified association with the telephone number used for the call.

B. Partial Attestation: The signing provider shall satisfy all of the following conditions:

• Is responsible for the origination of the call onto the IP-based service provider voice network.
• Has a direct authenticated relationship with the customer and can identify the customer.
• Has NOT established a verified association with the telephone number being used for the call.

C. Gateway Attestation: The signing provider shall satisfy all of the following conditions:

• Has no relationship with the initiator of the call (e.g., international gateways).

A / Full Attestation comes a higher level of trust. It informs the terminating service provider that the received caller ID can be fully trusted. It is in the case of A-level attestation where your call (where implemented) may receive a green check-mark, [V], or verified tag in the caller ID. That said, you are responsible to adhere to the guidelines to conform with the STIR/SHAKEN ecosystem.

Use Cases

The three elements (SBC, OTG, TN) can be used separately or in conjunction to match the flexibility of your network. The order of precedence is as follows:

1. Specific switch
2. Specific OTG
3. Specific TN.

These are some examples:

• Know your customer.  In this case, you decide to Attest A all calls based on the originating trunk group (OTG). This is based on the nature of traffic sourced from your customer's trunk group (e.g. requires SIP registration against the ANI and ANI can not be spoofed). 
• Know your customer hybrid. In this example, you can add policies for certain telephone numbers (ANI) and a specific OTG for A level attestation in addition to a more general rule that will attest B calls that do not match the specific list of ANIs.

• Trusted SBC. In some cases, a trusted SBC or switch may carry traffic that controls the customer's source and identity. This could be a call feature server (CFS) or class 5 system.
• Trusted numbers. You can use the ANI criteria to upload number blocks/DIDs you own and assign the appropriate attestation level that will match the right-to-use number. This could be Attest A (i.e. it is your customer and they have the right to use that number).
• International gateway. This is a good example of how to use OTG to simplify your attestation policies. In this case, just specify the OTG (or if you have an SBC dedicated for international gateways even simpler) and attest C.

Notes:

• 'any' is a valid wildcard when there's no specific, SBC, OTG, or ANI to match.
• Partial ANI matching (e.g. 85875422 will cover 8587542200 through 2299) is supported in addition to full digit match (8587542200). The most specific ANI will win.
• Be careful when using specific SBC, OTG, and ANI. At present the criteria is done in that order (SBC, OTG and then ANI).

When/How to use "Ignore"?

STIR/SHAKEN is all about enhancing the trust in the originating caller ID.  Ignore is an action that enables to block traffic before it leaves your network. This action is to be used in conjunction with Sansay's VSXi. Here are some uses cases where this may be applicable:

• Block invalid A-number.

• Block known recurring and known bad acting phone numbers.

• Block numbers part of a blacklist, see example below:

Updating NSS Policy table

It is normal operations for your list of customers and DIDs to change over time. NSS bulk update/delete/replace via our UI and API are designed to support number changes.

Our NSS Management API guide describes in detail with examples what operations can be performed via API: https://support.sansay.com/t/y4hls8d/nss-management-via-rest-api#examples