[VoiceOps] STIR/SHAKEN Discussion: Will it help?
Peter Beckman
beckman at angryox.com
Tue Dec 17 17:32:03 EST 2019
On Tue, 17 Dec 2019, Paul Timmins wrote:
> I see it as stopping fraud the same way SPF and DKIM stopped spam.
Yes! Agreed. It makes legit traffic easier to identify, but does nothing
to stop spam.
> On 12/17/19 3:38 PM, Dovid Bender wrote:
>> Mike beat me to it. It's going to stop fraud. The bigger issue you are
>> going to have is the larger packets. So many devices out there can't seem
>> to fragment packets correctly.
>>
>>
>> On Tue, Dec 17, 2019 at 3:28 PM <mike at astrocompanies.com
>> <mailto:mike at astrocompanies.com>> wrote:
>>
>> Hi Peter,
>>
>> Good question. First, if you're using Hooli, you'll have to
>> migrate to
>> Pipernet sooner or later. Their middle-out compression provides
>> much better
>> call quality so it's worth the effort to migrate.
>>
>> But to the issue you raised, the purpose of STIR/SHAKEN is not to
>> block
>> robocalls per se, it is to provide an authentication chain so that
>> you can
>> determine and contact the originating carrier regardless of the
>> route the
>> call took to reach the terminating side. This has been a big
>> issue; many
>> VoIP companies hand off calls to large indifferent CLEC or IXCs
>> who send
>> them everywhere but won't respond to the terminating carrier's
>> fraud and
>> nuisance requests.
>>
>> So, now we can see that the call was attested by Hooli, and if
>> Hooli does
>> not cooperate with our fraud/nuisance investigations we are now
>> authorized
>> to block traffic signed by Hooli. That does fix the problem to a
>> large
>> degree.
>>
>> However, it's also worthy of note that this is not the main
>> problem that
>> needs to be solved. The main problem that needs to be solved is
>> the case
>> where you are sending the call to Hooli originating from a number
>> that is
>> assigned to our CLEC, which you don't have permission to use. This
>> does
>> solve that problem, because Hooli is only going to issue partial
>> attestation
>> for that call since it's not their number. So we can still
>> contact Hooli
>> about it because they attested it and from that I can find them,
>> but we or
>> our subscriber can also block calls with partial attestations if
>> we/they
>> choose to.
>>
>> Regards,
>>
>> Mike
>>
>> Mike Ray, MBA, CNE, CTE
>> Astro Companies, LLC
>> 11523 Palm Brush Trail #401
>> Lakewood Ranch, FL 34202
>> DIRECT: call or text 941 600-0207
>> http://www.astrocompanies.com
>>
>> -----Original Message-----
>> From: VoiceOps <voiceops-bounces at voiceops.org
>> <mailto:voiceops-bounces at voiceops.org>> On Behalf Of Peter Beckman
>> Sent: Tuesday, December 17, 2019 2:58 PM
>> To: VoiceOps <voiceops at voiceops.org <mailto:voiceops at voiceops.org>>
>> Subject: [VoiceOps] STIR/SHAKEN Discussion: Will it help?
>>
>> A few months ago I attended an FCC STIR/SHAKEN discussion in
>> Washington DC.
>> They didn't get deep into the technical details but there were a
>> bunch of
>> big carrier representatives there.
>>
>> If you haven't followed STIR/SHAKEN, it's really just an
>> additional SIP
>> header that contains cryptographically-signed information about
>> the origin
>> point of the call.
>>
>> You can verify the signature with publically published public keys
>> so you
>> know whomever signed it is really them.
>>
>> Here's a few resources if you want to learn more:
>>
>> https://www.bandwidth.com/glossary/stir-shaken/
>> https://www.fcc.gov/call-authentication
>> https://en.wikipedia.org/wiki/STIR/SHAKEN
>> https://www.home.neustar/stir-shaken-resource-hub
>>
>> There are three levels to tell you how much you should trust the
>> origin of
>> the call:
>>
>> 1. Full -- The call came from the originating carrier's
>> customer and is
>> authorized to use the number
>>
>> 2. Partial -- The call came from the originating carrier's
>> customer but
>> may or may not be authorized to use the number
>>
>> 3. Gateway -- The carrier has authenticated from where it
>> received the
>> call, but cannot authenticate the call source (e.g.,
>> International
>> Gateway call).
>>
>> As an example, as will be many legit cases, a Verizon Wireless mobile
>> customer will place a call, which will route to Verizon, who will
>> sign the
>> call using STIR/SHAKEN with Full Attestation and we can all
>> "trust" the
>> call.
>>
>> But now we throw in VoIP.
>>
>> I'm a small customer, Initech, of a larger carrier, Hooli. I don't
>> sign my
>> calls, so I hand my calls to my larger carrier, Hooli. Hooli sees
>> the call
>> from me (their customer) with a valid CallerID I'm authorized to
>> use and so
>> Hooli signs the call with STIR/SHAKEN with Full Attestation.
>>
>> Turns out the call was a robocall.
>>
>> What changes? The only thing that changes is that the receiving
>> party, say
>> Soylent Corp, knows that Hooli originated the call. Soylent is not
>> Hooli's
>> customer, so how does Soylent complain to Hooli about the content
>> of the
>> call?
>>
>> And as carriers, we are not legally responsible for the content of our
>> customer's calls.
>>
>> How will Soylent accept 90% of Hooli's Fully Attested valid
>> traffic but
>> avoid the 10% that is spam/robocalls that are ALSO Fully Attested?
>>
>> How exactly does STIR/SHAKEN help fix the robocall and spam call
>> problem?
>>
>> Yes, I could block all of Hooli's calls where the attestation is
>> Partial or
>> Gateway, but you run the risk of false positives, especially in the
>> International category, or just when Hooli isn't sure, like when I
>> rent a
>> DID from Acme but do termination through Hooli -- Hooli doesn't
>> know that I
>> am authorized to use that DID from Acme, even though I am, so
>> Hooli has to
>> mark my call as Partial or Gateway.
>>
>> I'm all for reducing annoying spam and robocalls, but I'm still
>> not yet
>> convinced that STIR/SHAKEN is going to materially reduce them.
>>
>> Let's discuss!
>>
>> Beckman
>> ---------------------------------------------------------------------------
>> Peter Beckman Internet Guy
>> beckman at angryox.com <mailto:beckman at angryox.com>
>> http://www.angryox.com/
>> ---------------------------------------------------------------------------
>> _______________________________________________
>> VoiceOps mailing list
>> VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org>
>> https://puck.nether.net/mailman/listinfo/voiceops
>>
>> _______________________________________________
>> VoiceOps mailing list
>> VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org>
>> https://puck.nether.net/mailman/listinfo/voiceops
>>
>>
>> _______________________________________________
>> VoiceOps mailing list
>> VoiceOps at voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>
>
>
---------------------------------------------------------------------------
Peter Beckman Internet Guy
beckman at angryox.com http://www.angryox.com/
---------------------------------------------------------------------------
-------------- next part --------------
_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
More information about the VoiceOps
mailing list