[VoiceOps] STIR/SHAKEN warning!

[Nathan Anderson]

I suspect things might be different now (& I just haven't kept up), but
although it is clearly *possible* to transmit a TFN as the calling number /
CID, I seem to remember that even just a mere few years ago, it was HIGHLY
discouraged, and if you ever were to receive a call bearing a TFN as its CID,
it had a very high likelihood of being fraudulent or spam.  This was of course
back when the vast, vast majority of TFNs were essentially implemented as a
call forward or alias to a number that hung off of a local exchange.  So of
course outbound calls that many? most? companies with TFNs would make would
typically be sourced from their local exchange number(s) and not from the TFN
(s) (unless maybe a given company had a PRI and their provider allowed them to
source calls from their TFN?).

 

Loosely tangentially related, as a purely anecdotal report, I will note that I
have yet to see a S/S signature/PASSporT attached to ANY calls made *to* ANY of
our TFNs, via any of the 3 SIP wholesalers we have used as both RespOrgs and
for actual traffic.

 

-- Nathan

 

From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of David
Frankel via VoiceOps
Sent: Friday, July 7, 2023 7:52 AM
To: 'Ivan Kovacevic'; 'Voice Ops'
Subject: Re: [VoiceOps] STIR/SHAKEN warning!

 

Ivan asks: “How are you handling TFN atestations?”

 

When the signer of a call gives A-level attestation, it means that the signer
knows that the caller “is authorized to use” the calling number.

 

The signer can “know” that in any of a variety of ways. For toll-free numbers,
the most sophisticated and secure is probably via Delegate Certificates. SOMOS,
the North American Toll-Free Number Administrator, has commented about this in
a current FCC proceeding: https://www.fcc.gov/ecfs/document/10605623514445/1

 

As the signer, there are other ways you could determine that the caller is
authorized to use the number. For example, you could solicit some documentation
from them (like an invoice from their RespOrg and/or service provider) and you
could call the number and verify that your caller answers. The regulations
(today) do not specify exactly how you “know” so you (as the signer) need to
act in the spirit of the rules.

 

This problem is not unique to toll-free numbers. I might have a geographic
number that I obtain from provider A (and that’s how I get inbound calls to the
number), but I make outbound calls from that number via providers B and C for
redundancy and cost reasons.

 

Bear in mind that providers can set their own rules for what calls they will
accept and what attestations they will assign, and those rules can be more
restrictive than what might be dictated by regulation. For example, a provider
might say “I will only assign A-level attestation to calls that use calling
numbers assigned by me.” That’s their prerogative.  In fact, a provider might
say: “I will only accept calls that use calling numbers assigned by me. Those
calls will get A-level attestation. I will reject all other calls.” There are
no rules (to my knowledge) that prohibit providers from setting these kinds of
rules.

 

From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Ivan Kovacevic via
VoiceOps
Sent: Friday, July 7, 2023 7:27 AM
To: Voice Ops <voiceops at voiceops.org>
Subject: Re: [VoiceOps] STIR/SHAKEN warning!

 

Hopefully on-topic. How are you handling TFN atestations?  

 

Although a part of NANP - it's a different technology at the network level in
terms of chain of authority and routing.

 

RespOrg manages the number, but can provision and use many carriers to make
outbound calls using the TFN Caller ID (and to receive inbound calls via the
same TFN)... RespOrgs is not necessarily a carrier - who and how checks that
RespOrg has the authority in case of delegated attestation. I may be
overcomplicating it in my mind.. but it doesn't feel like the regulation maps
1-to-1 over to TFNs... Just wondering what everyone's experience is. 

 

Thanks,

 

Ivan

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20230707/c6413467/attachment.htm>