<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">I suppose but that also means they need to go back and figure out which prefixes to allow, since historically hasn’t been tracked.</div><div dir="ltr"><br></div><div dir="ltr">Also, how does the man in the middle since most calls don’t go from originating carrier to terminating carrier, know if the originator did their job?</div><div dir="ltr"><br><blockquote type="cite">On Oct 4, 2022, at 4:50 PM, Michael Thomas <mike@mtcc.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p><br>
</p>
<div class="moz-cite-prefix">On 10/4/22 1:40 PM,
<a class="moz-txt-link-abbreviated" href="mailto:sronan@ronan-online.com">sronan@ronan-online.com</a> wrote:<br>
</div>
<blockquote type="cite" cite="mid:BC2FFC0F-7696-4007-9C2F-ACCAF20B9230@ronan-online.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Except the pstn DB isn’t distributed like DNS is.</div>
</blockquote>
<p><br>
</p>
<p>Yes, I had forgot about "dip" in that sense. But an originating
provider doesn't need to do a dip to know that the calling number
routes to itself. I've been talking about the calling provider not
the called provider all along.</p>
<p>Mike<br>
</p>
<blockquote type="cite" cite="mid:BC2FFC0F-7696-4007-9C2F-ACCAF20B9230@ronan-online.com">
<div dir="ltr"><br>
<blockquote type="cite">On Oct 4, 2022, at 2:40 PM, Michael
Thomas <a class="moz-txt-link-rfc2396E" href="mailto:mike@mtcc.com"><mike@mtcc.com></a> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p><br>
</p>
<div class="moz-cite-prefix">On 10/4/22 11:21 AM, Shane Ronan
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAJ_LqoEoCeGVfsHQg3XHd6eaOVwuZdPYTx_kC4MmCZ5pWuDs_g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div dir="ltr">Except the cost to do the data dips to
determine the authorization isn't "free".</div>
</blockquote>
<p>Since every http request in the universe requires a
"database dip" and they are probably a billion times more
common, that doesn't seem like a very compelling concern.</p>
<p>Mike<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CAJ_LqoEoCeGVfsHQg3XHd6eaOVwuZdPYTx_kC4MmCZ5pWuDs_g@mail.gmail.com"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Oct 4, 2022 at
2:18 PM Michael Thomas <<a href="mailto:mike@mtcc.com" moz-do-not-send="true" 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">
<div>
<p><br>
</p>
<div>On 10/4/22 6:07 AM, Mike Hammett wrote:<br>
</div>
<blockquote type="cite">
<div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">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 name="x"></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 type="cite">
<div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">
<div><br>
-----<br>
Mike Hammett<br>
Intelligent Computing Solutions<br>
<a href="http://www.ics-il.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">http://www.ics-il.com</a><br>
<br>
Midwest-IX<br>
<a href="http://www.midwest-ix.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">http://www.midwest-ix.com</a><span name="x"></span><br>
</div>
<br>
<hr id="m_5695148775473131614zwchr">
<div style="color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From:
</b>"Shane Ronan" <a href="mailto:shane@ronan-online.com" target="_blank" moz-do-not-send="true"><shane@ronan-online.com></a><br>
<b>To: </b>"Michael Thomas" <a href="mailto:mike@mtcc.com" target="_blank" moz-do-not-send="true"><mike@mtcc.com></a><br>
<b>Cc: </b><a href="mailto:nanog@nanog.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" 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" moz-do-not-send="true" 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" moz-do-not-send="true" class="moz-txt-link-freetext">verobroadband.com@nanog.org</a>
on behalf of <a href="mailto:mike@mtcc.com" target="_blank" moz-do-not-send="true" 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" moz-do-not-send="true" 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>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</blockquote>
</div></blockquote></body></html>