<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'>Isn't part of STIR/SHAKEN to make it easier to determine the ingress provider, or the provider of last blame?<br><br><div><span name="x"></span><br><br>-----<br>Mike Hammett<br>Intelligent Computing Solutions<br>http://www.ics-il.com<br><br>Midwest-IX<br>http://www.midwest-ix.com<span name="x"></span><br></div><br><hr id="zwchr"><div style="color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Michael Thomas" <mike@mtcc.com><br><b>To: </b>"Mike Hammett" <nanog@ics-il.net>, "Shane Ronan" <shane@ronan-online.com><br><b>Cc: </b>nanog@nanog.org<br><b>Sent: </b>Tuesday, October 4, 2022 1:18:24 PM<br><b>Subject: </b>Re: FCC chairwoman: Fines alone aren't enough (Robocalls)<br><br>
<p><br>
</p>
<div class="moz-cite-prefix">On 10/4/22 6:07 AM, Mike Hammett wrote:<br>
</div>
<blockquote cite="mid:2084565525.74.1664888871183.JavaMail.mhammett@Thunderfuck2">
<style>p { margin: 0; }</style>
<div style="font-family: arial,helvetica,sans-serif; font-size:
10pt; color: #000000">I think the point the other Mike was
trying to make was that if everyone policed their customers,
this wouldn't be a problem. Since some don't, something else
needed to be tried.<br>
<br>
<div><span></span><br>
</div>
</div>
</blockquote>
<p>Exactly. And that doesn't require an elaborate PKI. Who is
allowed to use what telephone numbers is an administrative issue
for the ingress provider to police. It's the equivalent to gmail
not allowing me to spoof whatever email address I want. The FCC
could have required that ages ago.<br>
</p>
<p><br>
</p>
<p>Mike<br>
</p>
<blockquote cite="mid:2084565525.74.1664888871183.JavaMail.mhammett@Thunderfuck2">
<div style="font-family: arial,helvetica,sans-serif; font-size:
10pt; color: #000000">
<div><br>
-----<br>
Mike Hammett<br>
Intelligent Computing Solutions<br>
<a class="moz-txt-link-freetext" href="http://www.ics-il.com" target="_blank">http://www.ics-il.com</a><br>
<br>
Midwest-IX<br>
<a class="moz-txt-link-freetext" href="http://www.midwest-ix.com" target="_blank">http://www.midwest-ix.com</a><span></span><br>
</div>
<br>
<hr id="zwchr">
<div style="color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From:
</b>"Shane Ronan" <a class="moz-txt-link-rfc2396E" href="mailto:shane@ronan-online.com" target="_blank"><shane@ronan-online.com></a><br>
<b>To: </b>"Michael Thomas" <a class="moz-txt-link-rfc2396E" href="mailto:mike@mtcc.com" target="_blank"><mike@mtcc.com></a><br>
<b>Cc: </b><a class="moz-txt-link-abbreviated" href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a><br>
<b>Sent: </b>Monday, October 3, 2022 9:54:07 PM<br>
<b>Subject: </b>Re: FCC chairwoman: Fines alone aren't enough
(Robocalls)<br>
<br>
<div dir="ltr">The issue isn't which 'prefixes' I accept from
my customers, but which 'prefixes' I accept from the people
I peer with, because it's entirely dynamic and without a
doing a database dip on EVERY call, I have to assume that my
peer or my peers customer or my peers peer is doing the
right thing.
<div><br>
</div>
<div>I can't simply block traffic from a peer carrier, it's
not allowed, so there has to be some mechanism to mark
that a prefix should be allowed, which is what Shaken/Stir
does.</div>
<div><br>
</div>
<div>Shane</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Oct 3, 2022 at
7:05 PM Michael Thomas <<a href="mailto:mike@mtcc.com" target="_blank" class="moz-txt-link-freetext">mike@mtcc.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">The problem has always
been solvable at the ingress provider. The <br>
problem was that there was zero to negative incentive to
do that. You <br>
don't need an elaborate PKI to tell the ingress provider
which prefixes <br>
customers are allow to assert. It's pretty analogous to
when submission <br>
authentication was pretty nonexistent with email... there
was no <br>
incentive to not be an open relay sewer. Unlike email
spam, SIP <br>
signaling is pretty easy to determine whether it's spam.
All it needed <br>
was somebody to force regulation which unlike email there
was always <br>
jurisdiction with the FCC.<br>
<br>
Mike<br>
<br>
On 10/3/22 3:13 PM, Jawaid Bazyar wrote:<br>
> We're talking about blocking other carriers.<br>
><br>
> On 10/3/22, 3:05 PM, "Michael Thomas" <<a href="mailto:mike@mtcc.com" target="_blank" class="moz-txt-link-freetext">mike@mtcc.com</a>>
wrote:<br>
><br>
> On 10/3/22 1:54 PM, Jawaid Bazyar wrote:<br>
> > Because it's illegal for common carriers to
block traffic otherwise.<br>
><br>
> Wait, what? It's illegal to police their own
users?<br>
><br>
> Mike<br>
><br>
> ><br>
> > On 10/3/22, 2:53 PM, "NANOG on behalf of
Michael Thomas" <nanog-bounces+jbazyar=<a href="mailto:verobroadband.com@nanog.org" target="_blank" class="moz-txt-link-freetext">verobroadband.com@nanog.org</a>
on behalf of <a href="mailto:mike@mtcc.com" target="_blank" class="moz-txt-link-freetext">mike@mtcc.com</a>>
wrote:<br>
> ><br>
> ><br>
> > On 10/3/22 1:34 PM, Sean Donelan
wrote:<br>
> > > 'Fines alone aren't enough:' FCC
threatens to blacklist voice<br>
> > > providers for flouting robocall
rules<br>
> > ><br>
> > > <a href="https://www.cyberscoop.com/fcc-robocall-fine-database-removal/" rel="noreferrer" target="_blank" class="moz-txt-link-freetext">https://www.cyberscoop.com/fcc-robocall-fine-database-removal/</a><br>
> > ><br>
> > > [...]<br>
> > > “This is a new era. If a provider
doesn’t meet its obligations under<br>
> > > the law, it now faces expulsion
from America’s phone networks. Fines<br>
> > > alone aren’t enough,” FCC
chairwoman Jessica Rosenworcel said in a<br>
> > > statement accompanying the
announcement. “Providers that don’t follow<br>
> > > our rules and make it easy to
scam consumers will now face swift<br>
> > > consequences.”<br>
> > ><br>
> > > It’s the first such enforcement
action by the agency to reduce the<br>
> > > growing problem of robocalls
since call ID verification protocols<br>
> > > known as “STIR/SHAKEN” went fully
into effect this summer.<br>
> > > [...]<br>
> ><br>
> > Why did we need to wait for
STIR/SHAKEN to do this?<br>
> ><br>
> > Mike<br>
> ><br>
><br>
><br>
</blockquote>
</div>
</div>
<br>
</div>
</blockquote>
</div><br></div></body></html>