[VoiceOps] STIR/SHAKEN Discussion: Will it help?
Alex Balashov
abalashov at evaristesys.com
Tue Dec 17 16:17:29 EST 2019
I knew Gavin Belson was behind this.
—
Sent from mobile, with due apologies for brevity and errors.
> On Dec 17, 2019, at 4:07 PM, Paul Timmins <paul at timmins.net> wrote:
>
>
> I see it as stopping fraud the same way SPF and DKIM stopped 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> 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> On Behalf Of Peter Beckman
>>> Sent: Tuesday, December 17, 2019 2:58 PM
>>> To: VoiceOps <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 http://www.angryox.com/
>>> ---------------------------------------------------------------------------
>>> _______________________________________________
>>> VoiceOps mailing list
>>> 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
>>
>>
>> _______________________________________________
>> VoiceOps mailing list
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20191217/8bec3a25/attachment.htm>
More information about the VoiceOps
mailing list