<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">I knew Gavin Belson was behind this.<br><br><div dir="ltr">—<div>Sent from mobile, with due apologies for brevity and errors.</div></div><div dir="ltr"><br><blockquote type="cite">On Dec 17, 2019, at 4:07 PM, Paul Timmins <paul@timmins.net> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix"><font size="2" face="Tahoma" color="black"><span style="font-size:10pt;" dir="ltr">I see it
as stopping fraud the same way SPF and DKIM stopped spam.</span></font></div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 12/17/19 3:38 PM, Dovid Bender
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAM3TTh1Oa-rWt+j-dCWAZ+MKWS=AhjstO6aS-6-xxMhox9oaSg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">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.
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Dec 17, 2019 at 3:28
PM <<a href="mailto:mike@astrocompanies.com" moz-do-not-send="true">mike@astrocompanies.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi
Peter,<br>
<br>
Good question. First, if you're using Hooli, you'll have to
migrate to<br>
Pipernet sooner or later. Their middle-out compression
provides much better<br>
call quality so it's worth the effort to migrate.<br>
<br>
But to the issue you raised, the purpose of STIR/SHAKEN is not
to block<br>
robocalls per se, it is to provide an authentication chain so
that you can<br>
determine and contact the originating carrier regardless of
the route the<br>
call took to reach the terminating side. This has been a big
issue; many<br>
VoIP companies hand off calls to large indifferent CLEC or
IXCs who send<br>
them everywhere but won't respond to the terminating carrier's
fraud and<br>
nuisance requests.<br>
<br>
So, now we can see that the call was attested by Hooli, and if
Hooli does<br>
not cooperate with our fraud/nuisance investigations we are
now authorized<br>
to block traffic signed by Hooli. That does fix the problem
to a large<br>
degree.<br>
<br>
However, it's also worthy of note that this is not the main
problem that<br>
needs to be solved. The main problem that needs to be solved
is the case<br>
where you are sending the call to Hooli originating from a
number that is<br>
assigned to our CLEC, which you don't have permission to use.
This does<br>
solve that problem, because Hooli is only going to issue
partial attestation<br>
for that call since it's not their number. So we can still
contact Hooli<br>
about it because they attested it and from that I can find
them, but we or<br>
our subscriber can also block calls with partial attestations
if we/they<br>
choose to.<br>
<br>
Regards,<br>
<br>
Mike<br>
<br>
Mike Ray, MBA, CNE, CTE<br>
Astro Companies, LLC<br>
11523 Palm Brush Trail #401<br>
Lakewood Ranch, FL 34202<br>
DIRECT: call or text 941 600-0207<br>
<a href="http://www.astrocompanies.com" rel="noreferrer" target="_blank" moz-do-not-send="true">http://www.astrocompanies.com</a><br>
<br>
-----Original Message-----<br>
From: VoiceOps <<a href="mailto:voiceops-bounces@voiceops.org" target="_blank" moz-do-not-send="true">voiceops-bounces@voiceops.org</a>>
On Behalf Of Peter Beckman<br>
Sent: Tuesday, December 17, 2019 2:58 PM<br>
To: VoiceOps <<a href="mailto:voiceops@voiceops.org" target="_blank" moz-do-not-send="true">voiceops@voiceops.org</a>><br>
Subject: [VoiceOps] STIR/SHAKEN Discussion: Will it help?<br>
<br>
A few months ago I attended an FCC STIR/SHAKEN discussion in
Washington DC.<br>
They didn't get deep into the technical details but there were
a bunch of<br>
big carrier representatives there.<br>
<br>
If you haven't followed STIR/SHAKEN, it's really just an
additional SIP<br>
header that contains cryptographically-signed information
about the origin<br>
point of the call.<br>
<br>
You can verify the signature with publically published public
keys so you<br>
know whomever signed it is really them.<br>
<br>
Here's a few resources if you want to learn more:<br>
<br>
<a href="https://www.bandwidth.com/glossary/stir-shaken/" rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.bandwidth.com/glossary/stir-shaken/</a><br>
<a href="https://www.fcc.gov/call-authentication" rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.fcc.gov/call-authentication</a><br>
<a href="https://en.wikipedia.org/wiki/STIR/SHAKEN" rel="noreferrer" target="_blank" moz-do-not-send="true">https://en.wikipedia.org/wiki/STIR/SHAKEN</a><br>
<a href="https://www.home.neustar/stir-shaken-resource-hub" rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.home.neustar/stir-shaken-resource-hub</a><br>
<br>
There are three levels to tell you how much you should trust
the origin of<br>
the call:<br>
<br>
1. Full -- The call came from the originating carrier's
customer and is<br>
authorized to use the number<br>
<br>
2. Partial -- The call came from the originating
carrier's customer but<br>
may or may not be authorized to use the number<br>
<br>
3. Gateway -- The carrier has authenticated from where it
received the<br>
call, but cannot authenticate the call source (e.g.,
International<br>
Gateway call).<br>
<br>
As an example, as will be many legit cases, a Verizon Wireless
mobile<br>
customer will place a call, which will route to Verizon, who
will sign the<br>
call using STIR/SHAKEN with Full Attestation and we can all
"trust" the<br>
call.<br>
<br>
But now we throw in VoIP.<br>
<br>
I'm a small customer, Initech, of a larger carrier, Hooli. I
don't sign my<br>
calls, so I hand my calls to my larger carrier, Hooli. Hooli
sees the call<br>
from me (their customer) with a valid CallerID I'm authorized
to use and so<br>
Hooli signs the call with STIR/SHAKEN with Full Attestation.<br>
<br>
Turns out the call was a robocall.<br>
<br>
What changes? The only thing that changes is that the
receiving party, say<br>
Soylent Corp, knows that Hooli originated the call. Soylent is
not Hooli's<br>
customer, so how does Soylent complain to Hooli about the
content of the<br>
call?<br>
<br>
And as carriers, we are not legally responsible for the
content of our<br>
customer's calls.<br>
<br>
How will Soylent accept 90% of Hooli's Fully Attested valid
traffic but<br>
avoid the 10% that is spam/robocalls that are ALSO Fully
Attested?<br>
<br>
How exactly does STIR/SHAKEN help fix the robocall and spam
call problem?<br>
<br>
Yes, I could block all of Hooli's calls where the attestation
is Partial or<br>
Gateway, but you run the risk of false positives, especially
in the<br>
International category, or just when Hooli isn't sure, like
when I rent a<br>
DID from Acme but do termination through Hooli -- Hooli
doesn't know that I<br>
am authorized to use that DID from Acme, even though I am, so
Hooli has to<br>
mark my call as Partial or Gateway.<br>
<br>
I'm all for reducing annoying spam and robocalls, but I'm
still not yet<br>
convinced that STIR/SHAKEN is going to materially reduce them.<br>
<br>
Let's discuss!<br>
<br>
Beckman<br>
---------------------------------------------------------------------------<br>
Peter Beckman
Internet Guy<br>
<a href="mailto:beckman@angryox.com" target="_blank" moz-do-not-send="true">beckman@angryox.com</a>
<a href="http://www.angryox.com/" rel="noreferrer" target="_blank" moz-do-not-send="true">http://www.angryox.com/</a><br>
---------------------------------------------------------------------------<br>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org" target="_blank" moz-do-not-send="true">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank" moz-do-not-send="true">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
<br>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org" target="_blank" moz-do-not-send="true">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank" moz-do-not-send="true">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
VoiceOps mailing list
<a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
</pre>
</blockquote>
<p><br>
</p>
<span>_______________________________________________</span><br><span>VoiceOps mailing list</span><br><span>VoiceOps@voiceops.org</span><br><span>https://puck.nether.net/mailman/listinfo/voiceops</span><br></div></blockquote></body></html>